Как-то все сложно, друзья. +i на критические конфиги (а их на отдельно
взятом тазу не так уж и много обычно), и пусть подавится.
13 марта 2010 г. 10:52 пользователь Valentin Nechayev
Wed, Mar 10, 2010 at 21:27:29, basil wrote about "Re: [uanog] apache dummy question":
ну давайте поофтопим :)
нормальные дистрибутивы конфиги не затирают
в частности федора: создает файл-конфиг с расширением rpmnew (кажись так, ибо пользую федору сугубо на десктопе) во фре: если софт ставиться из портов, то каждый ментейнер заботиться о том, чтобы конфиги не затирались, а если не получается у ментейнера - то коммитеры всегда помогают, даже русского коммитера находят если надо :)
_Нормального_ подхода по-настоящему я не видел нигде. Потому что единственный нормальный подход, jIMHO - это использование VCS, при котором есть ветка канонической формы конфигов (в CVS такое называется vendor branch) и ветка текущих конфигов, и при накате нового состояния выполняется слияние (merge) правок из текущей ветки и ветки канонической формы.
При любом другом подходе, не обладая комплектом из двух разностей (diffs) 1) между прошлым каноническим состоянием (C0) и текущим содержанием (A0) 2) между прошлым и текущим каноническими (C0 и C1)
невозможно гарантированно вычислить A1 (то, что должно получиться в результате).
Подход RPM даёт A0 и C1, но не даёт C0.
В случае отсутствия конфликта слияния должно выполняться A1 = A0 + (C1 - C0) или же A1 = C1 + (A0 - C0)
а лучше оба одновременно, это означает, что диффы C1-C0 и A0-C0 взаимно коммутативны, и это идеальный случай. Но если хотя бы один из этих вариантов выполнился без проблем (при текущем уровне интеллекта системы слияния в VCS) - это уже достаточный аргумент ставить такой конфиг как результат слияния.
Остаются случаи, когда автоматическое слияние ломается. Например, если у нас в C0 было написано
Port 34567
а админ заменил в A0 на
Port 45555
приход C1 с записями
ListeningPort 34567 OutgoingPort 34567
не может быть автоматически обработан. Понятно, что A1 должен в этом месте получить как минимум следующее:
ListeningPort 45555 OutgoingPort 45555
для достижения той же функциональности, что была при апгрейде. Но грамотный админ, видя обе разницы, с этим справится.
Среди виденных мной существующих сейчас практических подходов мне максимально осмысленным представляется подход FreeBSD. Он предполагает слияние при наличии A0 и C1 и позволяет удобно управлять этим слиянием в случае заметных расхождений (и автоматическое решение в типичных случаях), предоставляя удобную оболочку для интерактивной обработки (а не поиска .rpmnew по всему файловому дереву). К сожалению, он не предусматривает сохранение C0, поэтому наиболее типичная автоматизация не происходит.
-netch-
-- Yours, Max Telecommunication/HPC consulting