[sisyphus] Кто держит /tmp/.private?

[sisyphus] Кто держит /tmp/.private?

[Alexei V. Mezin]

Как-то после очередного апдейта Сиизфа заметил, что при загрузке 
раздается ругать на невозможность удалить каталоги в /tmp/.private 
Заглянул туда, действительно есть каталоги по именам юзеров. И 
действительно, их невозможно удалить. Пермишены выставлены как надо, 
более того, от рута сменил владельца/группу на root/root, проверил 
lsattr'ом всякие хитрые атрибуты. Все нормально, а удалить не дает:
[root@threebears .private]# rm -rf ./zmei/
rm: невозможно удалить каталог `./zmei/': Operation not permitted

Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?

Re: [sisyphus] Кто держит /tmp/.private?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

On Thu, Dec 08, 2005 at 01:38:51AM +0300, Alexei V. Mezin wrote:
> Как-то после очередного апдейта Сиизфа заметил, что при загрузке 
> раздается ругать на невозможность удалить каталоги в /tmp/.private 
> Заглянул туда, действительно есть каталоги по именам юзеров. И 
> действительно, их невозможно удалить. Пермишены выставлены как надо, 
> более того, от рута сменил владельца/группу на root/root, проверил 
> lsattr'ом всякие хитрые атрибуты. Все нормально, а удалить не дает:
> [root@threebears .private]# rm -rf ./zmei/
> rm: невозможно удалить каталог `./zmei/': Operation not permitted
> 
> Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?

http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Кто держит /tmp/.private?

[Alexei V. Mezin]

Dmitry V. Levin пишет:

>> Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?
> 
> http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"
Спасибо, разобрался.
Но возник вопрос: а в системе сейчас предусмотрены автоматические 
средства чистки /tmp/.private? А то завел юзера в тестовых целях, через 
день удалил, а каталог остался навечно. И при старте системы очистка 
/tmp ругается, нестрашно, но тоже нехорошо.

-- 
Alexei V. Mezin

NT-MDT Co.
Phone: 095-913-5736
Fax: 095-913-573
Email: mezin@ntmdt.ru
URL: http://www.ntmdt.com

A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Andrei Bulava]

Alexei V. Mezin wrote:
> Dmitry V. Levin пишет:
> 
>>> Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?
>>
>>
>> http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"
> 
> Спасибо, разобрался.
> Но возник вопрос: а в системе сейчас предусмотрены автоматические
> средства чистки /tmp/.private? А то завел юзера в тестовых целях, через
> день удалил, а каталог остался навечно. И при старте системы очистка
> /tmp ругается, нестрашно, но тоже нехорошо.

У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(

Конечно, расширение знаний простого пользователя GNU/Linux - это
благородная цель, но вот оправданная ли в данном случае? У меня нет
возможности монтировать /tmp на tmpfs и нет желания ещё каким-то образом
обходить эти грабли с /tmp/.private (видимо, лезть в исходные коды
скриптов, заведующих автоматической чисткой /tmp во время старта системы).

Добрее нужно быть к коллегам (про пользователей вообще молчу)... :-]

-- 
// AB1002-UANIC

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Led]

В сообщении от Четверг 08 Декабрь 2005 14:58 Andrei Bulava написал(a):
> Alexei V. Mezin wrote:
> > Dmitry V. Levin пишет:
> >>> Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?
> >>
> >> http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"
> >
> > Спасибо, разобрался.
> > Но возник вопрос: а в системе сейчас предусмотрены автоматические
> > средства чистки /tmp/.private? А то завел юзера в тестовых целях, через
> > день удалил, а каталог остался навечно. И при старте системы очистка
> > /tmp ругается, нестрашно, но тоже нехорошо.
>
> У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(
>
> Конечно, расширение знаний простого пользователя GNU/Linux - это
> благородная цель, но вот оправданная ли в данном случае? У меня нет
> возможности монтировать /tmp на tmpfs и нет желания ещё каким-то образом
> обходить эти грабли с /tmp/.private (видимо, лезть в исходные коды
> скриптов, заведующих автоматической чисткой /tmp во время старта системы).
>
> Добрее нужно быть к коллегам (про пользователей вообще молчу)... :-]

А установка TEMP=~/tmp где-нибудь в ~/.bashrc не помогает?

-- 
Led.

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Epiphanov Sergei]

В сообщении от Thursday 08 December 2005 16:11 Led написал(a):
> > У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(
> >
> > Конечно, расширение знаний простого пользователя GNU/Linux - это
> > благородная цель, но вот оправданная ли в данном случае? У меня нет
> > возможности монтировать /tmp на tmpfs и нет желания ещё каким-то образом
> > обходить эти грабли с /tmp/.private (видимо, лезть в исходные коды
> > скриптов, заведующих автоматической чисткой /tmp во время старта
> > системы).
> >
> > Добрее нужно быть к коллегам (про пользователей вообще молчу)... :-]
>
> А установка TEMP=~/tmp где-нибудь в ~/.bashrc не помогает?

Для этого надо быть выше, чем просто пользователь. Надо уже знать про то, что 
некоторые переменные среды оказывают влияние, потом какие поимённо и на что 
влияют. Спросите у пользователя про те же CFLAGS, CXXFLAGS, LD_LIBRARY_PATH 
и т.д. Интересно, кто сможет перечислить все системные переменные (вроде 
TMP, TMPDIR, CFLAGS, LDFLAGS, PS1, PS2, PS4, ...) и на что они влияют?

