[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

[Alexey Tourbin]

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

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

Это аргумент не в пользу коквера, а в пользу сквида.  А что такое
домашняя машина и где вы видели dialup и нужно ли юникс часто выключать
это вопрос особый, у меня например аптайм up 5 days и это после
обновления ядра.

В общем, сохранение $TMPDIR в интересах частых перезагрузок это не
аргумент.  Или же специфический аргумент.

[-- 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: 2258 bytes --]

PreScriptum: так устроит?  works for me.

http://git.altlinux.org/people/mike/packages/?p=pam-config.git;a=commit;h=6a1463ee73843fca44000e0a3a837c9c83b63999
http://git.altlinux.org/people/mike/packages/?p=pam_mktemp.git;a=commit;h=12b86dd85e2421d13fc8766b4fb31091dab81d6a

PPS: извиняюсь за спам -- надо было сперва
ssh git.alt git-clone к себе, правильно?


On Sat, Mar 17, 2007 at 10:33:11PM +0300, Dmitry V. Levin wrote:
> > В общем, выгода от нечитаемости /tmp/.private слишком
> > призрачна, а привет слишком большой.
> Я же сказал, что ручка управления правами /tmp/.private (раньше
> или позже) будет.  Просто сейчас у upstream maintainer'ов
> другие приоритеты не дают реализовать эту возможность
> достаточно быстро.

Стоило ли вкатывать недоделанный софт в basesystem?
Я бы постарался проверить на себе при анонсе заранее.

> Если кто-то может помочь патчем, который можно будет принять
> без переписывания, то я буду очень рад.

На pam0_config?  Такой же ты не примешь...

--- system-auth.mktemp  2005-08-26 02:52:30 +0300
+++ system-auth 2007-03-18 00:12:06 +0200
@@ -1,7 +1,7 @@
 #%PAM-1.0
 auth     required      pam_tcb.so shadow fork prefix=$2a$ count=8 nullok
 account  required      pam_tcb.so shadow fork
-account  required      pam_mktemp.so
+account  optional      pam_mktemp.so
 password required      pam_passwdqc.so min=disabled,24,12,8,7 max=40 passphrase=3 match=4 similar=deny random=42 enforce=users retry=3
 password required      pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 nullok write_to=tcb
 session  required      pam_tcb.so

Если всё же да, то можно оторвать pam_mktemp от pam_config
и регулировать вопрос его установкой или сносом.  Почитал
sag-configuration-file и проверил, что при отсутствии модуля
и при его наличии отрабатывает правильно (соотв. $HOME/tmp,
/tmp/.private/$USER).

Тогда можно положить в pam_mktemp control facility имени raorn@:
https://bugzilla.altlinux.org/show_bug.cgi?id=6814#c23
(s/required/optional/g) -- и вроде как полный ажур.

Только не совсем понял по /usr/lib/rpm/pam.req --
оно выдаёт жёсткие зависимости на optional modules?

-- 
 ---- 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

[Michael Shigorin]

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

On Sun, Mar 18, 2007 at 12:14:23AM +0300, Dmitry V. Levin wrote:
> > Возможно ли сделать так, чтобы в серверном варианте дистрибутива
> > было как тебе видней, а в "общего назначения" -- off by default?
> Я не претендую на абсолютное знание того, как лучше сделать по
> умолчанию в том или ином продукте.  В этой ситуации я принимаю такое
> решение, которое, на мой взгляд, принесёт большинству потенциальных
> пользоваталей максимум пользы и минимум вреда.

Спасибо.  Надеюсь, ряд сходится.

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

Ага.

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

Я вполне представляю реальных в количествах порядка нескольких
десятков системных администраторов, разработчиков и пользователей.

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

Хорошо; техническое там, организационное -- тут.

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

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

Кстати, кнопкой "вверх" файлооткрывалок из ~/tmp пользователь
попадает домой, а вот из /tmp/.private/, даже если получится
пройти -- в знакомые окрестности добираться ещё далеко.

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

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

Да.  И хорошо бы это делать системно (воспроизводимо,
обратимо, персистентно).

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

Уже да. :)

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

Если хочешь -- пинай при малейших сомнениях в исправимости
производимых улучшений.  Постараюсь проверять и отвечать кратко.

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

Ммм... не спорю; только это не отменяет неприятной
подразумеваемости "пользователь--группа".

1700 $USER:root вместо 1770 root:$USER должно её убрать
и на первый взгляд не вносит неприятных эффектов (да и
патч насчёт sgid в glibc можно откатить?).

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

Тоже следует упомянуть в документации pam_mktemp, наверное.
Набросок здесь:

http://git.altlinux.org/people/mike/packages/?p=pam_mktemp.git;a=commit;h=d7768f30f6d580e66727582459bb211eb0205ba2

