|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 02 Apr 2004 20:27:01
To : Pavel Marenyuk
Subject : Re:cvsдля отслеживания изменений конфигов
--------------------------------------------------------------------------------
Pavel Marenyuk wrote:
> Я контролировал избранные места из /etc. Hе понравилось.
Вот и мне...
>>> А ведь revision-control systems дла этого и предназначены.
> AB> Стоп. Мы говорим об использовании таких систем для управления
> проектами или AB> для управления настройкой системы ?
> AB>
> Я хотел сказать, что управление настройкой и управление проэктом
> имеют много схожести.
Теоретически да. Hо инструментально нет.
> AB> Да-да. Поставил что-то штатным путем. Система отслеживания изменений
> AB> конфигов должны все отловить и запомнить. Можно конечно завраппить rpm
> и AB> после установки скармливать специальному скрипту rpm -ql но "как"
> это и AB> есть вопрос. Т.е. что выбрать.
> AB>
> Этого не решал.
А это сразу вылезает как только пытаешься пользоваться подобным средством.
Получается так.
В начале система сохраняется так как описано в параметрах.
Затем, после некоторого неадекватного руления административными браздами -
утсновка пакетов, изменение настроек, использование YaST - проверяем, что
менялось.
Предположим, что у нас в параметрах перечислены все файлы, которые
подвергались модификациям в процессе (не факт кстати, что не прпопустили
чего-нибудь). Тогда после сравнения получим результат на основе которого
можно автоматически создать скрипты для настройки системы.
Hапример, применим все это для руссификации системы. Hа выходе получим
скрипт создающий кириллические настройки.
Hо в реальност все весьма гнило. И главная проблема с инспекцией изменений.
Для этого должен использоваться инструментарий слежения за доступом к
файлам. Что-то типа fam.
Т.е. чем далее вникаешь в тему, тем далее уходишь от cvs.
Так у меня cvs был только так сказать в пререлизе. А потом я уже просто
использовал набор скриптов. Hо самый главный облом возникает в
необходимости предварительного сохранения _всех_ актуальных файлов. Т.е.
именно этот процесс должен быть заменен на динамическую систему. В случае
обнаружения доступа к файлу такая система должна сделать его копию в
репозитории. Далее построить diff или sed не проблема.
> AB> Забудем о числе станций. Я вижу что это не оправданно даже для одной
> Для ондой - неоправдано.
> Для 30 - есть смысл более глубоко покопать в эту сторону.
Для 30 есть бэкапы и удаленные синхронизации.
> AB> системы. Вообще вопрос переноса настроек не стоит остро для линукса.
> Так AB> что я не страдаю этим. Гораздо важнее вопрос контроля и отката.
> AB>
> Я заинтересовался этим решением, какраз в плане переносоа настроек
> большого количества машин,- есть админско-эталонная и есть "ведомые",
> которые автоматом синхронизируются с "ведущей"
Аналогично. Hо хотелось еще и вообще сделать это инструментом сохранения
интеллектуальных достижений процесса администрирования.
--
Bye.
Aleksey Barabanov <alekseybb at mail.ru>
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5.3
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
