[sisyphus] /tmp на tmpfs?

[sisyphus] /tmp на tmpfs?

[Ivan Adzhubey]

Приветствую!

Последним обновлением (setup-2.2.10-alt1) создало /etc/fstab.rpmnew с такой 
строчкой:

tmpfs      /tmp     tmpfs   nosuid 0 0

Это новая политика партии? Я помню, обсуждалась возможность такой 
конфигурации, но это было давно и к консенсусу тогда кажется так и не пришли.
В changelog пакета написано незатейливо: "/etc/fstab: Added /tmp entry." А 
аргументы?

--Иван





The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.

Re: [sisyphus] /tmp на tmpfs?

[Michael Shigorin]

On Fri, Mar 16, 2007 at 03:26:53PM -0400, Ivan Adzhubey wrote:
> Последним обновлением (setup-2.2.10-alt1) создало
> /etc/fstab.rpmnew с такой строчкой:
> tmpfs      /tmp     tmpfs   nosuid 0 0
> Это новая политика партии?

Некоторые так после нагрузочного тестирования делали 
ещё года четыре тому.

> Я помню, обсуждалась возможность такой конфигурации, но это
> было давно и к консенсусу тогда кажется так и не пришли.
> В changelog пакета написано незатейливо: "/etc/fstab: Added
> /tmp entry." А аргументы?

Чистить не надо, например.  Опять же раздел, выделенный под /tmp,
можно пустить под своп с не меньшим эффектом.

Проблемы бывают при большой нагрузке на VM -- потеря файлов.
Для /tmp это скорее приемлемо.

Мне вот только интересно, что с /tmp/.private при этом будет.
(не подумайте, что в восторге от _этого_, но в bugzilla меня
проигнорировали)

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

Re: [sisyphus] /tmp на tmpfs?

[Dmitry V. Levin]

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

On Sat, Mar 17, 2007 at 12:50:08AM +0200, Michael Shigorin wrote:
> On Fri, Mar 16, 2007 at 03:26:53PM -0400, Ivan Adzhubey wrote:
> > Последним обновлением (setup-2.2.10-alt1) создало
> > /etc/fstab.rpmnew с такой строчкой:
> > tmpfs      /tmp     tmpfs   nosuid 0 0
> > Это новая политика партии?
> 
> Некоторые так после нагрузочного тестирования делали 
> ещё года четыре тому.
> 
> > Я помню, обсуждалась возможность такой конфигурации, но это
> > было давно и к консенсусу тогда кажется так и не пришли.
> > В changelog пакета написано незатейливо: "/etc/fstab: Added
> > /tmp entry." А аргументы?
> 
> Чистить не надо, например.  Опять же раздел, выделенный под /tmp,
> можно пустить под своп с не меньшим эффектом.
> 
> Проблемы бывают при большой нагрузке на VM -- потеря файлов.
> Для /tmp это скорее приемлемо.
> 
> Мне вот только интересно, что с /tmp/.private при этом будет.
> (не подумайте, что в восторге от _этого_, но в bugzilla меня
> проигнорировали)

Я не очень люблю вести обсуждения в bugzilla - этот инструмент для
напоминания об ошибках не предназначен для обсуждения.
Давайте лучше обсуждать здесь.

Что касается /tmp на swap'е по умолчанию в новых системах, то я не вижу
ни одного реального минуса в этом подходе.


-- 
ldv

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

Re: [sisyphus] /tmp на tmpfs?

[Ivan Adzhubey]

On Friday 16 March 2007 09:44:35 pm Dmitry V. Levin wrote:
> On Sat, Mar 17, 2007 at 12:50:08AM +0200, Michael Shigorin wrote:
> > On Fri, Mar 16, 2007 at 03:26:53PM -0400, Ivan Adzhubey wrote:
> > > Последним обновлением (setup-2.2.10-alt1) создало
> > > /etc/fstab.rpmnew с такой строчкой:
> > > tmpfs      /tmp     tmpfs   nosuid 0 0
> > > Это новая политика партии?
> >
> > Некоторые так после нагрузочного тестирования делали
> > ещё года четыре тому.
> >
> > > Я помню, обсуждалась возможность такой конфигурации, но это
> > > было давно и к консенсусу тогда кажется так и не пришли.
> > > В changelog пакета написано незатейливо: "/etc/fstab: Added
> > > /tmp entry." А аргументы?
> >
> > Чистить не надо, например.  Опять же раздел, выделенный под /tmp,
> > можно пустить под своп с не меньшим эффектом.
> >
> > Проблемы бывают при большой нагрузке на VM -- потеря файлов.
> > Для /tmp это скорее приемлемо.
> >
> > Мне вот только интересно, что с /tmp/.private при этом будет.
> > (не подумайте, что в восторге от _этого_, но в bugzilla меня
> > проигнорировали)
>
> Я не очень люблю вести обсуждения в bugzilla - этот инструмент для
> напоминания об ошибках не предназначен для обсуждения.
> Давайте лучше обсуждать здесь.
>
> Что касается /tmp на swap'е по умолчанию в новых системах, то я не вижу
> ни одного реального минуса в этом подходе.

Я тоже не вижу минусов, просто потому, что ничего не знаю про tmpfs, ее 
текущее состояние в 2.6.x, переспективы, надежность и пр. Если мне кто-нибудь 
расскажет или покажет где смотреть - буду признателен. Пока гуглю понемногу, 
но это не лучший способ получения достоверной информации. Вижу, что она 
использует виртуальную память и своп для временного хранения неиспользуемых 
файлов. Как минимум, это значит, что размер свопа должен быть теперь увязан 
не только с размером физической памяти и требованиями запускаемых приложений, 
но и с требованиями к размеру /tmp. Для "среднестатистического" десктопа это 
может быть и не очень важно, но серверы-то бывают разные. У меня например 
есть один, у которого /tmp под нагрузкой занимет 2/3 диска, такие там 
приложения крутятся. Вряд ли я смогу его просто переключить на tmpfs без 
переразбивки диска. Да и непонятно, что произойдет с производительностью 
задач интенсивно использующих файлы в /tmp.

Про проблемы с /tmp/.private я вообще ничего не понял, обсуждение в этой 
рассылке было коротким и загадочным.

--Иван

Re: [sisyphus] /tmp на tmpfs?

[Alexey Tourbin]

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

On Sat, Mar 17, 2007 at 02:13:44AM -0400, Ivan Adzhubey wrote:
> Я тоже не вижу минусов, просто потому, что ничего не знаю про tmpfs, ее 
> текущее состояние в 2.6.x, переспективы, надежность и пр. Если мне кто-нибудь 
> расскажет или покажет где смотреть - буду признателен. Пока гуглю понемногу, 
> но это не лучший способ получения достоверной информации. Вижу, что она 
> использует виртуальную память и своп для временного хранения неиспользуемых 
> файлов. Как минимум, это значит, что размер свопа должен быть теперь увязан 
> не только с размером физической памяти и требованиями запускаемых приложений, 
> но и с требованиями к размеру /tmp. Для "среднестатистического" десктопа это 
> может быть и не очень важно, но серверы-то бывают разные. У меня например 

В этом главный недостаток автоматического перехода на tmpfs.
Нужен своп в несколько гигабайт.

> переразбивки диска. Да и непонятно, что произойдет с производительностью 
> задач интенсивно использующих файлы в /tmp.

По сравнению с ext3 производительность увеличится в РАЗЫ.

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