> > Вопрос разумности смены умолчания остаётся при этом открытым.
> OK, послушаем, какие ещё будут мнения.

Ну свой последний довод я закоммитил.  Фильтр на pam_mktemp
топорный, правда, но сейчас ничего лучше не придумалось.

-- 
 ---- 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

[Александр Гвоздев]

В сообщении от Суббота 17 марта 2007 Michael Shigorin написал(a):
> * /tmp оно на то и /tmp, что семантика у него другая, нежели у $HOME:
>   1. Данные из него могут быть удалены, если к ним не было
>      обращений в течении некоторого времени
>   2. Данные из него могут быть удалены при перезагрузке
>   3. На нём может быть noexec
>   4. Оно может быть на tmpfs ($HOME на tmpfs это просто волшебство)
>   [mithraen]
Согласен.
По опыту использования MentorGraphics Exdedition (разводка печатных плат) уже замучился чистить /tmp.
Оно само за собой убирать не умеет. Как и mc.

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

[Michael Shigorin]

On Sun, Mar 18, 2007 at 05:30:39AM +0300, Александр Гвоздев wrote:
> > * /tmp оно на то и /tmp, что семантика у него другая, нежели у $HOME:
> >   1. Данные из него могут быть удалены, если к ним не было
> >      обращений в течении некоторого времени
> >   2. Данные из него могут быть удалены при перезагрузке
> >   3. На нём может быть noexec
> >   4. Оно может быть на tmpfs ($HOME на tmpfs это просто волшебство)
> >   [mithraen]
> Согласен.
> По опыту использования MentorGraphics Exdedition (разводка
> печатных плат) уже замучился чистить /tmp.  Оно само за собой
> убирать не умеет. Как и mc.

Засуньте на tmpfs, если памяти хватает и между перезагрузками
данные там успевают стать ненужными; или поставьте и включите 
stmpclean.

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

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

[Хихин Руслан]

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

Здравствуйте Michael Shigorin
  В сообщении от 18 марта 2007 Michael Shigorin написал(a):
 > Засуньте на tmpfs, если памяти хватает

Вот - это самый интересный вопрос - какая должна быть память, какой Swap 
и какой размер отвести под /tmp для записи двухслойного DVD, например 
через K3b, который по-умолчанию кладёт образ в /tm/.private.. :)

По сути дискусси - я не понял самого главного 
- какая цель приследуются при переводе /tmp под tmpfs ? (предпологаю 
повышения быстродействия системы ?)

- в каких случаях это реально повышает быстродействие, а в каких нет ?

- как реальной программе указать, что в  /tmp/.private/ надо класть 
только данные на "одну перезагрузку".

 Реально на работе был хороший опыт работы с Linter - сделали скрипт, 
который перед его запуском  (в демоне) копировал из заданной папки 
содержимое файлов в tmpfs, а после отключения его (по stop) сохранял 
информацию опять на диске. Ну, естественно всё под UPS. - 
быстродействие его повысилось на порядок, хотя как и любая база данных, 
основную информацию он держит в своём сashe.  

-- 
С  уважением Хихин Руслан

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

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

[Хихин Руслан]

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

Здравствуйте Dmitry V. Levin
  В сообщении от 18 марта 2007 Dmitry V. Levin написал(a):
 > > Возможно ли сделать так, чтобы в серверном варианте дистрибутива
 > > было как тебе видней, а в "общего назначения" -- off by default?
Вот - тут слово  "off by default" ( в остатке ) важно.

Как бы хотелоссь :
{
case вариант1
....
case вариантN
....
default  
 вариант_по_умолчанию
}

Как обычно бывает :

if (не подходит вариант_по_умолчанию)
{
case вариант1
....
case вариантN
....
}



-- 
С  уважением Хихин Руслан

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

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

[Vyatcheslav Perevalov]

В сообщении от 18 марта 2007 03:52 Alexey Tourbin написал(a):
>  А что такое
> домашняя машина и где вы видели dialup и нужно ли юникс часто выключать
> это вопрос особый, у меня например аптайм up 5 days и это после
> обновления ядра.
1) Для домашнего десктопа вероятность выключения/перезагрузки в более другую 
ось/аварийного отключения питания сильно отличается от нуля. 
2) dialup - явление достаточно распространённое, чтобы им пренебрегать 
3) вопрос не стоит о необходимости частого выключения/перезагрузки 
операционной системы, вопрос идёт о машине, на которую эта система (наряду с 
другими) установлена.
-- 
Всего хорошего
		/vip

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

[Andrey Rahmatullin]

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

On Sun, Mar 18, 2007 at 12:43:31AM +0300, Vitaly Lipatov wrote:
> Я хотел бы заметить, что в $TMPDIR, как я понимаю, хранится кэш 
> konqueror например
И это печально, кстати.
Ибо это /var/cache, а не /tmp

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