-- 
С уважением, Епифанов Сергей

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Led]

В сообщении от Четверг 08 Декабрь 2005 15:21 Epiphanov Sergei написал(a):
> В сообщении от Thursday 08 December 2005 16:11 Led написал(a):
> > > У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(
> > >
> > > Конечно, расширение знаний простого пользователя GNU/Linux - это
> > > благородная цель, но вот оправданная ли в данном случае? У меня нет
> > > возможности монтировать /tmp на tmpfs и нет желания ещё каким-то
> > > образом обходить эти грабли с /tmp/.private (видимо, лезть в исходные
> > > коды скриптов, заведующих автоматической чисткой /tmp во время старта
> > > системы).
> > >
> > > Добрее нужно быть к коллегам (про пользователей вообще молчу)... :-]
> >
> > А установка TEMP=~/tmp где-нибудь в ~/.bashrc не помогает?
>
> Для этого надо быть выше, чем просто пользователь. Надо уже знать про то,
> что некоторые переменные среды оказывают влияние, потом какие поимённо и на
> что влияют. Спросите у пользователя про те же CFLAGS, CXXFLAGS,
> LD_LIBRARY_PATH и т.д. Интересно, кто сможет перечислить все системные
> переменные (вроде TMP, TMPDIR, CFLAGS, LDFLAGS, PS1, PS2, PS4, ...) и на
> что они влияют?

А разве правка /etc/skel - это пользовательская операция?

А разработчик - уже не пользователь? И этот разработчик ничего не знает про 
CFLAGS?

-- 
Led.

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Andrew Borodin]

On Thu, Dec 08, 2005 at 04:21:56PM +0300, Epiphanov Sergei wrote:
> Спросите у пользователя про те же CFLAGS, CXXFLAGS, 
> LD_LIBRARY_PATH и т.д. Интересно, кто сможет перечислить все 
> системные переменные (вроде TMP, TMPDIR, CFLAGS, LDFLAGS, PS1, 
> PS2, PS4, ...) и на что они влияют?

CFLAGS, CXXFLAGS, LDFLAGS в повседневной деятельности 
пользователя, вроде, не участвуют.

-- 

С уважением,
А. Бородин.

[sisyphus] [JT]Re: A: заботливо уложенные грабли pam_mktemp

[Alexei V. Mezin]

Andrei Bulava пишет:

> У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(
> 
> (видимо, лезть в исходные коды
> скриптов, заведующих автоматической чисткой /tmp во время старта системы).
Да скрипты поправить дело не то чтоб не хитрое, но подъемное. Тут вопрос 
идеологический. Зачем так сделали. И как теперь "идеологически 
правильно" возникшие грабли переступать.


> 
> Добрее нужно быть к коллегам (про пользователей вообще молчу)... :-]
> 
О пользователях, в свете свежевышедшего Компакт 3.0. А там как сделано? 
Тоже стартовые скрипты матерятся про невозможность удалить директории в 
/tmp? Что рассказывать тем, кто поставит себе Компакт и получит (если 
там так же) проблему? Рассказать им, где и как они должны прочитать про 
lsattr, bash programming, sed/awk/grep/xargs, perl и т.п.? Или 
рассказать, что АЛЬТ такой вот забавный дистрибутив?


-- 
Alexei V. Mezin

NT-MDT Co.
Phone: 095-913-5736
Fax: 095-913-573
Email: mezin@ntmdt.ru
URL: http://www.ntmdt.com

Re: [sisyphus] [JT] A: заботливо уложенные грабли pam_mktemp

[Andrei Bulava]

Alexei V. Mezin wrote:
> Andrei Bulava пишет:

>> Добрее нужно быть к коллегам (про пользователей вообще молчу)... 
>> :-]
>> 
> О пользователях, в свете свежевышедшего Компакт 3.0. А там как 
> сделано? Тоже стартовые скрипты матерятся про невозможность удалить 
> директории в /tmp?

Не знаю.

> Что рассказывать тем, кто поставит себе Компакт и получит (если там
> так же) проблему? Рассказать им, где и как они должны прочитать про
> lsattr, bash programming, sed/awk/grep/xargs, perl и т.п.?

:-)

> Или рассказать, что АЛЬТ такой вот забавный дистрибутив?

Можете рассказывать, что некто abulava@ не написал рапорт о граблях с
pam_mktemp в Sisyphus, когда это было ещё возможно. Увы и ах :-\

-- 
// AB1002-UANIC

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

On Thu, Dec 08, 2005 at 02:58:24PM +0200, Andrei Bulava wrote:
> Alexei V. Mezin wrote:
> > Dmitry V. Levin пишет:
> > 
> >>> Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?
> >>
> >> http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"
> > 
> > Спасибо, разобрался.
> > Но возник вопрос: а в системе сейчас предусмотрены автоматические
> > средства чистки /tmp/.private? А то завел юзера в тестовых целях, через
> > день удалил, а каталог остался навечно. И при старте системы очистка
> > /tmp ругается, нестрашно, но тоже нехорошо.
> 
> У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(

Какой именно вопрос, зачем EXT2_APPEND_FL или почему ругается?
У меня есть ответ на любой из этих вопросов. :)

> Конечно, расширение знаний простого пользователя GNU/Linux - это
> благородная цель, но вот оправданная ли в данном случае?

