[Sysadmins] Архивирование настроек системы и прочее...

[Fr. Br. George]

On Wed, Nov 29, 2006 at 11:44:17AM +0200, Dmitriy L. Kruglikov wrote:
> Доброго времени суток, коллеги.
> 
> Прошу коллективного разума для анализа и приведения в 
> удобоваримое состояние нескольких идей,
> описанных в статье:
> http://www.freesource.info/wiki/DmitriyKruglikov/Raznoe/etcmirror
Когда я работал в support@, у нас висела очень похожая задача.
Вкратце она формулировалась так:

     Исходная стуация:
0. От клиента пришла заявка, что что-то не работает на сервере.
1. Админ зашёл на сервер клиента и что-то там правил до тех пор, пока
   оно не заработало.
2. Админ выполнил ритуальные действия по:
   (a) сохранению изменённого
   (b) документированию, что и зачем изменил
   (c) закрытию заявки
3. Клиент подтверждает, что работает, заявка снимается

Попытки решить дело CVS-ом привели к бунту на корабле: неудобно
закидывать изменения, повсюду валяются метаданные, документировать
приходится _не_ там, где правил (в TT-системе).

Беда в том, что CVS, GIT и прочее -- это средства в первую очередь
совместной разработки, а никак не бэкапа. Средства же бэкапа, как
правило, имеют первой целью _полное_ восстановление, а не восстановление
конфигов, и, следовательно, жрут трафик так, что ими пользваоться
нельзя.

Соответственно, встала задача автоматизации ритуальных действий
(a) rsync? Наша идея была не в том, чтобы искать какие-то строки, а в
том, чтобы бэкапить _всё_, что изменилось _везде_, где лежат конфиги
минус логи и прочее автоизменяемое. То есть иметь список каталогов для
бэкапа и список исключений, которые бэкапить не надо. А бэкапить каждый
раз разницу плюс изменения в правах доступа.
(b) Сама процедура такого бэкапа должна была автоматически запускать
редактор отчёта (как это длается в CVS со товарищи). Отчёт должен быть
трёх видов: обязательный краткий -- для клиента и закрытия заявки,
автоматический со списком файлов (чтобы было понятно, что изменял) и
необязательный комментированный diff -- если что-то хитромудрое было
проделано.
(c) Затем получившийся пучок отсылался куда-то в хранилище, дабы не
пропадало; в идеале из него должен был вырезаться отчёт #1 и цепляться к
заявке. Без идеала -- copy-paste из веб-морды хранилища.

Бонусом от этого должны были стать:
- документированность конфигов
- возможность подключения к работе _другого_ админа
- полуавтоматическое восстановление конфигов из хранилища (возможно,
  даже в виде применения патчей на слегка другой базовой системе)

Но, увы, никто этим не занялся, а кто занялся -- не сделал.

Если вас интересует такая постановка задачи, можно подумать вместе над
развитием etcmirror. Может быть, в виде пары etcmirror+trac...

-- 
			George V. Kouryachy (aka Fr. Br. George)
			mailto:george at altlinux_ru