Вход:  Пароль:  
FreeSource: AltLinux/Sisyphus/admin/IvmanAutomount ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

Новые веяния в области автомонтирования

Hal+ivman+pmount


Проблема со сменными носителями существовала с момента появления первого носителя и разные операционные системы абсолютно по разному подходили к решению этого вопроса. На моей памяти в линуксе я использовал supermount/autofs/subfs и у каждого из этих вариантов было множество недостатков. Попробую их перечислить:


  1. Необходимость выяснить текущее имя устройства
  2. Наличие прав на запись в системные конфигурационные файлы
  3. Всевозможные проблемы с «залипанием» сменного устройства с последующей перезагрузкой для его извлечения

Решение первого пункта было возложено на сервис hotplug и многие ощутили на себе последствия этого шага, как-то затирания /etc/fstab. Сейчас ситуация стабилизировалась, но у многих мысль о допускании кого-то на автоматическую запись в /etc/fstab вызывает дрожь. Многие, в том числе и я, для спокойного сна воспользовались командой chattr +i /etc/fstab. Информацию же о имени устройства можно получить через сервис Hal.


Но это сделало еще более острым второй вопрос – если никто из сервисов, работающих под правами рута не вносит запись, то это вынужден делать пользователь. Самому себе можно дать права на редактирование чего угодно, но это не подходит для ситуации с несколькими пользователями или для корпоративной среды. rider@ по старой традиции возложил монтирование сменных устройств на информационную подсистему hal, и теперь уже к нему появляются претензии по поводу бредовых записей в /etc/fstab...
Есть начинание по запрету записи в /etc/fstab и перенесение его изменяемой части в /etc/fstab.d

Что предлагает Ivman?


Отсутствие необходимости писать в /etc/fstab или куда-либо еще для автоматического монтирования. Теперь все сервисы у нас занимаются только своим делом:

Как это все работает


И это все?


Нет, это очень маленькая часть возможностей ivman!
ivman стандартно работает в двух экземплярах:


Маленький пример:


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

Совместимость с другими системами автомонтирования


ivman запущенный под системным аккаунтом не мешает никому из них... Но и не работает сам – это связано в первую очередь с паузой которую он делает для отработки пользовательских правил. За это время hotplug(а в последних версия hal) успевает произвести запись в fstab и вызвать монтирование устройства. У копии запущенной от простого пользователя возникает состояние гонки и результат абсолютно непредсказуем. Поэтому рекомендуется избегать пересечения по устройствам у различных систем автомонтирования.
UPDATE: последние версии hal ничем таким не занимаются
Продолжение следует...


Добрые советы

Большой проблемой на данный момент является совместимость этой схемы с утилитами записи CD и DVD дисков.
Для growisofs я рекомендую использовать такой workarround:
Создать в каталоге ~/bin файл с именем growisofs и следующим содержанием:



by Nick S. Grechukh:

Поддержка iocharset в ivman

ivman версии 0.6.4 местами обрабатывал policy.mount_option (исключая iocharset). я изготовил патч на эту тему и отправил его в дедал: патченый ivman передает pmount -c $hal.volume.policy.mount_option.iocharset$, если он задан в hal policy.


