Re: Что почитать о мон тировании сменных носителей?
,-[Sun, Oct 04, 2009 at 15:26 +0300, Aleksey Cheusov:] | Здравствуйте! | | Прошу совета -- что почитать о всём том хозяйстве, которое | занимается в debian lenny мнотированием сменных носителей. | |Выбрасываешь это чудише на основе HAL к чертям и монтируешь с помощью |autofs/am-utils на выбор. | |Пример конфигов на основе autofs: | |/etc/auto.misc: а можно ли с autofs задудонить выполнение некоего скрипта при подсоединении некоего устройства ? почитал хауту: привязка типа программа должна лишь рожать текст с опциями монтирования устройств. а то ужасно хочется, чтоб книжка синхронизировалась при примонтировании. и не вижу в автофс возможности mountexec ) -- __ mpd status: [playing] di_music/torrents/Ted Nugent - Ted Nugent[torrents.ru]/01 Stranglehold.flac ** * jabber: devil_ins...@jabber.ru * * Registered linux user #450844* ** -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Что почитать о мон тировании сменных носителей?
,-[Wed, Nov 04, 2009 at 23:07 +0300, Artem Chuprina:]
|Evgeniy M. Solodookhin - debian-russian@lists.debian.org @ Wed, 4 Nov 2009
22:39:21 +0300:
|
| EMS а можно ли с autofs задудонить выполнение некоего скрипта при
| EMS подсоединении некоего устройства ?
|
|Нет. Это не его дело.
|
|Его дело - подмонтировать _файловую систему_ при обращении к ней. А на
|подсоединение устройства - это проще всего чем-нибудь типа
|
|#!/usr/bin/perl
|my $found;
|while (1) {
|if (-f '/dev/disk/by-.../...') {
|system('/the/script') if !$found; # вот тут и пригодится autofs
|found=1;
|} else {
|found=0;
|}
|sleep(1);
|}
|
|--
|Нужны две программы - одна с интерфейсом, а другая чтобы работу делала.
| Victor Wagner в aut24i$gc...@wagner.wagner.home
|
спасибо, почему-то так и думал
)
--
__
mpd status: [paused]
di_music/torrents/Ted Nugent - Ted Nugent[torrents.ru]/05 Snakeskin Cowboys.flac
**
* jabber: devil_ins...@jabber.ru *
* Registered linux user #450844*
**
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Что почитать о мон тировании сменных носителей?
On Tue, Oct 06, 2009 at 08:49:50PM +0400, Alexander Galanin wrote: On Tue, 6 Oct 2009 00:40:26 +0400 Stanislav Maslovski stanislav.maslov...@gmail.com wrote: Тут сначала надо бы разобраться необходимо ли вообще предохраняться от race. В документации не очень внятно написано про порядок вызова callouts для _разных_ устройств. Т.е., может ли быть так, что cleanup скрипт еще не завершился (стартует по факту создания записи /org/freedesktop/Hal/devices/computer), а hal-autofs(add) уже выполняется (стартует по факту втыкания флешки). Кстати, как я сейчас вижу, мое решение вовсе не избавляет от этого race condition, если на момент запуска hal-autofs(add) в /media/ _отсутствует_ симлинк c именем `basename $UDI`. Нужен семафор. Второй момент -- может ли по каким-то причинам реализоваться ситуация, когда hal-autofs(remove) еще не завершился, а hal-autofs(add) уже стартовал для того же девайса (выдернули и тут же воткнули флешку). От этого мое решение предохраняет (даже если удаление не отработает то и зацикливание на ожидании не страшно -- hald прибивает подвисшие callouts, и симлинк уже есть). (ехидно) Вот примерно об этом я и говорил, когда употребил слова простой и понятный. Это как раз-таки ерунда. Сугубо техническая деталь. Решается одним вопросом в рассылке h...@lists.freedesktop.org или прямым экспериментом. -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Что почитать о мон тировании сменных носителей?
On Tue, Oct 06, 2009 at 11:16:20PM +0400, Stanislav Maslovski wrote: On Tue, Oct 06, 2009 at 08:49:50PM +0400, Alexander Galanin wrote: On Tue, 6 Oct 2009 00:40:26 +0400 Stanislav Maslovski stanislav.maslov...@gmail.com wrote: Тут сначала надо бы разобраться необходимо ли вообще предохраняться от race. В документации не очень внятно написано про порядок вызова callouts для _разных_ устройств. Т.е., может ли быть так, что cleanup скрипт еще не завершился (стартует по факту создания записи /org/freedesktop/Hal/devices/computer), а hal-autofs(add) уже выполняется (стартует по факту втыкания флешки). Кстати, как я сейчас вижу, мое решение вовсе не избавляет от этого race condition, если на момент запуска hal-autofs(add) в /media/ _отсутствует_ симлинк c именем `basename $UDI`. Нужен семафор. Второй момент -- может ли по каким-то причинам реализоваться ситуация, когда hal-autofs(remove) еще не завершился, а hal-autofs(add) уже стартовал для того же девайса (выдернули и тут же воткнули флешку). От этого мое решение предохраняет (даже если удаление не отработает то и зацикливание на ожидании не страшно -- hald прибивает подвисшие callouts, и симлинк уже есть). (ехидно) Вот примерно об этом я и говорил, когда употребил слова простой и понятный. Это как раз-таки ерунда. Сугубо техническая деталь. Решается одним вопросом в рассылке h...@lists.freedesktop.org или прямым экспериментом. Поэкспериментировал. hald _сериализует_ вызов add/remove callouts для одного девайса, следовательно, сценарий 2 исключается. Вызов callouts для разных девайсов не сериализован (что разумно, иначе бы hald нещадно тупил при старте), поэтому сценарий 1 возможен. Но хитрость в том, что find в скрипте cleanup вызывается у меня с опцией -L (следовать симлинкам, про что я совсем забыл), поэтому, если по каким-то причинам скрипт cleanup протормозит и hal-autofs(add) отработает раньше и положит в /media свой симлинк, то когда find -L на него наткнется, произойдет активация механизма autofs в ядре, файловая система подмонтируется, симлинк окажется указывающим на корневой каталог устройства (т.е. на объект -type d, a не -type l) и в список на удаление не попадет. То есть, даже если cleanup скрипт отработает позже hal-autofs(add), это не приведет к удалению только что созданного симлинка. Так что все проще некуда и while со sleep-ом из скрипта можно смело удалить ;) -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Что почитать о мон тировании сменных носителей?
On Mon, Oct 05, 2009 at 06:57:08PM +0400, Alexander Galanin wrote: On Sun, 4 Oct 2009 16:28:39 +0400 Stanislav Maslovski stanislav.maslov...@gmail.com wrote: On Sun, Oct 04, 2009 at 02:03:22PM +0400, Alexander Galanin wrote: Как результат такой перегруженности процесса монтирования, нормальных средств для работы с демоном HAL нет. Нормальный понимается как простой, 'понятный и скриптуемый. Не так страшен черт, как его малюют. Довольно давно уже (примерно с момента, когда иксы к hal привязали) для себя использую связку из autofs, hald и пары скриптов. До этого использовал связку udev + autofs. Насколько просто, понятно и скриптуемо это решение -- можешь посмотреть сам. Прилагаю tar.gz. Занятно. Только вот непонятно, зачем нужно ожидание исчезновения симлинки из /media. Это на случай race между cleanup скриптом и отработкой события add в другом скрипте, или между событиями удаления/добавления в одном скрипте (точнее, между двумя рейнкарнациями одного скрипта). Предложения как сделать лучше принимаются. Текущий вариант остался со времени proof of concept. А также очень хотелось бы узнать документ, из которого взяты значения для fdi-файла. aptitude install hal-doc w3m /usr/share/doc/hal-doc/spec/hal-spec.html А уж совсем хорошо было бы услышать авторское описаие того, как это всё-таки работает. Примерно так: 1. Скрипт hal-autofs-cleanup отрабатывает при добавлении в базу записи /org/freedesktop/Hal/devices/computer. Это происходит при каждом (ре)старте hald. Назначение скрипта - удалить битые символические ссылки, если таковые остались в /media (например, после зависания компа или падения hald). 2. При втыкании нового устройства hald опрашивает его и приступает к созданию записи о нем в своей базе. При этом просматриваются fdi файлы из /etc/hal/fdi/policy (детали есть в документации). В hal-autofs-policy.fdi у меня сказано, что если воткнутое устройство является hotplugguble storage c файловой системой vfat или ext2 (флешки, mmc карты) или removable storage c файловой системой iso9660 (сидиромы), то: a) оно помечается в базе, как обрабатываемое autofs (я добавляю свой идентификатор autofs к info.capabilities) б) добавляется запись об опциях монтирования для обнаруженной файловой системы (добавляю свой ключ volume.autofs.mount_options) в) скрипт hal-autofs назначается обработчиком событий add/remove для устройств, помеченных идентификатором autofs 3. После обработки policy файлов hald запускает только что зарегистрированный callout скрипт (c $HALD_ACTION=add). Скрипт создает симлинк в /media, указывающий на динамическую точку монтирования в /var/autofs/hal/. В качестве имени симлинка и динамической точки монтирования берется последняя часть HAL UDI (трюк с basename). 4. При попытке обратиться к /media/`basename $UDI` просыпается automounter (так как симлинк ведет в /var/autofs/hal/, упомянутый в /etc/auto.master) и запускает map скрипт /etc/auto.hal, который извлекает из базы HAL a) блочное имя устройства б) тип файловой системы в) мои опции монтирования и возвращает эту информацию automounter-у. automounter монтирует FS в /var/autofs/hal/`basename $UDI` с нужными опциями, после чего она доступна и через симлинк в /media/. 5. При освобождении файловой системы automounter ее отмонтирует (по истечении таймаута, заданного в auto.master, у меня 5 сек) 6. При выдергивании флешки hald приступает к удалению записей об устройстве и вызывает callout скрипт c $HALD_ACTION=remove. Скрипт удаляет соответствующий симлинк из /media. -- Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Что почитать о мон тировании сменных носителей?
On Mon, Oct 05, 2009 at 11:10:11PM +0400, Stanislav Maslovski wrote: On Mon, Oct 05, 2009 at 06:57:08PM +0400, Alexander Galanin wrote: On Sun, 4 Oct 2009 16:28:39 +0400 Stanislav Maslovski stanislav.maslov...@gmail.com wrote: On Sun, Oct 04, 2009 at 02:03:22PM +0400, Alexander Galanin wrote: Как результат такой перегруженности процесса монтирования, нормальных средств для работы с демоном HAL нет. Нормальный понимается как простой, 'понятный и скриптуемый. Не так страшен черт, как его малюют. Довольно давно уже (примерно с момента, когда иксы к hal привязали) для себя использую связку из autofs, hald и пары скриптов. До этого использовал связку udev + autofs. Насколько просто, понятно и скриптуемо это решение -- можешь посмотреть сам. Прилагаю tar.gz. Занятно. Только вот непонятно, зачем нужно ожидание исчезновения симлинки из /media. Это на случай race между cleanup скриптом и отработкой события add в другом скрипте, или между событиями удаления/добавления в одном скрипте (точнее, между двумя рейнкарнациями одного скрипта). Предложения как сделать лучше принимаются. Текущий вариант остался со времени proof of concept. В догонку: Тут сначала надо бы разобраться необходимо ли вообще предохраняться от race. В документации не очень внятно написано про порядок вызова callouts для _разных_ устройств. Т.е., может ли быть так, что cleanup скрипт еще не завершился (стартует по факту создания записи /org/freedesktop/Hal/devices/computer), а hal-autofs(add) уже выполняется (стартует по факту втыкания флешки). Кстати, как я сейчас вижу, мое решение вовсе не избавляет от этого race condition, если на момент запуска hal-autofs(add) в /media/ _отсутствует_ симлинк c именем `basename $UDI`. Нужен семафор. Второй момент -- может ли по каким-то причинам реализоваться ситуация, когда hal-autofs(remove) еще не завершился, а hal-autofs(add) уже стартовал для того же девайса (выдернули и тут же воткнули флешку). От этого мое решение предохраняет (даже если удаление не отработает то и зацикливание на ожидании не страшно -- hald прибивает подвисшие callouts, и симлинк уже есть). __ Stanislav -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Что почитать о мон тировании сменных носителей?
On Sun, Oct 04, 2009 at 02:03:22PM +0400, Alexander Galanin wrote: Как результат такой перегруженности процесса монтирования, нормальных средств для работы с демоном HAL нет. Нормальный понимается как простой, 'понятный и скриптуемый. Не так страшен черт, как его малюют. Довольно давно уже (примерно с момента, когда иксы к hal привязали) для себя использую связку из autofs, hald и пары скриптов. До этого использовал связку udev + autofs. Насколько просто, понятно и скриптуемо это решение -- можешь посмотреть сам. Прилагаю tar.gz. Eсли кто захочет использовать у себя, править нужно hal-autofs-policy.fdi, на предмет добавления нужных файловых систем и опций монтирования (например, у меня там нет ntfs). -- Stanislav hal-autofs.tar.gz Description: Binary data