> Даже если такому поведению startkde есть оправдание,
Есть объяснение, но оправдания нет.
		-- ldv in devel@

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

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

[Valery V. Inozemtsev]

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

В сообщении от 18 марта 2007 Andrey Rahmatullin написал(a):
> On Sun, Mar 18, 2007 at 12:43:31AM +0300, Vitaly Lipatov wrote:
> > Я хотел бы заметить, что в $TMPDIR, как я понимаю, хранится кэш
> > konqueror например
>
> И это печально, кстати.
> Ибо это /var/cache, а не /tmp

у меня вот такой костыль
$ cat ~/.xsession.d/kdecache
#!/bin/sh

if [ ! -d $TMPDIR/kdecache-$USER/favicons ] || [ ! -d $TMPDIR/kdecache-$USER/http ]; then
        mkdir -p $TMPDIR/kdecache-$USER
        ln -fs $HOME/.kde/share/kde/cache/{favicons,http} $TMPDIR/kdecache-$USER/
fi

-- 
Valery V. Inozemtsev

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

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

[Sergey]

On Sunday 18 March 2007, Alexey Tourbin wrote:

> А что такое домашняя машина

Это компьютер, который стоит дома. Где ещё, иногда, спят. Часто домом
называют квартиру, иногда, даже, однокомнатную. Впрочем, и двухкомнвтные
бывают не на столько большими, чтобы шум из соседней комнаты не слышать.
А компьютер шумит...

> и где вы видели dialup 

$ps ax|grep ppp
<skip>
 7549 ttyS0    Ss+    0:00 pppd 115200 -detach crtscts defaultroute usepeerdns user asy
<skip>

:-)

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

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

[Ivan Adzhubey]

On Sunday 18 March 2007 06:21:30 am Хихин Руслан wrote:
> Здравствуйте Michael Shigorin
>
>   В сообщении от 18 марта 2007 Michael Shigorin написал(a):
>  > Засуньте на tmpfs, если памяти хватает
>
> Вот - это самый интересный вопрос - какая должна быть память, какой Swap
> и какой размер отвести под /tmp для записи двухслойного DVD, например
> через K3b, который по-умолчанию кладёт образ в /tm/.private.. :)

Ну наконец-то хоть кто-то меня поддержал ;-) А то дискуссия стремительным 
домкратом ушла в направлении обсуждения /tmp/.private, то есть мелких 
деталей, которые меня пока не интересуют совершенно, а на мои вопросы, с 
которых этот тред начался, господа разработчики забили.

> По сути дискусси - я не понял самого главного
> - какая цель приследуются при переводе /tmp под tmpfs ? (предпологаю
> повышения быстродействия системы ?)
>
> - в каких случаях это реально повышает быстродействие, а в каких нет ?

Вот-вот. В чем идея-то?? И как реализация на tmpfs практически повлияет на 
сервер/кластер работающий с 80 гигабайтами временных файлов в /tmp? Правильно 
я понимаю, что в таком случае ни о каком /tmp на tmpfs не может идти речи? А 
когда может? Когда начинает расти производительность, а когда - падать? 
Кто-нибудь вооще это мерял?

--Иван

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

[Sergey S. Skulachenko]

On Sun, 18 Mar 2007 20:57:28 +0400
Sergey wrote:

> бывают не на столько большими, чтобы шум из соседней комнаты
> не слышать. А компьютер шумит...

Нет, не шумит, если:
1. Блок питания заменить на ATX 420W Thermaltake Silent
PureRower (W0009RE) с двумя вентиляторами, скорость вращения
которых управляется температурой проточного воздуха;
2. Применением системной платы, на которой есть управление
вентилятором процессора по его температуре, правильным выбором
вентилятора.
В результате - чистое наслаждение. Игра стОит свеч, хоть это и
пас в сторону. Но обмен опытом, к этому не быстро приходишь,
не с первого захода...

-- 
С уважением,
С.С.Скулаченко

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

[Хихин Руслан]

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

Здравствуйте Sergey S. Skulachenko
  В сообщении от 18 марта 2007 Sergey S. Skulachenko написал(a):
 > В результате - чистое наслаждение. Игра стОит свеч, хоть это и
 > пас в сторону. Но обмен опытом, к этому не быстро приходишь,
 > не с первого захода.
Ну не всем нравится дома постоянно включённый компьютер :)

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

-- 
С  уважением Хихин Руслан

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

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

[Хихин Руслан]

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

Здравствуйте Ivan Adzhubey
  В сообщении от 18 марта 2007 Ivan Adzhubey написал(a):
 > Вот-вот. В чем идея-то?? И как реализация на tmpfs практически
 > повлияет на
 > сервер/кластер работающий с 80 гигабайтами временных файлов в /tmp?
 > Правильно
 > я понимаю, что в таком случае ни о каком /tmp на tmpfs не может идти
 > речи? А  когда может? Когда начинает расти производительность, а
 > когда -   падать?
