Meetings/ModernOsFeatures/MailingList

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 mailing list (http://uneex.cs.msu.su)
Uneex@imap.cs.msu.su
https://imap.cs.msu.su/mailman/listinfo/uneex