В данном случае это не при чём.

> У меня нет возможности монтировать /tmp на tmpfs

Жаль.  swap+tmpfs - неплохая комбинация (к которой наши стартовые скрипты
пока что ещё не очень готовы).


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Michael Shigorin]

On Thu, Dec 08, 2005 at 04:49:32PM +0300, Dmitry V. Levin wrote:
> > У меня нет возможности монтировать /tmp на tmpfs
> Жаль.  swap+tmpfs - неплохая комбинация (к которой наши
> стартовые скрипты пока что ещё не очень готовы).

Ну, используется, но это далеко не все ответы.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

* Dmitry V. Levin <ldv@> [051208 16:51]:
> Жаль.  swap+tmpfs - неплохая комбинация (к которой наши
> стартовые скрипты пока что ещё не очень готовы).
Почему не готовы?  Я так живу вроде...

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Thu, Dec 08, 2005 at 04:57:35PM +0300, Alexey I. Froloff wrote:
> > стартовые скрипты пока что ещё не очень готовы).
> Почему не готовы?  Я так живу вроде...
+1

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Всё просто, на самом деле. Те кто могут что-то сделать, _естественно_
продвигают свои предпочтения. Это разумно и правильно, ибо их мнение стоит
несколько больше, чем мнение тех, кто не в состоянии сделать (или оплатить
разработку).
		-- mithraen in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: A: заботливо уложенные грабли pam_mktemp

[Andrei Bulava]

Andrey Rahmatullin wrote:
> On Thu, Dec 08, 2005 at 04:57:35PM +0300, Alexey I. Froloff wrote:
> 
>>>стартовые скрипты пока что ещё не очень готовы).
>>
>>Почему не готовы?  Я так живу вроде...
> 
> +1

HOWTO напишите, пожалуйста.

-- 
// AB1002-UANIC

[sisyphus] Re: A: заботливо уложенные грабли pam_mktemp

[Michael Shigorin]

On Thu, Dec 08, 2005 at 07:56:28PM +0200, Andrei Bulava wrote:
> >>>стартовые скрипты пока что ещё не очень готовы).
> >>Почему не готовы?  Я так живу вроде...
> > +1
> HOWTO напишите, пожалуйста.

/dev/shm /tmp tmpfs size=384m 0 0

(при --bind'анье /tmp и /var/tmp играл роль какой-то порядок
или что-то ещё отламывалось -- подробней сейчас не скажу)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: A: заботливо уложенные грабли pam_mktemp

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Thu, Dec 08, 2005 at 08:06:40PM +0200, Michael Shigorin wrote:
> On Thu, Dec 08, 2005 at 07:56:28PM +0200, Andrei Bulava wrote:
> > >>>стартовые скрипты пока что ещё не очень готовы).
> > >>Почему не готовы?  Я так живу вроде...
> > > +1
> > HOWTO напишите, пожалуйста.
> 
> /dev/shm /tmp tmpfs size=384m 0 0

Для целей тестовой пересборки Сизифа tmpfs монтируется из рассчёта
tmpfs /tmp tmpfs nosuid,nr_inodes=1m,size=2g 0 0
на каждый CPU (пересборка ведётся в режиме --nprocs=1).

Мораль: параметры монтирования /tmp существенно зависят от решаемых задач.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: A: заботливо уложенные грабли pam_mktemp

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 279 bytes --]

On Fri, Dec 09, 2005 at 02:58:55AM +0300, Dmitry V. Levin wrote:
> Мораль: параметры монтирования /tmp существенно зависят от
> решаемых задач.

А дефолты -- одни на всех.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

On Thu, Dec 08, 2005 at 10:17:44PM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 08, 2005 at 04:57:35PM +0300, Alexey I. Froloff wrote:
> > > стартовые скрипты пока что ещё не очень готовы).
> > Почему не готовы?  Я так живу вроде...
> +1

startup-0.9.8.4-alt1:
- init.d/halt:
  + Unmount non-/dev tmpfs filesystems before deactivating swap.

Без этого tmpfs на swap размещать опасно: при выключении swap
переполненный файлами tmpfs может вызвать катастрофическую нехватку
памяти с непредсказуемыми последствиями.

2vsu: Интересно, какие ядра как себя в этой ситуации ведут?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

* Dmitry V. Levin <ldv@> [051209 02:52]:
> Без этого tmpfs на swap размещать опасно: при выключении swap
> переполненный файлами tmpfs может вызвать катастрофическую нехватку
> памяти с непредсказуемыми последствиями.
А, ну да.  Просто я забыл уже когда выключал домашний тазик не по
скачку питания...

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Sviataslau Svirydau]

Dmitry V. Levin wrote:

>startup-0.9.8.4-alt1:
>- init.d/halt:
>  + Unmount non-/dev tmpfs filesystems before deactivating swap.
>
>Без этого tmpfs на swap размещать опасно: при выключении swap
>переполненный файлами tmpfs может вызвать катастрофическую нехватку
>памяти с непредсказуемыми последствиями.
>
>2vsu: Интересно, какие ядра как себя в этой ситуации ведут?
>  
>
Еще интересно как себя поведет swsusp2 во время усыпания в своп при
наличии там файлов tmpfs? ;)