> Кто-нибудь вооще это мерял?

Ну мерить, собственно не мерил.
Вот что я сделал :
Создал два SWAP раздела объёмом 12Гб + плюс память у меня около 2Гб,
для /tmp в tmpfs задал объём в 20Гб (что-бы не прервать опыт по причине 
заполнения всего tmpfs), и начал с помощью mc закачивать
 в /tmp  файлы с внешнего USB. 

Естественно скорость закачки определялась узким местом - в данном случае 
скоростью чтения с USB, так что выигрышного участка я не видел 
(предпологаю - где-то до 1.5 - 2 Гб скорость), при заполненности tmpfs  
около 2Гб, начал заполняться swap (я так понимаю, скорость начала 
определяться скоростью записи на жёсткий диск в swap), до 12Gb скорость 
была приемлема (соизмеримая со скоростью жесткого диска), дальше начала 
снижаться и при 14 Гб сравнилась со скоростью Dialup-модема, после чего 
работатьна компе стало невозможно (ядро только и занималось свопом), 
после чего я прекратил опыт и перезагрузился.

Отсюда делаю выводы - выигрыш при заполненности tmpfs до размера 
(0,7-1,0) ОЗУ, в интервале до размера swap (+0,xxx ОЗУ) - на уровне 
работы жёсткого диска, дальше тормоза (снижение скорости).

-- 
С  уважением Хихин Руслан

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

[sisyphus] tmpfs usage

[Michael Shigorin]

On Sun, Mar 18, 2007 at 01:44:33PM -0400, Ivan Adzhubey wrote:
> >  > Засуньте на tmpfs, если памяти хватает
> > Вот - это самый интересный вопрос - какая должна быть память, какой Swap
> > и какой размер отвести под /tmp для записи двухслойного DVD, например
> > через K3b, который по-умолчанию кладёт образ в /tm/.private.. :)
> Ну наконец-то хоть кто-то меня поддержал ;-) А то дискуссия
> стремительным домкратом ушла в направлении обсуждения
> /tmp/.private, то есть мелких деталей, которые меня пока не
> интересуют совершенно, а на мои вопросы, с которых этот тред
> начался, господа разработчики забили.

Простите, там получился перевязанный пучок трёх проблем:

- /tmp/... vs /home/.../tmp
- tmpfs vs filesystem
- сервер vs десктоп

> > По сути дискусси - я не понял самого главного
> > - какая цель приследуются при переводе /tmp под tmpfs ?
> > (предпологаю повышения быстродействия системы ?)

Насколько понимаю, мало кто делает выделенный раздел /tmp.

Таким образом, он оказывается на корне (мало кто делает
bind mount /var/tmp туда, а те немногие -- уже ходили 
в багзилу с жалобами на mount).

Отсюда забитие /tmp порождает забитие / со всеми вытекающими.

Выход: отрезать отдельный раздел, который будет преимущественно
"гулять", или снизить использование /tmp.

Первый вариант реализуется /tmp на tmpfs, которая живёт в 
RAM+swap; увеличив своп на размер потенциально выделенного под
отдельный /tmp дискового пространства, получаем одним байтом
двоих зайцев: когда нужен своп, это место будет использовано
под него; когда нужен /tmp -- под него.

Более динамическое использование ресурса -- ср. с необходимостью
забивать руками при сборке ядра выделение памяти под page cache
в OpenBSD несколько лет тому против линуксового динамического.

> > - в каких случаях это реально повышает быстродействие,
> > а в каких нет ?

В тех, когда работа с временными файлами напряжённая.

> Вот-вот. В чем идея-то?? И как реализация на tmpfs практически
> повлияет на сервер/кластер работающий с 80 гигабайтами
> временных файлов в /tmp? Правильно я понимаю, что в таком
> случае ни о каком /tmp на tmpfs не может идти речи?

Скорее да.

> А когда может? Когда начинает расти производительность, а когда
> - падать?  Кто-нибудь вооще это мерял?

Можно попробовать поставить такой эксперимент (тут тоже по 80Gb
в /tmp при RAM 8Gb), но мне почему-то кажется более осмысленным
на такие /tmp совать reiserfs -o notail,noatime.

Возможно, потому, что баланс объёма данных и типичной работы 
с ними тут скорее отличается от "положить одну исошку" или даже
"собрать kde".

-- 
 ---- 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: 1440 bytes --]

On Sun, Mar 18, 2007 at 01:44:33PM -0400, Ivan Adzhubey wrote:
[...]
> Вот-вот. В чем идея-то?? И как реализация на tmpfs практически повлияет на 
> сервер/кластер работающий с 80 гигабайтами временных файлов в /tmp? Правильно 
> я понимаю, что в таком случае ни о каком /tmp на tmpfs не может идти речи? А 
> когда может? Когда начинает расти производительность, а когда - падать? 

