Bookmarks-on-tranquilizers

Сегодня обнаружил, что текстовое поле в конце файла id_rsa.pub - просто комментарий. Это значит, что после копирования его на удаленный хост в authorized_keys можно заменить свой настоящий логин и имя хоста на строку "тут был Вася" и никто никогда не поймет, кто такой Вася и как он сюда попал.
И еще. Можно работать на удаленном хосте, не светясь ни в auth.log, ни в `who` ни в `last`, без возможности посмотреть, что творится в консоли через watch - для этого достаточно запускать ssh-сессию так: ssh user@host "bash".

Мораль здесь одна: если у человека есть ssh аккаунт на машине, то контроллировать его действия практически невозможно.

Если не бояться страшных аббревиатур, то можно обнаружить очень полезные вещи у себя под носом. RCS - элементарная штука.

Для чего она нужна я думаю объяснять никому не надо. А для раобты с ней используются всего пять команд: ci (импорт), co (экспорт), rscdiff, rlog и rcs (тюнинг, настройка).

RCS поддерживает работу нескольких пользователей с одним файлом, но мне она не нужна. Поэтому мой рецепт для работы следующий:

1. #ls -R > file - это файл, с которым будем работать.
2. #mkdir RCS - здесь будет располагаться RCS репозиторий.
3. #ci -l file - так файл сохраняется в RCS (почему -l - см. ниже)
4. #rcs -U file - установка постоянной блокировки - однопользовательский режим работы.
4. #vi file - редактируем файл.
5. #rcsdiff file - смотрим различия между сохраненной в RCS версией файла и текущей.
6. #ci -l file - сохраняем в RCS новую версию файла (при этом нас попросят ввести комментарий к версии)
7. #rlog file - просмотр changelog файла.

Это все!

Теперь несколько слов про опции. Практически для каждой команды можно указать параметр -r N.N - номер ревизии. Так, co -r 1.1 извлечет файл с номером версии 1.1, а ci -r 2.0 сохранит файл под версией 2.0. Иногда полезно выполнить rcsdiff -r 1.1 -r 1.2 file (сравнение двух версий, находящихся в репозитории) или rcsdiff -r 1.2 file (сравнение текущей версии с версией 1.2)

По умолчанию "ci" _перемещает_ файлы в репозиторий, а "co" извлекает их в режиме read only (т.е. права доступа 444 и не установлена блокировка, т.е. невозможно будет сохранить изменения). Опция -u для ci эквивалентна последовательному вызову ci file&&co file, а -l - ci file&&co file&&chmod 644 file&&rcs -l file. Т.е. файл сохраняется в RCS и извлекается, готовый к редактированию. При установленном sticky locking -u ведет себя так же как и -l.

Дальнейшее чтение: rcsintro(1), rcs(1), co(1), ci(1).

Моя задача сегодня - сделать так, чтобы один из скриптов имел возможность выполнять какие-либо команды на локальной или удаленной машине. Причем не просто команды, а инлайн перл- и шелл-скрипты (генерируемые на лету), причем их довольно много, а выполнять надо часто, поэтому system() и `` отпадают сразу хотя бы из соображений быстродействия.

Итак, в глубинах CPAN отыскалось следующее:

• IPC::Open2: Вроде бы получалось запускать (в режиме неблокирующего чтения), но это довольно сложно: во-первых, надо было еще обойти все глюки с буфферизацией ввода-вывода и не наплодить при этом своих, и во-вторых у меня не получилось корректно завершить процесс - хотя бы перехватить Ctrl-C



• Expect.pm: Практически идеальный вариант. Все программирование сводится к установке своих обработчиков на появление тех или инных сообщений от запущенной программы. В будущем я скорей всего еще воспользуюсь этим модулем, но в данном случае он не подходит, поскольку для его работы нужен отдельный pty, а этот ресурс может и не быть доступен в тех услових, в которых придется работать моей программе.



• IPC::Session: Это обертка вокруг IPC::Open3, которая с точки зрения пользователя ведет себя как Excpect.pm - это мой выбор! Я пока не знаю, чего я лишился, отказавшись от Excpect, который работает через отдельный pty, но пока мне это кажется самым удобным вариантом. :)



• Net::SSH::Perl: к сожалению, этот модуль не заработал на моей машине (FreeBSD 4.11) - зависает во время тестирования один из зависимых модулей. По идее, Net::SSH - это аналог open3, но работающий с удаленной консолью, а Net::SSH::Perl - это IPC::Session-подобный интерфейс. Количество зависимостей и размер Bundle::SSH устрашают, но, судя по документации - вполне подходящий вариант.

Теперь я знаю, почему ставить *nix даже на десктоп нужно в разные разделы. Разносить /, /var и /tmp по разным разделам - это минимум.

На моем рабочем компьютере сегодня начались какие-то проблемы с ФС (линукс, установленный в один ext3 раздел). Для того, чтобы натравить fsck на корневой раздел надо, по идее, сначала сделать "mount -o remount,ro /", а это невозможно - "mount: / is busy". Вот и придется решать проблему перезагрузкой, хоть это и противоречит моим убеждениям..

Впрочем, что делать, если бы я разбил диск и проблемы начались в разделе /var - вопрос открытый..