-- 
Best regards,
Sviatoslav Sviridov

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On Fri, Dec 09, 2005 at 09:56:18AM +0200, Sviataslau Svirydau wrote:
> Еще интересно как себя поведет swsusp2 во время усыпания в своп при
> наличии там файлов tmpfs? ;)
Нормально поведет.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Посмотрите MTU на интерфейсах.
Фрагментация IP-пакетов разрешена?

Всё, мой телепатический модуль перегрелся.
		-- alb in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Alex Yustasov]

On Fri, Dec 09, 2005 at 09:56:18AM +0200, Sviataslau Svirydau wrote:
> Еще интересно как себя поведет swsusp2 во время усыпания в своп при
> наличии там файлов tmpfs? ;)
Было 
# mount
shmfs on /dev/shm type tmpfs (rw)
# df
shmfs                 118M     0  118M   0% /dev/shm

В fstab ничего не было, это udev?

Добавил в fstab 
/dev/shm /tmp tmpfs size=256m 0 0

Сейчас 
# mount
shmfs on /dev/shm type tmpfs (rw)
/dev/shm on /tmp type tmpfs (rw,size=256m)

# df
/dev/shm              256M  8.0K  256M   1% /tmp
shmfs                 118M     0  118M   0% /dev/shm

Swsusp2 нормально работает, было бы место в swap свободное. :) Ядро 2.6.14.
Попробовал забить весь /tmp, оставалось 11M. Swsusp2 сжал image до 21M, заснул
и проснулся нормально. Причем при ImageSizeLimit nocache - image получался
около 50M.

# swapon -s
Filename                                Type            Size    Used    Priority
/dev/hda5                               partition       337324  39776   -1

-- 
    Alex Yustasov

[mocp] 00:44[02:40]  Entwine -  DiEversity -  Bitter Sweet

[sisyphus] Re: A: заботливо уложенные грабли pam_mktemp

[Andrei Bulava]

Dmitry V. Levin wrote:
> On Thu, Dec 08, 2005 at 02:58:24PM +0200, Andrei Bulava wrote:
> 
>>Alexei V. Mezin wrote:
>>
>>>Но возник вопрос: а в системе сейчас предусмотрены автоматические
>>>средства чистки /tmp/.private?
>>
>>У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(
> 
> 
> Какой именно вопрос, зачем EXT2_APPEND_FL или почему ругается?
> У меня есть ответ на любой из этих вопросов. :)

Первое: почему автоматически не чистится /tmp? Вопросы про
EXT2_APPEND_FL и ругательства больше относятся к моим интересам
разработчика, но уж никак не пользователя.

Второе: где почитать о методике атаки на файлы в /tmp без флага
EXT2_APPEND_FL?

>>Конечно, расширение знаний простого пользователя GNU/Linux - это
>>благородная цель, но вот оправданная ли в данном случае?
> 
> В данном случае это не при чём.

Т.е. здесь имеет место обычный недосмотр?

-- 
// AB1002-UANIC

Re: [sisyphus] Re: A: заботливо уложенные грабли pam_mktemp

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]

On Thu, Dec 08, 2005 at 04:14:57PM +0200, Andrei Bulava wrote:
> Dmitry V. Levin wrote:
> > On Thu, Dec 08, 2005 at 02:58:24PM +0200, Andrei Bulava wrote:
> >>Alexei V. Mezin wrote:
> >>
> >>>Но возник вопрос: а в системе сейчас предусмотрены автоматические
> >>>средства чистки /tmp/.private?
> >>
> >>У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(
> > 
> > Какой именно вопрос, зачем EXT2_APPEND_FL или почему ругается?
> > У меня есть ответ на любой из этих вопросов. :)
> 
> Первое: почему автоматически не чистится /tmp?

Почему вы сделали такой вывод?
/etc/rc.d/scripts/cleanup чистит /tmp при загрузке, если установлен
параметр CLEAN_TMP.
stmpclean чистит в том числе и /tmp по крону.

> Вопросы про
> EXT2_APPEND_FL и ругательства больше относятся к моим интересам
> разработчика, но уж никак не пользователя.

И что это за вопросы?

> Второе: где почитать о методике атаки на файлы в /tmp без флага
> EXT2_APPEND_FL?

История появления EXT2_APPEND_FL на /tmp/.private довольно давняя.
Модуль pam_mktemp появился задолго до замены tmpwatch на stmpclean.
tmpwatch имел много недостатков, и одним из них было удаление файлов,
принадлежащих root.  Как следствие, каталог $TMPDIR мог быть удалён
раньше, чем завершился последний использующий его процесс.  Для решения
этой и других сходных проблем на каталог /tmp/.private добавляется
EXT2_APPEND_FL.  Сейчас риск, что каталог /tmp/.private/<user> исчезнет
досрочно, не так велик, как раньше, так что в принципе можно рассматривать
возможность отказаться от установки EXT2_APPEND_FL на /tmp/.private;
некоторые файловые системы, включая tmpfs, вообще не поддерживают
EXT2_APPEND_FL.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: A: заботливо уложенные грабли pam_mktemp

[Sergey]

On Thursday 08 December 2005 18:28, Dmitry V. Levin wrote:

> stmpclean чистит в том числе и /tmp по крону.

Забывая, правда, про каталоги...

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] Re: A: заботливо уложенные грабли pam_mktemp

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