Зависит от характера работы.

Типичный для сборочного сервера характер работы такой:
- несколько гигабайт RAM;
- tmpfs на 8*N гигабайт (где N - это число параллельных сборок);
  около 8G нужно для сборки OOo, остальным надо меньше;
- swap размером 2*RAM+sizeof(tmpfs).

При этом производительность заметно выше чем если бы сборка велась на
обычной файловой системе.  Разумеется, чем больше занят swap, тем ниже
выигрыш в производительности.

Что касается падения производительности, то при наличии достаточного
свободного места в swap'е я этого падения не замечал.  Мне _кажется_, что
этого свободного места должно быть не меньше чем размера RAM.

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

> Кто-нибудь вооще это мерял?

Я попробую специально замерить производительность в ситуации, когда
заполненная часть tmpfs больше размера RAM в 4, 8, 16, 32, 64, 128 раз.


-- 
ldv

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

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

[Александр Гвоздев]

В сообщении от Воскресенье 18 марта 2007 Sergey S. Skulachenko написал(a):
> On Sun, 18 Mar 2007 20:57:28 +0400
> Sergey wrote:
> 
> > бывают не на столько большими, чтобы шум из соседней комнаты
> > не слышать. А компьютер шумит...
> 
> Нет, не шумит, если:
> 1. Блок питания заменить на ATX 420W Thermaltake Silent
> PureRower (W0009RE) с двумя вентиляторами, скорость вращения
> которых управляется температурой проточного воздуха;
> 2. Применением системной платы, на которой есть управление
> вентилятором процессора по его температуре, правильным выбором
> вентилятора.
> В результате - чистое наслаждение. Игра стОит свеч, хоть это и
> пас в сторону. Но обмен опытом, к этому не быстро приходишь,
> не с первого захода...
> 
Вышеуказанный комплект железяк продавать вместе с коробкой дистрибутива? :)
У меня дома много компов (сервак, бук жены, два тестовых тазика, мой) и все шумят.
Тихо, но заметно. Особенно в однокомнатной квартире. Так что на ночь всё, кроме сервера выключается.
На работе - вообще молчу. Там 2x Xeon в качестве десктопа.

Насчёт перезагрузок: отлаживал драйвер одной самосборной железяки - перезагружался (по ресету) каждые 5-7 минут.
И так около месяца :). На то он и десктоп, вообще-то, чтоб работать с 10 до 18 часов :).

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

[Dmitry V. Levin]

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

On Sun, Mar 18, 2007 at 01:27:03AM +0200, Michael Shigorin wrote:
> PreScriptum: так устроит?  works for me.
> 
> http://git.altlinux.org/people/mike/packages/?p=pam-config.git;a=commit;h=6a1463ee73843fca44000e0a3a837c9c83b63999
> http://git.altlinux.org/people/mike/packages/?p=pam_mktemp.git;a=commit;h=12b86dd85e2421d13fc8766b4fb31091dab81d6a

Это не совсем правильно:
1. control для system-auth не стоит помещать в pam_mktemp.
Я думал сделать отдельный пакет и поставить его в зависимость пакету
pam-config.
2. Не стоит отрывать зависимость на pam_mktemp.  Если есть шанс того,
что пакет потеряется, будучи используемым, то лучше этот шанс занулить.

> On Sat, Mar 17, 2007 at 10:33:11PM +0300, Dmitry V. Levin wrote:
> > > В общем, выгода от нечитаемости /tmp/.private слишком
> > > призрачна, а привет слишком большой.
> > Я же сказал, что ручка управления правами /tmp/.private (раньше
> > или позже) будет.  Просто сейчас у upstream maintainer'ов
> > другие приоритеты не дают реализовать эту возможность
> > достаточно быстро.
> 
> Стоило ли вкатывать недоделанный софт в basesystem?

Это pam_mktemp недоделанный? :)
Уважаемые люди его уже несколько лет используют. ;)

> > Если кто-то может помочь патчем, который можно будет принять
> > без переписывания, то я буду очень рад.
> 
> На pam0_config?  Такой же ты не примешь...

Я имел в виду сам pam_mktemp (две новые возможности в нём), а не
pam0_config.

> --- system-auth.mktemp  2005-08-26 02:52:30 +0300
> +++ system-auth 2007-03-18 00:12:06 +0200
> @@ -1,7 +1,7 @@
>  #%PAM-1.0
>  auth     required      pam_tcb.so shadow fork prefix=$2a$ count=8 nullok
>  account  required      pam_tcb.so shadow fork
> -account  required      pam_mktemp.so
> +account  optional      pam_mktemp.so
>  password required      pam_passwdqc.so min=disabled,24,12,8,7 max=40 passphrase=3 match=4 similar=deny random=42 enforce=users retry=3
>  password required      pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 nullok write_to=tcb
>  session  required      pam_tcb.so
[...]
> Только не совсем понял по /usr/lib/rpm/pam.req --
> оно выдаёт жёсткие зависимости на optional modules?

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