в версии 0.6.6 все поменяли, теперь mount_command выбирается из mount/pmount/pmount-hal при инициализации, и в дальнейшем не меняется. Причем, общесистемный экземпляр всегда использует pmount, а пользовательский – pmount-hal. Соответственно, передать что-либо udi-зависимое невозможно :(


Единственным выходом остается определять кодировку в самом pmount, см. ниже. Для пользовательского ivman – таки можно ориентироваться на hal, для этого надо поправить pmount-hal.

Поддержка iocharset в pmount

pmount поддерживает явное задание кодировки iocharset – ключ -c. Если кодировка не задана, то поведение pmount мне представляется странным: он берет текущую локаль (пользователя, под которым запущен) и если она utf8 – выставляет iocharset=utf8, но игнорирует любую другую.


Можно было бы исправить pmount, чтобы он всегда монтировал с текущей локалью в iocharset, однако это не поможет при запуске из системного ivman (или просто от рута). Я предпочел заменить запрос локали вызовом libnatspec. Пакет можно взять тут:
ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/i586/RPMS.daedalus/pmount-0.9.3-alt1.gns1.i586.rpm
или собрать:
ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Daedalus/SRPMS.daedalus/pmount-0.9.3-alt1.gns1.src.rpm


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

Конфигурирование ivman

Запускать ivman можно с помощью chkconfig – для системного демона или любого файла автозапуска пользователя, вроде .xsession.d, .bash_profile или .profile. Пользователю не стоит опасаться, что при повторном в ходе в систему с другой консоли запустится новый экземпляр ivman, в последний встроена проверка на этот счет. Также, системный и пользовательский процессы могут нормально работать вместе, если у них не пересекаются «сферы влияния», например монтированием сменных дисков занимается системный демон, а монтированием цифрового фотоаппарата – пользовательский. Для этого достаточно разнести необходимые действия по разным конфигам. Основным используемым файлом конфигурации ivman является файл Ivm Config Actions?.xml, находящийся в /etc/ivman для системного демона и в /.ivman – для пользовательского приложения. Синтаксис его выглядит следующим образом:



где name является названием свойства устройства, а value – значением этого свойства, при совпадении которых выполняется необходимое действие.


Самым простым способом подобрать нужные значения будет использование программы hal-device, с помощью которых можно посмотреть свойства всех устройств, присутствующих в системе и подобрать нужную комбинацию свойств/значений.


Также, при запуске события на появление устройства можно использовать имена свойств hal как переменные, окружив их знаками "$" например:



Эта команда выполнит строку вида pmount /dev/hda1 при монтировании жесткого диска.


Условия можно вкладывать друг в друга:



при этом сначала выполняется проверка внешних параметров, а затем внутренних.

Примеры конфигурации

В начале файла Ivm Config Actions?.xml находится глобальная команда команда включения/выключения монтирования сменных носителей:



По умолчанию устройства монтируются в каталог /media в подпапки, равные имени block device (для флэшек – в папку usbdisk). Если мы хотим монтировать определенные устройства в определенные папки, то можем поступить таким образом:



Пример для автозапуска DVD-Video дисков:



Пример для монтирования любой цифровой фотокамеры, работающей по протоколу PTP:



Таким образом, используя hal можно легко назначать практически любые действия событиям hal, от монтирования CD дисков с определенной меткой в определенную папку, до автоматического определения сканера или принтера. Помочь в этом разобраться должен следующие мануалы: ivman(8), Ivm Config Actions?.xml(5), pmount(1), а также коментарии в файлах конфигурации ivman.

Особенности использования pmount

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


Также не стоит забывать, что hal/ivman образатывают события о появлении и исчезновении устройств, а не об их наличии. Таким образом я пока не вижу способа сделать конфиг для ivman, который монтировал бы жесткий диск, подключенный к выключенному компьютеру, поскольку устройство уже существует в момент запуска ivman. Флэшка, которая уже была воткнута в момент включения, тоже не смонтируется – здесь вам не Microsoft ® Windows ™.


UPDATE из changelog:
18 April 2006: Ivman 0.6.11 released. Changes since last ivman:

Пример конфигурации точек монтирования через FDI 

/etc/hal/fdi/policy/00-gns-flash.fdi

фрагмент /etc/ivman/IvmConfigActions.xml

фрагмент /etc/ivman/IvmConfigBase.xml

Как все это работает


При подгрузке (обнаружении) нового устройства в ядре возникает так называемое uevent (userspace event).


У этого события есть три типа обработки:

  1. Вызвать внешнюю программу (если есть). Путь задается в /proc/sys/kernel/hotplug
  2. Передать сообщение на unixdomain socket (не знаю где задается путь к сокету)
  3. Передать специальное сообщение socket NETLINK с типом NETLINK_KOBJECT_UEVENT

Первый способ остался для обратной совместимости со старой системой. В более новых дистрибутивах вместо hotplug'а запускается процесс udevd, который слушает socket NETLINK для получения информации о новых устройствах. В правилах (rules) udevd помимо создания устройства есть 1. вызов hotplug'а и 2. передача сообщения hald.


Страницы, ссылающиеся на данную: ALTLinux/Sisyphus/admin/IvmanAutomount/subfs
EugeneOstapets


 
Файлов нет. [Показать файлы/форму]
Много комментариев (8). [Показать комментарии/форму]