On Thu, Dec 08, 2005 at 06:51:05PM +0400, Sergey wrote:
> On Thursday 08 December 2005 18:28, Dmitry V. Levin wrote:
> 
> > stmpclean чистит в том числе и /tmp по крону.
> 
> Забывая, правда, про каталоги...

Пожалуйста, будьте конкретнее.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] A: заботливо уложенные грабли pam_mktemp

[Andrei Bulava]

Dmitry V. Levin wrote:
> On Thu, Dec 08, 2005 at 04:14:57PM +0200, Andrei Bulava wrote:
>
>>Первое: почему автоматически не чистится /tmp?
> 
> Почему вы сделали такой вывод?

По сообщениям об ошибках от /etc/rc.d/scripts/cleanup и нижеследующему:

# last -5 reboot
reboot   system boot  2.6.12-std26-up- Thu Dec  8 11:01         (05:47)
reboot   system boot  2.6.12-std26-up- Thu Dec  8 10:56         (00:03)

wtmp begins Thu Dec  1 04:02:02 2005
# last -5 raven
raven    pts/11       localhost        Mon Dec  5 13:56 - 14:25 (00:28)
raven    pts/9        localhost        Fri Dec  2 13:23 - 16:52 (03:28)

wtmp begins Thu Dec  1 04:02:02 2005
# ls -al /tmp/.private/raven/orbit-raven
total 8
drwx------ 2 raven raven 4096 Aug  8 20:16 .
drwxrwx--T 8 root  raven 4096 Aug 30 19:14 ..
srwxr-xr-x 1 raven raven    0 Aug  5 12:45 linc-22a0-0-619505dfd4a2a

<skip />

>>Второе: где почитать о методике атаки на файлы в /tmp без флага
>>EXT2_APPEND_FL?

<skip />

> в принципе можно рассматривать
> возможность отказаться от установки EXT2_APPEND_FL на /tmp/.private;
> некоторые файловые системы, включая tmpfs, вообще не поддерживают
> EXT2_APPEND_FL.

Спасибо за отличный ответ. Если так, и будущее за tmpfs, давайте не
создавать себе трудностей в настоящем?

+1 за отказ от установки EXT2_APPEND_FL на /tmp/.private

-- 
// AB1002-UANIC

Re: [sisyphus] A: заботливо уложенные грабли pam_mktemp

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

On Thu, Dec 08, 2005 at 04:55:01PM +0200, Andrei Bulava wrote:
[...]
> # ls -al /tmp/.private/raven/orbit-raven
> total 8
> drwx------ 2 raven raven 4096 Aug  8 20:16 .
> drwxrwx--T 8 root  raven 4096 Aug 30 19:14 ..
> srwxr-xr-x 1 raven raven    0 Aug  5 12:45 linc-22a0-0-619505dfd4a2a

Так я об этом уже говорил, /etc/rc.d/scripts/cleanup глючит, а stmpclean
не должен это трогать, поскольку
$ man stmpclean |colcrt |grep -w root
     The stmpclean utility never removes files or directories owned by root.

> > в принципе можно рассматривать
> > возможность отказаться от установки EXT2_APPEND_FL на /tmp/.private;
> > некоторые файловые системы, включая tmpfs, вообще не поддерживают
> > EXT2_APPEND_FL.
> 
> Спасибо за отличный ответ. Если так, и будущее за tmpfs, давайте не
> создавать себе трудностей в настоящем?
> 
> +1 за отказ от установки EXT2_APPEND_FL на /tmp/.private

Спасибо за мнение, будем думать.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Michael Shigorin]

On Thu, Dec 08, 2005 at 02:58:24PM +0200, Andrei Bulava wrote:
> >>> Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?
> >> http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"
> У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(

Ещё #8030.

> Добрее нужно быть к коллегам (про пользователей вообще молчу)... :-]

Думать надо, когда дефолты трогаются.  И не стесняться спросить
коллег, поскольку всё не предусмотришь.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: A: заботливо уложенные грабли pam_mktemp (was: Re: [sisyphus] Кто держит /tmp/.private?)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

On Thu, Dec 08, 2005 at 03:55:18PM +0200, Michael Shigorin wrote:
> On Thu, Dec 08, 2005 at 02:58:24PM +0200, Andrei Bulava wrote:
> > >>> Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?
> > >> http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"
> > У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(
> 
> Ещё #8030.

Я не буду откатывать это изменение.  Я готов рассматривать предложения
по конфигурированию самого pam_mktemp.  Предложения по отказу от
pam_mktemp мне не интересны, просьба не тратить время на них.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] defaults, блин, без головы (was: A: заботливо уложенные грабли pam_mktemp)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

On Thu, Dec 08, 2005 at 05:01:30PM +0300, Dmitry V. Levin wrote:
> > > >>> Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?
> > > >> http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"
> > > У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(
> > Ещё #8030.
> Я не буду откатывать это изменение.

Обоснование добавил в багу (да и, кажется, ранее почтой сюда).
Какого-либо обоснования такого _умолчания_ не видел _вообще_.

> Я готов рассматривать предложения по конфигурированию самого
> pam_mktemp.  Предложения по отказу от pam_mktemp мне не
> интересны, просьба не тратить время на них.

Что ты предлагаешь для системного возврата к $HOME/tmp, кроме
смены дистрибутива? (нет, не на Owl -- почему-то подозреваю, что
там то же сделано; вот только там это, может быть, уместней)

Пойми меня правильно -- работало; сломали; нэ работает.  Я могу
полезть разбираться с изменениями, но нахожу такой подход
неправильным в корне.

2 devel: уважайте умолчания.  Эти треклятые зверушки значат
слишком много, чтобы так с ними играться -- и кусаются.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] defaults, блин, без головы (was: A: заботливо уложенные грабли pam_mktemp)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

