Чем так хорош OpenSource и почему он живее всех живых? Тем что каждый разработчик заботится о "преемниках" этого кода, т.е. о тех, кто будет его читать/править/патчить (нередко копаясь в cvs/svn репозиториях можно встретить "косметические правки"). Но "великие системные администраторы" почему-то об этом забывают и делают так "как умеют/знают/удобнее". В этом нет ничего плохого, если ты в пожизненном найме, но у нас это не практикуется. Я поделюсь своими наработками, которые могут сделать работу администратора эффективнее.
Основные моменты:
- придерживаться идеологии дистрибутива
- избегать неоправданной избыточности
- максимально всё комментировать/документировать
- заранее предусматривать возможность быстрого бэкапа
Обобщение этих четырёх пунктов: рабочая система должна быть построена так, чтобы её можно было максимально быстро воспроизвести с нуля.
Примеры по каждому пункту (здесь приведу примеры только для серверов, но рабочих станций это касается тоже).
Идеология:
- Gentoo: стартап скрипты в init.d, а их конфиги в conf.d; сборка софта из portage, если нет в portage или нужно установить патч - пиши ebuild
- Debian и все дебиано-образные: установка только deb(!), если нужно собрать исходник -> сделай deb пакет (если это deb-source, то dpkg-buildpackage, если это чистый исходник, то dh_make -> правим debian/rules -> dpkg-buildpackage); нужно пересобрать ядро? -> make-kpkg; собрать модуль ядра? -> module-assistant
- FreeBSD: нужно наложить патч на софтину? положи его в /usr/ports/***/files и собери порт любым известным тебе способом.
Что касается всех дистрибутивов Linux и Unix: в каждом из них своя организация файлов конфигурации и прежде чем править конфиги разберись с ней. Например это касается apache. Его от системы к системе пинают кто как может, но при этом везде есть свои плюсы и удобства. Например не нужно в Ubuntu (в дебиан скорее всего так же) по примерам их интернет править конфиг httpd.conf чтобы добавить новый сайт, ведь всё что нужно уже и так есть: sites-available - сюда кладём конфиг сайта, sites-enabled - сюда линку на конфиг если мы хотим сайт включить, mods-available - подключаемые модули, mods-enabled - кладём линку если мы модуль хотим включить и так далее. Во FreeBSD структура конфигов apache иная, но тоже удобная и её так же нужно принимать во внимание.
Избыточность:
- Не нужно заводить базу mysql для 10 пользователей и их паролей, храни их в файлах
- Не нужно заводить три базы mysql (если на это нет веских причин) для ftp, web, и mail сервера. Вместо этого сделай одну базу ldap
- Не нужно писать фаервольные правила для tcp|udp с разрешением в обе стороны, используйте keep-state (а для tcp желательно ещё и setup)
- Если правка происходит от дефолтного конфига, старайся минимальными правками добиться желаемого результата
- Не меняйте без надобности права на директории, обычно права по умолчанию оптимальные, а проблема чаще всего в том, от какого пользователя и группы запускается служба, которой необходим доступ к этой дире
Документированность:
- Документируй всё! Если ты в конфиг помещаешь целый блок, то (если это возможно) помести его в начало или в конец файла и при этом обозначь начало и конец этого блока, а строки его (блока) при необходимости прокомментируй.
- У себя держи информацию о том, какие службы на каких серверах установлены и что дополнительно было сделано, напрмер: gateway: ipfw+natd (стандартные конфиги + /etc/ipfw.rules) - это будет означать что установлен ipfw с natd, запускаются они стандартными скриптами из /etc/rc.d и настройками из /etc/rc.conf, а правила ipfw лежат в /etc/ipfw.rules
Бэкап:
- Если сервер должен работать непрерывно (а на то он и сервер), то заранее подумай о том, какие тома сделать отдельными и положить их на LVM (только если это Linux, для FreeBSD достаточно отдельного слайса), чтобы можно было делать мгновенные снапшоты (обычно это директория /var).
Комментариев нет:
Отправить комментарий