[sisyphus] Re: hotplug, UDEV и пакетная запись cd-r

[Arioch]

Konstantin A. Lepikhov пишет:

> причем тут скрипт запуска pktsetup и upstream pktcdvd патча

Так апстрим - патча?
Письмо было из трех строк. Первые две - про скрипт. Третья- про
апстрим. Каким фильтром догадаться, что апстрим - патча,а не скрипта?

Ладно, забудем про апстрим ?

В любом случае, на SourceForge сайтанет, а trylinux.com помре.

>>>писать длинные и бесполезные changelog'и и я умею. По-существу, вы можете
>>>внятно сформулировать чтовас не устраивает? 
>>copy-paste стиль скрипта. один и тот же код в разных местах.
> напишите свой.

Совсем-совсем новый свой с чистого листа? Пока не могу.

Для этого нужно разобраться
  1) как существующий скрипт взаимодействует с системой
  2) какие средства системы можно использовать
И договориться
   Что вообще должна делать идеальная обвязка и что не должна.

Как пример вопроса:
  2.1) раз check_kernel() в скрипте привязано к Alt Linux - можно ли
посчитать, что и остальные функции скрипта можно привязывать к Альту?
Тем паче, что судя по sf.net, апстрим не обновлялся уже год как ?




Пока я могу только изменятьсуществующий скрипт, не радикально, чтобы не
отломать существующее взаимодействие (о котором в добавок не всегда знаю
- иногда только догадываюсь).

А также показывать на странные на мой взгляд моменты, чтобы
  а) узнать что я ничего не понимаю и именно так и должно быть (и почему)
  б) узнать, что это действительно неправильно, и как должно было быть

>>Вывод на экран выбивается из стиля остальных скриптов.Точнее ввыод на 
>>экран просто "абы что-нибудь"
> меня этот вывод устраивает.

Иными словами "понаехало тут юзеров, воображжают что дистр для них.
Брысь в апстрим (LFS) " :-/

> поддержки packet writing в ядре?

Я не могу разделить претензии между скриптом, pktsetup, UDEV и ядром.
Иногда могу предполагать, но не более.


Начну с начала. Медленно и детально.

1) Пакетная запись включается только в результате настройки руками.
Сделать ее через hotplug/hal/udev - пока не могу. Не хватает информации.
1.1) То же про /media - automount/submount/supermount/ivmon

2) pktsetup может отключить устройство, которое он не создавал. Тем
самым оставив повисший файлустройства. Это баг.

3) создается два файла устройства - видимо второй создается UDEV'ом при
загрузке pktcdvd.ko. Это, вероятно,баг в настройке UDEV.
Есть несколько вопросов на тему "что именно происходит", но пока обойдемся.

4) Если при отработке скриптапроизойдет ошибка - скрипт об этом не
сообщит ни вызывающей программе if any (вернет $? == 0 - якобы нет
ошибки), ни администратору влоги, ни юзеру (вывод на консоль туманна
даже если юзер из терминалазапустит скрипт руками, а отсутствие цветных
[ OK ] | [ FAILED ]  не даст разглядеть при автозапуске из /etc/rc?.d )
fixed

5) права на файлы - три разных группы
brw-r-----  1 root root  251,  0 Авг 12 03:51 cdwriter
crw-rw----  1 root cdrom  10, 62 Авг 12 03:47 control
brw-rw----  1 root disk 251, 0 Авг 12 03:51 /dev/pktcdvd0

Кто назначает права на control? UDEV rules или pktcdvd.ko ?
По крайней мере файл создается при загрузке модуля.
Ладно, mea culpa, пороюсь в правилах UDEV - найду.

Опять возникает "вечный вопрос" - какая группа из множества в /etc/group
за что отвечает? Я так понимаю, что включать-выключать пакетную запись
могут юзеры из группы cdrom, а вот читать и писать ( по версииUDEV ) -
юзеры из группы disk. Т.е. вечныйвопрос привнес сюда неразбериху.