On Thu, Dec 08, 2005 at 04:19:41PM +0200, Michael Shigorin wrote:
> On Thu, Dec 08, 2005 at 05:01:30PM +0300, Dmitry V. Levin wrote:
> > > > >>> Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?
> > > > >> http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"
> > > > У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(
> > > Ещё #8030.
> > Я не буду откатывать это изменение.
> 
> Обоснование добавил в багу (да и, кажется, ранее почтой сюда).
> Какого-либо обоснования такого _умолчания_ не видел _вообще_.

Жаль, ты много пропустил.  Было обсуждение, которое вылилось в #6814;
были ещё какие-то следы обсуждения, поищи сам.

> > Я готов рассматривать предложения по конфигурированию самого
> > pam_mktemp.  Предложения по отказу от pam_mktemp мне не
> > интересны, просьба не тратить время на них.
> 
> Что ты предлагаешь для системного возврата к $HOME/tmp, кроме
> смены дистрибутива? (нет, не на Owl -- почему-то подозреваю, что
> там то же сделано; вот только там это, может быть, уместней)

Об этом тоже рассказывалось; есть /etc/pam.d/system-auth, ~/.bash_profile
и прочие подобные средства настройки на разных уровнях.

> Пойми меня правильно -- работало; сломали; нэ работает.

Некоторые считают иначе: не хватало -> реализовали -> пользуемся.

Твой подход деструктивен, поскольку не учитывает других точек зрения, и,
сделовательно, никуда не ведёт.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: defaults, блин, без головы

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]

On Thu, Dec 08, 2005 at 07:31:57PM +0300, Dmitry V. Levin wrote:
> > > > Ещё #8030.
> > > Я не буду откатывать это изменение.
> > Обоснование добавил в багу (да и, кажется, ранее почтой сюда).
> > Какого-либо обоснования такого _умолчания_ не видел _вообще_.
> Жаль, ты много пропустил.  Было обсуждение, которое вылилось в #6814;

Точно, ещё помнил, что пришёл к шапочному разбору.

Дим, согласись, "доводов много, чтобы их здесь приводить"
-- это "на авторитете".  Работает, пока ничего не ломается.
Иначе ломается авторитет.

> были ещё какие-то следы обсуждения, поищи сам.

Спасибо, попробую.

> > Что ты предлагаешь для системного возврата к $HOME/tmp, кроме
> > смены дистрибутива?
> Об этом тоже рассказывалось; есть /etc/pam.d/system-auth,
> ~/.bash_profile и прочие подобные средства настройки на разных
> уровнях.

Все перечисленные уровни выше (или ниже, смотря как смотреть)
пользователя/администратора, не являющегося экспертом в ALT Linux.
Навязывание статуса эксперта IMTCO контрпродуктивно.

(нет, наши пользователи этого не почувствуют, но это неправильно)

> > Пойми меня правильно -- работало; сломали; нэ работает.
> Некоторые считают иначе: не хватало -> реализовали -> пользуемся.
> Твой подход деструктивен, поскольку не учитывает других точек
> зрения, и, сделовательно, никуда не ведёт.

Я учитываю другую точку зрения в меру видения её доводов.
Боюсь, большинство каковых даже не представляю.

В остальном мой подход по крайней мере публично обоснован
и зиждется на вполне прикладных ситуациях.

-- 
Если бы еще "простой пользователь" всегда понимал, что он "простой
пользователь", а не "эксперт", -- это было бы замечательно.
                -- aen in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: defaults, блин, без головы

[Led]

В сообщении от Четверг 08 Декабрь 2005 19:54 Michael Shigorin написал(a):
> On Thu, Dec 08, 2005 at 07:31:57PM +0300, Dmitry V. Levin wrote:
> > > > > Ещё #8030.
> > > >
> > > > Я не буду откатывать это изменение.
> > >
> > > Обоснование добавил в багу (да и, кажется, ранее почтой сюда).
> > > Какого-либо обоснования такого _умолчания_ не видел _вообще_.
> >
> > Жаль, ты много пропустил.  Было обсуждение, которое вылилось в #6814;
>
> Точно, ещё помнил, что пришёл к шапочному разбору.
>
> Дим, согласись, "доводов много, чтобы их здесь приводить"
> -- это "на авторитете".  Работает, пока ничего не ломается.
> Иначе ломается авторитет.
>
> > были ещё какие-то следы обсуждения, поищи сам.
>
> Спасибо, попробую.
>
> > > Что ты предлагаешь для системного возврата к $HOME/tmp, кроме
> > > смены дистрибутива?
> >
> > Об этом тоже рассказывалось; есть /etc/pam.d/system-auth,
> > ~/.bash_profile и прочие подобные средства настройки на разных
> > уровнях.
>
> Все перечисленные уровни выше (или ниже, смотря как смотреть)
> пользователя/администратора, не являющегося экспертом в ALT Linux.

Может в альтераторе поддержку сделать?

-- 
Led.