Я думаю, что пакет pam_mktemp пусть лучше будет сам по себе, а управление
system-auth -- само по себе.


-- 
ldv

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

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

[Александр Гвоздев]

В сообщении от Воскресенье 18 марта 2007 Michael Shigorin написал(a):
> On Sun, Mar 18, 2007 at 05:30:39AM +0300, Александр Гвоздев wrote:
> > > * /tmp оно на то и /tmp, что семантика у него другая, нежели у $HOME:
> > >   1. Данные из него могут быть удалены, если к ним не было
> > >      обращений в течении некоторого времени
> > >   2. Данные из него могут быть удалены при перезагрузке
> > >   3. На нём может быть noexec
> > >   4. Оно может быть на tmpfs ($HOME на tmpfs это просто волшебство)
> > >   [mithraen]
> > Согласен.
> > По опыту использования MentorGraphics Exdedition (разводка
> > печатных плат) уже замучился чистить /tmp.  Оно само за собой
> > убирать не умеет. Как и mc.
> 
> Засуньте на tmpfs, если памяти хватает и между перезагрузками
> данные там успевают стать ненужными; или поставьте и включите 
> stmpclean.
> 
Это было очень давно, про stmpclean я тогда не знал :)
Написал своё, с аналогичным эффектом. Туда же входил `apt-get autoclean`

сейчас поставил на tmpfs. Работает.
Всё-таки tmp - это tmp. Как было правильно отмечено рядом: cache - это /var/cache.

[sisyphus] [wiki] tmpfs

[Michael Shigorin]

On Sun, Mar 18, 2007 at 10:49:53PM +0300, Dmitry V. Levin wrote:
> > Вот-вот. В чем идея-то?? И как реализация на tmpfs
> Зависит от характера работы.

Так... добавил сюда:
http://www.freesource.info/wiki/AltLinux/Dokumentacija/TmpFS

Хорошо бы ещё краткое введение нарисовать.

PS: это кросспост, просьба отвечать в один список.

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

[sisyphus] system-auth и pam_mktemp

[Michael Shigorin]

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

On Mon, Mar 19, 2007 at 12:08:06AM +0300, Dmitry V. Levin wrote:
> > PreScriptum: так устроит?  works for me.
> > http://git.altlinux.org/people/mike/packages/?p=pam-config.git;a=commit;h=6a1463ee73843fca44000e0a3a837c9c83b63999
> > http://git.altlinux.org/people/mike/packages/?p=pam_mktemp.git;a=commit;h=12b86dd85e2421d13fc8766b4fb31091dab81d6a
> Это не совсем правильно:
> 1. control для system-auth не стоит помещать в pam_mktemp.

Знаю, но пока ничего лучше не придумал.

> Я думал сделать отдельный пакет и поставить его в зависимость
> пакету pam-config.

А чем это отличается от засовывания в pam-config?

> 2. Не стоит отрывать зависимость на pam_mktemp.  Если есть шанс
> того, что пакет потеряется, будучи используемым, то лучше этот
> шанс занулить.

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

> > On Sat, Mar 17, 2007 at 10:33:11PM +0300, Dmitry V. Levin wrote:
> > > Я же сказал, что ручка управления правами /tmp/.private
> > > (раньше или позже) будет.  Просто сейчас у upstream
> > > maintainer'ов другие приоритеты не дают реализовать эту
> > > возможность достаточно быстро.
> > Стоило ли вкатывать недоделанный софт в basesystem?
> Это pam_mktemp недоделанный? :)

Да, сэр! :)

> Уважаемые люди его уже несколько лет используют. ;)

Уважаемые люди таки могли бы уже сказать, что с правилом
Linux 2.x.20, поговаривают о незавозе ow patch. :)

Если серьёзно, то доделанность в рамках Owl может оказаться
недостаточной в более широком случае, что и наблюдаем.

> > > Если кто-то может помочь патчем, который можно будет
> > > принять без переписывания, то я буду очень рад.
> > На pam0_config?  Такой же ты не примешь...
> Я имел в виду сам pam_mktemp (две новые возможности в нём),
> а не pam0_config.

Да понял, понял, просто туда лезть совсем не с руки.

> optional можно использовать для указания несуществующих
> модулей, но это не совсем то, для чего optional был придуман.

За мной приедут? :)

> Да и ругань в логе будет приличная.

Ммм... а, /var/log/auth/secure:
Mar 18 00:11:55 home su[13630]: PAM [error: /lib/security/pam_mktemp.so: cannot open shared object file: No such file or directory]

Некрасиво.

