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 | 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