Re: [sisyphus] /tmp на tmpfs?

[Alexey Tourbin]

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

On Sat, Mar 17, 2007 at 11:31:56AM +0300, Alexey Tourbin wrote:
> On Sat, Mar 17, 2007 at 02:13:44AM -0400, Ivan Adzhubey wrote:
> > Я тоже не вижу минусов, просто потому, что ничего не знаю про tmpfs, ее 
> > текущее состояние в 2.6.x, переспективы, надежность и пр. Если мне кто-нибудь 
> > расскажет или покажет где смотреть - буду признателен. Пока гуглю понемногу, 
> > но это не лучший способ получения достоверной информации. Вижу, что она 
> > использует виртуальную память и своп для временного хранения неиспользуемых 
> > файлов. Как минимум, это значит, что размер свопа должен быть теперь увязан 
> > не только с размером физической памяти и требованиями запускаемых приложений, 
> > но и с требованиями к размеру /tmp. Для "среднестатистического" десктопа это 
> > может быть и не очень важно, но серверы-то бывают разные. У меня например 
> 
> В этом главный недостаток автоматического перехода на tmpfs.
> Нужен своп в несколько гигабайт.

Другой недостаток состоит в том, что размер tmpfs надо явно указывать,
по умолчанию он кажется был равен половине RAM, а часто бывает слишком
мало.

nosuid,nr_inodes=1M,size=8G

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

Re: [sisyphus] /tmp на tmpfs?

[Sergey]

On Saturday 17 March 2007, Alexey Tourbin wrote:

> > В этом главный недостаток автоматического перехода на tmpfs.
> > Нужен своп в несколько гигабайт.
> 
> Другой недостаток состоит в том, что размер tmpfs надо явно указывать,
> по умолчанию он кажется был равен половине RAM, а часто бывает слишком
> мало.
 
Так а с пропаданием файлов-то что ? При сборке пакетов пропажи перестали
иметь место быть ?

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

Re: [sisyphus] /tmp на tmpfs?

[Alexey Tourbin]

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

On Sat, Mar 17, 2007 at 01:57:26PM +0400, Sergey wrote:
> > Другой недостаток состоит в том, что размер tmpfs надо явно указывать,
> > по умолчанию он кажется был равен половине RAM, а часто бывает слишком
> > мало.
>  
> Так а с пропаданием файлов-то что ? При сборке пакетов пропажи перестали
> иметь место быть ?

Не знаю.  Я у себя ни разу не сталкивался.  Может кто-то знает?

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

Re: [sisyphus] /tmp на tmpfs?

[gns]

при сборке не пропадают, наверное, из-за

gns@gns /usr/lib/rpm $ grep -R 'tmp' ./
./macros:%_tmppath              %{_var}/tmp
./macros:%buildroot             %{_tmppath}/%{name}-buildroot
gns@gns /usr/lib/rpm $ rpm -qf macros
librpm-4.0.4-alt73

не пропадает :)

2007/3/17, Alexey Tourbin <at@altlinux.ru>:
> On Sat, Mar 17, 2007 at 01:57:26PM +0400, Sergey wrote:
> > > Другой недостаток состоит в том, что размер tmpfs надо явно указывать,
> > > по умолчанию он кажется был равен половине RAM, а часто бывает слишком
> > > мало.
> >
> > Так а с пропаданием файлов-то что ? При сборке пакетов пропажи перестали
> > иметь место быть ?
>
> Не знаю.  Я у себя ни разу не сталкивался.  Может кто-то знает?
>

Re: [sisyphus] /tmp на tmpfs?

[Alexey Tourbin]

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

On Sat, Mar 17, 2007 at 12:17:11PM +0200, gns@altlinux.ru wrote:
> при сборке не пропадают, наверное, из-за
> 
> gns@gns /usr/lib/rpm $ grep -R 'tmp' ./
> ./macros:%_tmppath              %{_var}/tmp
> ./macros:%buildroot             %{_tmppath}/%{name}-buildroot
> gns@gns /usr/lib/rpm $ rpm -qf macros
> librpm-4.0.4-alt73

Я собираю на tmpfs как хешером так и rpm'ом.
Макросы переопределяются в ~/.rpmmacros.

> не пропадает :)

Меня, конечно, интересовало, решена ли эта проблема *в ядре* или нет.

> 2007/3/17, Alexey Tourbin <at@altlinux.ru>:
> > On Sat, Mar 17, 2007 at 01:57:26PM +0400, Sergey wrote:
> > > > Другой недостаток состоит в том, что размер tmpfs надо явно указывать,
> > > > по умолчанию он кажется был равен половине RAM, а часто бывает слишком
> > > > мало.
> > >
> > > Так а с пропаданием файлов-то что ? При сборке пакетов пропажи перестали
> > > иметь место быть ?
> >
> > Не знаю.  Я у себя ни разу не сталкивался.  Может кто-то знает?

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

[sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Michael Shigorin]

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

On Sat, Mar 17, 2007 at 04:44:35AM +0300, Dmitry V. Levin wrote:
> > Мне вот только интересно, что с /tmp/.private при этом будет.
> > (не подумайте, что в восторге от _этого_, но в bugzilla меня
> > проигнорировали)
> Я не очень люблю вести обсуждения в bugzilla - этот инструмент для
> напоминания об ошибках не предназначен для обсуждения.
> Давайте лучше обсуждать здесь.

Хорошо.

Попробую пересказать доводы, приведённые в этих багах:
https://bugzilla.altlinux.org/show_bug.cgi?id=6814
https://bugzilla.altlinux.org/show_bug.cgi?id=8030
сторонниками и противниками использования pam_mktemp (TMPDIR
в /tmp/.private/$USER) по умолчанию (противников использования
/вообще/ не наблюдал):

Executive summary:

+ использовать tmpfs на swap универсальней, чем /tmp+swap;
+ временные данные ДОЛЖНЫ жить в /tmp и никак иначе;
+ единый /tmp гораздо удобнее автоматически чистить;
+ данное умолчание возможно изменить вручную индивидуально.

- создаются отсутствовавшие до того проблемы пользования;
- изменяется баланс расхода дискового пространства;
- отсутствует аргументация изменения рабочей конфигурации;
- изменения возможно избежать только необновлением системы;
- переконфигурирование требует заметной компетенции;
- многократно нарушается принцип наименьшего удивления;
- изменение производится в картельном порядке и предельно
  доступно изложенная аргументация удивившихся коллег
  игнорируется или получает ответ в духе "мы лучше знаем,
  что вам надо".

Осторожно, выдёргивание цитат лучше считать субъективным.

--- pro (mithraen, ldv):

* "Напоминаю про наше последнее обсуждение" [mithraen]

* Доводов много, чтобы их здесь приводить. [ldv]

* Что касается требований к месту по разделам, то мы двигаемся в
  сторону увеличения swap и помещения /tmp на tmpfs. [ldv]

* Разве оно перестало быть настраиваемым? [ldv]

* /tmp оно на то и /tmp, что семантика у него другая, нежели у $HOME:
  1. Данные из него могут быть удалены, если к ним не было
     обращений в течении некоторого времени
  2. Данные из него могут быть удалены при перезагрузке
  3. На нём может быть noexec
  4. Оно может быть на tmpfs ($HOME на tmpfs это просто волшебство)
  [mithraen]

