[Uneex] Предложение по теме семинара
Yuri Ryazantsev
yuri на unix.ru
Ср Ноя 3 02:13:16 MSK 2004
Fr. Br. George wrote:
> [2Yuri] Если с абзацами времени нет, давайте хотя бы ключевые слова -- о
> чём предполагается говорить. Я могу выудить их из предыдущей переписки,
> однако не уверен, что всё это появится в разговоре.
Прошу сразу учитывать, что все вопросы поднимаемые в этой дискуссии
имеют не одно решение. А значит не нужно искать повода для разжигания
религиозных войн :-)) Каждый волен делать то, что может, в той
обстановке, которая ему привычна. Тем более, что универсального
дистрибутива нет. Всегда под рукой у админа есть "напильник" для заточки.
Ну если ничего не забыл, то по порядку (правда не в том порядке, в
котором это было первоначально; но так мне кажется логичнее при
построениях сети в компании :-) :
1. Организация сетевых соединений и мониторинг сети.
Здесь можно много обсуждать :-)) Но построить чуть более сложную
сеть, чем /24 с одним default gateway оказалось значительно проще на BSD
системах. Это связано и с тем, что эти системы и использовались больше в
ISP и, соответственно, программ больше - а, значит, и выбор удобного
инструмента :-) По мелочам:
- VLAN. Поддержку этого в стартовых скриптах (и во всем остальном) для
Mandrake можно назвать практически отсутствующей. Для использования во
FreeBSD мне вообще ничего не потребовалось исправлять, кроме одной
строки в isc-dhcp
(http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/39621). А теперь даже
есть опция переименования сетевых интерфейсов:
# ifconfig xl0 name extern
Насколько приятней работать, когда не надо помнить что vlan12 - это
интерфейс сети N-ского отдела :-))
- построение фильтрации пакетов. Можно вспомнить, как стало удобнее под
Linux, когда перешли от ipchains на iptables. Такое же чувство я испытал
еще на двух переходах - с iptables на ipf; и с ipf на pf. Скажу только
про последний - в пределах одного конфигурационного файла разрешаешь
задачи - NAT, ограничение трафика (ALTQ), ограничение количества
соединений, динамическая фильтрация и т.д. Как последний аргумент, могу
рассказать о построении отказоустойчивого firewall (два сервера включены
в параллель; один работает, другой в горячем резерве. В момент
переключения даже таблица connection state "подхватывается").
- netgraph. Идеология может быть и спорная, но мне пока нравиться.
Фактически это набор кубиков конструктора для сетевых интерфейсов на
уровне ядра. Грубо - если мне надо сделать PPP через ethernet на ATM, то
я беру три кубика и соединяю их последовательно. Подчеркну, что
полученная сборка обрабатывает пакеты на уровне ядра (быстродействие).
Более подробно и не так грубо - http://citrin.pp.ru/netgraph/
2. Построение сервера.
- базовая система. Сравните два диалога:
- Какая ОС на сервере?
- FreeBSD
- А версия?
- 4.10
- Какая ОС на сервере?
- Linux
- А версия?
- 2.6.8
- А с какими патчами?
- ....
В последний еще можно добавить и вопрос о дистрибутиве, т.к. у всех по
разному :-((
Базовый разворот системы на нулевой сервер требет моего присутствия у
консоли от 10 до 20 минут. Далее все остальные действия по сети. Даже
полный update системы. Поэтому в моем понимании система должна состоять
из небольшой базовой части (ядро и базовые утилиты и библиотеки), и
отдельного набора пакетов под задачи (разные для разных серверов).
- rc_subr практически аналог /etc/sysconfig. Суть - переменными
производить необходимые настройки на практически неизменных скриптах.
Только исторически во FreeBSD это раньше был один файл (/etc/rc.conf), а
теперь более гибкое решение - добавлен каталог(и).
- управление пакетами. Может у меня что-то в голове не так, но я ни разу
не попадал на дистрибутив, в который все пакеты, нужные мне для решения
задач, не требовали внесение исправлений. Добавить требуемый патч -
проблем нет, также как и собрать после этого новый пакет. Но вести
собственную поддержку пакета вместе с кем-то с тобой не связанным уже
становится нетривиально. Добавлять свои изменения и оставаться в том же
окружении разработки, что и система во FreeBSD оказалось удобнее. Думаю,
что в Gentoo должно быть еще удобнее.
- UFS2. Понимаю, что журналируемые ФС до такой степени надежны, что не
надо их проверять. Но по мне fsck - ближе. А когда для больших объемов
это background, то вообще здорово. Дополнительная фича - snapshot.
Позволяет решить без больших проблем следующие задачи:
- online доступ к состоянию некоторого архива N-ой давности (read-only);
- сделать backup ФС на работающем сервере, как мгновенный снимок,
особенно полезно для backup почтовых серверов;
Для тех, кто проведет параллель между snapshot и возможностями Linux
LVM, предлагаю подумать на тему как LVM "узнает" когда можно делать
снимок ФС, если ФС - надстройка над LVM. Вроде как есть патч,
разрешающий эту проблему, но по рассказам, мне показалось, что это
"костыль". Буду благодарен, если кто просветит.
- jail. Похож на chroot, но кроме этого еще и изолирует сетевой стек и
пространство процессов. Почти "виртуальная машина со своим сетевым
интерфейсом". У меня каждая небольшая задача сидит в своем jail'е.
Например - почтовый сервер состоит из mailbox storage, SMTP server, user
DB, syslog. Физически на одной машине, но в 4 jail'ах. Самое приятное,
что в случае необходимости ничего не стоит любой из jail'ов перенести на
другую машину (например по соображениям нагрузки) в этой сети. При этом
даже IP не меняется :-)) Далее предлагаю фантазировать каждому :-))
- MAC - mandatory access control. Как я уже сказал - это для маньяков,
помешанных на защищенности. Тема слишком обширна, для того, чтобы у нас
хватило на нее время :-))
3. Осталось два пункта - почта и Internet и Intranet. Опираясь на то,
что было сказано перед этим, можно будет только привести примеры
практической реализации.
[2 George] Понимаю, что это не тезисы, но я обещал дискуссию :-))
> При условии положительного ответа на обе просьбы завтра сделаю анонс про
> пятницу. В пятницу аудитория без компьютеров, но они нам нужны?
Наверное нет. Достаточно чтобы было чем и на чем писать :-))
PS. Рекомендую для прочтения :-))
http://www.freebsd.org/doc/ru_RU.KOI8-R/articles/explaining-bsd/article.html
--
Yuri Ryazantsev <yuri на unix.ru> | RIPE: YR1-RIPE
UNIX System Network Administrator | RIPN: YAR1-RIPN
Подробная информация о списке рассылки Uneex