> Я думаю, что пакет pam_mktemp пусть лучше будет сам по себе,
> а управление system-auth -- само по себе.

Хорошо, что в итоге делаем?  К system-auth там ещё минимум
один кандидат на потрогать есть, про ldap.

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

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

Re: [sisyphus] system-auth и pam_mktemp

[Dmitry V. Levin]

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

On Sun, Mar 18, 2007 at 11:36:17PM +0200, Michael Shigorin wrote:
> On Mon, Mar 19, 2007 at 12:08:06AM +0300, Dmitry V. Levin wrote:
[...]
> > Я думал сделать отдельный пакет и поставить его в зависимость
> > пакету pam-config.
> 
> А чем это отличается от засовывания в pam-config?

Решает проблему обновления с "неподконтрольной" версии.
Историю с "su" помнишь?  Зачем наступать на эти грабли снова?

> > > > Если кто-то может помочь патчем, который можно будет
> > > > принять без переписывания, то я буду очень рад.
> > > На pam0_config?  Такой же ты не примешь...
> > Я имел в виду сам pam_mktemp (две новые возможности в нём),
> > а не pam0_config.
> 
> Да понял, понял, просто туда лезть совсем не с руки.

Я не ограничивал кандидатов.  Если хотите, это мой тест на пригодность
к выполнению определённого вида работ.

> Хорошо, что в итоге делаем?

pam-config-control.


-- 
ldv

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

Re: [sisyphus] [wiki] tmpfs

[Mikhail Yakshin]

Michael Shigorin wrote:
> On Sun, Mar 18, 2007 at 10:49:53PM +0300, Dmitry V. Levin wrote:
>>> Вот-вот. В чем идея-то?? И как реализация на tmpfs
>> Зависит от характера работы.
> 
> Так... добавил сюда:
> http://www.freesource.info/wiki/AltLinux/Dokumentacija/TmpFS
> 
> Хорошо бы ещё краткое введение нарисовать.
> 
> PS: это кросспост, просьба отвечать в один список.

Еще
http://www.freesource.info/wiki/ALTLinux/Dokumentacija/Hasher/Speed

Хотя, судя по правкам, я вижу, что эту страницу уже нашли :)

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [sisyphus] system-auth и pam_mktemp

[Michael Shigorin]

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

On Mon, Mar 19, 2007 at 12:47:00AM +0300, Dmitry V. Levin wrote:
> > > Я думал сделать отдельный пакет и поставить его в зависимость
> > > пакету pam-config.
> > А чем это отличается от засовывания в pam-config?
> Решает проблему обновления с "неподконтрольной" версии.
> Историю с "su" помнишь?  Зачем наступать на эти грабли снова?

Не помню, можешь описать "изнутри"?

> > Хорошо, что в итоге делаем?
> pam-config-control.

Ты/я?

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

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

Re: [sisyphus] system-auth и pam_mktemp

[Dmitry V. Levin]

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

On Mon, Mar 19, 2007 at 12:29:47AM +0200, Michael Shigorin wrote:
> On Mon, Mar 19, 2007 at 12:47:00AM +0300, Dmitry V. Levin wrote:
> > > > Я думал сделать отдельный пакет и поставить его в зависимость
> > > > пакету pam-config.
> > > А чем это отличается от засовывания в pam-config?
> > Решает проблему обновления с "неподконтрольной" версии.
> > Историю с "su" помнишь?  Зачем наступать на эти грабли снова?
> 
> Не помню, можешь описать "изнутри"?

Для того, чтобы пакет обновился нормально, нужно выполнить %pre_control
в секции %pre и %post_control в секции %post.

Для того, чтобы выполнить %pre_control, файл описания control'а должен
быть на месте.

Таким образом, файл /etc/control.d/facilities/pam_mktemp должен быть
установлен до обновления пакета pam-config.

Этого можно добиться, запаковав этот файл в отдельный пакет и поставив
этот пакет в зависимость пакета pam-config.

> > > Хорошо, что в итоге делаем?
> > pam-config-control.
> 
> Ты/я?

Если хочешь потренироваться, то я только за.
В принципе Raorn уже всю черновую работу сделал.


-- 
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: 1926 bytes --]

On Sun, Mar 18, 2007 at 01:44:33PM -0400, Ivan Adzhubey wrote:
> Ну наконец-то хоть кто-то меня поддержал ;-) А то дискуссия стремительным 
> домкратом ушла в направлении обсуждения /tmp/.private, то есть мелких 
> деталей, которые меня пока не интересуют совершенно, а на мои вопросы, с 
> которых этот тред начался, господа разработчики забили.
> 
> > По сути дискусси - я не понял самого главного
> > - какая цель приследуются при переводе /tmp под tmpfs ? (предпологаю
> > повышения быстродействия системы ?)
> >
> > - в каких случаях это реально повышает быстродействие, а в каких нет ?
> 
> Вот-вот. В чем идея-то?? И как реализация на tmpfs практически повлияет на 
> сервер/кластер работающий с 80 гигабайтами временных файлов в /tmp? Правильно 