* 1. /tmp в любой системе обязана быть, и выполнять именно те
  функции, которые положены по FHS (хранить временные данные,
  заведомо не имеющие смысла после перезагрузки). И делается это
  либо tmpfs, либо отдельным физическим разделом.

  Те кто не хотят делать так -- ССЗБ и пусть продолжают создавать
  себе геморрой самостоятельно.
  [mithraen]

* Если напишете грамотный патч, он наверняка будет принят. [mithraen]

* А агрегировать tmp надо отнюдь нетолько на серверах. На рабочих
  станциях тоже весьма удобственно, ибо автоматически чистить
  можно штатными средствами. [mithraen]

* Временные файлы не должны лежать в $HOME. Это аксиома. Поэтому
  pam_mktemp "The Right Thing(tm)". Вопрос теперь в том, как
  сделать чтобы эта правильность не мешала usability. [mithraen]


--- contra (mike, sbolshakov и более мягко -- raorn и ktirf)

* нельзя ли в привести здесь доводы за такое решение ?
  с переездом TMPDIR некоторым образом изменились требования
  к распределению места по разделам, как минимум. [sbolshakov]

* /* проблемы для пользователей, которые не имеют соответствующей
     группы (до внесения специфических модификаций в glibc -- 
     и для SGID-программ, использующих TMPDIR) // mike */

  drwxrwx--T  2 root raorn 4096 Jun  4 18:53 /tmp/.private/raorn
  [...]
  Как насчёт пользователей с одной общей группой типа users?  [raorn]

* usertmp   /home/wrar/tmp   tmpfs   size=1g 0 0 [wrar]

* напоролся на то, что GUI'шный софт (точнее, файл-селектор в
  OOo) встал при попытке перейти из такого каталога в домашний
  "штатными средствами", бишь кнопкой "вверх" -- с жалобой "не
  могу прочитать каталог". [...] [mike]

* Это общий "недостаток" практически у всех файл-селекторов: если
  прав на чтение каталога нет, пользователь не сможет пройти через
  него вверх или вниз. [...] [ktirf]

* это _плохое_ умолчание.  Обоснование:
  - серверы требуют настройки
  - десктопы если и настраиваются, то редко квалифицированно
  - проблемы на серверах, которые это изменение решает, некритичны
  - проблемы на десктопах, которые оно создаёт -- критичны
  [mike]

* отсылки на FHS не более убедительны, чем тезис о том, что
  временные данные пользователя -- это в первую очередь ДАННЫЕ
  ПОЛЬЗОВАТЕЛЯ.  И дефолты должны создавать минимум проблем на
  ровном месте [...] [mike]

* Отвечать в тысячный раз в jabber, почту, телефон, что "это
  такие фирменные грабли, заточенные под некоторых продвинутых
  пользователей" -- не хочется совсем. [mike]

* error: removing these packages would break dependencies:
        pam_mktemp.so is needed by pam0-config-1.2.0-alt1 [mike]

* Не один администратор рефлекторно настрожится при виде
  неудаляемого скрытого каталога в общедоступном по записи /tmp.
  На сейчас все эти неприятности прибиты гвоздями к pam0_config. [mike]

* Половина проблем -- из-за прав и атрибутов, вешать их под
  control -- проще, чем /boot с /lib/modules.  Но при этом всё
  равно остаётся вышеописанная часть вида /tmp vs /home. [mike]

