Если не бояться страшных аббревиатур, то можно обнаружить очень полезные вещи у себя под носом. 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 устрашают, но, судя по документации – вполне подходящий вариант.
Сегодня обнаружил, что текстовое поле в конце файла id_rsa.pub – просто комментарий. Это значит, что после копирования его на удаленный хост в authorized_keys можно заменить свой настоящий логин и имя хоста на строку “тут был Вася” и никто никогда не поймет, кто такой Вася и как он сюда попал.
И еще. Можно работать на удаленном хосте, не светясь ни в auth.log, ни в `who` ни в `last`, без возможности посмотреть, что творится в консоли через watch – для этого достаточно запускать ssh-сессию так: ssh user@host “bash”.
Мораль здесь одна: если у человека есть ssh аккаунт на машине, то контроллировать его действия практически невозможно.
Теперь я знаю, почему ставить *nix даже на десктоп нужно в разные разделы. Разносить /, /var и /tmp по разным разделам – это минимум.
На моем рабочем компьютере сегодня начались какие-то проблемы с ФС (линукс, установленный в один ext3 раздел). Для того, чтобы натравить fsck на корневой раздел надо, по идее, сначала сделать “mount -o remount,ro /”, а это невозможно – “mount: / is busy”. Вот и придется решать проблему перезагрузкой, хоть это и противоречит моим убеждениям..
Впрочем, что делать, если бы я разбил диск и проблемы начались в разделе /var – вопрос открытый..