про cdwriter (GID == 0, root) скажу ниже

6) дублирование кода в скрипте - неужели нужно объяснять почему это
плохо ???

7) скрипт может загрузить pktcdvd.ko при старте - но не выгрузитего при
останове. Это м.б. не очень важно - но не красиво. Интуитивно всегда
предполагаешь, что при остановке демона за ним все почищается и система
становится в таком же виде, как до запуска.

7.1) запуск pktcdvd.ko мне кажется еще одним доказательством, что скрипт
оторвался от оригинала и привязан к обычаям AltLinux (подробнее - ниже)

7.2) я понимаю логику грузить этот модуль в случае service udftools
start. Однако service udftools status, service udftools #--help и
service udftools stop - тоже его запускают, хотя он пpи такой команде
заведомо не нужен

8) раз уж скрипт привязан к обычаям AltLinux, то и справка (при запуске
без параметров) должна выводиться с использованием /sbin/service


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

Теперь про права.

zsh 31 [1] % ls -l /usr/bin/pktsetup
-rwxr-xr-x  1 root root 6960 Янв 24  2005 /usr/bin/pktsetup

Т.е. pktsetup должен запускаться не от рута, а от любого пользователя в
системе.

zsh 43 % ls /dev/pktcdvd -l
crw-rw----  1 root cdrom 10, 62 Авг 14 17:28 control

Взаимодействие с ядром при этом разрешено только группе cdrom.

Права на /dev/pktcdvd/cdwriter даются пользователю (успешно)
запустившему pktsetup - любому изгруппы cdrom

Значит скрипт udftools ( а именно он запускает pktsetup ) предназначен
авторами-апстримщиками длязапуска от любого пользователя. Так ли это?
zsh 45 % ls -l /etc/init.d/udftools
-rwxr-xr-x  1 root root 5081 Авг 12 17:44 /etc/init.d/udftools

Именно так! Права - идентичныправам на сам pktsetup.
Правда, если бы апстрим привязывал пакетную запись к группе cdrom,
вероятно права были бы  -rwxr-xr-x root cdrom
Т.е. вероятно - эти права назначает UDEV. (проверил - действительно)

Однако в AltLinux скрипт должен запускаться от root'a - аначе не
отработает insmod
Это значит, что юзер не сможет воспользоваться диском - ему просто н
разрешат. Впрочем, если он вдруг входит в группу root, то сможет диск
читать.

Т.е. либо скрипт должен иметьвозможность запускаться
непривелигерованным юзером - либо после создания устройства ему нужно
делать chmod & chown


---------------  Теперь про UDEV:

<bdv на localhost:/etc/udev/rules.d>  zsh/2 13 [2] %     grep pkt *.rules
50-alt.rules:KERNEL=="pktcdvd", NAME="pktcdvd/control", GROUP="cdrom",
         MODE="0660"
50-alt.rules:KERNEL=="pktcdvd[0-9]*", SYMLINK+="pktcdvd/%n",
	GROUP="disk"

Исходя из этого, я думаю что:
   1) именно UDEV намеренно раздает разные права на cpntrol и на сам
диск.  Видимо, группа cdrom - это те, кто могут физически втыкать и
вытыкать диски. Кто такая группа disk - мне, юзеру, не известно :-(
Не понятно - почему группа ставится не cdwriter - ведь по сути это
запись дисков ? Это вопрос к UDEV (rider ?)

   2) тем не менее дублирующиеся блочные устройства создает не UDEV.
Вероятно /dev/pktcdvd0 создает pktcdvd.ko, а /dev/pktcdvd/cdwriter
создает pktsetup. Бага относится к кому-то из них, в зависимости от
взглядов автора/мейнтейнера кто их них должен создавать файл устройства.

Я зря поверил
> багу на удефф. pktsetup не виноват.