* я не считаю pam_mktemp безусловным `the right thing'.
  Поддержу предложение иметь на это дело control, off by default.
  уточню, управлять хотелось бы фактом существования pam0_mktemp
  в связке, а не правами ниже /tmp -- $TMPDIR, равная $HOME/tmp,
  для меня достаточна. [sbolshakov]


--- pro et contra
? все sgid программы (например xscreensaver) пролетают мимо
  $TPMDIR как фанера над парижем... [raorn]
! Что касается sgid-ных исполняемых объектов, то они могут
  чувствовать себя спокойно начиная с glibc-2.2.5-alt6 (это
  ALT-specific). [ldv]

= Лично мне, продвинутому пользователю настольной системы, нужно следующее:
  1. Возможность разместить каталог (каталоги всех пользователей)
     на отдельной файловой системе (я люблю tmpfs, но здесь это не
     предполагается).
  2. Незаметность этого каталога в том смысле, что если уж он
     лежит у меня в ~, он должен начинаться на точку (обоснование:
     я не могу его удалить, потому что он нужен системе).
  3. Недоступность каталога одного пользователя другому пользователю.
  4. Быстрый и простой доступ к каталогу (/tmp/.private/username
     здесь явно проигрывает; в качестве ещё одного костыля могу
     предложить симлинк ~/tmp -> /tmp/.private/username).
  5. Нулевые затраты на maintenance этого каталога (stmpclean
     вполне справляется с этой задачей при условии его
     умолчательного правильного натравливания).
  По совокупности лично мне очень нравится pam_mktemp плюс
  закладка на /tmp/.private/ktirf [ktirf]

= Created an attachment (id=1133)
  /etc/control.d/facilities/pam_mktemp
  Извините, что вмешиваюсь, но проблема "Обычных
  Пользователей(tm)" решается одним файликом в
  /etc/control.d/facilities и галкой (или умолчательным
  поведением) в инсталяторе.  Не знаю, есть ли противопоказания к
  применению control(8) на /etc/pam.d/system-auth... [raorn]

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

Для меня это одна из трёх наиболее тяжёлых и неприятных ситуаций,
связанных с участием в разработке, развёртывании и поддержке
ALT Linux до сего времени, если честно.

> Что касается /tmp на swap'е по умолчанию в новых системах,
> то я не вижу ни одного реального минуса в этом подходе.

Мгм.

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

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

[sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Michael Shigorin]

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

On Sat, Mar 17, 2007 at 11:31:56AM +0300, Alexey Tourbin wrote:
> > серверы-то бывают разные. У меня например 
> В этом главный недостаток автоматического перехода на tmpfs.
> Нужен своп в несколько гигабайт.

Лёш, задача эквивалентна большой кнопке "чтоб работало".
Тут на кластере по 80Gb локальных целиком в /tmp примонтировано.

> > переразбивки диска. Да и непонятно, что произойдет с
> > производительностью задач интенсивно использующих файлы в
> > /tmp.
> По сравнению с ext3 производительность увеличится в РАЗЫ.

Вот только на incoming вылезло (и не слышал радостных сообщений,
что отловлено и задушено) -- что файлики теряются при заметной
нагрузке на VM.  Бишь собирая на tmpfs и что-то ещё делая, что
page cache потянет, рискуем терять (случайные?) файлы на tmpfs.

Для кухарки это приемлемо, для сервера -- зависит от того,
что в том /tmp.  А отвечает за сервер его администратор,
и это вовсе не всегда ldv@ или mithraen@.  Пока по крмере.

Вопрос чем-то похож на использование xfs для /var по умолчанию,
которое недавно обсуждалось: налицо tradeoff, где ALT Linux
может предложить толковому администратору существенную выгоду,
но вот неопытный может на ней и погореть, если дефолт будет
экстремистским.  Соответственно и не дорастёт до опытного
администратора ALT.

-- 
 ---- 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/$USER vs $HOME/tmp как умолчание для TMPDIR

[Denis G. Samsonenko]

День добрый!

17.03.07, Michael Shigorin написал:
> * отсылки на FHS не более убедительны, чем тезис о том, что
>   временные данные пользователя -- это в первую очередь ДАННЫЕ
>   ПОЛЬЗОВАТЕЛЯ.  И дефолты должны создавать минимум проблем на
>   ровном месте [...] [mike]

Разрешите присоединиться к этому утверждению. Я считаю, что файлы
пользователя (вне зависимости от их сорта и типа) не должны лежать вне
пределов его $HOME директории.

Мне, как пользователю домашнего десктопа нравится вариант с /tmp на
tmpfs, но при этом с юзерским tmp в $HOME/tmp. Памяти не так уж и
много на десктопы ставят, да и разделов больше трёх как правило не
создают (/, /home и swap). В связи с этим мне кажется оптимальным
маленький /tmp на tmpfs для системы и $HOME/tmp, ограниченный только
размером раздела под /home (как правило самый большой раздел на
домашнем десктопе), для временных файлов пользователя.

У меня, например, в ~/tmp образы создаваемых CD пишутся. И мне совсем
не улыбается, если они будут писаться в /tmp, в котором размер
свободного пространства сравним с размером создаваемого образа, вместо
того, чтобы писать его в пределах большого /home, наполненность
которого сам же пользователь и контролирует.

-- 
Всего доброго,

Денис.

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Michael Shigorin]

On Sun, Mar 18, 2007 at 12:21:42AM +0900, Denis G. Samsonenko wrote:
> У меня, например, в ~/tmp образы создаваемых CD пишутся. И мне
> совсем не улыбается, если они будут писаться в /tmp, в котором
> размер свободного пространства сравним с размером создаваемого
> образа, вместо того, чтобы писать его в пределах большого
> /home, наполненность которого сам же пользователь и
> контролирует.

User/group quotas сюда же.

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Dmitry V. Levin]

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

On Sun, Mar 18, 2007 at 12:21:42AM +0900, Denis G. Samsonenko wrote:
> День добрый!
> 
> 17.03.07, Michael Shigorin написал:
> > * отсылки на FHS не более убедительны, чем тезис о том, что
> >   временные данные пользователя -- это в первую очередь ДАННЫЕ
> >   ПОЛЬЗОВАТЕЛЯ.  И дефолты должны создавать минимум проблем на
> >   ровном месте [...] [mike]
> 
> Разрешите присоединиться к этому утверждению. Я считаю, что файлы
> пользователя (вне зависимости от их сорта и типа) не должны лежать вне
> пределов его $HOME директории.

Т.е. вы предлагаете каталоги /tmp и /var/tmp запретить совсем?

> Мне, как пользователю домашнего десктопа нравится вариант с /tmp на
> tmpfs, но при этом с юзерским tmp в $HOME/tmp.

По умолчанию при создании нового пользователя уже очень давно создаётся
каталог (не ссылка) по имени $HOME/tmp.  Так что я не понимаю, за какую
сторону вы аргументируете.

> Памяти не так уж и много на десктопы ставят,

Думаю что про современные десктопы так уже не скажешь.

> да и разделов больше трёх как правило не
> создают (/, /home и swap). В связи с этим мне кажется оптимальным
> маленький /tmp на tmpfs для системы и $HOME/tmp, ограниченный только
> размером раздела под /home (как правило самый большой раздел на
> домашнем десктопе), для временных файлов пользователя.

А мне кажется неоптимальным маленький /tmp на tmpfs.
Похоже, не всем очевидно, что бОльший /tmp на tmpfs ещё не значит
бОльший расход памяти.

> У меня, например, в ~/tmp образы создаваемых CD пишутся.

Извините.  Не у вас пишутся, а вы записываете.

> И мне совсем не улыбается, если они будут писаться в /tmp,

Они будут записываться туда, куда вы скажете.


-- 
ldv

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Dmitry V. Levin]

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

On Sat, Mar 17, 2007 at 04:41:38PM +0200, Michael Shigorin wrote:
> On Sat, Mar 17, 2007 at 04:44:35AM +0300, Dmitry V. Levin wrote:
> > > Мне вот только интересно, что с /tmp/.private при этом будет.
> > > (не подумайте, что в восторге от _этого_, но в bugzilla меня
> > > проигнорировали)
> > Я не очень люблю вести обсуждения в bugzilla - этот инструмент для
> > напоминания об ошибках не предназначен для обсуждения.
> > Давайте лучше обсуждать здесь.
> 
> Хорошо.
> 
> Попробую пересказать доводы, приведённые в этих багах:
> https://bugzilla.altlinux.org/show_bug.cgi?id=6814
> https://bugzilla.altlinux.org/show_bug.cgi?id=8030
> сторонниками и противниками использования pam_mktemp (TMPDIR
> в /tmp/.private/$USER) по умолчанию (противников использования
> /вообще/ не наблюдал):
> 
> Executive summary:
> 
> + использовать tmpfs на swap универсальней, чем /tmp+swap;

Я не совсем понимаю, что такое "универсальней".  Я бы сказал иначе:
+ Хранить временные файлы на tmpfs эффективнее, поскольку tmpfs работает
  заметно быстрее любой существующей файловой системы на диске.
+ Хранить временные файлы на tmpfs экономичнее с точки зрения расхода
  дисковых ресурсов.

> + временные данные ДОЛЖНЫ жить в /tmp и никак иначе;

Я бы переформулировал:
+ Временные данные располагаться в $TMPDIR/; всё остальное --
  уже не совсем временное.

> + единый /tmp гораздо удобнее автоматически чистить;
> + данное умолчание возможно изменить вручную индивидуально.
+ Данное умолчание возможно изменить вручную общесистемно.

> - создаются отсутствовавшие до того проблемы пользования;

Это субъективно; одни проблемы создаются, другие решаются.

> - изменяется баланс расхода дискового пространства;

Это является минусом только когда дисковое пространство не готово
для изменения баланса.

> - отсутствует аргументация изменения рабочей конфигурации;

Это я не понимаю.

> - изменения возможно избежать только необновлением системы;

Это не соответствует действительности.

> - переконфигурирование требует заметной компетенции;

Это субъективно и при необходимости может быть улучшено.

> - многократно нарушается принцип наименьшего удивления;

Это очень субъективно.

> - изменение производится в картельном порядке и предельно
>   доступно изложенная аргументация удивившихся коллег
>   игнорируется или получает ответ в духе "мы лучше знаем,
>   что вам надо".

Это очень субъективно.

> * Доводов много, чтобы их здесь приводить. [ldv]

Ключевое слово "здесь".

>   drwxrwx--T  2 root raorn 4096 Jun  4 18:53 /tmp/.private/raorn
>   [...]
>   Как насчёт пользователей с одной общей группой типа users?  [raorn]

У каждого пользователя всё равно есть своя личная группа.

> * напоролся на то, что GUI'шный софт (точнее, файл-селектор в
>   OOo) встал при попытке перейти из такого каталога в домашний
>   "штатными средствами", бишь кнопкой "вверх" -- с жалобой "не
>   могу прочитать каталог". [...] [mike]
> 
> * Это общий "недостаток" практически у всех файл-селекторов: если
>   прав на чтение каталога нет, пользователь не сможет пройти через
>   него вверх или вниз. [...] [ktirf]

Я согласовал с автором pam_mktemp добавление параметра, управляющего
правами лоступа к каталогу /tmp/.private

> * Не один администратор рефлекторно настрожится при виде
>   неудаляемого скрытого каталога в общедоступном по записи /tmp.
>   На сейчас все эти неприятности прибиты гвоздями к pam0_config. [mike]

Неудаляемость имеет место быть не на всех файловых системах.
tmpfs не поддерживает эти атрибуты.

Кроме того, я согласовал с автором pam_mktemp добавление параметра,
управляющего добавлением этого атрибута к /tmp/.private

> * я не считаю pam_mktemp безусловным `the right thing'.
>   Поддержу предложение иметь на это дело control, off by default.
>   уточню, управлять хотелось бы фактом существования pam0_mktemp
>   в связке,