Re: [sisyphus] system-auth: edit vs control

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Thu, Dec 08, 2005 at 07:54:09PM +0200, Michael Shigorin wrote:
> > > Что ты предлагаешь для системного возврата к $HOME/tmp, кроме
> > > смены дистрибутива?
> > Об этом тоже рассказывалось; есть /etc/pam.d/system-auth,
> > ~/.bash_profile и прочие подобные средства настройки на разных
> > уровнях.
> 
> Все перечисленные уровни выше (или ниже, смотря как смотреть)
> пользователя/администратора, не являющегося экспертом в ALT Linux.
> Навязывание статуса эксперта IMTCO контрпродуктивно.

Ты считаешь, что наличие скрипта, редактирующего system-auth
(т.е. control) существенно снизит порог вхождения?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] system-auth: edit vs control

[Andrei Bulava]

Dmitry V. Levin wrote:
> On Thu, Dec 08, 2005 at 07:54:09PM +0200, Michael Shigorin wrote:

<skip />

>>Все перечисленные уровни выше (или ниже, смотря как смотреть)
>>пользователя/администратора, не являющегося экспертом в ALT Linux.
>>Навязывание статуса эксперта IMTCO контрпродуктивно.

Я об этом тоже писал, повторяться не буду.

> Ты считаешь, что наличие скрипта, редактирующего system-auth
> (т.е. control) существенно снизит порог вхождения?

IMHO, при наличии "Настройка / ALT Linux / Системный контроль" - да,
существенно.

Rationale: я - вряд ли единственный в мире человек, который изучал
устройство более другой операционной системы по её панели управления, а
не по сертифицированным курсам компании-производителя.

-- 
// AB1002-UANIC

[sisyphus] Re: system-auth: edit vs control

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

Dmitry V. Levin пишет:
> On Thu, Dec 08, 2005 at 07:54:09PM +0200, Michael Shigorin wrote:
> 
>>>>Что ты предлагаешь для системного возврата к $HOME/tmp, кроме
>>>>смены дистрибутива?
>>>
>>>Об этом тоже рассказывалось; есть /etc/pam.d/system-auth,
>>>~/.bash_profile и прочие подобные средства настройки на разных
>>>уровнях.
>>
>>Все перечисленные уровни выше (или ниже, смотря как смотреть)
>>пользователя/администратора, не являющегося экспертом в ALT Linux.
>>Навязывание статуса эксперта IMTCO контрпродуктивно.
> 
> Ты считаешь, что наличие скрипта, редактирующего system-auth
> (т.е. control) существенно снизит порог вхождения?

IMHO, ответ очевиден. И не только снизит порог вхождения, но и
сделает работу администратора удобнее. И снизит вероятность
опечатки при редактировании.

Кроме того, отладка настройки pam просто никакая, с тем же
limits.conf в vserver пришлось долго разбираться, что значит
"permission denied" при логине по ssh.

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

[sisyphus] Re: system-auth: edit vs control

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

On Fri, Dec 09, 2005 at 01:05:23PM +0300, Dmitry V. Levin wrote:
> > Все перечисленные уровни выше (или ниже, смотря как смотреть)
> > пользователя/администратора, не являющегося экспертом в ALT
> > Linux.  Навязывание статуса эксперта IMTCO контрпродуктивно.
> Ты считаешь, что наличие скрипта, редактирующего system-auth
> (т.е. control) существенно снизит порог вхождения?

А вероятность вхождения -- повысит.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: defaults, блин, без головы (was: A: заботливо уложенные грабли pam_mktemp)

[Konstantin A. Lepikhov]

