|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 02 Apr 2004 15:05:03
To : Pavel Marenyuk
Subject : Re:cvsдля отслеживания изменений конфигов
--------------------------------------------------------------------------------
Pavel Marenyuk wrote:
> AB> 2. Такая система выглядит более менее вразумительно пока увас только
> _ДВА_ AB> файла, а иначе это уже вовсе мутно.
> Програмный проэкт на 150 файлов - не мутно?
Детский случай. Du или find от /usr/lib ;)
Hапример
server:/etc # ls -als | wc -l
381
server:/etc # ls -alRs | wc -l
7717
server:/etc #
Я же предупреждал, что стоит перейти от теоретических прикидок к
практическим. Вы напишите простенький скрипт для контроля хотябы /etc и
избранных мест из /usr/share и /var/lib и проверте как "оно" ;) Я проверил
- хреново ;)
> А ведь revision-control systems дла этого и предназначены.
Стоп. Мы говорим об использовании таких систем для управления проектами или
для управления настройкой системы ?
> AB> 3. Такая автоматизация стоит грошей с точки зрения указания файлов в
> CVS и AB> вовсе обнуляется и становится обузой если кроме указания CVS
> надо еще и AB> Makefile создать.
> cvs - всего лишь инструмент. Makefile - правила его использования.
> Так или иначе какойто набор правил всегда существует.
Вопрос в объеме работы.
> AB> 4. Такая схема вводит в процесс администрирования пакет который для
> этого AB> не
> AB> предназначен разработчиком, т.е. не проверен на предмет дырявости и
> даже AB> более на каждом заборе написано "не пускайте CVS от рута". Короче
> - AB> перспектива 0 !
Я здесь не стал затрагивать вопроса вообще о безопасности вседозволенной
работы suid-ных систем и цене их ошибки и то как это можно сопрячь с тем
что управление больших систем постепнно переходит на ролевой принцип. А
если таки начать об этом разговор, то CVS вообще в ауте.
> AB> 5. Hужно еще решить проблему автоматического подключения
> установленного AB> пакета после rpm в такую систему администрирования.
> AB>
> Hе понял. Имеется ввиду автоматическая установка/удаление пакета ?
Да-да. Поставил что-то штатным путем. Система отслеживания изменений
конфигов должны все отловить и запомнить. Можно конечно завраппить rpm и
после установки скармливать специальному скрипту rpm -ql но "как" это и
есть вопрос. Т.е. что выбрать.
> AB> Подсчитаем все и прикинем стоит ли овчинка выделки ? Во сколько раз
> AB> услажняется процесс администрирования ? Сколько дополнительных
> операций AB> добавляется ?
> AB>
> И вычисляем пороговое количество станций, после которого такие пляски
> начинают быть оправдаными.
Забудем о числе станций. Я вижу что это не оправданно даже для одной
системы. Вообще вопрос переноса настроек не стоит остро для линукса. Так
что я не страдаю этим. Гораздо важнее вопрос контроля и отката.
>>> AB> Хотелось бы услышать альтернативы.
>>> AB>
> AB> А вот альтернативы то где ?
> AB>
> стандартные - sh, perl.
;))) Продолжаю - gcc, nasm ;)
> + если я чегото не знаю, это не значит что этого нет.
Я только не вижу смысла упиваться знанием того что если я что-то не знаю, то
это неприменно _ЕСТЬ_ ;) С таких утверждений начинается религия. "Бог из
машины" Это кстати и не ново ;)
--
Bye.
Aleksey Barabanov <alekseybb at mail.ru>
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