Я не против control.  Я не согласен с off by default.

> = Created an attachment (id=1133)
>   /etc/control.d/facilities/pam_mktemp
>   Извините, что вмешиваюсь, но проблема "Обычных
>   Пользователей(tm)" решается одним файликом в
>   /etc/control.d/facilities и галкой (или умолчательным
>   поведением) в инсталяторе.  Не знаю, есть ли противопоказания к
>   применению control(8) на /etc/pam.d/system-auth... [raorn]

Судя по зависимостям пакета control, противопоказаний нет.

Другими словами, добавление control для system-auth и расширение
управляемости pam_mktemp должно снять возникшую напряжённость.

Так?

> Для меня это одна из трёх наиболее тяжёлых и неприятных ситуаций,
> связанных с участием в разработке, развёртывании и поддержке
> ALT Linux до сего времени, если честно.

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


-- 
ldv

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Denis G. Samsonenko]

Вечер добрый!

18.03.07, Dmitry V. Levin написал:
> > Разрешите присоединиться к этому утверждению. Я считаю, что файлы
> > пользователя (вне зависимости от их сорта и типа) не должны лежать вне
> > пределов его $HOME директории.
>
> Т.е. вы предлагаете каталоги /tmp и /var/tmp запретить совсем?

Нет. Я не совсем в курсе, для чего нужен /var/tmp, я просто за то,
чтобы пользовательские временные файлы были в ~/tmp, а не в /tmp.

> > Мне, как пользователю домашнего десктопа нравится вариант с /tmp на
> > tmpfs, но при этом с юзерским tmp в $HOME/tmp.
>
> По умолчанию при создании нового пользователя уже очень давно создаётся
> каталог (не ссылка) по имени $HOME/tmp.  Так что я не понимаю, за какую
> сторону вы аргументируете.

Я за отсутствие /tmp/.privat/user.

> > Памяти не так уж и много на десктопы ставят,
> Думаю что про современные десктопы так уже не скажешь.

Какой уж есть. Всё равно мне жалко будет на десктопе выделять под своп
дополнительные несколько гигабайт, которые практически не будут
использоваться. Лучше их к /home приплюсовать.

Если бы хотябы при инсталлировании системы учитывалось, сколько на
борту физической памяти и каков размер свопа, при выборе варианта с
/tmp/.privat и без оного.

Я не говорю за серверы, только за домашний десктоп.

> А мне кажется неоптимальным маленький /tmp на tmpfs.
> Похоже, не всем очевидно, что бОльший /tmp на tmpfs ещё не значит
> бОльший расход памяти.

Очевидно. Но но размер этот всё же придётся чем-то обеспечить, тем же
увеличенным свопом, который будет лежать большую часть времени мёртвым
грузом.

> > У меня, например, в ~/tmp образы создаваемых CD пишутся.
> Извините.  Не у вас пишутся, а вы записываете.

Ничего отличного от этого я и не имел в виду.

> > И мне совсем не улыбается, если они будут писаться в /tmp,
> Они будут записываться туда, куда вы скажете.

Мне кажется логичным писать их в $TMPDIR, раз они временные.

В общем я за то, чтобы пользовательские файлы были при пользователе.
Он сам разберётся что с ними делать: хранить, или удалять время от
времени вручную или посредством неких скриптов по крону.

-- 
Всего доброго,

Денис.

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Dmitry V. Levin]

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

On Sun, Mar 18, 2007 at 02:08:43AM +0900, Denis G. Samsonenko wrote:
> В общем я за то, чтобы пользовательские файлы были при пользователе.

Вопрос не в том, где и почему, по вашему мнению, должны располагаться
временные файлы пользователей.
Вопрос в том, где и почему, по вашему мнению, должны по умолчанию
располагаться временные файлы пользователей.

Т.е. вопросы были следующие:
- значение по умолчанию;
- способы управления этим значением;
- способы управления этим умолчанием.


-- 
ldv

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Alexey Tourbin]

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

On Sat, Mar 17, 2007 at 07:21:43PM +0300, Dmitry V. Levin wrote:
> Я согласовал с автором pam_mktemp добавление параметра, управляющего
> правами лоступа к каталогу /tmp/.private

Я не понимаю, что в принципе можно скрывать в каталоге /tmp/.private,
делая его недоступным на чтение.  Чего нельзя узнать из
	awk -F: '$3>=500' /etc/passwd

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Dmitry V. Levin]

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

On Sat, Mar 17, 2007 at 08:38:52PM +0300, Alexey Tourbin wrote:
> On Sat, Mar 17, 2007 at 07:21:43PM +0300, Dmitry V. Levin wrote:
> > Я согласовал с автором pam_mktemp добавление параметра, управляющего
> > правами доступа к каталогу /tmp/.private
> 
> Я не понимаю, что в принципе можно скрывать в каталоге /tmp/.private,
> делая его недоступным на чтение.  Чего нельзя узнать из
> 	awk -F: '$3>=500' /etc/passwd

Не очень много, поскольку наличие каталогов пользователей можно
проверить полным перебором всех пользователей.

Если каталог не доступен на чтение, то его нельзя мониторить
с помощью inotify_add_watch(2).


-- 
ldv

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Alexey Tourbin]

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

On Sat, Mar 17, 2007 at 09:00:20PM +0300, Dmitry V. Levin wrote:
> On Sat, Mar 17, 2007 at 08:38:52PM +0300, Alexey Tourbin wrote:
> > On Sat, Mar 17, 2007 at 07:21:43PM +0300, Dmitry V. Levin wrote:
> > > Я согласовал с автором pam_mktemp добавление параметра, управляющего
> > > правами доступа к каталогу /tmp/.private
> > 
> > Я не понимаю, что в принципе можно скрывать в каталоге /tmp/.private,
> > делая его недоступным на чтение.  Чего нельзя узнать из
> > 	awk -F: '$3>=500' /etc/passwd
> 
> Не очень много, поскольку наличие каталогов пользователей можно
> проверить полным перебором всех пользователей.
> 
> Если каталог не доступен на чтение, то его нельзя мониторить
> с помощью inotify_add_watch(2).

То есть можно мониторить добавление новых пользователей?  Но добавление
новых пользователей можно мониторить и без inotify.  К сожалению я
сейчас не в состоянии вникнуть в inotify(7).  В худшем случае можно
мониторить mtime подкаталогов, т.е. гипотетическую активность
пользователей.  Но своего рода активность пользователей можно
мониторить штатно через last(1).

Теперь недостаток: если один из каталогов в полном пути недоступен на
чтение, то перестает работать стандартный алгоритм getcwd().  В
linux/glibc это системный вызов, так что вроде море по колено.  Но софт
который мы запускаем не всегда сводится к glibc.  В частности, мне
пришлось захачить перл, чтобы сделать возможным выполнение (точнее,
отключение) некоторых тестов при сборке с '%_builddir %_tmppath/BUILD%_builddir'.
См. 5.8.8-217-g70c50d0.

Тут Миша уже сказал, что по сути по той же самой причине перестают
работать файл-селекторы в графических гуях.