<цитата от="Michael Shigorin">
> On Thu, Dec 08, 2005 at 05:01:30PM +0300, Dmitry V. Levin wrote:
>> > > >>> Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?
>> > > >> http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"
>> > > У меня этот вопрос со дня появления pam_mktemp в Sisyphus :-(
>> > Ещё #8030.
>> Я не буду откатывать это изменение.
>
> Обоснование добавил в багу (да и, кажется, ранее почтой сюда).
> Какого-либо обоснования такого _умолчания_ не видел _вообще_.
майк, не мути воду. Говорили же, что глюки не в pam_mktemp, а в скриптах,
оставшихся со времен MDK. И это еще один из поводов, чтобы выкинуть этих
динозавров нафиг.

-- 
WBR et al.

[sisyphus] Re: defaults, блин, без головы

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

On Thu, Dec 08, 2005 at 08:01:13PM +0300, Konstantin A. Lepikhov wrote:
> майк, не мути воду.

Не уверен -- не гони.  Я не погулять вышел, по делу.

> Говорили же, что глюки не в pam_mktemp, а в скриптах,
> оставшихся со времен MDK. И это еще один из поводов, чтобы
> выкинуть этих динозавров нафиг.

У меня нет претензий к stmpclean & scripts/cleanup.
Но к сожалению -- есть претензии к реализации изменения.

Есть ряд людей, который придерживается мнения, что лучше $HOME/tmp;
есть ряд людей, который считает, что лучше /tmp/.private/$USER.

У меня была подобная ситуация с apache (точнее, suexec) -- #2461.
Бага пролежала два года до выяснения обстоятельств (спасибо
cray@, который пришёл и выяснил).  Но изменения поведения, 
которое бы пришло и многим многое сломало -- не было.

При отсутствии встроенного (как оказалось) механизма выбора
suexec root рано или поздно был бы реализован выбор из двух 
сборок suexec, как и планировалось.  Чтоб никто не ушёл.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Кто держит /tmp/.private?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Thu, Dec 08, 2005 at 11:43:50AM +0300, Alexei V. Mezin wrote:
> Dmitry V. Levin пишет:
> 
> >>Эти каталоги кто-то держит и не отдает? Или ошибки ФС (XFS)?
> >
> >http://www.google.ru/search?hl=ru&q="lsattr -d /tmp/.private"
> Спасибо, разобрался.
> Но возник вопрос: а в системе сейчас предусмотрены автоматические 
> средства чистки /tmp/.private? А то завел юзера в тестовых целях, через 
> день удалил, а каталог остался навечно.

Для тех, у кого /tmp сохраняется между перезагрузками системы,
сейчас не предусмотрены.

> И при старте системы очистка 
> /tmp ругается, нестрашно, но тоже нехорошо.

Это нехорошо, повесьте bug report.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Кто держит /tmp/.private?

[Alexei V. Mezin]

Dmitry V. Levin пишет:

> Для тех, у кого /tmp сохраняется между перезагрузками системы,
> сейчас не предусмотрены.
Т.е. официальная политика в дистрибутиве: /tmp помещать на виртуальную 
ФС и полностью обнулять при перезагрузке?

Если так, то придется приспосабливаться к официальной линии поведения.



-- 
Alexei V. Mezin

NT-MDT Co.
Phone: 095-913-5736
Fax: 095-913-573
Email: mezin@ntmdt.ru
URL: http://www.ntmdt.com

Re: [sisyphus] Кто держит /tmp/.private?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Thu, Dec 08, 2005 at 04:59:30PM +0300, Alexei V. Mezin wrote:
> Dmitry V. Levin пишет:
> 
> >Для тех, у кого /tmp сохраняется между перезагрузками системы,
> >сейчас не предусмотрены.
> Т.е. официальная политика в дистрибутиве: /tmp помещать на виртуальную 
> ФС и полностью обнулять при перезагрузке?

О каком дистрибутиве вы говорите?
В 2.4 pam_mktemp не использовался по умолчанию, а про 3.0 я не в курсе.

> Если так, то придется приспосабливаться к официальной линии поведения.

У того, что вы называете официальной линией поведения, есть разумное
обснование, которое можно прочесть в FHS-2.3:

$ bzfgrep /tmp /usr/share/doc/fhs-2.3/fhs.txt.bz2 |head -2
    /tmp : Temporary files
    /var/tmp : Temporary files preserved between system reboots


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Кто держит /tmp/.private?

[Andrei Bulava]

Alexei V. Mezin wrote:
> Dmitry V. Levin пишет:
> 
>> Для тех, у кого /tmp сохраняется между перезагрузками системы,
>> сейчас не предусмотрены.
> 
> Т.е. официальная политика в дистрибутиве: /tmp помещать на виртуальную
> ФС и полностью обнулять при перезагрузке?
> 
> Если так, то придется приспосабливаться к официальной линии поведения.

Баба Яга против. У меня и без tmpfs есть куда расходовать 1 Gb RAM, а у
некоторых и вовсе нету такого объёма.

-- 
// AB1002-UANIC

Re: [sisyphus] Кто держит /tmp/.private?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

On Thu, Dec 08, 2005 at 04:07:53PM +0200, Andrei Bulava wrote:
> Баба Яга против. У меня и без tmpfs есть куда расходовать 1 Gb RAM, а у
> некоторых и вовсе нету такого объёма.

Вообще-то для хранения данных в tmpfs обычно используется swap а не RAM.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: Кто держит /tmp/.private?

[@ 2005-12-08 14:25 UTC (permalink / raw)]

Re: [sisyphus] Re: Кто держит /tmp/.private?

[@ 2005-12-08 14:30 UTC (permalink / raw)]

[sisyphus] Re: Кто держит /tmp/.private?

[@ 2005-12-08 15:04 UTC (permalink / raw)]

Re: [sisyphus] Кто держит /tmp/.private?

[@ 2005-12-08 14:36 UTC (permalink / raw)]

Re: [sisyphus] Кто держит /tmp/.private?

[@ 2005-12-08 14:12 UTC (permalink / raw)]

Re: [sisyphus] Кто держит /tmp/.private?

[@ 2005-12-08 14:31 UTC (permalink / raw)]

Re: [sisyphus] Кто держит /tmp/.private?

[@ 2005-12-08 14:46 UTC (permalink / raw)]

Re: [sisyphus] Кто держит /tmp/.private?

[@ 2005-12-08 15:12 UTC (permalink / raw)]

Re: [sisyphus] Кто держит /tmp/.private?

[@ 2005-12-08 15:21 UTC (permalink / raw)]

Re: [sisyphus] Кто держит /tmp/.private?

[@ 2005-12-08 19:22 UTC (permalink / raw)]

Re: [sisyphus] Кто держит /tmp/.private?

[@ 2005-12-09 11:02 UTC (permalink / raw)]

[sisyphus] Re: Кто держит /tmp/.private?

[@ 2005-12-09 11:43 UTC (permalink / raw)]

Re: [sisyphus] Re: Кто держит /tmp/.private?

[@ 2005-12-09 18:11 UTC (permalink / raw)]

Re: [sisyphus] Кто держит /tmp/.private?

[@ 2005-12-07 22:50 UTC (permalink / raw)]