регламент root работ
Sergey Kuprianov
Хотелось бы услышать твои соображения на тему регламента работ на
unixbox'ах, при количестве root админов больше одного.
Интересуют не технические решения (jail), а именно трудовые соглашения.
Поясню проблему на пальцах.
Полу-удаленно поддерживаю несколько серверов у местного ISP.
На крайний случай невозможности связаться со мной при ЧП, ну и просто
"шоб было", пароли лежат "в офисе в сейфе".
Давеча с удивлением обнаружил, что на подконтрольные машины заходит
человек и беззаботно дергает за ручки, для дерганья совершенно не
предназначенные.
Поскольку ответственность за работоспособность этих машин целиком
и полностью лежит на мне, доступ "левым" root'ам был заблокирован.
Предстоит разговор с начальством и объяснение "не хорошести" ситуации.
Что думаете по этому поводу? Поделитесь опытом.
На какие условиях возможна работа более одного root'а на одной машине?
--
JID: difr...@jabber.ru
Andrew Filonov
SK> Что думаете по этому поводу? Поделитесь опытом. На какие
SK> условиях возможна работа более одного root'а на одной машине?
Ни при каких. Логинов рутом вообще быть не должно. Только в
черезвычайных ситуациях.
--
Andrew E. Filonov
(1) If you like it, they don't have it in your size.
(2) If you like it and it's in your size, it doesn't
fit anyway.
(4) If you like it and it fits, you can't afford it.
(5) If you like it, it fits and you can afford it, it
falls apart the first time you wear it.
Alex Korchmar
SK> Поскольку ответственность за работоспособность этих машин целиком
SK> и полностью лежит на мне, доступ "левым" root'ам был заблокирован.
SK> Предстоит разговор с начальством и объяснение "не хорошести" ситуации.
SK> Что думаете по этому поводу? Поделитесь опытом.
что начальству _такие_ вещи не об'ясняют. Оно отвечает за функционирование
этих машин большей суммой, чем то, что можно получить с тебя.
Соответственно, у него всегда есть право сделать по своему. А у тебя есть
право не работать на такое начальство.
SK> На какие условиях возможна работа более одного root'а на одной машине?
На любых. Твое право - проинформировать начальство, на каких условиях
ты представляешь это возможным для себя. В случае несовпадения
условий - увеличить прайс/оговорить и зафиксировать на бумаге раздел
ответственности/ свалить туда, где твои условия приемлемы.
> Alex
Sergey Kuprianov
> SK> Что думаете по этому поводу? Поделитесь опытом. На какие
> SK> условиях возможна работа более одного root'а на одной машине?
> Ни при каких. Логинов рутом вообще быть не должно. Только в
> черезвычайных ситуациях.
Все это понятно...
Еще раз - я не про техническую сторону вопроса.
Логиниться root'ом или su'титься - тут без разницы.
Я про гипотетическую возможность продуктивного руления машиной двумя
и более админами.
--
JID: difr...@jabber.ru
Eugene Grosbein
SK> Я про гипотетическую возможность продуктивного руления машиной двумя
SK> и более админами.
Это нормально при доверии админов друг другу. Технически взаимодействие
реализуется регламентом, обязующим обеих выполнять cvs commit при любой
модификации настроек, все настройки хранятся в CVS.
При отсутствии доверия надо или выгонять другого с машины или самому
уходить, иначе все это может очень плохо кончиться. И доказывай потом,
что ты не верблюд.
Eugene
--
"Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
Artem Chuprina
>> SK> Что думаете по этому поводу? Поделитесь опытом. На какие
>> SK> условиях возможна работа более одного root'а на одной машине?
>> Ни при каких. Логинов рутом вообще быть не должно. Только в
>> черезвычайных ситуациях.
SK> Все это понятно...
SK> Еще раз - я не про техническую сторону вопроса.
SK> Логиниться root'ом или su'титься - тут без разницы.
SK> Я про гипотетическую возможность продуктивного руления машиной двумя
SK> и более админами.
Она есть. Необходимое условие - ответственность на обоих.
--
Artem Chuprina
RFC2822: <r...@ran.pp.ru>, FIDO: 2:5020/122.256, ICQ: 13038757
Victor Wagner
SK> Все это понятно...
SK> Еще раз - я не про техническую сторону вопроса.
SK> Логиниться root'ом или su'титься - тут без разницы.
Используй sudo, оно логи ведет.
--
Vasily Korytov
Ведет-то ведет, но толку от них часто как с козла молока. Вот запустил я
/bin/csh -- а что сделал в нем, это х/з.
--
I accept RFC3156 and RFC2440-compatible encrypted mail.
PGP key fingerprint: 3273 7F6F 7B87 5DD5 9848 05FB E442 86BC 2E6B 6831
Constantin Stefanov
> Хотелось бы услышать твои соображения на тему регламента работ на
> unixbox'ах, при количестве root админов больше одного.
> Интересуют не технические решения (jail), а именно трудовые соглашения.
> Предстоит разговор с начальством и объяснение "не хорошести" ситуации.
> Что думаете по этому поводу? Поделитесь опытом.
> На какие условиях возможна работа более одного root'а на одной машине?
Как вариант - пароли лежат не просто так, а запечатанные в конверте.
Человек, который конверт открывает, пишет в спец. журнальчике, кто он
такой, зачем это ему понадобилось и что реально сделано. И назначен
человек, ответственный за сохранность конверта (секретарша у сейфа). Ее
обязанности - не отдавать конверт, пока не будет сделана запись в том
самом журнальчике.
Таким образом, ты все делаешь сам, но если тебя действительно нельзя
достать, то всегда известно, кто отвечает за содеянное. А ты,
естественно, после такого случая меняешь пароль, вновь его запечатываешь
в конверт и кладешь в сейф (и тоже расписываешься в том же журнальчике,
что положен новый пароль).
--
Константин Стефанов
Eugene B. Berdnikov
EG> 16 апр 2004, пятница, в 11:56 KRAST, Sergey Kuprianov написал(а):
SK>> Я про гипотетическую возможность продуктивного руления машиной двумя
SK>> и более админами.
EG> Это нормально при доверии админов друг другу. Технически взаимодействие
EG> реализуется регламентом, обязующим обеих выполнять cvs commit при любой
EG> модификации настроек, все настройки хранятся в CVS.
А поддержка cvs для всей системы и время на формальности с журналами
выходят дороже отдельно нанятого админа, как нетрудно догадаться.
Потому что нормальный админ знает, что cvs не способна отследить file
permissions, не понимает симлинков и т.д., поэтому он зайдет на машину и
выправит что нужно без всяких cvs, наплевав на регламент - так быстрее.
И чтобы регламент всё-таки соблюдался, надо у этих админов рутовый доступ
к машине отобрать, и нанять ещё отдельного рута за отдельные деньги... :)
--
Eugene Berdnikov
Anton V. Yuzhaninov
You wrote to Eugene Grosbein <Eugene....@f1.n5006.z2.fidonet.org> on
Sat, 17 Apr 2004 10:03:16 +0000 (UTC):
EBB> И чтобы регламент всё-таки соблюдался, надо у этих админов рутовый
EBB> доступк машине отобрать, и нанять ещё отдельного рута за отдельные
EBB> деньги... :)
И все же во многих случаях без двух рутов не обойтись. Один человек не может
быть доступен 24 часа в сутки, он может уехать, заболеть и т. п. Если сервер
должен работать в режиме 24x7, то должен быть человек, который может его в
любой момент заменить.
Я думаю единственный выход это два админа, который могут доверять друг
другу, и после каких либо изменений сообщают друг другу по почте о том,
какие изменения были произведены.
А что касается CVS, RCS то это хорошо работает для цисок, где все настройки
(за исключением vlan database) представлены одим текстовым файлом. Если есть
несколько циско админов, то очень полезно иметь систему вроде
/usr/ports/net/ciscoconf
Для unix тяжело придумать, что-то подобное.
--
Anton V. Yuzhaninov. E-mail: cit...@mail.ru
Anatoly Mashanov
16 Apr 04 12:33, you wrote to All:
SK> Hа крайний случай невозможности связаться со мной при ЧП, ну и просто
SK> "шоб было", пароли лежат "в офисе в сейфе".
SK> Предстоит разговор с начальством и объяснение "не хорошести" ситуации.
Вся ответственность лежит на держателе ключей от сейфа в офисе. Что и должно
быть прописано в трудовом договоре и служебной инструкции - что вскрытие пакета
с паролями является чрезвычайной ситуацией и должно производиться при
документированной в прошнурованной и пронумерованной книге невозможности
связаться с админом, несущим ответственность. Если начальство не готово на это
пойти - оно не единственное, начальств кругом много.
Anatoly
Eugene Grosbein
EG>> Это нормально при доверии админов друг другу. Технически взаимодействие
EG>> реализуется регламентом, обязующим обеих выполнять cvs commit при любой
EG>> модификации настроек, все настройки хранятся в CVS.
EBB> А поддержка cvs для всей системы и время на формальности с журналами
EBB> выходят дороже отдельно нанятого админа, как нетрудно догадаться.
Признайся, что ты не пробовал. Потому что это почти ничего не стоит,
кроме самодисциплины.
EBB> Потому что нормальный админ знает, что cvs не способна отследить file
EBB> permissions, не понимает симлинков и т.д.,
Hикто не отменял все остальное (make и т.д.)
EBB> поэтому он зайдет на машину и
EBB> выправит что нужно без всяких cvs, наплевав на регламент - так быстрее.
По-моему, ты это себе как-то превратно представляешь. Именно так и делается,
более того, это предусмотрено регламентом. А после изменений делается
cvs commit, в котором изменения комментируются; commit log уходит почтой
всем, кому надо. Если рутов только двое (для большего числа все сложнее),
то тот, кто обнаруживает изменение, о котором он не знал (не было cvs commit),
легко видит (cvs diff), что именно поменял второй и когда (timestamp).
При желании можно в крон засунуть cvs -q diff | grep -v | mail -E.
Случаи преднамеренного вредительства и заметания следов это совсем
другая ситуация.
Valentin Nechayev
>>> Eugene B. Berdnikov wrote:
EBB> А поддержка cvs для всей системы и время на формальности с журналами
EBB> выходят дороже отдельно нанятого админа, как нетрудно догадаться.
Нет, трудно.;) По крайней мере про cvs.
EBB> Потому что нормальный админ знает, что cvs не способна отследить file
EBB> permissions, не понимает симлинков и т.д., поэтому он зайдет на машину и
EBB> выправит что нужно без всяких cvs, наплевав на регламент - так быстрее.
Практически работающий вариант - диффы содержимого файлов и списков
прав и симлинков, хранимых через тот же cvs.
И общая рассылка с вопросами типа "кто сегодня ставил сапоги на пульт".
-netch-
Valentin Nechayev
>>> Anatoly Mashanov wrote:
AM> Вся ответственность лежит на держателе ключей от сейфа в офисе. Что и должно
AM> быть прописано в трудовом договоре и служебной инструкции - что вскрытие пакета
AM> с паролями является чрезвычайной ситуацией и должно производиться при
AM> документированной в прошнурованной и пронумерованной книге невозможности
AM> связаться с админом, несущим ответственность. Если начальство не готово на это
AM> пойти - оно не единственное, начальств кругом много.
Вопрос в том, согласны ли на это админы.
Я бы предпочёл не работать там, где требуется столь формальный подход.
-netch-
Valentin Nechayev
>>> Anton V. Yuzhaninov wrote:
AVY> А что касается CVS, RCS то это хорошо работает для цисок, где все настройки
AVY> (за исключением vlan database) представлены одим текстовым файлом. Если есть
AVY> несколько циско админов, то очень полезно иметь систему вроде
AVY> /usr/ports/net/ciscoconf
AVY> Для unix тяжело придумать, что-то подобное.
Я не знаю, кому тяжело придумать, но у нас работают их аж 4 штуки с примерно
однотипной функциональностью.
Почему 4 разных - не было причин интегрировать;))
Моя лежит под именем cvsbackup.pl где-то в районе ftp://segfault.kiev.ua/
-netch-
Victor Dronov
EBB> Потому что нормальный админ знает, что cvs не способна отследить
EBB> file permissions, не понимает симлинков и т.д., поэтому он зайдет
EBB> на машину и выправит что нужно без всяких cvs, наплевав на
EBB> регламент - так быстрее.
Это, пардон, либо честное заблуждение, от которого лучше поскорее
избавиться, либо намеренное вранье. "Hормальный" админ никогда не будет
делать "как быстрее" в ущерб документированности. Такое поведение и есть
критерий "нормальности".
--
Dronov пытается пристроить обратно пингвина, выпавшего из холодильника
Valentin Nechayev
>>> Victor Dronov wrote:
EBB>> Потому что нормальный админ знает, что cvs не способна отследить
EBB>> file permissions, не понимает симлинков и т.д., поэтому он зайдет
EBB>> на машину и выправит что нужно без всяких cvs, наплевав на
EBB>> регламент - так быстрее.
VD> Это, пардон, либо честное заблуждение, от которого лучше поскорее
VD> избавиться, либо намеренное вранье. "Hормальный" админ никогда не будет
VD> делать "как быстрее" в ущерб документированности. Такое поведение и есть
VD> критерий "нормальности".
Для ряда ситуаций единственно возможный вариант - сделать хоть и криво,
но "на вчера". И безо всякой документированности.
Другое дело, что после этого надо найти несколько минут привести в порядок
или хотя бы документировать сделанный хак.
-netch-
Denis Sotchenko
AM>> вскрытие пакета с паролями является чрезвычайной ситуацией и
AM>> должно производиться при документированной в прошнурованной и
AM>> пронумерованной книге невозможности связаться с админом, несущим
AM>> ответственность.
VN> Вопрос в том, согласны ли на это админы.
VN> Я бы предпочёл не работать там, где требуется столь формальный подход.
Так тут всегда есть два варианта - или админы друг другу
доверяют, или формальный подход. Лично у меня первый вариант.
__
__/ / Powered [pepsi inside]
\_\/ by MOTOROLA [smoking suxx]
Valentin Davydov
> Date: Fri, 16 Apr 2004 08:33:52 +0000 (UTC)
>
>Хотелось бы услышать твои соображения на тему регламента работ на
>unixbox'ах, при количестве root админов больше одного.
IMNSHO, для таких ситуаций лучше приспособлены не unixы, а несколько
иные операционные системы, с более совершенными механизмами разграничения
полномочий. В конце прошлого века удачным примером такой системы могла
служить OpenVMS, а как сейчас - увы, не скажу, ибо перестал следить.
>Поясню проблему на пальцах.
>
>Полу-удаленно поддерживаю несколько серверов у местного ISP.
>На крайний случай невозможности связаться со мной при ЧП, ну и просто
>"шоб было", пароли лежат "в офисе в сейфе".
Вот тут-то и ошибка. На крайний случай всяких ЧП существует boot -s с
консоли.
>Давеча с удивлением обнаружил, что на подконтрольные машины заходит
>человек и беззаботно дергает за ручки, для дерганья совершенно не
>предназначенные.
Так он, небось, и не подозревает, что они не предназначены: на них же
ничего такого не написано - ручка как ручка, дёргается точно так же,
как и соседняя, которой штатно какого-нибудь дурного демона шуруют.
>Поскольку ответственность за работоспособность этих машин целиком
>и полностью лежит на мне,
[skip]
>На какие условиях возможна работа более одного root'а на одной машине?
На условиях соразмерности прав и ответственности. В частности, каждый,
кто способен зайти рутом по сети, несёт полную ответственность за простои,
независимо от того, где он сам находился в это время.
Вал. Дав.
Valentin Davydov
> Date: Sat, 17 Apr 2004 10:42:58 +0000 (UTC)
>
> EBB> И чтобы регламент всё-таки соблюдался, надо у этих админов рутовый
> EBB> доступк машине отобрать, и нанять ещё отдельного рута за отдельные
> EBB> деньги... :)
>
>И все же во многих случаях без двух рутов не обойтись. Один человек не может
>быть доступен 24 часа в сутки, он может уехать, заболеть и т. п. Если сервер
>должен работать в режиме 24x7, то должен быть человек, который может его в
>любой момент заменить.
Для того, чтобы заменить сервер (на резервный, как я понимаю?), вовсе
необязательно иметь рутовый доступ. Достаточно ключей от помещения и
элементарных навыков перетыкания кабелей.
Вал. Дав.
Anton V. Yuzhaninov
You wrote to Anton V. Yuzhaninov on Sun, 18 Apr 2004 17:49:46 +0000 (UTC):
??>> И все же во многих случаях без двух рутов не обойтись. Один человек не
??>> может быть доступен 24 часа в сутки, он может уехать, заболеть и т. п.
??>> Если сервер должен работать в режиме 24x7, то должен быть человек,
??>> который может его в любой момент заменить.
VD> Для того, чтобы заменить сервер (на резервный, как я понимаю?), вовсе
VD> необязательно иметь рутовый доступ. Достаточно ключей от помещения и
VD> элементарных навыков перетыкания кабелей.
Не все ситуации, которые требуют вмешательства админа, требуют замены
сервера.
Для случая, когда сервер доступен по ssh, но не работает какой либо сервис,
нужен именно удаленный доступ, поскольку если что-то неработает в нерабочее
время, то быстрее пофиксить это удаленно, чем ехать на другой конец города.
А иногда в нерабочее время доступ в серверные помещения проблематичен, как
например на М9.
Ruslan Fedoseev
> AM>> вскрытие пакета с паролями является чрезвычайной ситуацией и
> AM>> должно производиться при документированной в прошнурованной и
> AM>> пронумерованной книге невозможности связаться с админом, несущим
> AM>> ответственность.
> VN> Вопрос в том, согласны ли на это админы.
> VN> Я бы предпочёл не работать там, где требуется столь формальный
> подход.
>
> Так тут всегда есть два варианта - или админы друг другу
> доверяют, или формальный подход. Лично у меня первый вариант.
Hу. Доверяют. И дальше что?
Мне кажется более спокойным вариант с cvs. По крайней мере админить так 30
серверов втроем у нас получается...
--
Public PGP key fingerprint = 3FAB E3F1 F2D3 0A65 7EC5 C17A 029D 13C3 505A
A175
С уважением
системный администратор фирмы ИТ Руслан Федосеев
тел. +380-642-41-35-75 Луганск
http://www.lds.net.ua/~martin кв. Жукова, 4б\1
--
Eugene Grosbein
VD> Вот тут-то и ошибка. Hа крайний случай всяких ЧП существует boot -s с
VD> консоли.
Hе забывай про удаленные сервера без serial console.
Кроме того, это просто неумно, перегружать сервер ради каждого
действия с EUID=0.
Alexander Uskov
16 Apr 04 12:33, you wrote to All:
SK> Что думаете по этому поводу? Поделитесь опытом.
SK> Hа какие условиях возможна работа более одного root'а на одной машине?
Условия простые - пароли лежат в запечатанном конверте, целостность которого
ты раз в некоторое время проверяешь. Если, в случае твоего отсутствия конверт
вскрывается, то как только ты провел анализ решения проблемы, генеришь новые
пароли и делаешь новый пакет. Если же конверт разорван а причины тебе объяснить
не могут - разрываешь всякие отношения с клиентом, кроме консультационных.
зы: И вообще, рут должен быть один.
~~~
wbr, Alexander Uskov
Eugene B. Berdnikov
>>>> Eugene B. Berdnikov wrote:
VN>
EBB>> выходят дороже отдельно нанятого админа, как нетрудно догадаться.
:) Во сколько обойдётся поставить и наладить cvs для конфигов 5-10 сервисов,
а заодно и обучить пару админов пользоваться этой штуковиной? (In Euro, pls).
EBB>> Потому что нормальный админ знает, что cvs не способна отследить file
EBB>> permissions, не понимает симлинков и т.д., поэтому он зайдет на машину и
EBB>> выправит что нужно без всяких cvs, наплевав на регламент - так быстрее.
VN> Практически работающий вариант - диффы содержимого файлов и списков
VN> прав и симлинков, хранимых через тот же cvs.
Вы как, генерите список изменений каждый день, по ctime? Просто интересно.
--
Eugene Berdnikov
Eugene B. Berdnikov
EG> 17 апр 2004, суббота, в 13:03 KRAST, Eugene B. Berdnikov написал(а):
EBB>> А поддержка cvs для всей системы и время на формальности с журналами
EBB>> выходят дороже отдельно нанятого админа, как нетрудно догадаться.
EG> Признайся, что ты не пробовал. Потому что это почти ничего не стоит,
EG> кроме самодисциплины.
Признаюсь - не пробовал. Потому что там, где оно _действительно_ нужно,
мне проще отсечь обезьян нахрен, чем обучить их cvs'у и дисциплине...
EBB>> Потому что нормальный админ знает, что cvs не способна отследить file
EBB>> permissions, не понимает симлинков и т.д.,
EG>
EG> Hикто не отменял все остальное (make и т.д.)
А всё остальное само собой возникает?
EBB>> поэтому он зайдет на машину и
EBB>> выправит что нужно без всяких cvs, наплевав на регламент - так быстрее.
EG>
EG> По-моему, ты это себе как-то превратно представляешь.
Как было у меня - так и представляю. Пришёл начальник и сказал, что надо
передать систему обезьяне. Я передал. Потом пришла счастливая обезьяна и
одним движением снесла 3 сервиса сразу, включая sshd.
Я не смог догадаться, в чём заключалось это движение, пока не вернулся
из командировки и не вошел с консоли. :) А когда узнал - понял, что это
безнадёжно... В следующий раз обезьяна удалит /bin/sh и ребутнёт машину,
а виноватым опять буду я. Это к вопросу о доверии.
Хохма была ещё в том, что случай был далеко не первый, поэтому все изменения
в конфигах строго-настрого полагалось во время моего отсутствия фиксировать.
Разумеется, удар микроскопа пришёлся по файлу, который "конфигом" не был... :)
--
Eugene Berdnikov
Eugene Grosbein
EBB>>> А поддержка cvs для всей системы и время на формальности с журналами
EBB>>> выходят дороже отдельно нанятого админа, как нетрудно догадаться.
EG>> Признайся, что ты не пробовал. Потому что это почти ничего не стоит,
EG>> кроме самодисциплины.
EBB> Признаюсь - не пробовал. Потому что там, где оно _действительно_ нужно
Hаверное, у тебя феноменальная память - ты помнишь, в какой день ты
поменял вот эту конкретную строчку вон в том файле примерно полгода назад
и зачем эта хрень вообще тут стоит. Второй вариант - у тебя просто нет
потребности в этой колбасе...
EBB> мне проще отсечь обезьян нахрен, чем обучить их cvs'у и дисциплине...
Админить production совсем без дисциплины?..
EBB>>> Потому что нормальный админ знает, что cvs не способна отследить file
EBB>>> permissions, не понимает симлинков и т.д.,
EG>> Hикто не отменял все остальное (make и т.д.)
EBB> А всё остальное само собой возникает?
Этого мало и оно влегкую решается списком в CVS. Возможно,
самоинтерпретируемым и самоисполняемым вроде сладкой парочки
Makefile и CVSROOT/loginfo.
EBB>>> поэтому он зайдет на машину и
EBB>>> выправит что нужно без всяких cvs, наплевав на регламент - так
EBB>>> быстрее.
EG>>
EG>> По-моему, ты это себе как-то превратно представляешь.
EBB> Как было у меня - так и представляю. Пришёл начальник и сказал, что надо
EBB> передать систему обезьяне. Я передал. Потом пришла счастливая обезьяна и
EBB> одним движением снесла 3 сервиса сразу, включая sshd.
А, ну-ну.
EBB> Я не смог догадаться, в чём заключалось это движение, пока не вернулся
EBB> из командировки и не вошел с консоли. :) А когда узнал - понял, что это
EBB> безнадёжно... В следующий раз обезьяна удалит /bin/sh и ребутнёт машину,
EBB> а виноватым опять буду я.
Почему?
EBB> Это к вопросу о доверии.
Это к вопросу об организации работы.
EBB> Хохма была ещё в том, что случай был далеко не первый, поэтому все
EBB> изменения
EBB> в конфигах строго-настрого полагалось во время моего отсутствия
EBB> фиксировать.
EBB> Разумеется, удар микроскопа пришёлся по файлу, который "конфигом" не
EBB> был... :)
А кроме CVS есть еще автоматические дампы на отдельный винт. Куда, кстати,
самому репозиторию тоже неплохо попадать.
Valentin Nechayev
>>> Eugene B. Berdnikov wrote:
EBB>>> А поддержка cvs для всей системы и время на формальности с журналами
EBB>>> выходят дороже отдельно нанятого админа, как нетрудно догадаться.
VN>> Нет, трудно.;) По крайней мере про cvs.
EBB> :) Во сколько обойдётся поставить и наладить cvs для конфигов 5-10 сервисов,
EBB> а заодно и обучить пару админов пользоваться этой штуковиной? (In Euro, pls).
Видишь ли... наверно, ты не так понял. Я не загоняю изменять через CVS.
Я через CVS отслеживаю уже сделанные изменения. Они пишутся почтой - всем
видны - и можно ругаться по их поводу.
EBB>>> Потому что нормальный админ знает, что cvs не способна отследить file
EBB>>> permissions, не понимает симлинков и т.д., поэтому он зайдет на машину и
EBB>>> выправит что нужно без всяких cvs, наплевав на регламент - так быстрее.
VN>> Практически работающий вариант - диффы содержимого файлов и списков
VN>> прав и симлинков, хранимых через тот же cvs.
EBB> Вы как, генерите список изменений каждый день, по ctime? Просто интересно.
ftp://segfault.kiev.ua/pub/cvsbackup.pl
Она делает checkout, копирует указанные каталоги, вызывает cvs update,
по рассказу той делает выводы о добавлении/изменении/удалении,
пишет диффы на stdout и коммитит изменения.
Запускать по крону когда хочется (у меня обычно раз в час).
-netch-
Eugene B. Berdnikov
VN> Видишь ли... наверно, ты не так понял. Я не загоняю изменять через CVS.
VN> Я через CVS отслеживаю уже сделанные изменения. Они пишутся почтой - всем
VN> видны - и можно ругаться по их поводу.
Ну это вполне разумный подход, imho.
VN>>> Практически работающий вариант - диффы содержимого файлов и списков
VN>>> прав и симлинков, хранимых через тот же cvs.
EBB>> Вы как, генерите список изменений каждый день, по ctime? Просто интересно.
VN> ftp://segfault.kiev.ua/pub/cvsbackup.pl
Неслабо! Такое, наверное, хорошо, когда надо следить за работой
десятка админов в прямом подчинении. :)
У нас подход выработался попроще, т.к. народу немного, а история не нужна.
В рабочее время каждый час по жизненно важным местам пробегается
find -mmin -60 и перечень файлов уходит в список. Плюс ночной бэкап
обычным rsync --backup-dir=/tmp/[...], чтобы старое состояние конфигов
хранить некоторое время. Где обезьян и вредителей нет - жить можно.
--
Eugene Berdnikov
Valentin Nechayev
>>> Eugene B. Berdnikov wrote:
EBB>>> Вы как, генерите список изменений каждый день, по ctime? Просто интересно.
VN>> ftp://segfault.kiev.ua/pub/cvsbackup.pl
EBB> Неслабо! Такое, наверное, хорошо, когда надо следить за работой
EBB> десятка админов в прямом подчинении. :)
Десятка не наберётся. Так, 8-9.;)) Пять дежурных (которые, правда, лезут
редко в конфиги), три собственно админа и я.
EBB> У нас подход выработался попроще, т.к. народу немного, а история не нужна.
EBB> В рабочее время каждый час по жизненно важным местам пробегается
EBB> find -mmin -60 и перечень файлов уходит в список. Плюс ночной бэкап
EBB> обычным rsync --backup-dir=/tmp/[...], чтобы старое состояние конфигов
EBB> хранить некоторое время. Где обезьян и вредителей нет - жить можно.
Ночной бэкап тоже есть, но там система другая - tar'ятся каталоги и
выливаются на спецтазик для бэкапов. На нём по каждому бэкапу хранятся
до десяти последних состояний. Суточные бэкапы включают только конфиги,
недельные - /usr/local/{src,compile} и прочие интересные места.
А обезьян и вредителей у нас нет. Но всё равно очень удобно видеть изменения
сразу и диффами.
-netch-
Artem Chuprina
EBB> У нас подход выработался попроще, т.к. народу немного, а история
EBB> не нужна. В рабочее время каждый час по жизненно важным местам
EBB> пробегается find -mmin -60 и перечень файлов уходит в список. Плюс
EBB> ночной бэкап обычным rsync --backup-dir=/tmp/[...], чтобы старое
EBB> состояние конфигов хранить некоторое время. Где обезьян и
EBB> вредителей нет - жить можно.
Порой бывают ситуации, когда ошибка при правке конфига относится к редко
встречающейся ситуации и проявляется через полгода.
--
Artem Chuprina
RFC2822: <r...@ran.pp.ru>, FIDO: 2:5020/122.256, ICQ: 13038757
Eugene B. Berdnikov
AC> Eugene B. Berdnikov -> Valentin Nechayev @ Tue, 20 Apr 2004 12:03:37 +0000 (UTC):
EBB>> ночной бэкап обычным rsync --backup-dir=/tmp/[...], чтобы старое
EBB>> состояние конфигов хранить некоторое время. Где обезьян и
EBB>> вредителей нет - жить можно.
AC> Порой бывают ситуации, когда ошибка при правке конфига относится к редко
AC> встречающейся ситуации и проявляется через полгода.
Нам интересны лишь ситуации типа "Вася случайно задел локтём этажерку Пети",
чтобы оперативно посмотреть, какие изменения были внесены сегодня утром
или вчера. Кто что правил полгода назад - нисколько не интересно. :)
--
Eugene Berdnikov
Artem Chuprina
EBB>>> ночной бэкап обычным rsync --backup-dir=/tmp/[...], чтобы старое
EBB>>> состояние конфигов хранить некоторое время. Где обезьян и
EBB>>> вредителей нет - жить можно.
AC>>
AC>> Порой бывают ситуации, когда ошибка при правке конфига относится к редко
AC>> встречающейся ситуации и проявляется через полгода.
EBB> Нам интересны лишь ситуации типа "Вася случайно задел локтём
EBB> этажерку Пети", чтобы оперативно посмотреть, какие изменения были
EBB> внесены сегодня утром или вчера. Кто что правил полгода назад -
EBB> нисколько не интересно. :)
У меня была пара случаев, когда случайно задетая этажерка аукалась через
полгода. Повторяю, ситуация, которой касается данная строчка,
встречается редко.
Alex Korchmar
AC> У меня была пара случаев, когда случайно задетая этажерка аукалась через
AC> полгода. Повторяю, ситуация, которой касается данная строчка,
AC> встречается редко.
достаточно часто - правишь что-нибудь на ходу в потрохах машины с аптаймом
в пол-года, а потом оно еще через месяц перезагружается - и не работает,
потому что поправил ты нормально, а в конфиге/стартапном скрипте облажался
(или вообще тебя отвлекли и ты забыл это дело там зафиксировать)
> Alex
Boris Veytsman
AK> Date: Sun, 25 Apr 2004 18:50:41 +0000 (UTC)
AK> достаточно часто - правишь что-нибудь на ходу в потрохах машины с
AK> аптаймом в пол-года, а потом оно еще через месяц перезагружается -
AK> и не работает, потому что поправил ты нормально, а в
AK> конфиге/стартапном скрипте облажался (или вообще тебя отвлекли и
AK> ты забыл это дело там зафиксировать)
Знакомая картинка. Мне в такой ситуации звонили в другой город: там
аптайм был пару лет, и я успел переехать :)
--
Good luck
-Boris
Хвалите, бабы, мужиков:
мужик за похвалу
достанет месяц с облаков
и пыль сметет в углу.
-- Игорь Губерман
Artem Chuprina
AC>> У меня была пара случаев, когда случайно задетая этажерка аукалась
AC>> через полгода. Повторяю, ситуация, которой касается данная
AC>> строчка, встречается редко.
AK> достаточно часто - правишь что-нибудь на ходу в потрохах машины с
AK> аптаймом в пол-года, а потом оно еще через месяц перезагружается -
AK> и не работает, потому что поправил ты нормально, а в
AK> конфиге/стартапном скрипте облажался (или вообще тебя отвлекли и ты
AK> забыл это дело там зафиксировать)
Имелось в виду не то, насколько часто по меркам жизни админа встречается
такой облом, а то, насколько редко по меркам жизни системы.
Перезагрузка раз в полгода - это редко. Обсуждаемая фигня как раз в
том, что если нет долговременных логов изменений вроде CVS, к моменту
наступления опы уже невозможно установить, кто что менял. В результате
починка может оказаться заметно дольше.