В общем, выгода от нечитаемости /tmp/.private слишком призрачна,
а привет слишком большой.

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Alexey Tourbin]

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

On Sat, Mar 17, 2007 at 09:16:18PM +0300, Alexey Tourbin wrote:
> Теперь недостаток: если один из каталогов в полном пути недоступен на
> чтение, то перестает работать стандартный алгоритм getcwd().  В
> linux/glibc это системный вызов, так что вроде море по колено.  Но софт
> который мы запускаем не всегда сводится к glibc.  В частности, мне
> пришлось захачить перл, чтобы сделать возможным выполнение (точнее,
> отключение) некоторых тестов при сборке с '%_builddir %_tmppath/BUILD%_builddir'.
> См. 5.8.8-217-g70c50d0.
> 
> Тут Миша уже сказал, что по сути по той же самой причине перестают
> работать файл-селекторы в графических гуях.
> 
> В общем, выгода от нечитаемости /tmp/.private слишком призрачна,
> а привет слишком большой.

Кроме того, по этой причине отваливает даже find(1)!  Сдавайся.
https://bugzilla.altlinux.org/show_bug.cgi?id=9419

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Dmitry V. Levin]

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

On Sat, Mar 17, 2007 at 09:16:18PM +0300, Alexey Tourbin wrote:
> On Sat, Mar 17, 2007 at 09:00:20PM +0300, Dmitry V. Levin wrote:
> > On Sat, Mar 17, 2007 at 08:38:52PM +0300, Alexey Tourbin wrote:
> > > On Sat, Mar 17, 2007 at 07:21:43PM +0300, Dmitry V. Levin wrote:
> > > > Я согласовал с автором pam_mktemp добавление параметра, управляющего
> > > > правами доступа к каталогу /tmp/.private
> > > 
> > > Я не понимаю, что в принципе можно скрывать в каталоге /tmp/.private,
> > > делая его недоступным на чтение.  Чего нельзя узнать из
> > > 	awk -F: '$3>=500' /etc/passwd
> > 
> > Не очень много, поскольку наличие каталогов пользователей можно
> > проверить полным перебором всех пользователей.
> > 
> > Если каталог не доступен на чтение, то его нельзя мониторить
> > с помощью inotify_add_watch(2).
> 
> То есть можно мониторить добавление новых пользователей?  Но добавление
> новых пользователей можно мониторить и без inotify.  К сожалению я
> сейчас не в состоянии вникнуть в inotify(7).  В худшем случае можно
> мониторить mtime подкаталогов, т.е. гипотетическую активность
> пользователей.  Но своего рода активность пользователей можно
> мониторить штатно через last(1).

Например, можно мониторить залогинивание пользователей (в т.ч.
неинтерактивных, например посредством crond), причем без poll'инга.

> Теперь недостаток: если один из каталогов в полном пути недоступен на
> чтение, то перестает работать стандартный алгоритм getcwd().  В
> linux/glibc это системный вызов, так что вроде море по колено.  Но софт
> который мы запускаем не всегда сводится к glibc.  В частности, мне
> пришлось захачить перл, чтобы сделать возможным выполнение (точнее,
> отключение) некоторых тестов при сборке с '%_builddir %_tmppath/BUILD%_builddir'.
> См. 5.8.8-217-g70c50d0.
> 
> Тут Миша уже сказал, что по сути по той же самой причине перестают
> работать файл-селекторы в графических гуях.
> 
> В общем, выгода от нечитаемости /tmp/.private слишком призрачна,
> а привет слишком большой.

Я же сказал, что ручка управления правами /tmp/.private (раньше или позже)
будет.  Просто сейчас у upstream maintainer'ов другие приоритеты не дают
реализовать эту возможность достаточно быстро.  Если кто-то может помочь
патчем, который можно будет принять без переписывания, то я буду очень
рад.


-- 
ldv

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Michael Shigorin]

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

---------------------------------------------------------------

