Ссылка давно ушла в офлайн; вот статья:--- Идеальный сисадмин: RPM
Автор: (C) 2003, Денис Овсиенко
Введение.
Не знаю, насколько это верно для других ОС (по крайней мере, не для всех, это точно), но для Linux однозначно справедливо следующее: операционная система -- это не набор файлов. Точнее, не просто набор файлов, а совокупность довольно порядочного багажа знаний: стандартов, принятых методик и просто соглашений с одной стороны и текущего состояния живой системы в целом с другой, включая и каждый отдельно взятый файл. Соответственно, и администрирование операционной системы отличается от администрирования содержимого файлового архива.
Давайте ещё раз взглянем на сам термин "операционная система". Здесь не зря употребляется слово "система" -- её компоненты зачастую не могут работать в отрыве друг от друга, значит, в большинстве случаев какие-то компоненты зависят от других компонент. Те, в свою очередь, зависят ещё от чего-либо, порождая трудно отслеживаемые иерархические и/или циклические зависимости, причём, ещё раз подчеркну, не только на уровне наличия/отсутствия файлов нужных версий, а и сетевых сервисов, RPC-вызовов, других неочевидных связей.
Почему здесь я делаю упор на файлы? Потому, что это первейший показатель упорядоченности системы и, пожалуй, единственная её область, в которой возможно навести хоть какой-то порядок. Если вы ещё не читали книгу[1], обязательно прочите хотя бы первые главы. Её автор постарался (и у него получилось) объяснить наглядно и убедительно принципы пакетного подхода, успешно применяемого в большинстве вчерашних, сегодняшних и завтрашних дистрибутивов. Если у вас нет возможности прямо сейчас обратиться к этому фундаментальному, хотя и порядком устаревшему труду, поясню: суть первой главы сводится к двум утверждениям:
1. Человек не может сам вручную отслеживать зависимости между тысячами и десятками тысяч файлов.
2. Машина должна работать, а человек думать (приписывается IBM, насколько я помню).
1. Кто виноват?
Довольно давно уже встречаются руководства по установке ПО для Linux, написанные самым разнообразным контингентом, которые сводятся к благословению и проклятию большинства софта для POSIX (*NIX): configure && make && make install ! Многие могут спросить: "И что тут такого? Я сам так делаю". Резонный вопрос. Если руководство называется "Как установить <название ПО> за 15 минут" и выполнение предписанных шагов действительно позволяет получить работающую программу за 15 минут, что неправильно? А вот что: такие руководства по совести должны называться "Как установить <название ПО> за 15 минут, если у вас уже не крутится рабочая инсталляция, которую нежелательно будет сломать из-за неудачно скомпилированных файлов или сноса всю прошлую неделю редактировавшегося конфигурационного файла неконтролируемым make install; если вы наизусть помните все ключи configure; если вы самостоятельно напишете init и logrotate сценарии для этого ПО; если вы не собираетесь автоматизированно обновляться до следующей версии и если вы самостоятельно разыщете все файлы, которые наплодил make install, когда захотите избавиться от этого ПО". Уже не так привлекательно, правда? Мне такая формулировка не нравится, хотя это дело личного и профессионального вкуса. Всё зависит от того, какие цели преследуются.
Давайте определимся, имеет ли смысл читать далее? Если:
* необходим быстрый эффект любым путём (есть специальная группа лекарств: симптоматические, единственное их действие заключается в том, что вы чувствуете себя здоровым и нагружаете обычной нормой работы больной организм);
* вам лень читать документацию;
* вы переустанавливаете систему очень часто и ничуть от этого не страдаете;
* обновления системы у вас популярностью не пользуются;
* вас вполне устраивает делать резервное копирование всей файловой системы, чтобы ничего случайно не забыть,
то напрягаться особо и не стоит. Если же наличествуют следующие признаки:
* ваша основная специализация -- сопровождение серверов, а не пользователей;
* вы непосредственно, то есть лично своей зарплатой/репутацией отвечаете за доступность и правильную работу сервисов, работающих в режиме как минимум 24*5/24*6;
* вы отвечаете более чем за одну машину;
* вы администрируете публично доступные сервисы и отдаёте себе отчёт в том, что свежую уязвимость сканер-автомат способен нащупать и "проломить" за несколько секунд;
* время восстановления работоспособности повреждённого или полностью уничтоженного участка сети и/или сервера не должно превышать время монтажа аппаратного обеспечения + несколько часов;
* предоставление сервисов вашей инфраструктурой планируется не на ближайшие пару месяцев, а на постоянной основе;
* показатель труда системных администраторов должен являться суммой усилий нынешних и предыдущих сотрудников, а не случайным значением из ряда разнесённых по времени и направлению попыток изменить что-то к лучшему,
то с большой степенью вероятности можно утверждать, что системное администрирование -- ваша работа и выполнять её можно только правильно, иначе это уже будет совсем другим занятием. При этом, чем больше организация и чем интенсивнее в ней используются информационные технологии, тем это очевиднее. Впрочем, это справедливо для большинства профессий.
2. Что делать?
Итак, как справиться с фермой серверов? Во-первых, поймите, что время, оставшееся до полной потери данных -- в лучшем случае остаток техресурса конкретного сервера. Во-вторых, разделите котлеты и мух, то есть определите, что именно на каждом сервере является уникальными данными (базы данных, наполнение web-серверов, мастер-зоны DNS и т. д.) и проведите их тщательную инвентаризацию. Выделите себе время и регулярно делайте резервное копирование, задвинув на все остальные занятия -- это ваша козырная карта в любой ситуации. Второй половиной будет пёстрый табор установленного ПО с прилагающимися конфигурационными файлами (если некоторые из них нетривиальны, то разумнее будет их отнести к первой группе). Выясните, что именно и где у вас работает -- возможно, не обойдётся без сюрпризов.
Фронт работ намечен, но как оценить степень соответствия идеалу? Очень просто. Например, существует наработанная методика обслуживания аппаратных маршрутизаторов: необходимо всего лишь хранить в безопасном месте копию файла его текущей конфигурации. Предположим, в маршрутизатор попадает молния и от него остаётся только помятая металлическая коробка с угольками. Требуем новый такой же модели, заливаем конфигурацию и -- вуаля! -- штатный режим восстановлен. Довольно показательно. Применим тот же подход, но с известными усложнениями в деталях.
Прежде всего необходимо знать, что восстанавливать. Для этого всё, что можно установить из входящих в дистрибутив RPM, а не собирать вручную, должно быть установлено из RPM. В этом случае вы получаете вместо карты с кладом "возьми исходники с этого сайта, патчи с этого, а скрипт, запускающий configure, в архиве, лежащем там-то... или вот там-то... не помню, поищи" краткое и однозначное "установи пакет такой-то". Предвижу возражения: что делать, если в дистрибутиве старая версия пакета? А если пакета в дистрибутиве нет? На первое отвечу: пользуйтесь системой обновлений вашего дистрибутива и настройте её на ваше локальное зеркало обновлений (неужели зеркало ещё не настроено?). Если периодичность обновлений оставляет желать лучшего, смените дистрибутив. Ведь вы обладаете правом разумного выбора средств, коль на вас возложена ответственность за результат. Возможно, это решит сразу и второй вопрос. Если не решит, то попросите издателей дистрибутива сделать это -- должны же они иметь какую-то обратную связь! Если не поможет, соберите пакет сами, а ещё лучше -- соберите и попросите включить в дистрибутив, всё равно работа уже проделана и вы сможете помочь другим администраторам. Некоторые из них потратят освободившееся время на сборку и включение пакета, который в будущем понадобится вам. Круг замкнулся.
Сборка своего пакета не запутывает вещи, а наоборот, концентрирует и систематизирует ваши сведения касательно определённого ПО в одном месте -- пакете, содержащем это ПО. Самый, казалось бы, маленький архив с исходными текстами может породить столько проблем, сколько не сможет иной многомегабайтный монстр. Если сложность spec-файла для пакета явно превышает сложность функций, пакетом выполняемых, подумайте, не подыскать ли аналогичное ПО, у автора которого тараканов в голове меньше. Только после того, как вы соберёте RPM, вы сможете оценить количество потенциальных проблем, которые были ликвидированы самим наличием уже готового пакета. Постарайтесь при сборке пакета не забывать о Linux Filesystem Standard, определяющем, что где должно находиться, потому что авторы многих утилит и системных программ предполагали, что утилиты эти будут работать именно в таким образом организованной файловой системе.
Итак, вы имеете список стандартных пакетов, и, возможно, несколько самосборных RPM. Возьмите подходящий по параметрам запасной сервер и выполните установку новой системы. Сохраните список пакетов из инсталлятора (если он этого не умеет, вы вправе изменить свои предпочтения). Несколько слов о наборе пакетов: выбор "устанавливать всё" не так хорош, как кажется. Во-первых, вы получите пакеты, которые никогда не будут использоваться, но будут требовать обновления. Во-вторых, если какой-то из используемых вами стандартных или самосборных пакетов имеет неправильные зависимости, вы этого просто не заметите, а неправильные зависимости -- вещь неприятная и определённый процент сбоев в будущем. В-третьих, на специализированном сервере собственно система вместе с ПО может занимать 300 мегабайт, так зачем же выбрасывать лишние гигабайты (5-10 и более в зависимости от дистрибутива) на ветер? Дисковое пространство лишним не бывает, это проверенное временем правило.
Оглянитесь, не осталось ли что-то за бортом. Я, например, чаще всего забывал установить утилиты сетевой диагностики. Если да, то повторяйте установку с сохранением списка пакетов до достижения состояния "ни прибавить, ни отнять". Поздравляю, теперь вы действительно знаете, что именно работает у вас на конкретно взятом сервере. Дискета, как известно, вещь дешёвая и ненадёжная, поэтому лучше всего будет поместить её образ и на CD с конфигурационными файлами. Основная часть работы проделана, теперь необходимо только поддерживать ваши запечатлённые на обычном CD-R концентрированные сведения актуальными. Восстановление самого ценного -- данных -- в терминах работы с пакетами не формулируется и сильно зависит от самих данных, так что постарайтесь прорепетировать эту сцену самостоятельно, но с соблюдением тех же требований: только чистый сервер и стопка компакт-дисков в руках. Если всё, абсолютно всё, работает так же, как и на производственном сервере, попробуйте их подменить и подождите неделю. Переходите к следующему серверу.
3. Как жить дальше?
Сложный по сути вопрос, но касательно системного администрирования могу дать однозначный ответ "лучше". Теперь вы знаете, откуда и для чего в вашей системе появляются файлы. Знаете, потому что появляются они из пакетов и имеют соответствующие записи в базе данных RPM. Теперь вы можете безбоязненно запускать программу обновления вашей системы (разве у вас такой нет? ;-) ), потому что она -- действительно система, система, основанная на пакетах, обладающих зависимостями, и обновление системы сведено к обновлению пакетов.
Вы ещё помните пару предложений о маршрутизаторе, в который может спокойно ударить молния? Мораль этого примера не в том, что все маршрутизаторы должны быть специализированными железками, а в словах "...копию файла его текущей конфигурации", точнее, в слове "текущей". Опять же, незамыленным взглядом посмотрите на это слово. Текущая -- значит, непрерывно меняющаяся. Жизнь не стоит на месте, выходят новые версии дистрибутивов. Главное, что должно быть неизменным -- отражение долговременных и важных изменений конфигурации вашей системы в её резервных копиях. Надеюсь, если вы будете применять такую практику, то теперь при установке даже одного действительно нужного пакета, при редактировании даже одной строчки в одном конфигурационном файле вы будете думать о нарезке свежего экземпляра того CD, который лежит запертым в сейфе и в любой ситуации позволяет вам уходить домой вовремя.
Ссылки
[1] Maximum RPM: http://www.redhat.com/docs/books/max-rpm/
Copyright (c) 2003, Denis Ovsienko
--- http://www.linuxlib.ru/Linux/idealsa.htm
PS: Денис впоследствии много чего поддерживал, проектировал и разрабатывал (включая altlinux.org/etcnet и различные RFC), а также был старшим по датацентрам Яндекса.
Вариант для распечатки
(ok), 10-Дек-20, 16:45 