Я измерял производительность sqlite3 на одном достаточно сложном запросе
(могу раскопать сам запрос и объяснить, как всё это запустить).  sqlite 
пишет write-ahead log с честным fdatasync(2).  На tmpfs этот запрос
отрабатывался в 60 раз быстрее, чем на ext3.  Несколько минут против
четырех часов.

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

> я понимаю, что в таком случае ни о каком /tmp на tmpfs не может идти речи? А 
> когда может? Когда начинает расти производительность, а когда - падать? 
> Кто-нибудь вооще это мерял?

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

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

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

[Ildar Mulyukov]

On 18.03.2007 16:21:30, Хихин Руслан wrote:
> - как реальной программе указать, что в  /tmp/.private/ надо класть
> только данные на "одну перезагрузку".

Полагаю, проблема уже решена, т.к. в 3.0 по умолчанию стоит stmpclean,  
который делает ровно то же самое, что и tmpfs

-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

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

[Хихин Руслан]

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

Здравствуйте Ildar Mulyukov
  В сообщении от 20 марта 2007 Ildar Mulyukov написал(a):
 > On 18.03.2007 16:21:30, Хихин Руслан wrote:
 > > - как реальной программе указать, что в  /tmp/.private/ надо
 > > класть только данные на "одну перезагрузку".
 >
 > Полагаю, проблема уже решена, т.к. в 3.0 по умолчанию стоит
 > stmpclean,
 > который делает ровно то же самое, что и tmpfs
Не понял я ответа :)
Если stmpclen удалит, например, нужный мне образ DVD, созданный k3b, то 
кто за это ответит :)  

-- 
С  уважением Хихин Руслан

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

Re: [sisyphus] system-auth и pam_mktemp

[Michael Shigorin]

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

On Mon, Mar 19, 2007 at 01:36:02AM +0300, Dmitry V. Levin wrote:
> > > > > Я думал сделать отдельный пакет и поставить его в зависимость
> > > > > пакету pam-config.
> > > > А чем это отличается от засовывания в pam-config?
> > > Решает проблему обновления с "неподконтрольной" версии.
> > > Историю с "su" помнишь?  Зачем наступать на эти грабли снова?
> > Не помню, можешь описать "изнутри"?
> Для того, чтобы пакет обновился нормально, нужно выполнить
> %pre_control в секции %pre и %post_control в секции %post.
> Для того, чтобы выполнить %pre_control, файл описания control'а
> должен быть на месте.
> Таким образом, файл /etc/control.d/facilities/pam_mktemp должен
> быть установлен до обновления пакета pam-config.
> Этого можно добиться, запаковав этот файл в отдельный пакет и
> поставив этот пакет в зависимость пакета pam-config.
> > > > Хорошо, что в итоге делаем?
> > > pam-config-control.
> > Ты/я?
> Если хочешь потренироваться, то я только за.

Надеялся на той неделе, но она вышла дурацкая.

> В принципе Raorn уже всю черновую работу сделал.

За что ему и спасибо.  Можешь завернуть итог?

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

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

Re: [sisyphus] system-auth и pam_mktemp

[Dmitry V. Levin]

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

On Sun, Mar 25, 2007 at 10:45:19PM +0300, Michael Shigorin wrote:
> On Mon, Mar 19, 2007 at 01:36:02AM +0300, Dmitry V. Levin wrote:
> > > > > > Я думал сделать отдельный пакет и поставить его в зависимость
> > > > > > пакету pam-config.
> > > > > А чем это отличается от засовывания в pam-config?
> > > > Решает проблему обновления с "неподконтрольной" версии.
> > > > Историю с "su" помнишь?  Зачем наступать на эти грабли снова?
> > > Не помню, можешь описать "изнутри"?
> > Для того, чтобы пакет обновился нормально, нужно выполнить
> > %pre_control в секции %pre и %post_control в секции %post.
> > Для того, чтобы выполнить %pre_control, файл описания control'а
> > должен быть на месте.
> > Таким образом, файл /etc/control.d/facilities/pam_mktemp должен
> > быть установлен до обновления пакета pam-config.
> > Этого можно добиться, запаковав этот файл в отдельный пакет и
> > поставив этот пакет в зависимость пакета pam-config.
> > > > > Хорошо, что в итоге делаем?
> > > > pam-config-control.
> > > Ты/я?
> > Если хочешь потренироваться, то я только за.
> 
> Надеялся на той неделе, но она вышла дурацкая.
> 
> > В принципе Raorn уже всю черновую работу сделал.
> 
> За что ему и спасибо.  Можешь завернуть итог?

1.4.0-alt1


-- 
ldv

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