Не знаю, насколько это верно для других ОС (по крайней мере, не для всех точно), но для Linux однозначно справедливо следующее: операционная система – это не набор файлов. Точнее, не просто набор файлов, а совокупность довольно порядочного багажа знаний: стандартов, принятых методик и просто соглашений с одной стороны и текущего состояния живой системы в целом с другой, включая и каждый отдельно взятый файл.
Соответственно и администрирование операционной системы отличается от администрирования содержимого файлового архива.
Давайте ещё раз взглянем на сам термин “операционная система”. Здесь не зря употребляется слово “система” — её компоненты зачастую не могут работать в отрыве друг от друга, значит, в большинстве случаев какие-то компонеты зависят от других компонент.
Те, в свою очередь, зависят ещё от чего-либо, порождая трудно отслеживаемые иерархические и/или циклические зависимости, причём, ещё раз подчеркну, не только на уровне наличия/отсутствия файлов нужных версий, а и сетевых сервисов, RPC-вызовов, других неочевидных связей.
Почему здесь я делаю упор на файлы? Потому, что это первейший показатель упорядоченности системы и, пожалуй, единственная её область, в которой возможно навести хоть какой-то порядок. Если вы ещё не читали книгу Maximum RPM, обязательно прочите хотя бы первые главы. Автор книги постарался (и у него получилось) объяснить принципы пакетного подхода, успешно применяемого в большинстве вчерашних, сегодняшних и завтрашних дистрибутивов, наглядно и убедительно. Если у вас нет возможности прямо сейчас обратиться к этому фундаментальному, хотя и порядком устаревшему труду, поясню: суть первой главы сводится к двум утверждениям:
человек не может сам вручную отслеживать зависимости между тысячами и десятками тысяч файлов;
машина должна работать, а человек думать (приписывается IBM, насколько я помню).
Кто виноват?
Довольно давно уже можно встретить руководства по установке ПО для Linux, написанные самым разнообразным контингентом, которые сводятся к благословлению и проклятию большинства софта для POSIX (*NIX):
configure && make && make install !
Многие могут спросить: “И что тут такого? Я сам так делаю”. Резонный вопрос. Если руководство называется “Как установить <название ПО> за 15 минут” и выполнение предписанных шагов действительно позволяет получить работающую программу за 15 минут, что неправильно?
А вот что: такие руководства по совести должны называться “Как установить <название ПО> за 15 минут, если у Вас уже не крутится рабочая инсталляция, которую нежелательно будет сломать из-за неудачно скомпилированных файлов или сноса всю прошлую неделю редактировавшегося конфигурационного файла неконтролирумым make install; если Вы наизусть помните все ключи configure; если Вы самостоятельно напишете init и logrotate сценарии для этого ПО; если Вы не собираетесь автоматизированно обновляться до следующей версии и если Вы самостоятельно разыщете все файлы, которые наплодил make install, когда захотите избавиться от этого ПО”. Немного менее привлекательно, да? Мне такая формулировка не нравится, хотя это дело личного и профессионального вкуса. Всё зависит от того, какие цели преследуются.
Давайте определимся, имеет ли смысл далее читать дальше? Если:
необходим быстрый эффект любым путём (есть специальная группа лекарств: симптоматические, единственное их действие заключается в том, что вы чувствуете себя здоровым и нагружаете обычной нормой работы больной организм);
вам лень читать документацию;
вы переустанавливаете систему очень часто и ничуть от этого не страдаете;
обновления системы у Вас популярностью не пользуются;
вас вполне устраивает делать резервное копирование всей файловой системы, чтобы ничего случайно не забыть, то напрягаться особо и не стоит. Если же наличествуют следующие признаки:
ваша основная специализация — сопровождение серверов, а не пользователей;
вы непосредственно, то есть лично своей зарплатой/репутацией отвечаете за доступность и правильную работу сервисов в режиме как минимум 24*5/24*6;
вы отвечаете более чем за 1 машину;
вы администрируете публично доступные сервисы и отдаёте себе отчёт, что свежую уязвимость сканер-автомат способен нащупать и проломить за несколько секунд;
время восстановления работоспособности повреждённого или полностью уничтоженного участка сети и/или сервера не должно превышать время монтажа аппаратного обеспечения + несколько часов;
предоставление сервисов вашей инфраструктурой планируется не на ближайшие пару месяцев, а постоянно;
показатель труда системных администраторов должен являться суммой усилий нынешних и предыдущих сотрудников, а не случайным значением из ряда разнесённых по времени и направлению попыток изменить что-то к лучшему,
то с большой степенью вероятности можно утверждать, что системное администрирование — ваша работа и выполнять её можно только правильно, иначе это уже будет совсем другим занятием. Причём чем больше организация и чем интенсивнее в ней используются информационные технологии, тем это очевиднее. Впрочем, это справедливо для большинства профессий.
Что делать?
Итак, как справиться с фермой серверов?
Во-первых, поймите, что время, оставшееся до полной потери данных — в лучшем случае остаток техресурса конкретного сервера.
Во-вторых, разделите котлеты и мух. То есть определите, что именно на каждом сервере является уникальными данными (базы данных, наполнение web-серверов, мастер-зоны DNS и т. д.) и тщательно инвентаризуйте.
Выделите себе время и регулярно делайте резервное копирование, задвинув на все остальные занятия — это ваша козырная карта в любой ситуации.
Второй половиной будет пёстрый табор установленного ПО с прилагающимися конфигурационными файлами (если некоторые из них нетривиальны, то разумнее будет их отнести к первой группе). Выясните, что именно и где у вас работает, возможно, не обойдётся без сюрпризов.
Фронт работ намечен, но как оценить степень соответствия идеалу?
Очень просто. Например, существует наработанная методика обслуживания аппаратных маршрутизаторов: необходимо всего лишь хранить в безопасном месте копию файла его текущей конфигурации.
Предположим, в маршрутизатор попадает молния и от него остаётся только помятая металлическая коробка с угольками. Требуем новый такой же модели, заливаем конфигурацию и — вуаля! — штатный режим восстановлен.
Довольно показательно. Применим тот же подход, но с известными усложнениями в деталях.
Прежде всего необходимо знать, что восстанавливать. Для этого всё, что можно установить из входящих в дистрибутив RPM, а не собирать вручную, должно быть установлено из RPM. В этом случае вы получаете вместо карты с кладом “возьми исходники с этого сайта, патчи с этого, а скрипт, запускающий configure, в архиве, лежащем там-то… или вот там-то… не помню, поищи” краткое и однозначное “установи пакет такой-то”.
Предвижу возражения: что делать, если в дистрибутиве старая версия пакета? А если пакета в дистрибутиве нет? На первое отвечу: пользуйтесь системой обновлений вашего дистрибутива и настройте её на ваше локальное зеркало обновлений (неужели зеркало ещё не настроено?).
Если периодичность обновлений оставляет желать лучшего, смените дистрибутив, вы обладаете правом разумного выбора средств, коль на вас возложена ответственность за результат. Возможно, это решит сразу и второй вопрос.
Если не решит, то попросите издателей дистрибутива сделать это, должны же они иметь какую-то обратную связь!
Если не поможет, соберите пакет сами, а ещё лучше – соберите и попросите включить в дистрибутив, всё равно работа уже проделана и вы сможете помочь другим администраторам. Некоторые из них потратят освободившееся время на сборку и включение пакета, который в будущем понадобится вам.
Итак, вы имеете список стандартных пакетов, и, возможно, несколько самосборных RPM. Возьмите подходящий по параметрам запасной сервер и выполните установку новой системы. Сохраните список пакетов из инсталлятора (если он этого не умеет, вы вправе изменить свои предпочтения).
Несколько слов о наборе пакетов: выбор “устанавливать всё” не так хорош, как кажется. Во-первых, вы получите пакеты, которые никогда не будут использоваться, но будут требовать обновления.
Во-вторых, если какой-то из используемых вами стандартных или самосборных пакетов имеет неправильные зависомости, вы этого просто не заметите, а неправильные зависмости — вещь неприятная и определённый процент сбоев в будущем.
В-третьих, на специализированном сервере собственно система вместе с ПО может занимать 300 мегабайт, так зачем же выбрасывать лишние гигабайты (5—10 и более в зависимости от дистрибутива) на ветер? Дисковое пространство лишним не бывает, это проверенное временем правило.
Оглянитесь, не забыто ли что-то за бортом. Я, например, чаще всего забывал установить утилиты сетевой диагностики. Если да, то повторяйте установку с сохранением списка пакетов до достижения состояния “ни прибавить, ни отнять”.
Поздравляю, теперь вы действительно знаете, что именно работает у вас на конкретно взятом сервере. Дискета, как известно, вещь дешёвая и ненадёжная, поэтому лучше всего будет поместить её образ и на CD с конфигурационными файлами. Основная часть работы проделана, теперь необходимо только поддерживать ваши запечатлённые на обычном CD-R концентрированнные сведения актуальными.
Восстановление самого ценного — данных — в терминах работы с пакетами не формулируется и сильно зависит от самих данных, так что постарайтесь прорепетировать эту сцену самостоятельно, но с соблюдением тех же требований: только чистый сервер и стопка компакт-дисков в руках. Если всё, абсолютно всё работает так же, как и на производственном сервере, попробуйте их подменить и подождите неделю.
Переходите к следующему серверу.
Как жить дальше?
Сложный по сути вопрос, но касательно системного администрирования могу дать однозначный ответ “лучше”.
Теперь вы знаете, откуда и для чего в вашей системе появляются файлы. Знаете потому, что появляются они из пакетов и имеют соответствующие записи в базе данных RPM. Теперь вы можете безбоязненно запускать программу обновления вашей системы (разве у вас такой нет? ;-), потому что она — действительно система, система, основанная на пакетах, обладающих зависимостями, и обновление системы сведено к обновлению пакетов. Вы ещё помните пару предложений о маршрутизаторе, в который может спокойно ударить молния? Мораль этого примера не в том, что все маршрутизаторы должны быть специализированными железками, а в словах “…копию файла его текущей конфигурации”, точнее, в слове “текущей”.
Опять же, незамыленным вглядом посмотрите на это слово. Текущая — значит, непрерывно меняющаяся. Жизнь не стоит на месте, выходят новые версии дистрибутивов. Главное, что должно быть неизменым — отражение долговременных и важных изменений конфигурации вашей системы в её резервных копиях.
Надеюсь, если вы будете применять такую практику, то теперь при установке даже одного действительно нужного пакета, при редактировании даже одной строчки в одном конфигурационном файле вы будете думать о нарезке свежего экземпляра того CD, который лежит запертым в сейфе и в любой ситуации позволяет вам уходить домой вовремя.
Автор Денис Овсиенко