> > * я не считаю pam_mktemp безусловным `the right thing'.
> >   Поддержу предложение иметь на это дело control, off by default.
> >   уточню, управлять хотелось бы фактом существования pam0_mktemp
> >   в связке,
> Я не против control.  Я не согласен с off by default.

Возможно ли сделать так, чтобы в серверном варианте дистрибутива
было как тебе видней, а в "общего назначения" -- off by default?

На серверах наиболее критичные проблемы или отсутствуют,
или снимаются при минимальном документировании на видном месте
"введения в ALT Server".

На системах общего назначения, в первую очередь десктопных --
поверь на слово, ~/tmp by default лучше по многим причинам
(скажи, где "здесь", расчертим-обсудим).

/* Это достаточно разумное умолчание общего плана, в отличие
   от предположения высокой сознательности и компетентности
   администратора и пользователей системы.  Один раз засунув 
   впопыхах уникальный файлик в /tmp и вспомнив только когда 
   он был прибит stmpclean'ом (M20), довольно хорошо помню
   эмоции, которые в моём случае достались мне же, а в общем
   -- стоит ожидать неконкретных жалоб на "теряющий данные 
   альт" в публичных местах. */

Дим, я ведь как умею -- тоже стараюсь помочь выпустить
такой дистрибутив, за который не будет стыдно.  Который
можно будет опять раздавать всем желающим, разворачивать
по всем проектам и писать вкусные анонсы на freshmeat,
lwn, distrowatch.  В котором будет интересно участвовать
и опытным вроде morozov@, и молодым вроде php-coder@.

---------------------------------------------------------------

On Sat, Mar 17, 2007 at 06:55:13PM +0300, Dmitry V. Levin wrote:
> > Разрешите присоединиться к этому утверждению. Я считаю, что
> > файлы пользователя (вне зависимости от их сорта и типа) не
> > должны лежать вне пределов его $HOME директории.
> Т.е. вы предлагаете каталоги /tmp и /var/tmp запретить совсем?

Это логически не следует.  Хотеть-то их запретить можно
(как и uid 0, и suid), да толку с того.

> > И мне совсем не улыбается, если они будут писаться в /tmp,
> Они будут записываться туда, куда вы скажете.

Так не хотелось бы сто раз "ёлочка, зажгись!".

On Sat, Mar 17, 2007 at 07:21:43PM +0300, Dmitry V. Levin wrote:
> > Executive summary:
> > + использовать tmpfs на swap универсальней, чем /tmp+swap;
> Я не совсем понимаю, что такое "универсальней".

В /tmp+swap не получается использовать место под /tmp для
свопа, если только не укладывать туда руками swapfiles.

А tmpfs позволяет использовать место и так, и так.
Вот и "более универсально".

> Я бы сказал иначе:
> + Хранить временные файлы на tmpfs эффективнее, поскольку tmpfs работает
>   заметно быстрее любой существующей файловой системы на диске.
> + Хранить временные файлы на tmpfs экономичнее с точки зрения расхода
>   дисковых ресурсов.

Ага.

> > + временные данные ДОЛЖНЫ жить в /tmp и никак иначе;
> Я бы переформулировал:
> + Временные данные располагаться в $TMPDIR/; всё остальное --
>   уже не совсем временное.

Ага.

Только решать временность -- владельцу этих данных.

> > + единый /tmp гораздо удобнее автоматически чистить;
> > + данное умолчание возможно изменить вручную индивидуально.
> + Данное умолчание возможно изменить вручную общесистемно.
> > - создаются отсутствовавшие до того проблемы пользования;
> Это субъективно; одни проблемы создаются, другие решаются.

Соображения по поводу _умолчаний_ высказал здесь:
https://bugzilla.altlinux.org/show_bug.cgi?id=6814#c15

> > - изменяется баланс расхода дискового пространства;
> Это является минусом только когда дисковое пространство не
> готово для изменения баланса.

Проблема в том, что изменение разбивки обычно не является
тривиальной задачей.  Особенно с учётом того, что "физический"
/tmp живёт или на корне (худший и распространённый вариант),
или в "быстром" начале диска.  Как и своп -- никак не в конце,
где разделы таскать удобнее.

> > - отсутствует аргументация изменения рабочей конфигурации;
> Это я не понимаю.

Была рабочая конфигурация, для многих -- даже фича дистро.
По багтрекеру пробегает "как мы договаривались" -- "applied".
Когда оказывается, что для многих новая конфигурация сломана,
в обратную сторону -- никак.

Хотя бы известить в sisyphus@ действительно было уместно.
Делать изменение идеально было бы вместе с ясно описанной
возможностью оставить всё как есть и ручкой вроде control.

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

Понимаешь, легко соглашаться с даже сложными выборами других
людей, когда результат работает.  В данном случае получается,
что выбор твой и mithraen@ оказывается важнее выбора тех,
кому достанется большинство негативных последствий -- даже
если им же в других задачах будет та же выгода от изменения.

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

> > - изменения возможно избежать только необновлением системы;
> Это не соответствует действительности.

В контексте _системы_ -- соответствует.  Аргументация вроде 
того, что против каждого изменения можно, уже зная его, настелить
соломы (сделать фейковый pam_mktemp.so, /etc/profile.d/tmpdir.sh
-- как вот приходится, или иные контрмеры), непродуктивна.

Если бы это было не так, ты бы и сейчас использовал какой редхат.

> > - переконфигурирование требует заметной компетенции;
> Это субъективно и при необходимости может быть улучшено.

Так начинать стоило с этого "улучшено".

> > - многократно нарушается принцип наименьшего удивления;
> Это очень субъективно.

Это summary; про свою субъективность написал выше.

> > - изменение производится в картельном порядке и предельно
> >   доступно изложенная аргументация удивившихся коллег
> >   игнорируется или получает ответ в духе "мы лучше знаем,
> >   что вам надо".
> Это очень субъективно.

Это мягкое изложение моего личного восприятия этого случая.

> > * Доводов много, чтобы их здесь приводить. [ldv]
> Ключевое слово "здесь".

Ну "здесь" спрашивал sbolshakov@:
https://bugzilla.altlinux.org/show_bug.cgi?id=6814#c2

Приведи здесь, в sisyphus@.  Или скажи, где будет продуктивно.

Мне тоже есть на что ещё потратить время.

> >   drwxrwx--T  2 root raorn 4096 Jun  4 18:53 /tmp/.private/raorn
> >   [...]
> >   Как насчёт пользователей с одной общей группой типа users?  [raorn]
> У каждого пользователя всё равно есть своя личная группа.

Это очень субъективно.  В LDAP может быть одна-две на всех,
из жизненных примеров.

> > * Это общий "недостаток" практически у всех файл-селекторов: если
> >   прав на чтение каталога нет, пользователь не сможет пройти через
> >   него вверх или вниз. [...] [ktirf]
> Я согласовал с автором pam_mktemp добавление параметра,
> управляющего правами лоступа к каталогу /tmp/.private

Спасибо; это решает "правовую" часть проблемы (но оставляет
"стораджевую").

> > * Не один администратор рефлекторно настрожится при виде
> >   неудаляемого скрытого каталога в общедоступном по записи /tmp.
> >   На сейчас все эти неприятности прибиты гвоздями к pam0_config. [mike]
> Неудаляемость имеет место быть не на всех файловых системах.
> tmpfs не поддерживает эти атрибуты.

Да, в случае официально рекомендуемого tmpfs для /tmp эта
проблема упрощается до "...при виде скрытого каталога в
общедоступном по записи".

А квоты на tmpfs работают?

> Кроме того, я согласовал с автором pam_mktemp добавление
> параметра, управляющего добавлением этого атрибута к
> /tmp/.private

Спасибо.

> > = Created an attachment (id=1133)
> >   /etc/control.d/facilities/pam_mktemp
> >   Извините, что вмешиваюсь, но проблема "Обычных
> >   Пользователей(tm)" решается одним файликом в
> >   /etc/control.d/facilities и галкой (или умолчательным
> >   поведением) в инсталяторе.  Не знаю, есть ли противопоказания к
> >   применению control(8) на /etc/pam.d/system-auth... [raorn]
> Судя по зависимостям пакета control, противопоказаний нет.
> Другими словами, добавление control для system-auth и расширение
> управляемости pam_mktemp должно снять возникшую напряжённость.
> Так?

В достаточной мере.  Вопрос разумности смены умолчания остаётся
при этом открытым.

> > Для меня это одна из трёх наиболее тяжёлых и неприятных
> > ситуаций, связанных с участием в разработке, развёртывании и
> > поддержке ALT Linux до сего времени, если честно.
> Ну если это одна из трёх наиболее тяжёлых, то я могу вздохнуть
> спокойно.

Да.  Предыдущие две давно в прошлом: принятие vsl@ и моя глупая
война с rider@ (в том числе и по части умолчаний) около 3.0.

-- 
 ---- 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/$USER vs $HOME/tmp как умолчание для TMPDIR

[Alexey Tourbin]

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

On Sat, Mar 17, 2007 at 10:33:11PM +0300, Dmitry V. Levin wrote:
> > То есть можно мониторить добавление новых пользователей?  Но добавление
> > новых пользователей можно мониторить и без inotify.  К сожалению я
> > сейчас не в состоянии вникнуть в inotify(7).  В худшем случае можно
> > мониторить mtime подкаталогов, т.е. гипотетическую активность
> > пользователей.  Но своего рода активность пользователей можно
> > мониторить штатно через last(1).
> 
> Например, можно мониторить залогинивание пользователей (в т.ч.
> неинтерактивных, например посредством crond), причем без poll'инга.

Как же их можно мониторить, если они не создают временных файлов,
а каталог не удаляется?  Мониторить можно только mtime подкаталога!
Я охотно допускаю, что чего-то не понимаю, но и объяснение здесь
интересно не только мне.  Слово "мониторить" нужно уточнить.  Мониторить
сам факт моего существования, новость о наличии как таковых продуктов
моей жизнедеятельности смысла нет.

> > В общем, выгода от нечитаемости /tmp/.private слишком призрачна,
> > а привет слишком большой.
> 
> Я же сказал, что ручка управления правами /tmp/.private (раньше или позже)
> будет.  Просто сейчас у upstream maintainer'ов другие приоритеты не дают
> реализовать эту возможность достаточно быстро.  Если кто-то может помочь
> патчем, который можно будет принять без переписывания, то я буду очень
> рад.

Хорошо.  Я хотел сказать, что лучше сделать /tmp/.private/ по
умолчанию 755, не считая chattr.  Иначе следует обсудить прежде всего
права доступа на каталог /home.  А если сделать /home 711 root:root то
какой-нибудь стандартно-левый getcwd() всплывет гораздо быстрее.

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Dmitry V. Levin]

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

On Sat, Mar 17, 2007 at 10:31:38PM +0200, Michael Shigorin wrote:
> Возможно ли сделать так, чтобы в серверном варианте дистрибутива
> было как тебе видней, а в "общего назначения" -- off by default?

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

Что касается серверного дистрибутива, то применение pam_mktemp там я
вижу совершенно оправданным.

Что касается дистрибутивов других профилей, то я хуже представляю себе
потенциальных пользователей этих продуктов.

> На системах общего назначения, в первую очередь десктопных --
> поверь на слово, ~/tmp by default лучше по многим причинам
> (скажи, где "здесь", расчертим-обсудим).

Ну раз зашёл разговор в этом списке, пусть будет в этом.
Только не в bugzilla.

> /* Это достаточно разумное умолчание общего плана, в отличие
>    от предположения высокой сознательности и компетентности
>    администратора и пользователей системы.  Один раз засунув 
>    впопыхах уникальный файлик в /tmp и вспомнив только когда 
>    он был прибит stmpclean'ом (M20), довольно хорошо помню
>    эмоции, которые в моём случае достались мне же, а в общем
>    -- стоит ожидать неконкретных жалоб на "теряющий данные 
>    альт" в публичных местах. */

Всё таки есть небольшая разница между $TMPDIR и $HOME/tmp:
Первый каталог предназначен для создания временных файлов с помощью
mkstemp(3) и ей подобными средствами; пользователь может и не знать о том,
когда эти файлы создаются и удаляются.
Второй каталог, видимо, предназначен для создания файлов пользователем
самостоятельно, при этом временность этих файлов определяет сам
пользователь.
Конечно, сисадмин и/или пользователь может сделать так, чтобы
$TMPDIR и $HOME/tmp совпадали (либо установив $TMPDIR равным $HOME/tmp,
либо сделав $HOME/tmp ссылкой на $TMPDIR).

> > > - изменяется баланс расхода дискового пространства;
> > Это является минусом только когда дисковое пространство не
> > готово для изменения баланса.
> 
> Проблема в том, что изменение разбивки обычно не является
> тривиальной задачей.  Особенно с учётом того, что "физический"
> /tmp живёт или на корне (худший и распространённый вариант),
> или в "быстром" начале диска.  Как и своп -- никак не в конце,
> где разделы таскать удобнее.

Я не призываю менять разбивку сразу.  Выключить pam_mktemp несложно.

> > > - изменения возможно избежать только необновлением системы;
> > Это не соответствует действительности.
> 
> В контексте _системы_ -- соответствует.  Аргументация вроде 
> того, что против каждого изменения можно, уже зная его, настелить
> соломы (сделать фейковый pam_mktemp.so, /etc/profile.d/tmpdir.sh
> -- как вот приходится, или иные контрмеры), непродуктивна.

Правильная системная ручка находится в system-auth.

> > > - переконфигурирование требует заметной компетенции;
> > Это субъективно и при необходимости может быть улучшено.
> 
> Так начинать стоило с этого "улучшено".

Невозможно начинать с улчшения того, что сперва не выглядит
нуждающимся в улучшении.

> > > * Доводов много, чтобы их здесь приводить. [ldv]
> > Ключевое слово "здесь".
> 
> Ну "здесь" спрашивал sbolshakov@:
> https://bugzilla.altlinux.org/show_bug.cgi?id=6814#c2

Мне не удобно вести обсуждения в bugzilla по чисто техническим причинам.
Вероятно, не мне одному.

> Приведи здесь, в sisyphus@.  Или скажи, где будет продуктивно.

Вроде бы привёл в предыдущем письме (мысленно собери все свои и мои +).

> > >   drwxrwx--T  2 root raorn 4096 Jun  4 18:53 /tmp/.private/raorn
> > >   [...]
> > >   Как насчёт пользователей с одной общей группой типа users?  [raorn]
> > У каждого пользователя всё равно есть своя личная группа.
> 
> Это очень субъективно.  В LDAP может быть одна-две на всех,
> из жизненных примеров.

Сисадмин, который использует LDAP таким образом, точно знает что он делает
и к каким последствиям это приведёт.

> > > * Это общий "недостаток" практически у всех файл-селекторов: если
> > >   прав на чтение каталога нет, пользователь не сможет пройти через
> > >   него вверх или вниз. [...] [ktirf]
> > Я согласовал с автором pam_mktemp добавление параметра,
> > управляющего правами лоступа к каталогу /tmp/.private
> 
> Спасибо; это решает "правовую" часть проблемы (но оставляет
> "стораджевую").

В конце концов, отключить монтирование /tmp - это закомментировать одну
строку в /etc/fstab.

Между прочим, при создании ovz-контейнера эта строка комментируется.

> > > * Не один администратор рефлекторно настрожится при виде
> > >   неудаляемого скрытого каталога в общедоступном по записи /tmp.
> > >   На сейчас все эти неприятности прибиты гвоздями к pam0_config. [mike]
> > Неудаляемость имеет место быть не на всех файловых системах.
> > tmpfs не поддерживает эти атрибуты.
> 
> Да, в случае официально рекомендуемого tmpfs для /tmp эта
> проблема упрощается до "...при виде скрытого каталога в
> общедоступном по записи".
> 
> А квоты на tmpfs работают?

Нет.  На сервере с недоверенными пользователями это может быть причиной
ограничения доступа к /tmp или отказа от использования tmpfs под /tmp.

> > Другими словами, добавление control для system-auth и расширение
> > управляемости pam_mktemp должно снять возникшую напряжённость.
> > Так?
> 
> В достаточной мере.  Вопрос разумности смены умолчания остаётся
> при этом открытым.

OK, послушаем, какие ещё будут мнения.


-- 
ldv

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

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Vitaly Lipatov]

On 18 марта 2007, Dmitry V. Levin wrote:
...
> Что касается дистрибутивов других профилей, то я хуже
> представляю себе потенциальных пользователей этих продуктов.
Я хотел бы заметить, что в $TMPDIR, как я понимаю, хранится кэш 
konqueror например, который хотелось бы сохранять на домашней 
машине с dialup и частыми перезагрузками.


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-17 21:52 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-17 23:27 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-17 23:49 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 2:30 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 8:24 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 10:21 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 10:48 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 10:51 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 16:05 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 16:18 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 16:57 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 17:44 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 17:48 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 17:55 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 18:21 UTC (permalink / raw)]

[sisyphus] tmpfs usage

[@ 2007-03-18 19:00 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 19:49 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 21:04 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 21:08 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-18 21:09 UTC (permalink / raw)]

[sisyphus] [wiki] tmpfs

[@ 2007-03-18 21:23 UTC (permalink / raw)]

[sisyphus] system-auth и pam_mktemp

[@ 2007-03-18 21:36 UTC (permalink / raw)]

Re: [sisyphus] system-auth и pam_mktemp

[@ 2007-03-18 21:47 UTC (permalink / raw)]

Re: [sisyphus] [wiki] tmpfs

[@ 2007-03-18 21:53 UTC (permalink / raw)]

Re: [sisyphus] system-auth и pam_mktemp

[@ 2007-03-18 22:29 UTC (permalink / raw)]

Re: [sisyphus] system-auth и pam_mktemp

[@ 2007-03-18 22:36 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-19 6:54 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-20 9:02 UTC (permalink / raw)]

Re: [sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[@ 2007-03-21 6:03 UTC (permalink / raw)]

Re: [sisyphus] system-auth и pam_mktemp

[@ 2007-03-25 19:45 UTC (permalink / raw)]

Re: [sisyphus] system-auth и pam_mktemp

[@ 2007-04-05 21:58 UTC (permalink / raw)]