Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On Sat, Apr 15, 2006 at 12:03:28PM +0400, Igor wrote: а у меня все автоматом монтируется вставил двд диск с фильмом, запустил проигрыватель Totem, пошло воспроизведение фильма [EMAIL PROTECTED] src]$ mount /dev/hda3 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) usbfs on /proc/bus/usb type usbfs (rw) /dev/hda5 on /home type ext3 (rw) /dev/hda1 on /mnt/disk_C type ntfs (ro,dmask=0,fmask=0111,nls=koi8-r) /dev/hda2 on /mnt/disk_D type ext3 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) /dev/hdc on /media/cdrecorder type udf (ro,nosuid,nodev,iocharset=cp1251,user=goga) Речь шла не о том, как прикрутить один из автомаунтеров или как это настроить в *DE, а о том, необходимо ли вообще монтировать DVD Video диск для просмотра фильма с него. В соседней ветке я показал, что плееру монтирование диска не нужно. Хотя естественно тот же xine будет играть DVD и с подмонтированного носителя. -- WBR, Dmitry signature.asc Description: Digital signature
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On Sun, Apr 09, 2006 at 06:00:12PM +1000, Никита wrote: Igor пишет: - в двд приводе вставлен и проигрывается двд диск с фильмом. - нажимается кнопка Eject на приводе - после чего диск размонтировывается, лоток с диском выезжает. Это реально сделать в дебиане ? есть готовое и проверенное решение ? echo dev.cdrom.lock=0 /etc/sysctl.conf Я бы не стал так делать. Возможно это и решит проблему при просмотре DVD фильма, который на сколько я знаю играется без монтирования, но это разрешит мне вытянуть ЛЮБОЙ даже подмонтированыый и используемый в данный момент диск с данными из привода. Вообще я не совсем понимаю, зачем монтировать DVD диск для просмотра фильма с него. -- WBR, Dmitry signature.asc Description: Digital signature
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On Mon, Apr 10, 2006 at 09:00:18AM +1000, Никита wrote: Dmitry Nezhevenko пишет: Я бы не стал так делать. Возможно это и решит проблему при просмотре DVD фильма, который на сколько я знаю играется без монтирования, но это разрешит мне вытянуть ЛЮБОЙ даже подмонтированыый и используемый в данный момент диск с данными из привода. ну если он играется без монтирования, то какие проблемы тогда? ничего не надо значит настраивать. Проблема в том что в этот же привод можно вставить CD с данными и мне ни что не помешает его извлечь не размонтировав. -- WBR, Dmitry signature.asc Description: Digital signature
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On 2006.03.01 at 12:19:50 +0300, Mikhail Ramendik wrote:
Ключик -f в данном, случае, к сожалению, не срабатывает - я проверял.
Но я тут подумал, что падение CD/DVD-ROM в device not ready _обязано_
корректно отрабатываться в любом случае, а если не отрабатывается - это баг
(не знаю, в iso9660 fs или нет...)
Боюсь что в VFS layer.
Затем что если ты вытаскиваешь диск, то shell у которого CWD на этом диске
тебе уже не нужен. shell-ы это вообще расходный материал - для каждого
скрипта новая копия запускается.
А если в этом шелле сидел совсем-другой-юзер?
То тогда вообще всё плохо. В многопользовательских системах (в смысле
где реально работают несколько живых пользователей )не должно
допускаться произвольное выдергивание диска из файловой системы. Либо
этот диск должен быть в эксклюзивном пользовании того пользователя,
который имеет физический доступ к дисководу.
Т.е. как раз в ситуации, когда на машине бывает несколько живых
пользователей, необходимость явным образом размонтировать диск является
разумной предусторожностью от того, чтобы пользователь, имеющий доступ к
дисководу, не помешал нечаянно работать другим пользователям.
Кстати, в этом случае вариант с сигналами срабатывает. Только делать его
нужно чуточку посложнее:
1. Сигналы посылать от имени пользователя-владельца консоли.
2. Диск размонтировать и отдавать только в случае если все процессы
получили сигнал. Если сигнал послать не дали (Permission denied) -
выяснить кому принадлежит процесс, захвативший диск и сообщить об этом
пользователю.
А если у тебя есть файлменеджер, который держит директорию на съемном
носителе, и не отрабатывает корректно сигнал, то такой файлменеджер
убивать надо не сигналом а aptitude remove.
Какой сигнал? Разве есть сигнал, означающий из-под тебя убрали файловую
систему?
Какой угодно. Хоть SIGHUP.
Сценарий при этом варианте:
login: xxx
password: xxx
[insert disk]
$ cd /mnt/cdrom
[disk automounted]
$ cp * ~/incoming
[copying...]
$
[eject disk, logon shell crashed]
login:
[user: WTF?!?!]
Пользователь, работающий с текстовой консоли, это не пользователь, а
системный администратор. Он должен своей головой думать. А в рамках
типичной GUI-системы процессом-лидером пользовательской сессии является
window manager, у которого cwd в ${HOME}.
/mnt/cdrom$ emacs
[long work..]
[eject CD]
[emacs crashes as parent is killed!]
У shell'а ещё и дети есть...
Ну, если shell прибили не SIGHUP-ом, то детям это не мешает.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On Wed, Mar 01, 2006 at 12:19:50PM +0300, Mikhail Ramendik wrote: Ключик -f в данном, случае, к сожалению, не срабатывает - я проверял. umount -l рулит в некоторых ситуациях. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On Wed, Mar 01, 2006 at 01:05:48PM +0300, Victor Wagner wrote: On 2006.03.01 at 12:19:50 +0300, Mikhail Ramendik wrote: То тогда вообще всё плохо. В многопользовательских системах (в смысле где реально работают несколько живых пользователей )не должно допускаться произвольное выдергивание диска из файловой системы. Либо этот диск должен быть в эксклюзивном пользовании того пользователя, который имеет физический доступ к дисководу. Вот мы и договорились до классической постановки вопроса: бывает ли однопользовательский UNIX. Сейчас много вопросов в это упирается: о том нужен спулер печати, могут ли сосуществовать в системе два активных десктопа, autologin и т.д. и т. п. В M$ Windows система просто спрашивает у пользователя, что ей делать в такой ситуации. В UNIX, в общем случае, это совершенно недопустимо. Файловые системы второго сорта это типичное лукавство. Приложение _имеет полное право_ ожидать какие-то ресурсы в файловой системе с которой запущено. В-общем, кнопки надо вытаскивать нафиг из cdrom, тем более толку от них никакого. Чем извлечение диска путем нажатия кнопки на корпусе лучше шортката или eject? Не более чем идиотская привычка. -- Иван Лох -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On 2006.03.01 at 15:19:09 +0300, Иван Лох wrote: On Wed, Mar 01, 2006 at 01:05:48PM +0300, Victor Wagner wrote: On 2006.03.01 at 12:19:50 +0300, Mikhail Ramendik wrote: То тогда вообще всё плохо. В многопользовательских системах (в смысле где реально работают несколько живых пользователей )не должно допускаться произвольное выдергивание диска из файловой системы. Либо этот диск должен быть в эксклюзивном пользовании того пользователя, который имеет физический доступ к дисководу. Вот мы и договорились до классической постановки вопроса: бывает ли однопользовательский UNIX. Сейчас много вопросов в это упирается: о том нужен спулер печати, могут ли сосуществовать в системе два активных десктопа, autologin и т.д. и т. п. Не бывает однопользовательского юникса, бывают внешние устройства (в том числе и с файловой системой внутри), которые следует рассматривать как эксклюзивную собственность какого-то конкретного пользователя, т.е. как часть его пользовательской консоли. Сюда помимо монитора, клавиатуры и мыши входят как минимум звуковая карта (колонки, микрофон) и все съемные устройства до которых пользователь может руками дотянуться. Эти устройства должны обладать двумя свойствами 1. По умолчанию должны быть недоступными всем остальным пользователям. 2. Должны быть доступны всем процессам данной пользовательской сессии, где бы физически эти процессы не выполнялись. Для звука эту задачу плюс-минус решают NAS, esd и aRts. Проблема только с ssh x forwarding-ом. Впрочем, в последних OpenSSH есть уже полноценные VPN-ы и, может быть, проблему удастся обойти с этой стороны. Для устройств с файловой системой FAT задача, по-моему, весьма неплохо решена посредсвтом mtools. Работает и с дискетами, и с флэшками. Для CDROM, к сожалению, аналога mtools нету. Кроме того, у подхода, предлагаемого mtools есть засада связанная с тем что действительно получается файловая система второго сорта. Архив, а не файловая система. Копировать можно, а что-то более умное делать (редактировать, выполнять) уже не очень. avfs в свое время была подходом к решению этой проблемы. Но, к сожалению avfs развилась в fuse, потеряв при этом одно из основных, с моей точки зрения, достоинств - то, что она была не system-wide, а per-session. В M$ Windows система просто спрашивает у пользователя, что ей делать в такой ситуации. В UNIX, в общем случае, это совершенно недопустимо. Вот и надо оторвать CD-ROM-ы от этого общего случая. Во всяком случае тогда когда юзер имеет физическую возможность и желание свободно вставлять/вынимать диски. В-общем, кнопки надо вытаскивать нафиг из cdrom, тем более толку от них никакого. Чем извлечение диска путем нажатия кнопки на корпусе лучше шортката или eject? Не более чем идиотская привычка. Эргономика, сэр. Физическая кнопка - она удобнее. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On Wed, Mar 01, 2006 at 05:41:57PM +0300, Victor Wagner wrote: Вот мы и договорились до классической постановки вопроса: бывает ли однопользовательский UNIX. Сейчас много вопросов в это упирается: о том нужен спулер печати, могут ли сосуществовать в системе два активных десктопа, autologin и т.д. и т. п. Не бывает однопользовательского юникса, бывают внешние устройства (в том числе и с файловой системой внутри), которые следует рассматривать как эксклюзивную собственность какого-то конкретного пользователя, т.е. как часть его пользовательской консоли. Сюда помимо монитора, клавиатуры и мыши входят как минимум звуковая карта (колонки, микрофон) и все съемные устройства до которых пользователь может руками дотянуться. Эти устройства должны обладать двумя свойствами 1. По умолчанию должны быть недоступными всем остальным пользователям. 2. Должны быть доступны всем процессам данной пользовательской сессии, где бы физически эти процессы не выполнялись. У меня тут стоят сканер с одной стороны и принтер с другой. Обычно принтером пользуюсь я, но если сетевой принтер недоступен, то на него валятся и чужие файлы. Более того, на него можно печатать специально. Для меня. Чей он? То же самое сканер. Для того чтобы сканировать консоль, вообще говоря, не нужна. Раньше при удаленном администрировании на медленных линиях часто приходилось просить вставить CDROM с каким-нибудь программным обеспечением. Что, любой кто находится физически у ящика может его извлечь? Любой может вытащить CDROM из моего компьютера лишь потому, что у него есть ключ от кабинета? Для звука эту задачу плюс-минус решают NAS, esd и aRts. Проблема только Кстати, звуковых карт (равно как и клавиатур) может быть больше одной. Много чаще есть два виртуальных дисплея. Оба локальные. Один активен, другой -- заперт: gdmgreeter из Lock Screen. Пользователи разные. Чей CDROM? Biometrical на CD пока нет ;-} В M$ Windows система просто спрашивает у пользователя, что ей делать в такой ситуации. В UNIX, в общем случае, это совершенно недопустимо. Вот и надо оторвать CD-ROM-ы от этого общего случая. Во всяком случае тогда когда юзер имеет физическую возможность и желание свободно вставлять/вынимать диски. И где грань? Съемный HDD он с какой стороны? У всех с разной. В-общем, кнопки надо вытаскивать нафиг из cdrom, тем более толку от них никакого. Чем извлечение диска путем нажатия кнопки на корпусе лучше шортката или eject? Не более чем идиотская привычка. Эргономика, сэр. Физическая кнопка - она удобнее. И мышь с 33 кнопками... И еще сенсорный экран на LCD. И 12 кнопок на принтере (это не шутка). Моя эргономика состоит в том, что если на CD одна кнопка я нажимаю ее обычно два раза. А если две, то угадывая в 50% случаев. C umount /cdrom eject не промахиваюсь. -- Иван Лох -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On 2006.03.01 at 18:37:55 +0300, Иван Лох wrote: Не бывает однопользовательского юникса, бывают внешние устройства (в том числе и с файловой системой внутри), которые следует рассматривать как эксклюзивную собственность какого-то конкретного пользователя, т.е. как часть его пользовательской консоли. Сюда помимо монитора, клавиатуры и мыши входят как минимум звуковая карта (колонки, микрофон) и все съемные устройства до которых пользователь может руками дотянуться. Эти устройства должны обладать двумя свойствами 1. По умолчанию должны быть недоступными всем остальным пользователям. 2. Должны быть доступны всем процессам данной пользовательской сессии, где бы физически эти процессы не выполнялись. У меня тут стоят сканер с одной стороны и принтер с другой. Обычно принтером пользуюсь я, но если сетевой принтер недоступен, то на него валятся и чужие файлы. Более того, на него можно печатать специально. Для меня. Чей он? Скорее общий, чем твой. Хотя протокол для работы с частным принтером в Unix как раз с незапамятных времен предусмотрен. Еще в те времена когда такие принтеры подключали к текстовым терминалам, придумали для этого capability в termcap (позднее в terminfo). То же самое сканер. Для того чтобы сканировать консоль, вообще говоря, не нужна. Со сканером - хуже. У него редко бывает автоподача бумаги. Причем автоподачи такой бумаги, которая нужна в сканере удаленному пользователю - не бывает совсем. Поэтому сканер я скорее склонен считать девайсом для интерактивной работы, т.е. требующим физического и эксклюзивного доступа. Раньше при удаленном администрировании на медленных линиях часто приходилось просить вставить CDROM с каким-нибудь программным обеспечением. Что, любой кто находится физически у ящика может его извлечь? Если соответствующий sysctl выставить, что собственно, предлагает Рамендик, то да. Точнее, то не будет имеющейся в данный момент защиты от нечаянного вытаскивания. Много чаще есть два виртуальных дисплея. Оба локальные. Один активен, другой -- заперт: gdmgreeter из Lock Screen. Пользователи разные. Чей CDROM? Biometrical на CD пока нет ;-} Это уж как договоритесь. Это вопрос, который должен решаться на уровне политики администрирования конкретной системы. Другое дело что средств для удобной реализации любой политики сейчас нет. Вот и надо оторвать CD-ROM-ы от этого общего случая. Во всяком случае тогда когда юзер имеет физическую возможность и желание свободно вставлять/вынимать диски. И где грань? Съемный HDD он с какой стороны? У всех с разной. Где локальный системный администратор провел - там и грань. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On 2006.02.28 at 10:12:53 +0300, Mikhail Ramendik wrote: В сообщении от 28 февраля 2006 08:33 Victor Wagner написал(a): В общем, этот способ чреват разнообразными граблями, и скорее всего разработчики ядра на сообщения об этих граблях будут реагировать словами А вы так не делайте. Выяснилось, однако, что разработчик ivmfn сейчас реализует тот же самый способ. Ну, почти тот же самый. Вот цитата из его письма, просьба сказать, будут ли здесь те же грабли. Здесь по крайней мере вызывается umount, пусть на уже вытащенный диск. А по хорошему, по событию eject надо запускать fuser -m и прибивать все процессы, использующие данную fs (заодно быстро выяснится, какие программы не умеют её вовремя отпускать, и можно будет их поправить или перестать использовать), и только потом umount. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On 2006.03.01 at 01:40:38 +0300, Mikhail Ramendik wrote: Здесь по крайней мере вызывается umount, пусть на уже вытащенный диск. Однако если хоть один процесс его держит, umount, если я правильно понимаю, просто не сработает :( А если не держит - так через таймаут (скажем, 3 секунды) autofs тоже сделает размонтирование. Насколько я понимаю, если файловая система уже недоступна, то ядро в этом случае ведет себя немножко по-другому. Опять же ключик -f у umount есть. А по хорошему, по событию eject надо запускать fuser -m и прибивать все процессы, использующие данную fs А вот этого я бы точно не делал. Зачем убивать файломенеджеры и шеллы, которые в этот момент смотрят на диск? Они ведь и так отнюдь не падают. Ради редких падающих/виснущих процессов убивать все? Затем что если ты вытаскиваешь диск, то shell у которого CWD на этом диске тебе уже не нужен. shell-ы это вообще расходный материал - для каждого скрипта новая копия запускается. А если у тебя есть файлменеджер, который держит директорию на съемном носителе, и не отрабатывает корректно сигнал, то такой файлменеджер убивать надо не сигналом а aptitude remove. Собственно есть две ситуации: 1. Мелкая (в стиле unix-way) программа, которая была запущена специально для работы с данными на этом диске. А потом просто пользователь забыл её закрыть. Тогда прибивание программы по событию вытаскивания диска - нормальное явление. Юзер не закрыл - система для него закроет. 2. Программа, которую убивать вообще-то жалко, но из-за того что программист головой не подумал, она не отпускает диск вовремя. В этом случае посылка сигнала делает тайный глюк (который имеет шансы проявиться, если вдруг программа обратится к неотпущенному ресурсу) явным. Нечто вроде electric fence, non-executable stack и прочих подобных средств отладки и защиты. В данном случае падение программы при вытаскивании диска делает просто более заметным факт, что эта программа с диском неаккуратно обращается. И, следовательно, должна быть либо исправлена, либо заменена на более правильную. Мне кажется, что правильно было бы сделать некую proxy file system (на fuse, вероятно, чтобы в ядро не лезть лишний раз), которая будет работать через обычную FS, но корректно отрабатывать её пропадание в любой момент (т.е. не зависать, а fail'иться). Однако я такое вряд ли в состоянии написать :( А Лично я не понимаю какая нафиг разница между fail-ящимся системным вызовом и прилетающим сигналом. И то, и другое может быть программой обработано. И то, и другое по умолчанию приводит к падению программы. В данном случае реализация особой ситуации посредством посылки сигнала обходится намного проще чем реализация её посредством возврата ошибки из системного вызова. Я бы рад сменить, скажем, shell на такой, который не держит за хвост свою текущую директорию, а открывает её только при подаче команды... (Правда, я и Для shell-а это как раз не имеет смысла. Прибил его и дело с концом. У него внутреннего состояния практически нет, кроме той самой CWD. Переменные среды, определенные только для данного shell - большая редкость. Беречь имеет смысл программы, у которых есть внутреннее состояние. Скажем, текстовый редактор с открытым и модифицированным файлом. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD/DVD ROM eject: решени е (или грабли?) вместо ivman
On 2006.02.28 at 01:23:21 +0300, Mikhail Ramendik wrote: Однако мне кажется, что (случайно, в архивах той же рассылки HAL) я нашёл решение для cd, которое кажется наиболее удобным. А именно - в /etc/sysctl.conf поставить dev.cdrom.lock = 0 . После чего монтировать CD/DVD ROM обычным autofs. Никакого таймаута ждать не придётся, как и искать, где тот затерявшийся shell, что не пускает размонтировать :) Eject работает в любой момент, и всё тут. Именно это нравилось мне в варианте с supermount. Конечно, это подходит только для read only... который и есть :) Однако один момент вызывает сомнения. Почему этот способ нигде не описан? CD/DVD-ROM существуют давно, /etc/sysctl.conf тоже не вчера появился, да и вопрос как обойтись без размонтирования или ожидания CD/DVD-ROM задаётся регулярно. Предлагают supermount, gnome-volume-manager, ivman, autofs с маленьким таймаутом - а такой вроде бы простой и универсальный способ, как dev.cdrom.lock=0, никто не задокументировал (или просто гугль не находит). Потому что у каждой проблемы есть простое, но неправильное решение. Это из той же серии. Никто не гарантировал того, что ядро поведет себя правильно, если из-под него выдернуть смонтированный носитель. Т.е. что autofs сумеет корректно размонтировать файловую систему, что забытый процесс с открытым файлом на этой файловой системе не начнет в безбожных количествах пожирать процессор и/или память. Кроме того, тебе заведомо не удастся смонтировать следующий диск, пока не размонтировался предыдущий. А если процесс, пытающийся обратиться к выдернутому, но не размонтированному диску, впал в uninterruptable sleep, ты вообще не сможешь это дело размонтировать до перезагрузки. В общем, этот способ чреват разнообразными граблями, и скорее всего разработчики ядра на сообщения об этих граблях будут реагировать словами А вы так не делайте. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
