№11(24) ноябрь 2004

подписной индекс 81655

www.samag.ru

Утилита nLite:
формируем свой дистрибутив
Windows XP/2000/2003
Мониторинг UNIX-серверов
c помощью Nagios и SNMP
Использование бездисковых
Linux-станций с загрузкой по сети
Пакетный фильтр OpenBSD
Танцуем самбу
Linare – настольный дистрибутив Linux
Иммунная система для компьютера
Пассивный перехват трафика
№11(24) ноябрь 2004

Запись дисков CD-R/RW в Linux

Создание и настройка
сервера терминалов
 оглавление

АДМИНИСТРИРОВАНИЕ СЕТИ
Мониторинг UNIX-серверов Пассивный перехват трафика
c помощью Nagios и SNMP
Павел Закляков
Андрей Бешков amdk7@mail.ru 52
tigrisha@sysadmins.ru 4
HARDWARE
Использование бездисковых
Linux-станций с загрузкой по сети Запись дисков CD-R/RW в Linux
Часть 1
Андрей Маркелов
andrew@markelov.net 12 Владимир Мешков
ubob@mail.ru 56
Пакетный фильтр OpenBSD
ПРОГРАММИРОВАНИЕ
Денис Назаров
pheonix@sysattack.com 16 Создаем кроссплатформенное
приложение на основе FLTK
Виртуальные войны
Сравнительное тестирование VMWare Workstation Антон Борисов
и Cooperative Linux. a.borisov@tesv.tmb.ru 64
Михаил Платов ОБРАЗОВАНИЕ
platov@cs.vsu.ru 21
Class Server 3.0. – новое решение
Обзор эмулятора mips64emul Microsoft в области образования
Александр Байрак Андрей Филиппович
x01mer@pisem.net 26 fil@ics.bmstu.ru 71
Лейся песня, Файловая система NTFS извне и изнутри
или Сервер потокового аудио Часть 1
своими руками
Крис Касперски
Сергей Яремчук kk@sendmail.ru 72
grinder@ua.fm 28
Разработка сценария регистрации
Танцуем самбу пользователей в сети
Часть 1
Роман Гребенников
grv@cs.vsu.ru 32 Иван Коробко
ikorobko@prosv.ru 78
Заметки о Linare
Создание и настройка сервера
Валентин Синицын терминалов
val@linuxcenter.ru 39
Роман Марков
Использование программы nLite stepan-razin@newmail.ru 90
Максим Костышин
Maxim_kostyshin@mail.ru 42 BUGTRAQ 63

БЕЗОПАСНОСТЬ
Иммунная система для компьютера
Сергей Яремчук
grinder@ua.fm 48
№11(24), ноябрь 2004 1
 администрирование
МОНИТОРИНГ UNIX-СЕРВЕРОВ
C ПОМОЩЬЮ NAGIOS И SNMP
В предыдущей статье этого цикла [1] мы говорили о том,
как научить Nagios следить за Windows-серверами, пользу-
ясь сведениями, предоставляемыми SNMP. Теперь пришла
пора рассказать, как можно собирать данные о жизнедея-
тельности серверов, работающих под управлением разных
диалектов UNIX. Для этого мы будем снова использовать
SNMP. Если вас мучают вопросы, что такое этот преслову-
тый SNMP, как он работает и для чего предназначен, то,
наверное, стоит ознакомиться с RFC 1156, 1157, 1213, 1146,
2571, 2574 и заодно прочитать предыдущую статью [1]. Пе-
ред началом повествования следует сказать, что система
мониторинга, на которой будут выполняться все действия,
описанные ниже, у меня работает под управлением
FreeBSD. За время, прошедшее с момента публикации пре-
дыдущей статьи, Nagios дорос до версии 1.2, также изме-
нилась с 4.7 на 4.10 версия системы FreeBSD, используе-
мой на моем сервере. Теперь уже нет необходимости ком-
пилировать Nagios из исходников, все прекрасно ставится
из портов. Впрочем, стоит, как всегда, сделать традицион-
ную оговорку: все, что я рассказывал в предыдущих стать-
ях о Nagios и о чем буду говорить впредь, вполне надежно
работает и под управлением других UNIX-подобных опера-
ционных систем.
Вдобавок необходимо заметить, что пакет usd-snmp, ис-
пользовавшийся нами для работы с SNMP прежде, теперь
превратился в net-snmp версии 5.1.1.
Перейдем к задаче на сегодня. Необходимо настроить
мониторинг серверов, работающих под управлением
FreeBSD 4.10 и ALT Linux 2.3. Соответственно, для приме-
ра им даны имена reddaemon и penguin. Впрочем, стоит
заметить, что net-snmp успешно работает и на многих дру-
гих UNIX-подобных системах:
! HP-UX (9.0, 10.20, 11.0);
! Ultrix (от 4.2 до 4.5);
! OSF (3.2, 4.0);
! Solaris (SPARC/ULTRA от 2.3 до 2.8) (Intel 2.9) SunOS
(4.1.4 и выше);
! NetBSD (от 1.0 до 1.5 alpha);
! FreeBSD (от 2.2 и выше);
! Linux (ядра от 1.3 и выше);
! BSDI (от 2.1 до 4.0.1);
! AIX (3.2.5, 4.1.5);
! OpenBSD (2.6, 2.8);
! OS X (10.1.1, 10.1.2);
! Irix (от 5.1 до 6.5);
! QNX 6.2.1A;
! Dynix/PTX 4.4.
На данный момент идут работы по портированию net-
snmp на Windows. В результате уже сейчас можно сказать,
4
АНДРЕЙ БЕШКОВ
что программа работает на 90% при условии компиляции с
помощью Visual C++ и cygwin32.
Отсюда можно сделать вывод, что, приложив некото-
рые усилия, мы смогли бы мониторить любую из этих опе-
рационных систем, благо процедуры установки и настрой-
ки net-snmp для каждой из них почти не отличаются друг от
друга.
Первым делом на сервере мониторинга, работающем
под FreeBSD, устанавливаем самую новую версию пакетов
net-snmp и nagios-plugins.
# cd /usr/ports/net-mgmt/net-snmp
# make install clean
# cd /usr/ports/net-mgmt/nagios-plugins
# make install clean
Пакет net-snmp4, все еще присутствующий в дереве пор-
тов, устанавливать не стоит из-за сильной устарелости.
На подопытных серверах также необходимо проинстал-
лировать net-snmp. Для FreeBSD это делается вышеуказан-
ным способом, но nagios-plugins ставить не следует. Для
ALT Linux 2.3 требуется выполнить следующие команды.
# apt-get update
# apt-get install net-snmp net-snmp-utils
На этом процедуру инсталляции можно считать завер-
шенной. Для того чтобы система могла отвечать на SNMP-
запросы, внутри нее должен работать демон snmpd. Ему,
как и всем порядочным программам, для успешного функ-
ционирования необходимо иметь конфигурационный файл.
В качестве такового обычно выступает snmpd.conf. При ра-
боте с Linux он, как правило, располагается в /etc/snmp/, а
для FreeBSD соответственно актуальна директория /usr/
local/etc/.
Файл конфигурации одинаков для всех систем, поэто-
му мы изучим его на примере, используемом для Linux.
# Ìåñòîíàõîæäåíèå ñèñòåìû â ðåàëüíîì ìèðå
syslocation Rostov-on-Don Kranoarmejskaya str. ↵
Building 1 testlab 407
# Êîíòàêòû àäìèíèñòðàòîðà
syscontact Andrew Beshkov admin@example.com tel. 390-34-89
# Ñåðâèñû, ïðåäîñòàâëÿåìûå ñèñòåìîé
sysservices = 79
Думаю, что есть необходимость подробно объяснить
процедуру, с помощью которой рассчитывается содержи-
мое переменной sysservices. Нужно выбрать из списка уро-
вень и подставить его номер вместо L в формулу 2L-1.
! 1 – physical (концентраторы);
! 2 – datalink/subnetwork (мосты);
! 3 – internet (IP-шлюзы);

! 4 – end-to-end (IP-хост);
! 5 – OSI (протоколы OSI);
! 6 – OSI (протоколы OSI);
! 7 – applications (SMTP, POP3 и прочие сервисы).
К примеру, для маршрутизатора расчет будет выглядеть
так: 23-1=4. А для обычного хоста 24-1 + 27-1 = 72. Если вы
хотите мониторить все уровни, то лучше всего использо-
вать цифру 79.
Можно создать файлы конфигурации с помощью про-
граммы snmpconf, но я предпочитаю делать все самостоя-
тельно. По крайней мере, так достигается глубинное пони-
мание механизмов работы используемого программного
обеспечения.
Следующим интересным моментом является безопас-
ность. В традиционном SNMP для версий протокола 1 и 2с
за нее отвечают строки сообществ (community strings). Их
стоит воспринимать как своеобразные аналоги паролей. Со-
общества бывают двух видов – private и public. Отличаются
они друг от друга лишь тем, что первое позволяет изме-
нять данные внутри наблюдаемого устройства, а второе
дает возможность только просматривать их. Самым про-
стым способом определить эти сообщества является вне-
сение в конфигурационный файл следующих строк:
rocommunity InK12345
rwcommunity 12r341289j
Как вы уже могли догадаться, rocommunity дает право
читать данные, а rwcommunity предоставляет полный дос-
туп. Впрочем rwcommunity тоже можно удалить, если вы не
собираетесь изменять данные внутри устройства с помо-
щью snmp. Вышеприведенные опции составляют минималь-
ный рабочий файл конфигурации. Но квалифицированные
системные администраторы обычно так не делают, потому
что иначе будет трудно различать это устройство среди ог-
ромного множества других SNMP-приборов.
Итак, давайте посмотрим, что за сведения могут предо-
ставить нам подопытные устройства. Для этого запускаем
на них демон snmpd. Чтобы это сделать, кладем на Linux-
машине файл snmpd.conf в /etc/snmp и затем выполняем
следующую команду:
# service snmpd start
Если есть желание, чтобы демон стартовал автоматичес-
ки при запуске машины, выполняем еще и такую команду:
# chkconfig snmpd on
И обязательно убеждаемся в успешности выполнения
предыдущей команды с помощью:
# chkconfig snmpd --list
Для FreeBSD файл с настройками должен находиться в
/usr/local/etc/snmp/. Кроме этого, нужно включить запуск де-
мона в скрипте /usr/local/etc/rc.d/snmpd.sh. Чтобы это сделать,
ищем внутри него строку snmpd_enable= «NO» и вписыва-
ем в нее слово «YES». Затем вручную запускаем демон.
№11(24), ноябрь 2004
администрирование
# /usr/local/etc/rc.d/snmpd.s
Стоит отметить тот факт, что, кроме snmpd, в комплект
net-snmp входит демон snmptrapd, отвечающий за обработку
SNMP-ловушек. По умолчанию он выключен, стоит помнить,
что в системе не должно работать ненужного программно-
го обеспечения, поэтому без особой надобности не будем
его включать. Говорить о том, как можно использовать эти
самые ловушки, мы будем в следующей статье.
Теперь можно проверить, что за сведения предоставля-
ют наши сервера. Сделать это можно как минимум двумя
способами. C помощью утилит командной строки snmpget
или snmpwalk.
# snmpwalk –m ALL -c InK12345 -v1 penguin ↵
.iso.org.dod.internet.mgmt.mib-2.system
SNMPv2-MIB::sysDescr.0 = STRING: Linux altlinux.unreal.net 2.4.27-std-up-alt1
#1 Sun Oct 17 22:42:45 MSD 2004 i686
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
SNMPv2-MIB::sysUpTime.0 = Timeticks: (1751738) 4:51:57.38
SNMPv2-MIB::sysContact.0 = STRING: Andrew Beshkov <admin@example.com>
SNMPv2-MIB::sysName.0 = STRING: penguin.example.com
SNMPv2-MIB::sysLocation.0 = STRING: Rostov-on-Don Kranoarmejskaya str.
Building 1 testlab 407
SNMPv2-MIB::sysServices.0 = INTEGER: 0
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (3) 0:00:00.03
SNMPv2-MIB::sysORID.1 = OID: IF-MIB::ifMIB
SNMPv2-MIB::sysORID.2 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.3 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.4 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.5 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.6 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
SNMPv2-MIB::sysORID.7 = OID:
SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.8 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.9 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORDescr.1 = STRING:
The MIB module to describe generic objects for network interface sub-layers
SNMPv2-MIB::sysORDescr.2 = STRING: The MIB module for SNMPv2 entities
SNMPv2-MIB::sysORDescr.3 = STRING:
The MIB module for managing TCP implementations
SNMPv2-MIB::sysORDescr.4 = STRING:
The MIB module for managing IP and ICMP implementations
SNMPv2-MIB::sysORDescr.5 = STRING:
The MIB module for managing UDP implementations
SNMPv2-MIB::sysORDescr.6 = STRING: View-based Access Control Model for SNMP.
SNMPv2-MIB::sysORDescr.7 = STRING: The SNMP Management Architecture MIB.
SNMPv2-MIB::sysORDescr.8 = STRING:
The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.9 = STRING:
The management information definitions for the SNMP User-based Security Model.
Опция –m ALL указывает, что нужно показать все дере-
во ниже выбранного OID, после -с располагается комьюни-
ти string, затем идут версия snmp-протокола, имя машины
и OID запрашиваемой ветви. Стоит отметить, что OID мож-
но записывать разными способами. В большинстве случа-
ев префикс iso.org.dod.internet.mgmt.mib-2. можно не писать,
так как он предполагается по умолчанию, соответственно
мы получим тот же самый результат, если напишем просто
system. Для указания OID вместо длинных названий можно
использовать цифровые идентификаторы. К примеру, этот
же куст дерева можно адресовать следующей комбинаци-
ей цифр .1.3.6.1.2.1.1. Если есть желание увидеть все MIB-
дерево, то можно выполнить вышеуказанную команду, вов-
се не указывая OID. Думаю, вы будете впечатлены разме-
рами листингов, которые система выведет вам. Использо-
вать командный интерфейс полезно, но, к сожалению, это
не всегда помогает получить правильное представление о
строении MIB-дерева.
В этом нам помогут утилиты, называемые MIB-браузе-
рами. Для Linux и FreeBSD лучше всего подойдет програм-
ма mbrowse. Обычно она по умолчанию входит во многие
5
 администрирование
дистрибутивы. В действии эта программа выглядит следу-
ющим образом.
Для систем Windows существует достаточно много по-
добных утилит. О том, какую из них и почему стоит выб-
рать, я подробно рассказывал в предыдущей статье [1].
Конечно, обилие доступных данных поражает, но все
же хотелось бы точно знать, как это использовать с наи-
большей выгодой. Давайте вновь вернемся к предмету на-
шего разговора. Кроме стандартных ветвей, net-snmp со-
здает свою собственную ветвь .iso.org.dod.internet.private.
enterprises.ucdavis, которая содержит в себе все необходи-
мые данные. В цифровом формате адрес этой ветви выг-
лядит так: .1.3.6.1.4.1.2021. Стоит отметить, что в некото-
рых snmp-браузерах данная ветка может быть недоступна
через свое символьное обозначение, но в то же время зап-
росы, выполняемые с помощью цифровых OID, будут впол-
не работоспособны. Думаю, вы со мной согласитесь, что
это немного неудобно, поэтому, чтобы включить распозна-
вание символьных имен, нам нужно будет скопировать MIB-
базы из /usr/share/snmp/mibs/ в рабочую директорию исполь-
зуемого браузера.
Как показывают тесты, все работает достаточно непло-
хо, но, к сожалению, наша система сейчас отвечает на
SNMP-запросы, приходящие с любого IP-адреса. К тому же,
по умолчанию используется первая версия протокола SNMP,
которая передает все данные в открытом виде. Необходи-
мо это исправить и заодно поднять уровень безопасности.
Для этого вносим в файл snmpd.conf следующие строки
вместо rocommunity и rwcommunity:
com2sec nagios 10.10.21.55/32 InK12345
group MyROGroup v2c nagios
view all included .1
access MyROGroup "" any noauth exact all
none none
Стоит отметить, что опции rocommunity и rwcommunity –
всего лишь оболочки вокруг более мощного набора команд
VACM (Version-based Access Control Module), которым мы
воспользовались ранее.
Таким образом, мы сказали, что система, подвергаемая
мониторингу, может принимать SNMP-запросы лишь от ма-
шины с адресом 10.10.21.55, которая является сервером
мониторинга, и привязали этот адрес к внутреннему имени
системы безопасности «nagios». Затем разрешили этому
имени символизировать группу MyROGroup, а заодно зак-
6
репили за ним право передавать SNMP-команды только с
помощью версии протокола 2с. Следующей строкой созда-
ли вид на определенную область SNMP-дерева. В данном
случае с помощью запросов можно просматривать все, что
лежит ниже .1 или .iso. Пользуясь этой опцией, можно ог-
раничить дерево, доступное запросу до одной ветки или
даже до единственного OID. И заключительной строкой ука-
зываем настройки безопасности для нашей группы
MyROGroup. После этого не забываем перезапустить де-
мон SNMP и проверить, как все работает.
# snmpwalk –m ALL -c InK12345 -v2ñ penguin ↵
.iso.org.dod.internet.mgmt.mib-2.system
Обратите внимание на опцию –v2c. Если все прошло
нормально, выполняем ту же команду с –v1 и убеждаемся,
что она не возвращает никаких сведений. Как вы, навер-
ное, уже догадались, мы полностью отключили возможность
вносить извне изменения в данные, находящиеся внутри
наблюдаемого объекта. Выполняем проверку того, как ра-
ботает модуль check_snmp, установленный на сервере
Nagios. К примеру, неплохо было бы посмотреть Uptime
системы:
# /usr/local/nagios/libexec/check_snmp -H penguin ↵
-o .1.3.6.1.2.1.1.3.0 -C InK12345 -P 2c
Invalid SNMP version 2c
По каким-то странным причинам автор забыл включить
в него возможность работы с протоколом версии 2с. Ошиб-
ка, говорящая, что эта версия не поддерживается, – не со-
всем то, что мы ожидали получить, поэтому давайте возьмем
в руки большой напильник и самостоятельно поправим мо-
дуль check_snmp. Для этого нужно отредактировать файл
/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-1.3.1/
plugins/check_snmp.c. Ищем в нем следующую строку:
-P, --protocol=[1|3]\n\
и заменяем ее на:
-P, --protocol=[1|2c|3]\n\
Затем, найдя условие такого вида:
if (proto == NULL || (strcmp(proto,DEFAULT_PROTOCOL) == ↵
0) ) { /* default protocol version */
asprintf(&proto, DEFAULT_PROTOCOL);
asprintf(&authpriv, "%s%s", "-c ", community);
}
80
↵ Вставляем после него вот такие строки:
else if ( strcmp (proto, "2c") == 0 ) { ↵
/* snmpv2c args */
asprintf(&proto, "%s", "2c");
asprintf(&authpriv, "%s%s", "-c ", community);
}
Проводим перекомпиляцию, а затем и замену старого
модуля новым.
# make install
После этого команда с ключом -P 2c должна отработать
 администрирование
нормально. Вписываем в файл checkcommands.cfg описа- normal_check_interval 1
ние команды check_snmp_oid, с помощью которой будем retry_check_interval 1
contact_groups onix-admins
проводить мониторинг и вызывать модуль check_snmp. register 0
}
define command{ Данный сервис показывает время работы системы с мо-
command_name check_snmp_oid
command_line $USER1$/check_snmp -H $HOSTADDRESS$ ↵ мента последней перезагрузки. Для этого используется OID
-o $ARG1$ -C $ARG2$ -w $ARG3$ -c $ARG4$ ↵ .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0. Почти
-u $ARG5$ -l "" -P $ARG6$
} такого же эффекта можно добиться с помощью .iso.org.dod
.internet.mgmt.mib-2.host.hrSystem.hrSystemUptime.0. Хотя
Затем в файле hosts.cfg рассказываем о наших серве- тут стоит сделать маленькое примечание: второй OID по-
рах. казывает не время, прошедшее с последнего перезапуска
системы, а момент последней инициализации SNMP.
# Îïèñûâàåì øàáëîí õîñòà
define host{ define service{
name generic-host use generic-service
notifications_enabled 1
event_handler_enabled 1 host_name Linux
service_description System Uptime
flap_detection_enabled 1 is_volatile 0
process_perf_data 1
retain_status_information 1 check_period 24x7
check_command check_snmp_oid ↵
retain_nonstatus_information 1 !.1.3.6.1.2.1.1.3.0!InK12345! ""! ""! ""!2c
max_check_attempts 10
notification_interval 120 }
notification_period 24x7
notification_options d,u,r Следующим интересным для нас моментом будет сово-
register 0
} купность сервисов, отображающих количество занятых бло-
ков разделов /, home, и совокупный процент использован-
define host{
use generic-host ных блоков физической и своп-памяти. Для того чтобы по-
host_name Linux нять, где находятся необходимые сведения, посмотрите вет-
alias Standard Linux Server
address penguin ку .iso.org.dod.internet.mgmt.mib-2.host.hrStorage.hrStorage
check_command check-host-alive Table. Принцип анализа ветви довольно прост. В hrStorage
}
Index содержится список уникальных идентификаторов, опи-
define host{ сывающих каждое устройство. А hrStorageType в свою оче-
use generic-host
host_name FreeBSD редь хранит типы устройств. hrStorageDesc заполнен тек-
alias Standart FreeBSD Server стовыми описаниями объектов. Для моей системы это выг-
address reddaemon
check_command check-host-alive лядит так:
}
hrStorageDescr.2 = STRING: Real Memory
hrStorageDescr.3 = STRING: Swap Space
И, конечно же, не забываем причислить их к группе хо- hrStorageDescr.4 = STRING: /
стов onix-servers, внеся следующие строки в файл host hrStorageDescr.5 = STRING: /home
hrStorageDescr.6 = STRING: /proc/bus/usb
groups.cfg
В hrStorageAllocationUnits указан размер блока для каж-
define hostgroup{ дого из устройств:
hostgroup_name onix-servers
alias Onix Servers
contact_groups onix-admins hrStorageAllocationUnits.2 = INTEGER: 1024 Bytes
members Linux, FreeBSD hrStorageAllocationUnits.3 = INTEGER: 1024 Bytes
} hrStorageAllocationUnits.4 = INTEGER: 4096 Bytes
hrStorageAllocationUnits.5 = INTEGER: 4096 Bytes
hrStorageAllocationUnits.6 = INTEGER: 1024 Bytes
Настройку оповещений и контактов пропускаем, так как
эта тема обсуждалась ранее неоднократно. Самое время за- Ну а hrStorageSize указывает, сколько блоков в каждом
няться описанием сервисов, за которыми мы будем следить. устройстве.

# Îïèñûâàåì øàáëîí ñåðâèñà hrStorageSize.2 = INTEGER: 54156

define service{ hrStorageSize.3 = INTEGER: 216836
name generic-service hrStorageSize.4 = INTEGER: 273087
active_checks_enabled 1 hrStorageSize.5 = INTEGER: 196780
passive_checks_enabled 1 hrStorageSize.6 = INTEGER: 0
parallelize_check 1
obsess_over_service 1 И наконец, самое интересное. Как вы уже, наверное,
check_freshness 0
notifications_enabled 1 догадались, hrStorageUsed содержит данные о том, сколь-
event_handler_enabled 1 ко блоков занято на каждом из устройств.
flap_detection_enabled 1
process_perf_data 1
retain_status_information 1 hrStorageUsed.2 = INTEGER: 52564
retain_nonstatus_information 1 hrStorageUsed.3 = INTEGER: 11220
notification_interval 120 hrStorageUsed.4 = INTEGER: 235014
notification_period 24x7 hrStorageUsed.5 = INTEGER: 8755
notification_options w,u,c,r hrStorageUsed.6 = INTEGER: 0
max_check_attempts 3

№11(24), ноябрь 2004 7

 администрирование
Теперь дело за малым: высчитать, сколько блоков со-
ответствуют заполнению устройств на 80% и 90%. И затем
создать на основе этих данных правила проверки.
В качестве примера приведем описание сервиса, пока-
зывающего, как обстоят дела с заполнением корневого
раздела.
Но это не очень удобно, так как в этом случае у систе-
мы есть лишь два состояния – «нормальное» и «критичес-
кое». Соответственно, нет промежуточного перехода в виде
состояния «предупреждение». Разобравшись с теорией,
давайте создадим сервис, который будет контролировать
состояние раздела / новым способом.

define service{ define service{

use generic-service use generic-service
host_name Linux host_name Linux
service_description Space on / service_description Space on / check 2
is_volatile 0 is_volatile 0
check_period 24x7 check_period 24x7
check_command check_snmp_oid ↵ check_command check_snmp_oid ↵
!.1.3.6.1.2.1.25.2.3.1.6.4! ↵ !.1.3.6.1.4.1.2021.9.1.9.1!InK12345!80!90!%
InK12345!218470!245778!blocks!2c }
}
Думаю, создать сервисы, выполняющие проверку ос-
Надеюсь, что на основе приведенного примера вы смо- тальных разделов, вы сможете сами. Идем дальше. Если
жете создать описание всех необходимых сервисов. В мире мы хотим следить за загрузкой процессора, добавляем в
UNIX-систем большинство задач можно решить разными snmpd.conf вот это:
способами. Сейчас вы в этом убедитесь. Давайте в оче-
редной раз расширим функциональность демона snmpd, load 12 20 30
внеся в snmpd.conf следующие строчки.
Этой строкой мы говорим демону, что желаем видеть
disk / 180000 статистику нагрузки на процессор за последнюю минуту,
disk /home 760000
за пять и пятнадцать минут. К сожалению, интервалы жес-
Таким образом, мы указываем, что хотим следить за тко закодированы, и изменить их невозможно. И, как обыч-
свободным местом на разделах / и home еще одним спосо- но, указываем необязательные пороговые ограничения в
бом. Вышеуказанные строки говорят демону snmp, что мы 12%, 20% и 30%, при превышении которых snmpd будет
хотим установить флаг ошибки в случае, если на разделе / устанавливать флаг ошибки. Смотрим ветку .iso.org.dod.
занято 180 Мб, а /home заполнен на 760 Мб. Впрочем, ни- internet.private.enterprises.ucdavis.laTable.laEntry и понима-
чего страшного не случится, если ограничения не устанав- ем, что нам наиболее интересны подветви laLoad, laLoadInt,
ливать вовсе. Кстати, стоит отметить, что ограничение мож- laLoadFloat.
но описывать не только в килобайтах, но и в процентах. В этих подветках содержатся одни и те же данные, но с
Теперь интересующие нас данные находятся внутри ветви разным округлением. Соответственно сервис для провер-
.iso.org.dod.internet.private.enterprises.ucdavis.dskTable.dskEntry. ки загрузки процессора за последнюю минуту будет выгля-
Принцип построения таблицы стандартен. Идентификатор деть вот так:
dskPath содержит данные об именах разделов.
define service{
dskPath.1 = STRING: / use generic-service
dskPath.2 = STRING: /home host_name Linux
service_description CPU Load 1 min
is_volatile 0
dskDevice устанавливает соответствие между раздела- check_period 24x7
ми и физическими устройствами диска. check_command check_snmp_oid ↵
!.1.3.6.1.4.1.2021.10.1.5.1!InK12345!60!90!%
}
dskDevice.1 = STRING: /dev/sda1
dskDevice.2 = STRING: /dev/sda6
Следующей интересной для нас особенностью являет-
В dskMinimum dskMinPercent содержатся пороговые зна- ся возможность запускать сторонние скрипты при получе-
чения для поднятия флага ошибки. Соответственно, dskTotal, нии того или иного SNMP-запроса. И опять добавляем в
dskAvail, dskUsed отображают общее, доступное и задей- snmpd.conf новые строки:
ствованное пространство дисков. Следующая ветвь, назы-
ваемая dskPercent, для нас наиболее интересна, так как exec users /bin/sh /usr/bin/count_users.sh
exec mailqueue /bin/sh /usr/bin/count_mail.sh
содержит величину заполнения дисков в процентах.
Затем создаем файлы count_users.sh count_mail.sh:, с
dskPercent.1 = INTEGER: 86 их помощью мы будем считать количество пользователей,
dskPercent.2 = INTEGER: 4
работающих на данный момент в системе, и размер почто-
Именно ее мы и будем контролировать. Конечно, можно вой очереди postfix.
контролировать состояние ветвей dskErrorFlag и dskErrorMsg. Содержимое файла count_users.sh:

dskErrorFlag.1 = INTEGER: 1 who | wc -l

dskErrorFlag.2 = INTEGER: 0 exit 0
dskErrorMsg.1 = STRING: /: less than 80% free (= 86%)
dskErrorMsg.2 = STRING: Содержимое файла count_mail.sh:

8
 администрирование
mailq | tail -n 1 | cut -f5 -d " " echo "first line"
exit 0 echo "second line"
exit 5
Теперь смотрим, что у нас находится внутри ветки
.iso.org.dod.internet.private.enterprises.ucdavis.extTable.extEntry. В результате осмотра ветви .1.3.6.1.4.1.2021.50 можно
увидеть следующие данные:
extNames.1 = STRING: users
extNames.2 = STRING: mailqueue .1.3.6.1.4.1.2021.50.1.1 = INTEGER: 1
extCommand.1 = STRING: /bin/sh /usr/bin /count_users.sh .1.3.6.1.4.1.2021.50.2.1 = STRING: "multi_line_test"
extCommand.2 = STRING: /bin/sh / usr/bin/count_mail.sh
extResult.1 = INTEGER: 0 .1.3.6.1.4.1.2021.50.3.1 = STRING: "/bin/sh /tmp/mytest.sh"
.1.3.6.1.4.1.2021.50.100.1 = INTEGER: 5
extResult.2 = INTEGER: 0 .1.3.6.1.4.1.2021.50.101.1 = STRING: "first line"
extOutput.1 = STRING: 1
extOutput.2 = STRING: 2 .1.3.6.1.4.1.2021.50.101.2 = STRING: "second line"
.1.3.6.1.4.1.2021.50.102.1 = INTEGER: 0
extErrFix.1 = INTEGER: 0 .1.3.6.1.4.1.2021.50.103.1 = ""
extErrFix.2 = INTEGER: 0
extErrFixCmd.1 = STRING:
extErrFixCmd.2 = STRING: Как видите, и такой функционал нам вполне доступен.
Следующая возможность, на которую хотелось бы обратить
Нас интересует extOutput, в которой находится первая ваше внимание, – функция проверки размера файла. Итак,
строка из того, что скрипт выводит на экран, и extResult с добавляем в snmpd.conf вот такую надпись:
кодом возврата скрипта, переданным командой exit. Судя
по приведенному выше списку значений, у нас в системе file /tmp/tinka.txt 12
находится один пользователь, а в почтовой очереди есть
два письма. Сервисы для проверки результатов работы тем самым указывая, что файл не должен быть более 12 Кб.
обоих скриптов будут выглядеть так: Затем смотрим, что хранит в себе ветка .iso.org.dod.internet
.private.enterprises.ucdavis.fileTable.fileEntry:
define service{
use generic-service fileIndex.1 = INTEGER: 1
host_name Linux fileName.1 = STRING: /tmp/tinka.txt
service_description Users
is_volatile 0 fileSize.1 = INTEGER: 15 kB
fileMax.1 = INTEGER: 12 kB
check_period 24x7 fileErrorFlag.1 = INTEGER: true(1)
check_command check_snmp_oid ↵
!.1.3.6.1.4.1.2021.8.1.101.1!InK12345!20!30!users fileErrorMsg.1 = STRING: /tmp/tinka.txt: ↵
size exceeds 12kb (= 15kb)
}
define service{
use generic-service Написать соответствующий сервис, в общем-то, неслож-
host_name Linux но, если мы хотим самостоятельно проверять размер фай-
service_description Mail queue
is_volatile 0 ла.
check_period 24x7
check_command check_snmp_oid ↵ define service{
!.1.3.6.1.4.1.2021.8.1.101.2!InK12345!40!80!messages use generic-service
}
host_name Linux
service_description size of /tmp/tinka.txt
is_volatile 0
Конечно, в реальном мире скрипты-проверки могут быть check_period 24x7
гораздо сложнее и возвращать с помощью команды exit check_command check_snmp_oid ↵
!.1.3.6.1.4.1.2021.15.1.3.1!InK12345!12!20!kbytes
коды, указывающие на те или иные проблемы в сети. В этом }
случае есть возможность с помощью добавочной опции
execfix указывать на программу, запускаемую snmpd и от- Но есть и другой путь: можно опереться на появление
вечающую за попытки автоматического исправления оши- кода и сообщения об ошибке в fileErrorFlag и fileErrorMsg. И
бок, обнаруженных проверочным скриптом. К примеру, та- все же мне кажется, что это не очень удобно.
ким образом можно описать программу исправления ава- Напоследок хотелось бы рассказать о возможности сле-
рийного положения с почтовой очередью. жения за количеством процессов того или иного приложе-
ния, работающих в системе.
execfix mailqueue /bin/sh /usr/bin/repair_mailqueue.sh
proc httpd 3 6
proc automount 1 1
Конечно, эта возможность опциональна, но упомянуть proc csserver 2
о ней все же стоило. Любопытный читатель может спро-
сить, а что делать, если мой скрипт выводит несколько строк Этими строками мы указываем snmpd, что в системе дол-
полезной информации, и мне нужно считать их все до еди- жно быть от двух до четырех процессов httpd и только один
ной. Я отвечу, что это не проблема. Нужно всего лишь до- automount. В то же время программа csserver вообще может
бавить в snmpd.conf вот такую строку: быть не запущена, но если она все же работает, то процес-
сов не должно быть более двух. Если же минимальный и
exec .1.3.6.1.4.1.2021.50 multi_line_test /bin/sh ↵ максимальный пороги не указаны, то процессов может быть
/tmp/mytest.sh
сколько угодно. Давайте посмотрим, что snmpd нам скажет
И создать скрипт /tmp/mytest.sh следующего содержа- в ответ на такие приказания. Для этого открываем ветвь
ния. .iso.org.dod.internet.private.enterprises.ucdavis.prTable.prEntry.

№11(24), ноябрь 2004 9

 администрирование
prIndex.1 = INTEGER: 1 is_volatile 0
prIndex.2 = INTEGER: 2 check_period 24x7
prIndex.3 = INTEGER: 3 check_command check_snmp_oid ↵
prNames.1 = STRING: httpd !.1.3.6.1.4.1.2021.4.6.0!InK12345!""!""!kbytes!2c
prNames.2 = STRING: automount }
prNames.3 = STRING: csserver
prMin.1 = INTEGER: 3 И соответственно мониторинг заполнения свопа можно
prMin.2 = INTEGER: 1 реализовать так же. Но это решение, на мой взгляд, не очень
prMin.3 = INTEGER: 0
prMax.1 = INTEGER: 6 изящно. Можно сделать гораздо лучше. Давайте будем сле-
prMax.2 = INTEGER: 1 дить за показателем memTotalFree, который показывает об-
prMax.3 = INTEGER: 3
prCount.1 = INTEGER: 1 щее количество свободной памяти системы. Это весьма удоб-
prCount.2 = INTEGER: 1 но, так как он равен сумме memAvailReal и memAvailSwap.
prCount.3 = INTEGER: 0
prErrorFlag.1 = INTEGER: 1 Тут возникает некоторая проблема с нетривиальностью про-
prErrorFlag.2 = INTEGER: 0 верки. Обычно ситуация обстоит так, что чем больше про-
prErrorFlag.3 = INTEGER: 0
prErrMessage.1 = STRING: Too few httpd running (# = 1) веряемая величина, тем ближе мы к критическому порогу,
prErrMessage.2 = STRING: но сейчас все наоборот. Необходимо сказать модулю, что,
prErrMessage.3 = STRING:
prErrFix.1 = INTEGER: 0 чем больше памяти нам доступно, тем лучше. Поэтому сер-
prErrFix.2 = INTEGER: 0 вис будет выглядеть так:
prErrFix.3 = INTEGER: 0
prErrFixCmd.1 = STRING:
prErrFixCmd.2 = STRING: define service{
prErrFixCmd.3 = STRING: use generic-service
host_name Linux
Надеюсь, смысл приведенных данных всем ясен. Тут, service_description Total memory Free
is_volatile 0
как всегда, возможно два пути для слежения: самим конт- check_period 24x7
ролировать значения из подветви prCount, либо опираться check_command check_snmp_oid ↵
!.1.3.6.1.4.1.2021.4.11.0!InK12345!20000:10000 ↵
на код ошибки prErrorFlag и сообщение в prErrMessage. По !9999:0!kbytes!2c
аналогии с execfix можно использовать ключевое слово }
procfix для описания программы, запускаемой в случае, если
с тем или иным процессом стряслось что-то неладное. Я Таким образом, сигнал «предупреждение» будет отправ-
думаю, что на основе примеров, приведенных выше, вы ляться, если свободной памяти останется от двадцати до
сможете легко самостоятельно написать определения нуж- десяти тысяч байт, а критические оповещения появятся, как
ных сервисов. Следующей интересной для нас веткой яв- только планка опустится еще ниже.
ляется .iso.org.dod.internet.private.enterprises.ucdavis.memory. Также неплохо было бы следить за сетевыми интерфей-
В ней хранятся подробные данные о состоянии оператив- сами с помощью ветки .iso.org.dod.internet.mgmt.mib-2.
ной памяти. Для моей машины эта ветвь выглядит так: interfaces.ifTable.ifEntry. Думаю, что примеров, приведенных
в статье, достаточно, чтобы сделать это самостоятельно.
memIndex.0 = INTEGER: 0 Разобравшись с проверками сервисов, работающих че-
memErrorName.0 = STRING: swap
memTotalSwap.0 = INTEGER: 216836 рез snmp 2c, давайте посмотрим, как выполнить все то же
memAvailSwap.0 = INTEGER: 209784 самое с помощью третьей версии протокола. Зачем нам это
memTotalReal.0 = INTEGER: 54156
memAvailReal.0 = INTEGER: 9320 нужно? Все очень просто: с точки зрения безопасности snmp
memTotalFree.0 = INTEGER: 219104 2с существенно лучше, чем версия 1, но, несмотря на это,
memMinimumSwap.0 = INTEGER: 16000
memShared.0 = INTEGER: 0 в ней все же есть недостатки. Дело в том, что при ее ис-
memBuffer.0 = INTEGER: 5728 пользовании строки сообществ передаются по сети в от-
memCached.0 = INTEGER: 13832
memSwapError.0 = INTEGER: 0 крытом виде. Думаю, это не то, что нам хотелось бы полу-
memSwapErrorMsg.0 = STRING: чить. Изумленный читатель может сказать: «Давайте со-
всем откажемся от использования 2с». К сожалению, та-
Наибольший интерес вызывают OID memTotalSwap mem кой идеалистический подход не всегда возможно воплотить
AvailSwap, означающие общий размер свопа и его свобод- в жизнь. Иногда приходится использовать именно 2с, пото-
ную часть. Затем стоит обратить внимание на memTotalReal му что не во всем имеющемся оборудовании есть поддер-
и memAvailReal, указывающие на размер физической па- жка третьей версии. К тому же, настройка snmpd для рабо-
мяти. Перспективнее всего следить за memAvailReal и ты с третьей версией snmp – дело весьма нетривиальное.
memAvailSwap. Но тут есть определенные проблемы. Дело Ниже я расскажу как этого добиться «малой кровью».
в том, что исчерпание физической памяти еще не означает Итак, приступим. В основе идеологии безопасности для
для системы каких-то ужасных последствий, все ненужное третьей версии лежит понятие модуля безопасности пользо-
в данный момент будет складироваться в своп. Поэтому вы- вателей USM (User-based Security Module). Он отвечает за
водить предупреждения по поводу того, что физическая па- хранение списка пользователей и их атрибутов. Соответ-
мять закончилась, не стоит. Сервис, следящей за этим ком- ственно каждый пользователь обозначается уникальным
понентом системы, должен выглядеть так: именем в терминах snmp, оно называется securityName. К
нему привязываются протокол аутентификации и ключ аутен-
define service{ тификации, соответственно, authProtocol и authKey. Вдоба-
use generic-service
host_name Linux вок к этому существует протокол шифрования privProtocol
service_description Physical memory Free и ключ шифрования privKey. Стоит отметить, что authKey и

10

privKey генерируются на основе пароля, переданного поль-
зователем. Пароль должен содержать не менее восьми сим-
волов.
Стандарт snmp версии 3 описывает три вида пакетов.
Первый не подписывается и не шифруется. Второй: отправ-
ляющая сторона подписывает пакет ключем authKey с по-
мощью протокола authProtocol. В качестве протокола гене-
рации подписи на данный момент могут выступать алго-
ритмы MD5 или SHA. Третий: подписывает и плюс к этому
данные пакета могут шифроваться с помощью протокола
privProtocol и ключа privKey. В качестве протокола шифро-
вания пока можно использовать только DES.
Ознакомиться подробнее с идеями, лежащими в осно-
ве USM, можно в RFC 2574.
Одной из самых странных идей, с которой приходится
сталкиваться, является способ управлением пользователя-
ми, применяемый для третьей версии протокола. Для этого
существует утилита snmpusm, но создать с ее помощью
пользователя с нуля невозможно. Она позволяет лишь кло-
нировать настройки существующего пользователя в атри-
буты вновь создаваемого. Налицо проблема курицы и яйца.
Нужно создать первого пользователя, но утилита для уп-
равления пользователями делать это не умеет.
Несколько раз перечитав man snmpusm, понимаем, что
созданием легендарного первопользователя должен зани-
маться демон snmpd. Ничего не скажешь, весьма сильный
ход и главное – какой нечеловеческой логикой это продик-
товано.
Итак, нам нужно внести в snmp такие строки:
rwuser initial
rwuser nagios
rouser nagios
createUser initial MD5 t2inKES10er DES
Или их аналог с расширенным описанием VACM:
group MyRWGroup usm nagios
group MyROGroup usm nagios
group MyRWGroup usm initial
access MyRWGroup "" any noauth exact all all none
createUser initial MD5 t2inKES10er DES
Затем перезапускаем snmpd. Пользователь initial будет
создан автоматически. В качестве пароля ему указано
t2inKES10er, алгоритмом подписи пакетов назначаем MD5,
а для шифрования данных используется DES. Создав пер-
вого пользователя, мы могли бы на этом остановиться. Но
делать этого все же не стоит из соображений безопаснос-
ти. Поэтому с помощью клонирования создаем нового
пользователя по имени nagios.
# snmpusm -v3 -u initial -n "" -l authNoPriv -a MD5 ↵
-A t2inKES10er localhost create nagios initial
User successfully created.
Так как он унаследовал все настройки от initial, сразу
же меняем ему пароль на что-нибудь труднозапоминаемое
вроде R18nm12KDM.
# snmpusm -v3 -u nagios_user -n "" -l authNoPriv -a MD5 ↵
-A t2inKES10er localhost passwd t2inKES10er R18nm12KDM
SNMPv3 Key(s) successfully changed.
№11(24), ноябрь 2004
администрирование
Затем удаляем из snmpd.conf все упоминания о пользо-
вателей initial, а также все строки с MyRWGroup и rwuser.
Тем самым мы лишили пользователя initial всех прав и ото-
брали у пользователя nagios возможность внесения изме-
нений в данные snmp. Не забываем перезапустить демона
snmpd, чтобы новые настройки вступили в силу. На серве-
ре мониторинга для проверки выполняем команду:
$ snmpget -v3 -u nagios -n "" -a MD5 -A R18nm12KDM ↵
-x DES 10.10.21.75 sysUpTime.0
system.sysUpTime.0 = Timeticks: (71318) 0:11:53.18
Из полученного ответа можно сделать вывод, что пере-
дача и обработка шифрованных и подписанных snmp паке-
тов работает как следует. Теперь давайте протестируем как
модуль check_snmp умеет выполнять запросы с помощью
третьей версии snmp.
$ /usr/local/nagios/libexec/check_snmp -H 10.10.21.75 ↵
-o sysUpTime.0 -L authPriv -U nagios_user1 -a MD5 ↵
-A R18nm12KDM -X R18nm12KDM -P 3
system.sysUpTime.0 = Timeticks: (71352) 0:11:54.10
Теперь осталось создать описание своей команды
check_snmp_oid_v3 в файле checkcommands.cfg. С помо-
щью нее мы будем проводить мониторинг и вызывать мо-
дуль check_snmp.
define command{
command_name check_snmp_oid_v3
command_line $USER1$/check_snmp -H $HOSTADDRESS$ ↵
-o $ARG1$ -w $ARG2$ -c $ARG3$ -L $ARG4$ ↵
-U $ARG5$ -a $ARG6$ -A $ARG7$ -X $ARG8$ ↵
-u $ARG9$ -l "" -P $ARG10$
}
Теперь давайте создадим сервис Total Memory Free v3
для демонстрации того, как нужно использовать команду
check_snmp_oid_v3. Записываем в services.cfg следующие
строки:
define service{
use generic-service
host_name Linux
service_description Total memory Free v3
is_volatile 0
check_period 24x7
check_command check_snmp_oid_v3! ↵
.1.3.6.1.4.1.2021.4.11.0!20000:10000!9000:0! ↵
authPriv!nagios!MD5!R18nm12KDM!R18nm12KDM!kbytes!3
}
Теперь данные будут доставляться к нам в шифрован-
ном виде. Напоследок стоит сказать, что все описания сер-
висов, предназначенные для сервера Linux, можно скопи-
ровать и, изменив имя машины, следить за FreeBSD.
На этой радостной ноте хотелось бы попрощаться, а
заодно пообещать, что в следующей статье мы будем изу-
чать настройку системы мониторинга для слежения за обо-
рудованием знаменитой фирмы CISCO.
Литература:
1. Бешков А. Мониторинг Windows-серверов с помощью
Nagios. Часть 2. – Журнал «Системный администратор»,
№8, август 2003 г. или http://onix.opennet.ru/monitoring/
nagios_win_2.html
11
 администрирование
ИСПОЛЬЗОВАНИЕ
БЕЗДИСКОВЫХ LINUX-СТАНЦИЙ
С ЗАГРУЗКОЙ ПО СЕТИ
Постановка задачи
Работа сотрудника отдела автоматизации – это постоянная
борьба с проблемами и решение задач, которые поперемен-
но подкидывают пользователи, разработчики эксплуатируе-
мого программного обеспечения и руководство организации.
И если два первых направления работы – это просто «борь-
ба за живучесть корабля», то последнее, как правило, – по-
ступательное движение вперед. Как раз в ходе решения од-
ной из таких задач и появилась на свет данная статья.
Итак, перед отделом автоматизации была поставлена
задача в короткие сроки ввести в строй два новых удален-
ных офиса, каждый численностью в пять-десять человек. Оба
офиса и «голову» связали посредством технологий VPN в
одну сеть. Минимальная ширина канала между тремя точка-
ми составила 256 Кбит, что вполне удовлетворило наши по-
требности. В каждом из офисов был развернут дополнитель-
ный контроллер домена Windows 2000, а для минимизации
трафика домен разделили на несколько сайтов. Все выше-
описанное является стандартным решением, и здесь я не
ожидал никаких сюрпризов. Главным вопросом для нас было,
как поведет себя основной инструмент работы сотрудников
организации – комплексная система автоматизации, при
работе с которой и в пределах одной площадки хватало про-
блем. Изначально ориентированная на Novell/BTRIVE 6.15
после миграции сети на Windows, она работала под Windows/
Pervasive.SQL 7.
После недели тестирования этого основного бизнес-при-
ложения организации, оказалось, что разработчик и вовсе
не оставил нам выбора, так как использование встроенного
терминального режима автоматизированной системы по
ряду причин нас не устроило. Опять же, из-за особенностей
функционирования в качестве терминального сервера была
выбрана платформа Microsoft Windows Server. Тестирование
же решений компании Citrix мы не проводили, так как рабо-
та с «родными» терминальными службами Windows нас впол-
не удовлетворила, а использование надстроек только уве-
личивает стоимость всей системы.
12
АНДРЕЙ МАРКЕЛОВ
Когда с серверной частью все определилось, встал воп-
рос по клиентской составляющей системы. В первую оче-
редь хотелось бы снизить необходимость в администриро-
вании пользовательских машин, так как постоянное присут-
ствие системного администратора на удаленных площадках
не планировалось. Кроме того, желательным представлялось
уменьшить стоимость решения, которая возросла из-за необ-
ходимости покупки терминальных лицензий. Также необхо-
димо было учесть намерение разместить в офисах устарев-
шие компьютеры класса Celeron-400 с ОЗУ от 32 до 64 Мб.
Идеальным со всех точек зрения оказалось использо-
вание в качестве рабочих мест бездисковых станций с заг-
рузкой по сети. При этом единственным компьютером, тре-
бующим внимания администратора, становится дополни-
тельный контроллер домена в каждом офисе, управляемый
по VNC. Само собой, что в рамках данной статьи я остав-
ляю за пределами внимания оборудование и ПО, обеспе-
чивающее шифрование трафика, доступ в Интернет и т. д.
В роли ОС, которая будет по сети загружаться на рабо-
чие станции, я выбрал Linux – что обеспечивает лицензи-
онную чистоту решения (по крайней мере на сегодняшний
момент). Доступ к рабочему столу Windows 2003 должен
был осуществляться при помощи разработки проекта
www.rdesktop.org, который стал стандартом для решения
данной задачи. В качестве же необходимых для такой заг-
рузки серверов DHCP и TFTP логично было бы использо-
вать уже имеющиеся в каждом сайте дополнительные кон-
троллеры домена Windows 2000. Благо существуют как бес-
платные реализации DHCP/TFTP под эту операционную
систему, так и встроенные сервера. При этом TFTP нали-
чествует в рамках службы Remote Installation Services (RIS).
Сетевые карты клиентских машин, естественно, долж-
ны поддерживать возможность загрузки по Etherboot/PXE.
В отдельных случаях из-за несовместимости оборудования
я допускал использование загрузчика, расположенного на
дискете.

Выбор реализации Linux
При выборе варианта ОС Linux с возможностью загрузки по
сети в первую очередь я обратил внимание на уже готовые
дистрибутивы подобной направленности со встроенным па-
кетом rdesktop. Наиболее известный из них – NetStation
(netstation.sourceforge.net), который застыл в виде бета-вер-
сии с конца 2002 года, и его наследники: PXES (pxes.source
forge.net), Thinstation (thinstation.sourceforge.net), и DIET-PC
(diet-pc.sourceforge.net). При этом DIET-PC предназначен для
пользователей, хорошо знакомых с ОС Linux, что сразу ис-
ключает его из области рассмотрения. Поскольку процеду-
ра его настройки весьма кропотлива, и в DIET-PC присут-
ствует достаточно много настроек, которые простому смер-
тному, не Linux-гуру, никогда не пригодятся. PXES является
наиболее «продвинутым» с большим числом дополнитель-
ных возможностей, включая собственную графическую сре-
ду, что также лишнее в моем случае. В моей конфигурации
клиент, минуя промежуточные меню, должен был сразу заг-
ружать удаленный рабочий стол и выходить на окно ввода
пароля Windows 2003 Server. Таким образом, я обратил вни-
мание на оставшийся дистрибутив – Thinstation.
Кратко рассмотрим его возможности:
! поддержка протоколов X, RDP, VNC, SSH, Telnet, ICA и
Tarantella;
! возможность использовать браузер Firefox;
! загрузка по сети при помощи Etherboot, PXE (при помо-
щи Etherboot-загрузчика или PXELinux), HDD, CD или
floppy-диска. К сожалению, отсутствует поддержка USB-
flash;
! работа на ПК класса x86-100 МГц c ОЗУ 16 Мб;
! наличие pre-build образа, и возможность самостоятель-
ной сборки через веб-интерфейс;
! поддержка локальных дисков, USB- и LPT-принтеров.
Из всех вариантов загрузки наиболее простой – это PXE
при помощи Etherboot-загрузчика. В рамках этой статьи мы
пойдем по самому простому пути будем использовать за-
ранее скомпилированный образ.
Установка и первоначальная настройка
Начнем с того, что скачаем со странички http://struktur.
kemi.dtu.dk/thinstation/download, доступной по ссылке с офи-
циального сайта, последний из архивов, в моем случае – это
был Thinstation-2.0.2-prebuilt-NetBoot.zip. Архив содержит в
себе все, что необходимо, включая TFTP/DHCP-сервер
Tftpd32, который удобен при первоначальной настройке и
конфигурировании. Если вы будете его использовать, то я
бы порекомендовал сразу же обновить его с домашней стра-
нички, где имеется более свежая версия. Кстати, Tftpd32
(http://tftpd32.jounin.net) – сама по себе отличная програм-
ма. Причем настолько, что даже рекомендуется Cisco для
некоторых потребностей клиентов компании.
Развернув архив, мы получаем пять директорий:
! BootDisk – образ дискеты с Etherboot-загрузчиком, для
ПК, с неподдерживаемыми сетевыми картами;
! BootPXE – загрузчик через PXE для эмуляции Etherboot;
! BuildFiles – примеры конфигурационных файлов;
! TFtp – сервер Tftpd32;
! TftpdRoot – корневая директория TFTP-сервера.
№11(24), ноябрь 2004
администрирование
Итак, первым делом запускаем самораспаковывающий-
ся архив thinstation.nbi (autoextract).exe, содержащий один-
единственный файл thinstation.nbi, архив сделан для того,
чтобы у вас была возможность ознакомиться с «CITRIX(R)
LICENSE AGREEMENT».
Теперь копируем TFtp и TftpdRoot на Windows-сервер в
нашем сегменте сети. В качестве такого сервера при ис-
пользовании Tftpd32 может выступать любая Windows-ма-
шина со статическим IP-адресом.
Допустим, мы скопировали обе директории на диск C:\.
Запускаем на исполнение C:\TFtp\Tftpd32.exe. Внешний вид
окна программы представлен на рис. 1. Необходимо задать
параметры сервера. Нажимаем кнопку «Settings» и пропи-
сываем в качестве «Base directory» значение «C:\TftpdRoot».
Далее идем на вкладку «DHCP server». Там необходимо ука-
зать начальный IP-адрес, выделяемый DHCP-сервером («IP
pool starting address»), размер пула адресов («Size of pool»),
маск у подсети («Mask»), имя файла с Etherboot-
загрузчиком(«Boot file»), в нашем случае это thinstation.
nbi.zpxe. Нажимаем кнопку «Save» для сохранения настро-
ек и сворачиваем приложение.
Ðèñóíîê 1. TFTP/DHCP-ñåðâåð Tftpd32, êîòîðûé óäîáåí ïðè
ïåðâîíà÷àëüíîé íàñòðîéêå
Все готово для работы. Вы можете попробовать вклю-
чить одну из машин с сетевой картой, поддерживающей
загрузку по протоколу PXE, не забыв выставить порядок
загрузки в BIOS станции. При включении машина должна
получить IP-адрес из выделенного диапазона и загрузить
по протоколу TFTP файл thinstation.nbi.zpxe. Он содержит
загрузчик, эмулирующий работу сетевой карты с поддерж-
кой Etherboot. Затем управление передается загрузчику,
который в свою очередь еще раз запрашивает по DHCP
адрес, и загружает файл с именем, совпадающим с назва-
нием файла самого загрузчика минус расширение zpxe, то
есть thinstation.nbi. Данный файл и есть образ Thinstation.
Когда образ загружен, Thinstation пытается загрузить из
корневой директории TFTP-сервера конфигурационный
файл thinstation.conf-<MAC-адрес клиента>, затем thin
station.conf-<IP-адрес клиента>. Если такие файлы найде-
ны, то Thinstation объединяет их содержимое с общим кон-
фигурационным файлом thinstation.conf.network, который в
отличие от двух вышеперечисленных обязан присутство-
вать на TFTP-сервере.
Постарайтесь избежать конфликтов между главным
файлом настроек и специфическим к группе или конкрет-
13
 администрирование
ной станции. Кроме того, можно объединять одним конфи- (16 bit color depth)"
гурационным файлом целые группы IP- и MAC-адресов. Это SESSION_0_TYPE=rdesktop
SESSION_0_RDESKTOP_SERVER=192.168.0.1
делается при помощи файла thinstation.hosts, имеющего SESSION_0_RDESKTOP_OPTIONS="-u Administrator ↵
следующий формат: -p password -a 16"

SESSION_1_TITLE="VNC server"
# HOST MAC GROUPS COMMENTS SESSION_1_TYPE=vncviewer
ws-oper1 0002B3655065 hi_res # Îïåðàöèîíèñò ¹1 SESSION_1_VNCVIEWER_SERVER=192.168.0.2
ws-oper2 0002B3651075 hi_res # Îïåðàöèîíèñò ¹2
ws-oper3 0002B365A021 hi_res ssh_en # Îïåðàöèîíèñò ¹3 SESSION_2_TITLE="Telnet server"
SESSION_2_TYPE=telnet
SESSION_2_TELNET_SERVER=192.168.0.3
В данном примере предполагается, что имеются два SESSION_3_TITLE="SSH server"
файла thinstation.conf.group-hi_res и thinstation.conf.group- SESSION_3_TYPE=ssh
ssh_en. SESSION_3_SSH_SERVER=192.168.0.4
Настройки, прописанные в первом файле, применяют- # Îáùèå îïöèè
ся ко всем трем станциям, а настройки из второго – только #
# Ðàñêëàäêà êëàâèàòóðû.  ñëó÷àå ðàáîòû ñ rdesktop îíà
к компьютеру ws-oper3. # ðîëè íå èãðàåò
То, как отображаются сессии терминальных клиентов в KEYBOARD_MAP=en_us
оснастке диспетчера терминальных служб, вы можете уви- # Îïöèè XServer
деть на рис. 2. #
SCREEN_RESOLUTION="1024x768"
SCREEN_COLOR_DEPTH="16"
SCREEN_HORIZSYNC="30-64"
SCREEN_VERTREFRESH="56-87"
MOUSE_RESOLUTION=100
# Îïöèè ïå÷àòè
#
PRINTER_0_NAME=usb
PRINTER_0_DEVICE=/dev/usb/lp0
PRINTER_2_TYPE=U

В заключение статьи, хочу сказать, что после отладки

Ðèñóíîê 2. Ñåññèè òîíêèõ êëèåíòîâ â îñíàñòêå äèñïåò÷åðà
òåðìèíàëüíûõ ñëóæá
Клиенты с именами вида ts_<MAC-адрес> – это как раз
клиентские терминалы, работающие под управлением
Thinstation. Клиенты с именами вида P<IP-адрес> работа-
ют под управлением дистрибутива PXES, рассмотрение
которого выходит за рамки данной статьи.
работы с терминальными клиентами, лучше всего передать
функции TFTP- и DHCP-серверов программному обеспече-
нию, способному работать в режиме службы на Windows
NT/2000/2003/XP, например, как я уже говорил, «родным»
службам Windows, либо воспользоваться соответствующи-
ми сервисами любой другой операционной системы.
Кроме того, на сайте проекта thinstation.sourceforge.net
при помощи веб-интерфейса вы можете самостоятельно
перекомпилировать образ Thinstation без загрузки исход-
ных кодов, включив какие-либо отсутствующие в prebuild
образе функции, например браузер, или исключив ненуж-
ные модули.

Ðèñóíîê 3. Ìåíþ Thincstation

Далее я приведу простой, но вполне работоспособный
вариант конфигурационного файла с комментариями.

# Îïöèè ñåññèé
#
# Ïåðâàÿ ñåññèÿ äîëæíà îáÿçàòåëüíî íà÷èíàòüñÿ ñ íîìåðà 0.
# Ïðè îòñóòñòâèè íåîáõîäèìîñòè âûáîðà ñåññèè, íàïðèìåð,
# êîãäà âû èñïîëüçóåòå òîëüêî rdesktop, ìîæíî ñíÿòü
# êîììåíòàðèé ñî ñëåäóþùåãî ïàðàìåòðà, è èñêëþ÷èòü ìåíþ
# âûáîðà ñåññèé.
#AUTOSTART=On
Ðèñóíîê 4. Ñàìîñòîÿòåëüíîå ïîñòðîåíèå îáðàçà ÷åðåç âåá-
SESSION_0_TITLE="Windows 2003 terminal server ↵ èíòåðôåéñ TS-O-Matic

14
 администрирование
ПАКЕТНЫЙ ФИЛЬТР OpenBSD
ДЕНИС НАЗАРОВ
Позвольте мне поведать вам вновь об уникальных возмож-
ностях операционной системы OpenBSD1. На сей раз мой
рассказ будет о пакетном фильтре, входящем в стандарт-
ный дистрибутив данной системы, начиная с версии 3.0.
Зачем вообще нужны пакетные фильтры? Любой из вас,
наверное, знает о неприятностях, существующих в просто-
рах сети, и не раз сталкивался с ними. Читая «Hacking
Exposed 3th edition», я наткнулся на фразу: «2.13 AM, Do
you know who is on your network?». Да, именно так, ведь вы,
будучи администратором сети, не можете постоянно сле-
дить за тем, как и что проходит через вашу сеть. Однако вы
можете контролировать данный процесс, используя пакет-
ные фильтры. Итак, прошу любить и жаловать – OpenBSD’s
Packet Filter (PF).
Конфигурация находится в файле /etc/pf.conf. Однако
фильтр отключен по умолчанию в только что установлен-
ном дистрибутиве, и существует 2 способа включить его:
! Отредактировать файл /etc/rc.conf, изменив значение
pf=NO на pf=YES, также стоит сразу проверить путь к
конфигурационному файлу в директиве pf_rules=/etc/
pf.conf и перезагрузить систему.
! Дать команду pfctl –e, которая заставит ядро включить
фильтр с пустыми настройками и без перезагрузки сис-
темы.
Приступаем к конфигурации фильтра. Что же он уме-
ет? Практически все. PF является очень серьезной альтер-
нативой таким монстрам, как Checkpoint Firewall и Sun
Screen, однако полностью бесплатен.
Итак, PF имеет следующие возможности.
Макросы
Макрос – очень удобная вещь, которая может сократить и
оптимизировать ваш конфигурационный файл и избавит
вас от проблем с частым использованием обьемных и час-
то повторяющихся директив. Я практически не представ-
ляю себе написание конфигурационных файлов для PF без
использования макросов.
Например, определение макросов:
ext_if = “fxp0”
external_addr = “{ 192.168.0.13/32, 192.168.0.113/32 }”
И их использование:
pass in on $ext_if from any to $external_addr keep state
pass out on $ext_if from $external_addr to any port 1337 ↵
keep state
В качестве имени макроса не могут использоваться за-
1
Предыдущие статьи автора: «Введение в OpenBSD», №6, 2003 г., «OpenBSD. Первые шаги», №8, 2003 г.
16
резервированные слова (pass, block, in, out и т. д.). Привы-
кайте сразу использовать макросы, это хороший стиль.
Следование ему в дальнейшем позволит избежать многих
проблем с пониманием работы и настройки фильтра.
Таблицы
Именные структуры, хранящие адреса хостов и сетей. Ис-
пользование таблиц предпочтительнее использования мак-
росов в тех случаях, когда необходимо описать огромное
количество адресов. Для обработки правил, использующих
таблицы, требуется меньше ресурсов, чем для обычных пра-
вил, решающих ту же задачу.
Таблицы также могут использоваться совместно с scrub
(нормализация трафика), rdr (перенаправление пакетов), nat
(трансляция адресов). И могут быть определены следую-
щими способами:
! Вручную. Постоянные таблицы могут быть созданы ко-
мандой add или replace утилиты pfctl до или после заг-
рузки набора правил.
! pf.conf – для описания таблиц в файле используется ди-
ректива table. Таблица, инициализированная с пустым
листом { }, будет очищена при загрузке.
Таблицы бывают двух видов:
! persist – этот флаг заставляет ядро хранить содержа-
ние таблицы, даже если она не используется никакими
правилами. Если таблица не помечена таким флагом,
то ядро уничтожит ее после того, как последнее прави-
ло, ссылающееся на нее, будет удалено.
! const – этот флаг запрещает изменять содержание таб-
лицы после того, как она была создана.
Например:
table <localz> const “{ 192.168.0.0/24, 192.186.13.0/24 }”
table <badhosts> persist
block in quick log on $ext_if from <badhosts> to any
pass in on $int_if from <localz> to $internal_addr keep state
Данный фрагмент конфигурационного файла создаст
2 таблицы. В первой, <localz>, будут содержаться адреса
наших внутренних сетей, а <badhosts> будет пустой. Таб-
лица <localz> не может быть изменена или дополнена, т.к
при создании использовался флаг const.
Правила фильтрации отбрасывают любые пакеты, при-
ходящие на внешний интерфейс ($ext_if) от хостов из таб-
лицы <badhosts>, и пропускающие любые пакеты на внут-
реннем интерфейсе ($int_if), приходящие от хостов из таб-
лицы <localz>.

# pfctl –t badhosts –T add 81.146.13.16
Теперь добавим в таблицу <badhosts> хост с адресом
81.146.13.16, и все пакеты от данного хоста будут отверг-
нуты. Таблицу <badhosts> лучше иметь всегда, т.к. в слу-
чае чего – это очень быстрый способ отвергнуть то, что
может причинить боль вашей сети.
Таблицы могут заполняться списком адресов из како-
го-либо файла. Синтаксис команды, выполняющей это дей-
ствие, таков:
table <spam> persts file “/etc/pf/spam” file “/etc/pf/openrelays”
block from <spam> to any port 25
Файлы /etc/pf/spam и /etc/pf/openrelay содержат список
IP-адресов в формате:
/etc/pf/spam
204.168.0.13
213.145.168.2
/etc/openrelay
213.146.16.0/24
166.15.13.5/28
Допускается использование FQDN вместо IP-адреса. Пе-
ред занесением в таблицу имя будет переведено в IP-ад-
рес с помощью функции gethostbyname().
Stateful Inspection
Прошу внимательно прочитать данный параграф, в нем я
попытаюсь дать базовые понятия о Stateful Inspection – за-
чем это надо и почему полезно.
State – «состояние, положение» в переводе с английс-
кого. PF Stateful – пакетный фильтр, а это означает, что он
отслеживает состояние соединения. Вместо того чтобы про-
пускать весь трафик, например, на порт 25 через все ин-
станции (читай фильтрацию) легче пропустить первый па-
кет и затем просто следить за соединением. Фильтр не сор-
тирует трафик – он уже предупрежден об этом соединении
и значит, просто следит за его состоянием.
Если пакет попадает под pass … keep state, фильтр со-
здает state для этого соединения и автоматически пропус-
кает весь трафик, принадлежащий данному соединению.
Перед тем как правила будут применены к данному па-
кету, фильтр проверяет наличие state для данного пакета,
и если находит – пакет будет пропущен без проверки пра-
вилами. State удаляются сразу же по закрытии соединения
или же по истечении тайм-аута.
Это дает некоторые преимущества. Сравнение пакета
с таблицей states подразумевает проверку его sequence но-
мера. Если номер вне диапазона ограниченного окна – па-
кет будет отброшен. Это позволяет избежать атак с подме-
ной адреса (spoofed attacks).
Также поиск среди states гораздо быстрее, чем полная
фильтрация пакета по правилам.
Использовать Stateful Inspection, еще раз напомню, по-
зволяет директива keep state.
Например:
block all
pass out proto tcp from any to any flags S/SA keep state
pass in proto tcp from any to any port 25 flags S/SA keep state
№11(24), ноябрь 2004
администрирование
Это основные понятия о Statetul Inspection.
Теперь давайте рассмотрим дополнительные настрой-
ки, которые мы можем использовать совместно с возмож-
ностью Stateful Inspection. Дело в том, что при стандартных
установках фильтр будет работать, однако часто бывает,
что для идеального функционирования сети данные пара-
метры следует основательно подправить.
set timeout <option>, где <option>:
! interval – интервал перед удалением истекших (expired)
state и фрагментов.
! frag – секунды перед тем, как неассемблированный па-
кет будет помечен как истекший.
! sc.track – время, в течение которого адрес отправителя
будет продолжать отслеживаться, даже после того как
последнее «состояние» для этого адреса будет оконче-
но.
! tcp.first – «состояние» после первого пакета.
! tcp.opening – «состояние» перед тем, как удаленный хост
пошлет первый пакет.
! tcp.estabished – «состояние» для TCP Three Way Hand
shake (установленного соединения).
! tcp.finwait – «состояние» после того, как оба хоста об-
менялись пакетами с установлеными FIN-флагами и
соединение считается закрытым.
! tcp.closed – «состояние» после того, как один из хостов
посылает пакет с флагом RST.
Протоколы ICMP и UDP настраиваются так же, как и TCP,
только с гораздо меньшим набором states.
! udp.first – «состояние» после первого пришедшего па-
кета.
! udp.single – «состояние», если удаленный хост послал
больше чем один пакет, а хост назначения не послал в
ответ ни одного.
! udp.multiple – «состояние» после того, как оба хоста по-
слали пакеты.
! icmp.first – «состояние» после первого пришедшего па-
кета.
! icmp.error – state на любое сообщение об ошибке, воз-
вращенное ICMP-прокотолом.
Любые другие протоколы могут настраиваться так же,
но используя:
! other.first;
! other.sigle;
! other.multiple.
Время timeout может изменяться в зависимости от коли-
чества state в той или иной группе, а также от нагрузки на
сеть, за это отвечают параметры adaptive.start и adaptive.end.
! adaptive.start – когда количество «состояний» достига-
ет данного порога, все timeout начинают изменять свои
значения по формуле:
(adaptive.end – number of states) /
(adaptive.end – adaprive.start)
! adaptive.end – когда количество «состояний» достигает
данного порога, все timeout-значения обнуляются и уда-
ляют за собой все «состояния».
17
 администрирование
Все вышеперечисленные значения могут быть опреде-
лены как глобально, так и для каждого правила в отдель-
ности, это затронет и «состояния», созданные такими пра-
вилами.
Например:
число IP-адресов, для которых будут создаваться «состоя-
ния». Используется опять же для тонкой настройки фильт-
ра, генерируется sticky-address и source-track опциями в
правилах.
Наконец, все это можно обьединить в одну строчку:

set timeout tcp.first 120 set limit { states 20000, frags 20000, src-nodes 2000 }
set timeout tcp.established 86400
set timeout { adaptive.start 6000, adaptive.end 12000 }
set limit states 10000 set optimization – опция, которая позволяет оптимизиро-
вать работу вашего фильтра для сетей следующего типа:
Как только таблица будет содержать 9000 state, значе- ! normal – обычная сеть, подходит для большинства се-
ния timeout снизятся до 50% (tcp.first 60, tcp.established тей.
43200). ! high-latency – соединение с большими обьемами трафи-
Манипуляция данными значениями позволяет очень тон- ка (например, спутниковое).
ко настроить работу вашего фильтра в тех или иных ситуа- ! satellite – синоним для high-latency.
циях. Это полезно для больших сетей или сетей, через ко- ! aggressive – аргессивный режим, позволяет очень силь-
торые проходят огромные обьемы трафика. но уменьшить использование памяти, однако ценой
set loginterface – опция, которая позволяет указать, для сбрасывания соединений, находящихся в состоянии idle,
какого интерфейса вы будете получать статистику по ко- работает быстрее, чем обычная.
манде. ! conservative – обратное от aggressive. Соотвественно
Например, у меня статистика выглядит так: грузим больше – живем дольше.
# pfctl -s i
Status: Enabled for 0 days 04:16:28 Debug: Urgent Я предпочитаю использовать на всех довольно загру-
женных серверах (порядка 150 Гб трафика в день на каж-
Hostid: 0xd5f48ad7
дом) режим aggressive, в то время как в обычных сетях, ко-
Interface Stats for em1 IPv4 IPv6 нечно же, я использую normal.
Bytes In 219620287 72
Вы спросите, а зачем это надо? Зачем нужны те лими-
Bytes Out 62229416 352
Packets In ты и тайм-ауты, которые я описывал выше? Ответ очеви-
Passed 759343 0 ден, PF может быть настроен так тонко, как не каждый па-
Blocked 1273 1
Packets Out кетный фильтр, существующий ныне. Порой стандартных
Passed 807867 2 уровней оптимизации либо «слишком мало», либо «очень
Blocked 3 3 много», вот и приходится играть с тайм-аутами и лимита-
State Table Total Rate ми, чтобы достичь идеальной производительности и мак-
current entries 344 симальной отдачи.
searches 3286659 213.6/s
inserts 37555 2.4/s set block-policy – определить, каким же будет ответ филь-
removals 37211 2.4/s тра для действия block в правилах.
Counters
match 182069 11.8/s
! drop – пакет просто отбрасывается.
bad-offset 0 0.0/s ! return – фильтр ответит пакетом с флагом RST для TCP
fragment 0 0.0/s или же пакетом ICMP UNREACHEBLE для UDP, и все
short 0 0.0/s
normalize 0 0.0/s
остальные пакеты будут просто отброшены.
memory 0 0.0/s
bad-timestamp 0 0.0/s set require-order – определить порядок обслуживания.
Идем дальше: По умолчанию фильтр пропускает пакет по следующей це-
set limit – позволяет установить жесткое ограничение на почке: Options → Normalization → Queueing → Translation →
количество областей в памяти с фиксированным размером, Filtering. То есть сначала применяются настройки для филь-
используемых пакетным фильтром. Например: тра, потом нормализация трафика, затем распределение
по очередям, дальше трансляция адреса и, наконец, сама
set limit states 20000 фильтрация.
Данная цепочка является идеальной с точки зрения раз-
устанавливает максимальное значение для количества эле- работчиков фильтра, но они оставляют вам возможность
ментов, используемых для «состояний». исправить ее на ваше усмотрение.
set fingerprints – указать системе, где находится файл с
set limit frags 20000 определениями отпечатков (fingerprints) для различных опе-
рационных систем. Ну где вы еще видели пакетный фильтр,
устанавливает максимальное значение для количества эле- который умеет пропускать наружу или внутрь пакеты, при-
ментов, используемых для «fragment reassembly», генери- ходящие от Linux, а от Windows 2003 отбрасывать? Мелочь,
руется при помощи scrub. а очень приятно. Например:

set limit scr-nodes 2000 set fingerprints "/etc/pf.os.devel"

18

set debug – уровень дебага для фильтра.
Опции:
! none – никаких сообщений;
! urgent – сообщения только для серьезных ошибок;
! misc – для различных ошибок;
! loud – для всего подряд.
Нормализация трафика
Не секрет, что нестандартными пакетами (например, раз-
мер или набор флагов) можно заставить некоторые серви-
сы перестать работать и еще много каких гадостей натво-
рить в сети.
scrub – директива, отвечающая за нормализацию тра-
фика.
Дополнительные параметры:
! no-df – убирает флаг «Don’t fragment» из заголовка па-
кета. Позволяет избавить вашу сеть от проблем со спе-
циально засланными пакетами огромного размера.
! min-ttl <number> – меняет минимальное значение TTL
для IP-пакета.
! max-mss <number> – меняет максимальное значение
MSS для TCP-пакета.
! random-id – меняет IP identification-поле в заголовке па-
кета для защиты TCP-соединения от вторжения мето-
дом подбора значения, передаваемого в данном поле,
применяется только к исходящим соединениям.
! fragment reassemble – позволяет держать в памяти фраг-
менты пакетов до того момента, пока пакет не будет пол-
ностью составлен. Гарантирует вам отсутствие лишне-
го трафика и нагрузки на сеть.
! fragment crop – стандартный метод, фрагменты пакетов
пропускаются в сеть, где уже сами хосты пытаются со-
брать их в целый пакет. Данный метод неэффективен с
точки зрения нагрузки на сеть.
! fragment drop-ovl – то же самое, что и предыдущее, раз-
ница лишь в том, что одинаковые фрагменты, пришед-
ние по какой-либо ошибке, будут отброшены фильтром.
! reassemble tcp – нормализация TCP-соединений. Допол-
нительные возможности – ttl, timeout modulation, extended
PAWS checks. Данные темы я рассмотрю в следующих
статьях, т.к это относится непосредственно к протоко-
лу, а не к пакетному фильтру.
Например:
scrub in all
и все, фильтр сам подберет оптимальные параметры и раз-
берется со всеми потенциально опасными пакетами.
Распределение по очередям
В этой статье я не буду описывать возможности PF при ра-
боте с контролем полосы пропускания, об этом в следую-
щих статьях. Скажу только, что в фильтр встроен ALTQ и
механизмы cbq, priq, hfsc.
NAT – Network Address Translation – трансляция адре-
сов. Определяет, как адреса будут транслироваться или
перенаправляться относительно других адресов.
Фильтр позволяет осуществить:
№11(24), ноябрь 2004
администрирование
! binat – полную двухстороннюю замену между внутрен-
ним и внешним IP-блоком;
! nat – обычную трансляцию;
! rdr – пакет перенаправляется на любой порт и любой
хост. Маленькое дополнение: если пакет перенаправля-
ется во внутренную сеть, то помимо rdr надо сделать и
nat для хоста, который будет отвечать во внешний мир
на данные перенаправленные пакеты.
Пример:
rdr on em1 inet proto tcp to port 80 -> $web_server port 80
Фильтрация пакетов
Фильтрация протекает стандартно – создаются правила.
Правила могут иметь 2 результата:
! block – пакет будет отброшен, используя следующие спо-
собы:
! drop – пакет просто удаляется и никаких данных в
ответ не посылается.
! return-rst – только для TCP-пакетов, отсылается пакет
с флагом RST, который прекращает соединение не-
медленно.
! return-icmp (return-icmp6) – возвращается сообщение
ICMP UNREACHABLE, однако данное значение мож-
но переопределить любым кодом ошибки ICMP-про-
токола.
! return – автоматически TCP RST будет возвращен для
TCP-пакетов и ICMP UNREACHABLE для UDP- и дру-
гих протоколов.
! pass – пакет будет пропущен фильтром.
Если ни одно правило не подходит, то пакет будет про-
пущен.
Итак, параметры фильтрации:
! in или out – пакет идет к нам или от нас соотвественно.
Если не определено, то считается, что направление двух-
стороннее.
! log – записывать информацию о пакетах, однако будут
записаны только пакеты, которые попадают в «состоя-
ния».
! log-all – записывать информацию о всех приходящих па-
кетах, независимо от того, попал он в state или нет.
! quick – если пакет попадает под это правило, то даль-
нейшие правила не применяются. Полезно, например,
использовать с таблицей <badhosts>.
! on <interface> – правила применяются только в случае,
если пакет идет с указанного интерфейса.
! proto <protocol> – правила применяются только к паке-
там данного протокола. Например, ICMP, TCP, UDP. Пол-
ный список протоколов находится в /etc/protocols.
from <source> port <sourceport> to <dest> port <destport>
Примерно понятно? Откуда, с какого порта, куда, на
какой порт.
Опции следующие:
! any – любой адрес.
19
 администрирование
! no route – адреса, которые вне таблицы роутинга.
! <table> – адреса из таблицы «table».
Порты могут указываться с использованием стандарт-
ных операторов (=, !=, <, <=, >, >=, :, ><, <>).
! flags <a>/<b> | <b> – данные правила применяются толь-
ко для пакетов с установленными флагами <a> перед
флагами <b>. Флаги F(IN), S(YN), R(ST), P(USH), A(CK),
(U)RG, E(CE), C(W)R.
Комбинировать флаги можно по-разному, однако опыт
показывает, что оптимальным является сочетание flags S/
SA. Это значит, что перед тем как отправлять пакеты с фла-
гами SYN+ACK (соединение установлено), хост обязан от-
править пакет с флагом SYN. Данный набор идеален для
обычных TCP/IP-сетей, где не проводят никаких сетевых эк-
спериментов, а просто потихонечку выкачивают весь Ин-
тернет к себе на жесткие диски.
Утилита управления
пакетным фильтром pfctl
Pfctl – довольно мощное средство, предоставляемое вам
для управления фильтром. И, кстати, единственное.
Используется для выполнения следующих операций:
! -e – включить фильтр.
! -d – выключить фильтр (статистика по pfctl –s i обнуля-
ется).
! -F modifier – обнулить значения для:
! nat – таблицы трансляций;
! queue – очередей;
! rules – правил фильтрации;
! state – «состояний»;
! Sources – таблицы отслеживания адресов отправи-
телей;
! info – статистики;
! Tables – таблиц;
! osfp – отпечатков операционных систем;
! all – очистить все вышеперечисленное.
! -f file – путь к конфигурационному файлу.
! -i interface – правила будут применены только к указан-
ному интерфейсу.
! -o – включить «оптимизатор» для правил. Новая воз-
можность фильтра позволяет:
! удалить повторяющиеся правила;
! удалить правила, которые являются частью другого
правила;
! скомбинировать разные правила в таблицу с общи-
ми частями;
! переопределить порядок правил для улучшения
фильтрации.
! -s modifier – то же самое, что и -F, только не обнуляет, а
показывает информацию, modifiers – все то же.
! -T command – используется для управления таблица-
ми:
! kill – удалить таблицу;
! flush – очистить таблицу;
! add – добавить один или несколько хостов в таблицу;
! replace – заменить адрес;
20
! show – показать хосты в таблице;
! test – проверить, попадает ли данный адрес в таблицу;
! zero – обнулить статистику таблицы;
! load – загрузить таблицы только из файла конфигу-
рации. Обычно используется так:
# pfctl –T load –f /etc/pf.conf
! -t указывает имя таблицы, в которой обрабатываются
команды для -T.
Вот, в общем, основные команды для pfctl. Думаю, с этой
утилитой вы разберетесь очень быстро.
Заключение
В следующей статье я обязательно расскажу вам обо всех
вещах, не затронутых в этой статье, таких как контроль
полосы пропускания, роутинг и т. д. И с удовольствием от-
вечу на все ваши вопросы относительно пакетного фильт-
ра OpenBSD.
Напоследок привожу пример конфигурационного фай-
ла, в котором использованы все те возможности, о кото-
рых я писал.
ext_if="{ rl0 }"
external_addr="{ 192.168.0.13/32, 192.168.0.113/32 }"
allowed_tcps = "{ 22, 25, 80 }"
allowed_udps="53"
insecure_tcps="{ 21, 53, 110 }"
#insecure_udps=
insecure_tcp_hosts = "{ 192.168.9.13/32, 192.168.13.13/32 }"
#insecure_udp_hosts
set timeout { interval 30, frag 10 }
set timeout { tcp.first 120, tcp.opening 30, ↵
tcp.established 86400 }
set timeout { tcp.closing 900, tcp.finwait 45, ↵
tcp.closed 90 }
set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
set timeout { icmp.first 20, icmp.error 10 }
set timeout { other.first 60, other.single 30, ↵
other.multiple 60 }
set limit { states 10000, frags 5000 }
set loginterface rl0
set optimization normal
set block-policy drop
set require-order yes
scrub in all
table <spamd> persist
table <spamd-white> persist
rdr pass inet proto tcp from <spamd> to ↵
any port smtp -> 127.0.0.1 port 8025
rdr pass inet proto tcp from !<spamd-white> to ↵
any port smtp -> 127.0.0.1 port 8025
block in log all
pass out proto { tcp, udp, icmp } all keep state
pass in on lo0 all
pass out on lo0 all
pass in inet proto icmp all icmp-type echoreq keep state
pass in on $ext_if proto tcp from any to ↵
$ext_if port $allowed_tcps flags S/SA keep state
pass in on $ext_if proto udp from any to ↵
$ext_if port $allowed_udps keep state
pass in on $ext_if proto tcp from $insecure_tcp_hosts to ↵
$ext_if port $insecure_tcps flags S/SA keep state
pass in on $ext_if proto tcp from any to ↵
any port > 49151 keep state

ВИРТУАЛЬНЫЕ ВОЙНЫ
Сравнительное тестирование
VMWare Workstation и Cooperative Linux
В рассмотрении работы любых систем, в том числе и вир-
туальных машин, значительную роль играет производитель-
ность. Ведь для любой системы, работающей в реальных
условиях, важна не только ее функциональность, но и об-
щая скорость работы, в том числе и в сравнении с другими
решениями, присутствующими на рынке. Для оценки про-
изводительности, как правило, используются пакеты, со-
стоящие из различных тестов, измеряющих производитель-
ность всех основных компонентов системы. Тесты могут из-
мерять как абсолютную производительность того или ино-
го компонента (синтетические тесты), так и скорость рабо-
ты определенной программы (тесты-приложения). Тесты
первой категории позволяют измерить пиковую произво-
дительность системы, которая, скорее всего, никогда не бу-
дет достигнута при работе реальных программ. Тесты-при-
ложения, напротив, показывают, насколько полно та или
иная программа использует потенциал рассматриваемой
системы.
В данной статье эти и другие «азы тестирования» будут
применены на практике. Речь пойдет о сравнительном тес-
тировании VMWare и Cooperative Linux. Кроме того, их ре-
зультаты будут также соотнесены с производительностью
обычного Linux, работающего в монопольном режиме.
Методика тестирования
Идея тестирования, в том числе и Linux, не нова. За все
время своего существования Linux обзавелся огромным
количеством тестов, измеряющих производительность не
только различных компонентов системы, но и работающих
в нем приложений. Некоторые из этих тестов уже де-факто
стали стандартами тестирования, в то время как другие
лишь завоевывают себе место под солнцем.
Поэтому для того, чтобы в n-й раз не изобретать вело-
сипед, разрабатывая пакеты тестов, специфичные для вир-
1
«В компьютерном мире есть три вида лжи: ложь, наглая ложь и тесты производительности». (c) Бенжамин Дизраэли, Марк Твен и
компьютерное сообщество.
№11(24), ноябрь 2004
администрирование
There are three kinds of lies:
lies, damned lies and benchmarks1
МИХАИЛ ПЛАТОВ
туальных машин, было принято решение использовать уже
существующие и «проверенные» тестовые пакеты. В каче-
стве основы для методики проведения тестов использова-
лись Linux Benchmarking Toolkit (LBT) и Scalable Test Platform
(STP), которые по необходимости дополнялись специфич-
ными тестами.
В итоге тестируемые системы были изучены при помо-
щи следующих тестовых пакетов:
! Компиляция ядра Linux 2.4.27 (стандартная конфигура-
ция).
! lm_bench 3.0_alpha3.
! nbench 2.2.1.
! ttcp 1.12.
! tiobench-0.3.3-r1.
! bonnie++ 1.93c.
Этот набор включает как синтетические тесты, измеря-
ющие производительность основных подсистем (целочис-
ленная и плавающая арифметика, производительность под-
системы памяти и жесткого диска, операции ввода-вывода
и т. д.), так и тесты приложений (компиляция ядра). Более
подробно с методикой тестирования в рамках LBT можно
ознакомиться на странице http://www.tldp.org/HOWTO/
Benchmarking-HOWTO-3.html.
Тесты выполнялись на компьютере следующей конфи-
гурации:
! Процессор – AMD Duron XP 1800 МГц.
! Материнская плата – ECS K7S6A (SIS 745).
! ОЗУ – DDR SDRAM 512 Мб.
! Память, выделяемая гостевой ОС – 128 Мб.
! Жесткий диск Samsung SP0802Т (для основной ОС).
! Жесткий диск Samsung SV0411N (для тестируемых си-
стем).
! Сетевая плата Intel PRO 100VE.
21
 администрирование
Следует отметить, что ввиду архитектурных особенно-
стей при тестах coLinux использовалось ядро Linux, моди-
фицированное патчами coLinux (описание архитектуры
coLinux можно найти в статье [1]). Для VMWare и «чистой»
системы использовалось ядро 2.4.27, собранное в конфи-
гурации по умолчанию.
При проведении тестов основной акцент делался не на
измерении производительности систем в абстрактных «по-
пугаях», а на определении того, какая из них выполняет
тот или иной тест наиболее эффективно.
Теоретическое отступление
Прежде чем приступить к рассмотрению реальных тестов
и их результатов посмотрим более подробно на сегодняш-
них претендентов.
Итак:
! VMWare Workstation – коммерческий продукт представ-
ляет собой типичную виртуальную машину. Для «госте-
вой» ОС VMWare предоставляет «известный» аппарат-
ный интерфейс (chipset – Intel 440BX, LAN – AMD PCnet32
и т. д.). Это позволяет запускать в виртуальной машине
практически все известные ОС, работающие на эмули-
руемом оборудовании. (DOS, Windows, Linux, Solaris,
FreeBSD, NetWare).
! Cooperative Linux – Open Source продукт, распространя-
емый по лицензии GPL. В его состав входит патч Linux-
ядра, позволяющий запустить ядро ОС Linux из Windows.
В качестве гостевой ОС может выступать только Linux,
причем ядро должно быть соответствующим образом
«пропатчено». Так, используемое в coLinux ядро не ра-
ботает с оборудованием в привычном для нас понима-
нии: оно не поддерживает Plug&Play, ACPI, PCI, видео и
звуковые карты, жесткие диски, USB и т. д. Работа со
всем жизненно важным оборудованием производится
через специальные драйверы (Cooperative PIC, CoLinux
Block Device, WinPCAP, TAP), работающие с оборудова-
нием через драйверы Windows.
У каждого из этих подходов есть свои «за» и «против».
Так, для того чтобы запустить ОС в VMWare, не требуется
прикладывать практически никаких усилий. С другой сто-
роны, для запуска существующего Linux из coLinux, при про-
чих равных, придется как минимум пересобрать ядро с пат-
чами coLinux. Кроме того, coLinux не поддерживает таких
вещей, как «прямая работа с USB-устройствами», видео-
карты и оборудование вообще. И если с USB-устройства-
ми все-таки можно работать (через интерфейс блочных
устройств), то о запуске X-сервера непосредственно на
coLinux можно забыть. Конечно, в качестве X-cервера мож-
но использовать какой-нибудь Cygwin/X, XWin-PRO, Mi-X
или HumningBird Exceed, установленный на Windows. Од-
нако мой опыт работы с Windows X-серверами показал, что
такое решение на данный момент слабо пригодно для ежед-
невного использования – уж очень низка производитель-
ность X-приложений. Справедливости ради нужно сказать,
что субъективная скорость работы X-сервера в VMWare
тоже далека от совершенства. Однако, безусловно, этот
вопрос требует дальнейшего изучения, которое выходит за
рамки данной статьи.
22
С точки зрения производительности остальных компо-
нентов ситуация неоднозначна. С одной стороны, VMWare –
типичная виртуальная машина (к тому же работающая на
большом количестве платформ), поэтому ей должны быть
присущи некоторые накладные расходы, вызванные необ-
ходимостью эмуляции «слоя виртуализации», обеспечива-
ющего интерфейс «известного» оборудования.
Ситуация с coLinux несколько иная. Компьютер эмули-
руется не полностью (в отличие от VMWare). Ядро содер-
жит минимум функциональности для работы с оборудова-
нием, поэтому скорость работы системы во многом зави-
сит от эффективности используемых драйверов и скорос-
ти работы самой ОС Windows. В случае VMWare произво-
дительность, конечно, тоже зависит от производительнос-
ти Windows, однако она также во многом зависит и от ско-
рости работы самого ядра «гостевой» системы. Поэтому
для достижения наибольшей производительности в VMWare,
необходимо скомпилировать ядро с поддержкой «виртуаль-
ного» оборудования. Теоретически подход, используемый
coLinux, может обеспечить большую производительность (за
счет отсутствия слоя виртуализации). Так это или нет, про-
верим на тестах.
Производительность процессора
Многие пользователи Linux-систем для определения про-
изводительности процессора используют BogoMIPS – внут-
реннюю переменную ядра, косвенно отражающую скорость
работы процессора. Сами разработчики ядра утверждают,
что BogoMIPS не является показателем производительно-
сти процессора и относиться к нему как тесту сколь-нибудь
серьезно нельзя. Тесты рассматриваемых сегодня систем
это только подтверждают: на всех виртуальных машинах
число BogoMIPS абсолютно одинаково – 3696. Ну что же,
давайте посмотрим, что скажут тестовые пакеты.
nbench – данный пакет измеряет, во сколько раз пока-
затели производительности данной системы превосходят
эталонную (Pentium-90 и K6-233). Результатом его работы
является набор индексов производительности подсистемы
памяти, целочисленных операций и операций с плавающей
точкой. Тест запускался с параметрами по умолчанию.
В целях экономии места приведены данные относитель-
но эталона K6-233 (для Pentium-90 ситуация выглядит ана-
логично) (см. рис. 1).
Что же, процессор, он и есть процессор. Все три рас-
сматриваемые системы идут практически вровень.
Ðèñóíîê 1

Подсистема памяти
Для измерения производительности подсистемы памяти ис-
пользовался низкоуровневый пакет синтетических тестов
lm_bench. В состав данного пакета входит несколько ути-
лит, измеряющих производительность базовых операций
(чтение, запись, копирование, произвольное чтение и т. д.)
применительно к различным компонентам ОС (подсистема
памяти, tcp, pipes, sockets и т. д.).
Ðèñóíîê 2
Для тестирования подсистемы памяти использовалась
утилита bw_mem. При запуске ей передавались следующие
параметры:
# bw_mem -P 1 -W 1 1024K rd|wr|cp
Для каждой машины измерялась скорость чтения (rd),
записи (wr) и копирования (cp). Для тестирования в услови-
ях многопоточности тест на каждой машине запускался для
трех параметров P – 1, 10 и 50. (Так как расхождение резуль-
татов для 1 и 50 потоков составило менее 1%, на диаграмме
приводится усредненное значение всех трех экспериментов).
Итак, все рассматриваемые «виртуальные» машины
одинаково эффективно работают с памятью. При чтении
coLinux оказался несколько быстрее VMWare, однако вы-
игрыш является настолько несущественным, что вполне мо-
жет быть списан на погрешности измерения.
Дисковая подсистема
Для тестирования дисковой подсистемы использовался вто-
рой жесткий диск, разбитый на два раздела. Первый раз-
дел был отформатирован в файловую систему ext2 (3 Гб),
на которую был записан Gentoo-Linux из образа, взятого с
сайта coLinux. Этот раздел использовался при тестирова-
нии Linux, VMWare и coLinux (в тестах обозначена как
«*_part»). Второй раздел был отформатирован в ntfs (10 Гб)
и использовался для измерения производительности дис-
ковой подсистемы coLinux и VMWare в случае, если образ
файловой системы хранится в виде файла. При проведе-
нии тестов в Linux добавлялась поддержка чипсета SIS5513,
в VMWare – чипсета PIIX. В обоих случаях при тестирова-
нии были включены режим DMA и 32-битный режим рабо-
ты с диском. Виртуальный диск в файл-образе в тесте с
VMWare подключался к интерфейсу IDE.
В организации дисковых подсистем наших подопытных
есть некоторые отличия. Как было отмечено выше, VMWare –
типичный представитель виртуальных машин, и дисковая
подсистема в ней реализована соответствующим образом,
№11(24), ноябрь 2004
администрирование
а именно эмуляцией контроллера IDE чипсета Intel i440BX.
С coLinux же ситуация обстоит несколько иначе: он не ра-
ботает с устройствами напрямую (ядро собирается без под-
держки шины PCI и соответственно без контроллера IDE).
Диск эмулируется специальным драйвером блочных уст-
ройств, работающих с Windows-демоном coLinux. По этой
причине было принято решение в пользу измерения произ-
водительности диска не низкоуровневыми утилитами (на-
пример, hdparm), а измерением скорости работы с файло-
вой системой. Однако для того, чтобы уменьшить влияние
файловой системы на результаты тестов, использовалась
нежурналируемая (и соответственно более быстрая) фай-
ловая система ext2fs.
При построении «виртуальной» системы можно исполь-
зовать два основных подхода:
! создать образ root-файловой системы в файле на су-
ществующем ntfs- или fat-разделе;
! создать (или использовать уже существующий) ext2-
раздел и работать с ним напрямую.
В первом случае на производительность дисковых опе-
раций в Linux накладывается дополнительное влияние фай-
ловой системы (скорость доступа, фрагментация и т. д.) и
ее драйвера. Второй случай этих проблем лишен, поэтому
производительность «виртуальных» систем на отдельном
разделе должна быть выше. Итак, перейдем к первому те-
сту – последовательное чтение блока данных. В данном те-
сте с диска последовательно считывается файл размером
256 Мб (блоками по 4 Кб). Для имитирования ситуации мно-
гозадачности тест проводится для 1, 2, 4 и 8 потоков.
Ðèñóíîê 3
Быстрее всех с диском работает «чистый» Linux, затем
идут VMWare и coLinux, работающие с выделенным разде-
лом. В случае одного потока производительность vmware
выше coLinux, однако с увеличением количества потоков
coLinux несколько вырывается вперед. Медленнее всего ра-
ботают VMWare и coLinux, использующие образ root-фай-
ловой системы на существующем разделе, хотя VMWare
все же показывает чуть более высокую производительность
(см. рис .4).
При произвольном чтении ситуация несколько меняет-
ся. Явно лидирует «чистый» Linux, все виртуальные маши-
ны показывают примерно одинаковую и достаточно низкую
скорость.
23
 администрирование
Ðèñóíîê 4
В следующем тесте измеряется скорость последова-
тельной записи на диск.
Ðèñóíîê 5
«Чистый» Linux, как всегда, впереди. За ним идут coLinux
и VMWare в различных конфигурациях дисковой подсисте-
мы. С увеличением количества потоков производительность
всех систем сравнивается.
Тест произвольной записи:
Ðèñóíîê 6
А вот и первая неожиданность: скорость записи у coLinux
и VMWare оказалась больше, чем у «чистого» Linux. Причи-
ной этому, скорее всего, является кэширование обращений
к диску, производимое ОС Windows. Для проверки этой ги-
потезы проведем тест с помощью другой утилиты – bonnie++
(sequential output, per block, size 300 Мб) (см. рис. 7).
Ситуация в целом такая же, хотя и имеются некие рас-
хождения, причина которых, скорее всего, кроется в высо-
коуровневой природе тестов.
24
Ðèñóíîê 7
Производительность TCP/IP
Как VMWare, так и coLinux поддерживают различные типы
организации взаимодействия между реальной и виртуаль-
ной машинами. Основными являются bridged и NAT (более
подробное описание можно найти в статье [1]). Для получе-
ния более полного представления об обоих исследуемых
виртуальных системах тестирование каждой их них прово-
дилось как в режиме bridged, так и NAT.
Отличительной особенностью «сетевых» тестов являет-
ся то, что для измерения производительности всегда тре-
буется «вторая сторона», выступающая при передаче в ка-
честве партнера.
Причем крайне желательно, чтобы такой партнер был
заведомо быстрее, при этом он не будет являться узким
местом и его производительность не окажет существенно-
го влияния на производительность измеряемой системы. В
роли такого партнера в данном тесте использовался заве-
домо более быстрый компьютер – Pentium-4 – 2.4 ГГц (се-
тевой интерфейс Intel PRO 100), также работающий под уп-
равлением Linux (дистрибутив Gentoo).
В тестах использовался пакет ttcp, измеряющий произ-
водительность TCP- и UDP-передач. Тест запускался 5 раз,
в качестве результата приводится среднее значение.
Ðèñóíîê 8
Первыми в данном тесте пришли Linux и VMWare в ре-
жиме bridged. Их скорость (91 Мбит/с) оказалась близка к
максимальной теоретически достижимой. На третьем мес-
те оказался coLinux в режиме NAT (скорость составила око-
ло 42 Мбит/с). Самыми медленными оказались coLinux в
режиме bridged и VMWare в режиме NAT.

Производительность каналов (pipes)
Канал (Pipe) – способ межпроцессного взаимодействия,
реализованный во всех популярных системах (Windows,
Linux и др.), активно используемый многими приложения-
ми. Для тестирования производительности каналов исполь-
зовался тест bw_pipe, входящий в пакет lmbench. Данный
тест создавал канал между двумя процессами и блоками
64 Кб передавал по нему 32 Мб данных:
# bw_pipe -P 1 -W1 -M 32768K
Результаты теста отражены в таблице:
Ðèñóíîê 9
Linux, как ему и положено, держится впереди. coLinux в
данном тесте опережает VMWare более чем в 2 раза.
Компиляция ядра
Для оценки общей производительности системы выполня-
лась привычная многим операция – компиляция ядра Linux.
Этот тест ценен не только достаточно показательным прак-
тическим результатом (в процессе компиляции активно ис-
пользуются процессор, память и дисковая подсистема), но
и тем, что практически все люди, активно работающие с
Linux, время от времени пересобирают ядро. В качестве «по-
допытного» использовалось ядро версии 2.4.27 со стандар-
тными опциями конфигурации ядра (make oldconfig).
При тестировании в VMWare и coLinux root-файловая си-
стема находилась на ext2-разделе второго жесткого диска.
Время компиляции ядра измерялось с помощью утилиты
time (время выполнения make dep не учитывалось):
# time make vmlinux
Тест в каждой системе выполнялся 3 раза, на диаграм-
ме приводится усредненное время компиляции (чем мень-
ше, тем лучше):
Ðèñóíîê 10
№11(24), ноябрь 2004
администрирование
Быстрее всех с задачей справился «чистый» Linux – 6
минут и 5 секунд. Вторым финишировал coLinux – 6 минут
32 секунды. На последнем месте (с достаточно большим от-
рывом) оказалась VMWare Workstation– 9 минут 13 секунд.
Выводы
Итак, несколько слов о результатах. В тестах процессора и
подсистемы памяти все тестируемые сегодня системы пока-
зали практически равные результаты, так что если главной
для вас задачей, решаемой Linux, является задача вычисли-
тельная, то можете смело использовать любую из систем. В
качестве дисковой подсистемы для виртуальной машины
можно использовать как выделенный Linux-раздел, так и
файл-образ на уже существующем fat или ntfs-разделе (хотя
первый вариант все-таки выглядит более привлекательно).
Ethernet. Если же вам необходим полноценный 100 Мбит
сетевой интерфейс в виртуальном Linux, то следует обра-
тить внимание на VMWare Workstation. Разработчики bridged-
драйвера VMWare действительно поработали на славу, обес-
печив производительность, практически не уступающую «чи-
стой» Linux-системе. Производительность сетевой подсис-
темы coLinux можно назвать приемлемой только в режиме
NAT. В режимах coLinux-bridged и VMWare-NAT «серьезно»
использовать сеть, скорее всего, не получится – уж больно
низка производительность.
И напоследок позвольте сказать еще несколько слов.
Решение о том, использовать ту или иную систему или нет,
всегда должно приниматься с учетом условий и реалий ре-
шаемой задачи, главное при этом не забывать, что «There
are three kinds of lies: lies, damned lies and benchmarks».
Литература, ссылки:
1. Платов М. Знакомство с Cooperative Linux. – Журнал
«Системный администратор», №10, октябрь 2004 г.
2. LBT: http://www.tldp.org/HOWTO/Benchmarking-HOWTO-
3.html.
3. STP: http://www.osdl.org/lab_activities/kernel_testing/stp.
4. VMWare Worksatation: http://www.vmware.com/products/
desktop/ws_features.html.
5. Cooperative Linux: http://www.colinux.org.
6. lmbench: http://www.bitmover.com/lmbench.
7. ttcp: http://www.pcausa.com/Utilities/pcattcp.htm.
8. netperf: http://www.netperf.org/netperf/NetperfPage.html.
9. tiobench: http://sourceforge.net/projects/tiobench.
10. bonnie++, http://www.coker.com.au/bonnie++.
Уважаемые читатели!
Теперь вы можете приобретать новые и старые
номера журнала через интернет-магазин
Стоимость 1 экземпляра – 140 рублей
Доставка почтой БЕСПЛАТНО в любую точку России
25
 администрирование
ОБЗОР ЭМУЛЯТОРА mips64emul
В этой статье я хотел бы вам рассказать об одном очень
интересном эмуляторе – mips64emul. В последнее время
меня заинтересовала тема эмуляции во всех ее проявле-
ниях. Начиная от эмулирования системных вызовов какой-
либо ОС, заканчивая полноценными виртуальными маши-
нами. В конечном итоге виртуальная машина – это тот же
самый эмулятор, отличие лишь в том, что эмулируется весь
компьютер целиком. Самые известные представители ряда
виртуальных машин – VMWare, Bochs, Virtual PC. И вот тут
мы подходим к самому интересному, все вышеперечислен-
ные программы эмулируют архитектуру x86. Соответствен-
но под ними у нас есть возможность запустить ОС, создан-
ные для этой архитектуры. Но ведь есть и другие архитек-
туры – PPC, m68k, SPARC, MIPS, и т. д. Потратив некото-
рое время на поиски программ, способных эмулировать
процессоры, отличные от x86, я нашел много чего интерес-
ного. Изыскания относительно одной из находок перед
вами.
Официальный сайт проекта mips64emul – www.mdstud.
chalmers.se/~md1gavan/mips64emul. Как ясно из названия,
он эмулирует процессоры MIPS. Данная программа способ-
на эмулировать как 64-, так и 32-битные процессоры MIPS.
MIPS в настоящее время используются достаточно широ-
ко: 90% всех компьютеров от Silicon Graphics используют
эти процессоры, также они используются в игровой пристав-
ке Sony Play Station 2 и во многих других устройствах.
Перейдем от теории к практике. Все свои эксперимен-
ты я проводил на P3-550 МГц/320 Мб RAM под управлени-
ем ОС FreeBSD 4.10. Также ее можно использовать под уп-
равлением другой BSD-системы или Linux.
Берем с сайта разработчика последнюю версию про-
26
АЛЕКСАНДР
АЛЕКСАНДР БАЙРАК
БАЙРАК
граммы. Я использовал версию 0.2. Процесс установки
mips64emul очень прост и каких-либо затруднений не выз-
вал:
./configure – help
Внимательно читаем, может быть, вам понадобится для
своих нужд добавить какие-либо опции.
./configure
gmake
gmake install
mips64emul поддерживает эмуляция достаточно боль-
шого количества компьютеров с mips-процессорами:
! DEC Station: PMAX(3100), 3MAX(5000), 3MIN(5000),
3MAX+(5000,5900), 5800, 5400, MAXINE(5000), 5500,
5100(MIPSMATE).
! ARC: NEC-RD94, PICA-61, NEC-R94, Deskstation Tyne.
! Sony Playstation 2 (CPU R5900).
! Cobalt (CPU RM5200).
! Различные машины от SGI (IPxx ).
! Некоторые карманные компьютеры с MIPS-процессора-
ми.
Поддерживаемые типы процессоров:
! R2000, R2000A, R3000, R3000A, R4000.
! R4300, R4400, R4600, R4700, R5000.
! RM5200, R5900, VR5432, R6000, RM 7000.
! R8000, R10000, R12000, R14000, 5K.
Далее, для каждого компьютера нужна ОС. На сайте раз-

работчика я прочитал, что на данный момент под эмулято-
ром можно свободно запустить следующие ОС:
! NetBSD/pmax;
! OpenBSD/pmax;
! Ultrix/RISC;
! Sprite.
С последними двумя я, к сожалению, не работал, и, как
следствие, дистрибутивов этих ОС у меня нет. Если при-
нять во внимание, что это коммерческие ОС, уже офици-
ально не поддерживаемые производителем, я не стал тра-
тить время на поиск дистрибутивов и для дальнейших экс-
периментов выбрал NetBSD. Во-первых, с ней я рабо-
таю чаще, нежели с OpenBSD, во-вторых, поддержка архи-
тектуры pmax в OpenBSD была закончена в версии 2.9 (она
вышла 1 июня 2001 года). А последняя версия NetBSD (на
момент написания – 1.6.2) отлично поддерживает pmax и
по сей день.
Не буду подробно останавливаться на процессе уста-
новки NetBSD, потому как есть замечательная статья Анд-
рея Бешкова [1].
Для начала нам нужно создать виртуальный жесткий
диск, на который мы будем устанавливать ОС.
dd if=/dev/zero of=/disk.img bs=1 count=512 seek=1100000000
После выполнения команды у нас получится файл раз-
мером 1050 Мб. Естественно, размер диска вы можете
уменьшить или увеличить в зависимости от своих потреб-
ностей.
Далее нам нужно определиться с методом установки:
NetBSD можно поставить непосредственно с boot CD-дис-
ка либо по сети, перед этим загрузившись с помощью ус-
тановочной дискеты. Я выбрал первый вариант. Берем с
ftp://ftp.netbsd.org/pub/NetBSD/iso/1.6.2/pmaxcd.iso.
Его размер около 75 Мб. Далее запускаем наш эмуля-
тор, указав ему грузиться с диска:
mips64emul –X –D2 –d disk.img –d bc:pmaxcd.iso –j netbsd.pmax
Давайте разберемся с опциями, которые мы указыва-
ем:
! -X – использовать X11.
! -D2 – эмулировать DEC Station 5000/200.
! -d disk.img – указываем файл, который является нашим
виртуальным диском.
! -d bc:pmaxcd.iso – указываем загрузочный диск.
! b – boot;
! c – CD-ROM.
! -j – указываем имя ядра.
Для тех, кто решил устанавливать систему по сети, со-
общаю порядок действий.
Сначала нужно списать образ загрузочной дискеты c
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.6.2/pmax/binary/
kernel/netbsd-INSTALL.gz. Далее нужно распаковать полу-
ченный архив:
gunzip netbsd-INSTALL.gz
№11(24), ноябрь 2004
администрирование
После чего запустить mips64emul:
mips64emul –X –D2 –d disk.img netbsd-INSTALL
Так же в случае процесса установки по сети придется
настроить сеть. Сетевой интерфейс будет называться le0.
Настройка сети каких-либо проблем не вызывает, вам нуж-
но лишь указать имя хоста, IP-адрес, маску сети, адрес шлю-
за и IP DNS-сервера.
Процесс инсталляции ОС занимает достаточно продол-
жительное время, так на моей системе он занял чуть боль-
ше четырех часов. Да, к сожалению, уже на этом этапе мож-
но заметить, что работает все медленнее, чем хотелось бы.
После того как процесс установки завершен, можно посмот-
реть, что у нас получилось:
mips64emul –X –M64 –D2 –d disk.img
Все опции запуска нам уже знакомы, за исключением –
M. Это опция служит для задания количества оперативной
памяти, т.е. в данном случае я указал, что на эмулируемом
компьютере установлено 64 Мб памяти.
Система загружается порядка 5 минут. Я никогда не
работал на настоящей DEC Station 5000/200, но думаю, что
на ней загрузка системы ничуть не быстрее, потому как
тактовая частота процессора всего 25 МГц. После запуска,
без дополнительной настройки мы можем запустить X-
windows, выполнив команду startx. В качестве window
manager используется стандартный twm. Более подробно о
настройке NetBSD вы можете прочитать в моей статье [2].
Исходя из документации к mips64emul, помимо вышеука-
занных ОС, можно запустить другие системы, созданные для
процессоров MIPS. Например, NetBSD/sgimips, NetBSD/arc,
NetBSD/cobalt, NetBSD/playstation2 (www.netbsd.org), Linux/
SGI (http://www.linux-mips.org). И некоторые другие малоиз-
вестные реализации Linux для MIPS-процессоров. Ради
справедливости нужно заметить, что поддержка всего вы-
шеперечисленного пока находится в экспериментальном ре-
жиме. Но судя по тому, как динамично развивается проект
(а ему меньше двух лет), можно предположить, что все эти
ОС в скором времени можно будет запускать абсолютно
спокойно.
А какая практическая польза от использования этого
эмулятора, спросите вы. Я лично использую его исключи-
тельно из «спортивного» интереса. Но он окажется очень
полезным для программистов, пишущих приложения, на-
целенные на MIPS-процессоры, но по какой-либо причине
не имеющие его под рукой. Также это отличный полигон
для изучения данной архитектуры в академических целях.
Буду рад услышать описания ваших экспериментов, свя-
занных с этим эмулятором. Пишите!
Литература:
1. Бешков А. NetBSD: установка и настройка. – Журнал
«Системный администратор», №9, август 2003г., также
доступна электронная версия – http://onix.opennet.ru/
netbsd/netbsd.html.
2. Байрак А. Первые шаги в NetBSD. Часть 1. – Журнал
«Системный администратор», №6, июнь 2004 г.
27
 администрирование
ЛЕЙСЯ ПЕСНЯ,
ИЛИ
СЕРВЕР ПОТОКОВОГО АУДИО
СВОИМИ РУКАМИ
Чтобы покончить с бардаком, нужно возглавить его само-
му. Если пользователи по утрам, вместо того чтобы рабо-
тать, выходят в Интернет в поисках новостей, что подчас
съедает большую долю трафика, то почему бы не органи-
зовать свою ленту новостей на корпоративном сайте, по-
немногу пользователи привыкнут, и нагрузка на внешний
канал уменьшится. Но новости и прочая текстовая инфор-
мация еще ничего по сравнению с гигабайтами музыки, ви-
део и прочего материала, который хотят протащить в сеть
через узкий канал. Можно организовать фильтрацию, ус-
тановить лимиты, все это иногда помогает, но гигабайты
информации, при этом часто одинаковой, все равно соби-
раются на жестких дисках компьютера, затрудняя архива-
цию.
Сегодня разберемся как создать сервер, который будет
транслировать аудиопотоки.
В настоящее время существует достаточно большое ко-
личество приложений, позволяющих организовать такую
трансляцию. Написаны они на разных языках программи-
рования, работающих под управлением разных операци-
онных систем, отличающихся лицензией, поддерживаемы-
ми форматами и прочими характеристиками. Самый боль-
шой список, который мне удалось найти, размещен на стра-
нице http://sound.condorow.net/netaudio.html. Наиболее из-
вестным решением является использование веб-сервера
Apache, модуль и необходимую информацию о настройках
которого можно найти по адресам: http://www.tangent.org/
mod_mp3 и http://sander.vanzoest.com/apachecon/2001. Дру-
гим не менее популярным решением является SHOUTcast
от компании Nullsoft, подарившей миру WinAMP. Есть тяже-
ловес jetCast Server (http://jetaudio.com/download/jetcast.html),
поддерживающий большое количество форматов, или про-
стой в настройке и совместимый практически со всеми по-
добными серверами – AnaloxX SimpleServer:Shout (http://
analox.com). Как видите, выбор есть.
В статье мы познакомимся с наиболее популярным Open
Source-решением – Icecast (http://www.icecast.org). На дан-
ный момент Icecast поддерживает форматы Ogg Vorbis и
MP3, при особой необходимости любой другой формат мо-
жет быть добавлен без проблем, работает под управлени-
ем как Windows, так и UNIX-подобных систем, гибок и ле-
гок в настройке, имеет толковую документацию, распрост-
раняется в исходных кодах.
Кто есть кто
Механизм трансляции аудиопотоков имеет свои особенно-
сти, поэтому сначала разберемся, как это работает, и оп-
28
СЕРГЕЙ ЯРЕМЧУК
ределимся с терминами. Любой сервер аудиопотоков, будь
то Icecast или SHOUTcast, предназначен только для транс-
ляции и работы с клиентами, которые подсоединяются, что-
бы послушать музыку. Сервер не занимается поиском ин-
формации на жестком диске, кодированием и прочим, как
это происходит с серверами, занимающимися трансляци-
ей видео. Необходимую информацию ему нужно сначала
переслать. Причем есть два варианта. Первый – использо-
вать аналогичный сервер (впрочем, не все серверы на 100%
совместимы между собой) в качестве источника информа-
ции. Такой сервер называется master relay. Можно забрать
весь поток с сервера и перетранслировать его полностью
или забрать только часть точек монтирования. Последний
вариант также может понадобиться при неполной совмес-
тимости серверов. Например, если в качестве мастер-сер-
вера для icecast будет выступать SHOUTcast, то весь поток
забрать не получится, необходимо указывать отдельные
точки монтирования. Да, что такое точка монтирования?
Точка монтирования – это ресурс на сервере, который пред-
ставляет один поток трансляции. Например, клиент хочет
послушать музыку, запустив XMMS, нажимает <Ctrl + L>,
вводит http://cal.icecast.net:8630/prog1.ogg (ссылка рабочая)
и слушает себе музыку. Параметр cal.icecast.net указывает
на сервер, 8630 – на порт, используемый для трансляции
(по умолчанию на большинстве серверов – 8000), а
prog1.ogg на источник информации, это и есть точка мон-
тирования. Причем если для mp3-потока указывать расши-
рение не обязательно, то для ogg это требуется. Конечно
же и наш сервер также может быть источником информа-
ции для других slave relay серверов. Такая схема принята
по нескольким причинам, чтобы равномерно распределить
клиентов, избежать дублирования информации на жестких
дисках, не перегружать каналы, ведь проще забрать поток
и перетранслировать его самому, чем позволить всем
пользователям тащить это в одиночку. Другим источником
информации для сервера могут быть так называемые source
client или broadcasting tools. Но о них позже.
Установка Icecast
Для установки понадобятся: libxml2 (http://xmlsoft.org/
downloads.html), libxslt (http://xmlsoft.org/XSLT/downloads.html),
опционально curl (http://curl.haxx.se/download.html) и для ра-
боты с OggVorbis библиотеки с http://www.vorbis.com. Но не
спешите скачивать, скорее всего, это уже есть в дистрибу-
тиве. После скачиваем архив с icecast (670 Кб), распаковы-
ваем: ./configure, make, make install. После чего в каталоге
/usr/local/bin/ появится исполняемый файл icecast, конфи-

гурационный файл icecast.xml в /usr/local/etc/, докумен-
тация и файлы для администрирования будут положены
в /usr/local/share/icecast/.
Конфигурируем Icecast
Единственный конфигурационный файл icecast.xml имеет
одинаковую структуру как для Linux, так и для Windows. Со-
стоит из нескольких секций, в которых сгруппированы па-
раметры, схожие по назначению. Значения всех парамет-
ров описывать вряд ли целесообразно, т.к. название гово-
рит само за себя, остановлюсь лишь на краткой характери-
стике и тех параметрах, на которые следует обратить вни-
мание. Первая секция файла называется limits, в ней опи-
сываются параметры подключения клиентов, таких как
максимальное их число, тайм-аут, после которого клиент
отключается, если связь с ним прервалась, размер очере-
ди, и пр. Изменять их стоит только при большом количе-
стве пользователей и плохих каналах (в перегруженных
сетях). Следующая секция authentication содержит пароли
и пользователей, имеющих доступ к серверу для тех или
иных целей. В поле source-password прописывается неза-
шифрованный пароль для source client, имя пользователя,
используемое источниками «source», поле relay-password
на данный момент не используется, поля admin-user и admin-
password содержат имя пользователя и пароль для адми-
нистрирования сервера.
Далее описываются параметры подключения источни-
ков информации (source client). Так, если на компьютере одна
сетевая плата, то для работы достаточно в параметре
hostname указать имя компьютера (или localhost, если ис-
точник находится на том же компьютере), в ином случае
директивой bind-address указываем на сетевой интерфейс,
параметр port при этом укажет на IP-порт (по умолчанию
8000), который будет открыт для подключения источников.
Обратите внимание, что возможно задание нескольких пор-
тов директивой listen-socket. Директивами master-server,
master-server-port, master-update-interval и master-password
устанавливаются параметры master relay сервера, с кото-
рого будет получаться весь аудиопоток, транслируемый сер-
вером, если нет такого сервера, то оставляем как есть, т.е.
закомментированными. Если нет необходимости в получе-
нии всего аудиопотока с мастер-сервера для использова-
ния отдельных точек монтирования, используется секция
relay, в которой параметры server и port указывают на мас-
тер-сервер, mount и local-mount указывают соответственно
на экспортируемую и локальную точку монтирования. При
работе с сервером SHOUTcast, для того чтобы передавать и
метаданные в опции relay-shoutcast-metadata установите 1.
В секциях mount, устанавливаются специфические парамет-
ры для точки монтирования, указанной в mount-name. Эти-
ми параметрами могут быть имя пользователя и пароль
(username и password), которым позволено соединяться,
максимальное количество пользователей (max-listeners),
необязательный параметр dump-file устанавливает файл,
куда будет записываться поток, а в случае если с точкой
монтирования что-то произойдет, то клиенты могут быть
автоматически переброшены на другую точку, указанную
в параметре fallback-mount. В секциях paths и logging ука-
зываются файлы и каталоги, необходимые для работы сер-
№11(24), ноябрь 2004
администрирование
вера, трогать их не стоит, но проверьте наличие всех ката-
логов на пути к файлам. Единственно интересным пара-
метром является «alias source», позволяющий создать не-
сколько разных точек монтирования из одной. И в security
устанавливаются параметры, позволяющие повысить защи-
щенность системы, так, chroot позволит выполняться Icecast
в ограниченной среде и в случае взлома злоумышленник
дальше указанного каталога не пойдет, а в changeowner
нужно указать имя пользователя и группу, от имени кото-
рых будет работать процесс сервера.
Настраиваем источник информации
В принципе можно присоединиться к любому серверу транс-
ляций, прописав параметры в секции relay, и больше ни о
чем не беспокоиться. Но будем разбираться, как организо-
вать трансляцию самому.
Список (далеко не полный) совместимых клиентов и про-
игрывателей для прослушивания потоков можно найти на
странице http://www.icecast.org/3rdparty.php.
Родным source-клиентом для Icecast является IceS (http:/
/www.icecast.org/ices.php), недавно появилась версия 2.0,
работает только под UNIX (точнее, под Linux, FreeBSD,
OpenBSD, Solaris) системами. Среди других, с которыми уда-
лось немного поэкспериментировать, понравился Darkice
(http://darkice.sourceforge.net), работающий также только под
UNIX, но умеющий поставлять информацию для Iceсast вер-
сий 1 и 2 и SHOUTcast или iceplay (http://icecast.linuxpower.org),
работающий только с mp2-файлами. Для пользователей
Windows пригодится SAM2 (http://www.spacialaudio.com) или
ezstream (http://www.icecast.org/ezstream.php), который рабо-
тает также и в UNIX-системах. Есть утилита, написанная и
для Mac OSX – Nicecast (http://www.rogueamoeba.com/nicecast).
Как видите, выбирать есть из чего.
Кстати, источник информации не обязательно должен
находиться на одном и том же компьютере. Для примера
займемся настройкой IceS. На данный момент имеются две
версии IceS. Версия 0.3, развитие которой приостановле-
но, предназначена для создания mp3-потоков, и версия 2.0,
умеющая транслировать только OggVorbis, по причине ма-
лого спроса поддержка mp3 была убрана. Если есть необ-
ходимость работы как с mp3, так и OggVorbis, то возможно
использование этих двух программ параллельно.
Другой вариант, взять ezstream, поддерживающий два
формата (как понимаете, один источник – одна точка мон-
тирования) и к тому же очень простой в настройках. Для
установки, помимо вышеперечисленных библиотек, пона-
добится libshout 2.0, ссылку на которую найдете на сайте
IceCast. Далее устанавливаем библиотеку и IceS обычным
образом, никаких особенностей здесь нет. Источником дан-
ных для IceS может служить компакт-диск, файлы на жест-
ком диске и любое устройство, с которого можно снять ин-
формацию.
Здесь стоит отметить, что почти все source clients по-
зволяют взять информацию со своего стандартного входа,
обработать и выдать на стримсервер. Для настройки пара-
метров IceS используется файл в формате XML, образцы
которого после установки вы найдете в /usr/local/share/ices.
Здесь их два: ices-live.xml содержит базовые настройки для
Live-трансляции (микрофон, СD-ROM и пр.), а в ices-
29
 администрирование
playlist.xml вы найдете шаблон, используемый при транс- <param name="rate">44100</param>
ляции из файлов, записанных в плейлист. Отличаются они <param name="channels">2</param>
<param name="device">/dev/dsp</param>
только разделом input, в котором описывается источник ин- <param name="metadata">1</param>
формации. Все описывать тоже не буду, остановлюсь лишь <param name="metadatafilename">test</param>
</input>
на параметрах, требующих пояснения.
Для запуска в качестве демона устанавливаем back Далее следует большая секция instance, описывающая
ground в 1. подключение к стримсерверу. При этом возможно задание
нескольких параметров, что позволит отсылать информа-
<background>1</background> цию нескольким таким серверам или создавать несколько
точек монтирования с разными параметрами на одном сер-
Далее описываются параметры вывода логов, при пер- вере.
воначальной отладке установите consolelog в 1, при этом
все ошибки будут выводиться на консоль. <instance>

<consolelog>1</consolelog> Ниже определяем имя узла, порт и пароль, последний

должен совпадать со значением в секциях source-password
Секция stream описывает передаваемый поток. файла icecast.xml.

<stream> <hostname> Çäåñü ïèøåì àäðåñ èëè èìÿ, êóäà îòïðàâëÿåì

<metadata>
<name> Çäåñü âïèøèòå íàçâàíèå ïîòîêà, îíî áóäåò
âèäíî â ïðîèãðûâàòåëå </name>
<genre> Æàíð ìåëîäèé </genre>
<description> Êðàòêîå îïèñàíèå ïîòîêà </description>
</metadata>
Модуль input задает параметры, откуда брать инфор-
мацию.
Ниже пример для плейлиста, обратите внимание: режим
задается тегом module – playlist.
<input>
<module>playlist</module>
<param name="type">basic</param>
Тип плейлиста может быть basic (простой текстовый
ASCII-файл, содержащий список Ogg Vorbis) или script, при
этом указанная программа генерирует его динамически.
<param name="file">playlist.txt</param>
Это для статического плейлиста, при динамической ге-
нерации списка песен используется конструкция:
<param name='program'></param>
Далее следуют параметры random (перемешивание
списка), restart-after-reread (перезапускает программу для
пересчитывания списка) и once (при 1 проигрывает список
только один раз, и работа заканчивается).
</input>
ïîòîê </hostname>
<port>8000</port>
<password>passwd</password>
<mount>/example.ogg</mount>
А здесь точка монтирования, которая будет видна
пользователям, желающим послушать музыку.
Ниже параметры повторной попытки, если не удается
сразу подключиться к серверу.
<reconnectdelay>2</reconnectdelay>
<reconnectattempts>5</reconnectattempts>
Параметр буферизации потока (лучше не трогать).
<maxqueuelength>80</maxqueuelength>
Параметры перекодирования, которые могут понадо-
биться, например, для уменьшения нагрузки на сеть, долж-
ны соответствовать принятым значениям, входным данным
и частотам дискретизации, иначе можно попортить каче-
ство материала.
<encode>
<nominal-bitrate>64000</nominal-bitrate>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
</instance>
Вот и все. Теперь собираем файлы в плейлист.
#find /home/sound -name *.ogg > ↵
/usr/local/share/ices/playlist.txt
В результате файл должен состоять из списка вида:

Для считывания входящей информации, например, с /home/sound/Song.ogg

микрофона, или других устройств применяется другая кон-
струкция. Теперь запускаем IceCast.
# /usr/local/bin/icecast -b -c /usr/local/etc/icecast.xml
<input> Changed groupid to 65534.
<module>oss</module>
Changed userid to 65534.

module может быть также alsa (device обычно plughw:0,0), И подаем информацию.
stdinpcm (при считывании со стандартного входа, секции
device не надо) и sun при работе Sun Solaris DSP. # ices /usr/share/ices/ices-playlist.xml

30

Теперь, набрав в строке любимого проигрывателя:
http://èìÿ_óçëà:8000/example.ogg
должны услышать музыку. На эту роль подходят как XMMS
и WinAMP, так и консольные ogg123 и mpg123.
И пару слов об ошибках, с которыми удалось столкнуть-
ся. Например, при запуске IceCast из-под root программа
выдала такую информацию.
# /usr/local/bin/icecast -c /usr/local/etc/icecast.xml
WARNING: You should not run icecast2 as root
Use the changeowner directive in the config file
Все просто: в целях безопасности под root сервер не
запускается, а директива changeowner в конфигурацион-
ном файле по умолчанию закомментирована. Исправьте,
только проследите, чтобы такой пользователь и группа в
системе были.
Далее возможны ошибки из-за невнимательности, свя-
занные с отсутствием каталогов, прописанных в конфигу-
рационных файлах, например, процесс может создать лог-
файл, но попутных каталогов создать не может. Например,
при запуске IceS выскочила такая ошибка:
unable to open log /var/log/ices/ices.log
Если проверить командой:
ls /var/log/ices/
№11(24), ноябрь 2004
администрирование
то может выясниться, что такого каталога не существует,
создайте его командой:
mkdir /var/log/ices
Если все равно ничего не получается, то загляните в
лог-файлы, в них выводится достаточно информации, что-
бы разобраться с проблемой. Например, в одном из доку-
ментов я нашел информацию о том, что вторая версия
IceCast все-таки работает с mp3-файлами. Не работает. А
в логах это выглядело так.
[2004-06-21 14:48:19] INFO playlist-builtin/playlist_read
Currently playing "/usr/share/ices/music/alisa/lodka.ìð3"
[2004-06-21 14:48:19] WARN playlist-builtin/playlist_read
Corrupt or missing data in file (usr/share/ices/music/alisa/lodka.ìð3)
А при загрузке OggVorbis-файла все нормально.
[2004-06-21 14:49:11] INFO playlist-builtin/playlist_read
Currently playing "/usr/share/ices/rammstein/Sonne.ogg"
[2004-06-21 14:49:11] INFO stream/ices_instance_stream
Connected to server: 127.0.0.1:8000/example.ogg
[2004-06-21 14:49:12] DBUG reencode/reencode_page
Reinitialising reencoder for new logical stream
[2004-06-21 14:49:12] INFO encode/encode_initialise
Encoder initialising in VBR mode: 2 channels, 44100 Hz, nominal 64000
Вот и все. Как видите, создать свой сервер трансляции
аудиопотоков не так уже и сложно. При внимательности на
все про все у вас уйдет от силы час-два.
Успехов.
31
 администрирование
ТАНЦУЕМ САМБУ
Любая операционная система имеет сильные и слабые сто-
роны. В чем-то она получается удачнее других, в чем-то –
нет, поэтому никогда нельзя однозначно расставить раз-
ные ОС по рангам. На таком «пьедестале почета» участни-
ки могут казаться идеальным решением для одной сферы
применения, но в других областях на них вряд ли можно
смотреть серьезно.
Среди людей, вращающихся в IT-сфере, уже много лет
идет религиозная война между сторонниками UNIX-подоб-
ных и Windows-систем. Это является неотъемлемой чертой
человеческой натуры, которая выражается в бесконечном
поиске идеала. Если же этот идеал вдруг находится, то зак-
рываются глаза на все его отрицательные качества – ведь
совершенству не положено их иметь.
Несомненно, рациональнее всего беспристрастно смот-
реть на вещи и не бросаться в гущу сражений на вечную
тему. Ведь если есть возможность использовать преиму-
щества разных операционных систем в рамках одной сети,
к чему нужны все эти религиозные предрассудки?
Главным и основным качеством любого системного ад-
министратора по всеобщему признанию является чувство
лени – стоит один раз правильно настроить систему, а даль-
ше останется только пить чай, наблюдая за тем, как все
работает без постороннего вмешательства. Шутка шуткой,
но удобство работы очень часто влияет на результат в луч-
шую сторону. Как показывает практика, в первую очередь
оно зависит от размера подконтрольной сети, причем чем
больше компьютерная сеть, тем грамотнее следует проду-
мывать ее внутреннее устройство в плане удобства после-
дующего администрирования. В случае маленькой комна-
ты с дюжиной компьютеров при возникновении какой-ни-
будь проблемы вполне реально подойти и лично с ней ра-
зобраться или поменять требуемую настройку вручную на
каждой машине, если есть такая необходимость. Но если
компьютеров в сети далеко за сотню, а пользователей и
того больше, то всех четырех рук системного администра-
тора не хватит, с какой бы скоростью он не размахивал ими.
В этом случае необходима мощная централизованная сис-
тема управления и контроля за работой сети.
Стандартным решением в случае большого количества
пользователей и рабочих станций является объединение
всех их в единый домен.
Для этого, если верить статистике, чаще всего исполь-
зуются программные решения компании Microsoft. Понятие
«домен» в последнее время стало неразрывно связано с
сетями под управлением Windows.
32
конкурсная статья
РОМАН ГРЕБЕННИКОВ
Но не окнами едиными жив этот мир. Существует боль-
шое количество задач, работу которых по тем или иным
причинам не доверяют этим операционным системам. По-
рой просто нет необходимости или возможности заводить
какой-нибудь www- или ftp-сервер на мощном в плане же-
леза компьютере, так как последние версии Windows весь-
ма требовательно относятся к аппаратной конфигурации
своего места жительства. Появление сервера на базе лю-
бой UNIX-подобной операционной системы в сети с доме-
ном может пошатнуть всю идею самой централизации, ведь
UNIX – это другой мир, в котором все работает иначе, и к
любой проблеме уже неприменимы те решения, которые
существовали раньше.
В случае, если с появившейся в сети «белой вороной»
общается только системный администратор и информация,
с которой работают сервисы на этой машине, не требует
синхронизации с данными, находящимися в домене, то осо-
бенно изощренная настройка серверу не нужна. Здесь ра-
ботает правило, гласящее, что чем проще система, тем
меньше вероятность выхода ее из строя.
Но если вдруг неожиданно потребуется открыть доступ
на данный сервер доменным пользователям, то сразу же
возникнет масса проблем, которые быстро решить не уда-
ется:
! Заводить для каждого нового пользователя отдельную
учетную запись неудобно.
! Среднестатистический пользователь не в состоянии за-
помнить больше одного пароля.
! У сервисов на UNIX-машине могут возникать проблемы
с доступом к данным, находящимся под управлением
доменных политик.
! И еще какая-нибудь проблема, возникшая именно на ва-
шей системе, причем, скорее всего, не одна.
Выход из сложившейся ситуации один – необходимо
интегрировать UNIX-сервер в Windows-домен, чтобы он был
способен проводить аутентификацию пользователей на кон-
троллере домена. При должной настройке сразу исчезнут
все проблемы, возникавшие раньше с синхронизацией ин-
формации о пользователях, – теперь данные о них будут
едины и для Windows-систем, и для UNIX.
В данной статье я старался не привязываться к какой-
то конкретной реализации UNIX и попытался дать доста-
точно обобщенные советы в плане настроек. Дело в том,
что все перечисленные программные пакеты не являются
большой редкостью, официально поддерживаются на боль-

шом количестве *nix-систем и конфигурируются одинаково
на разных платформах.
Однако, как бы я ни старался сделать статью универсаль-
ной, хочу сразу заметить, что существовала базовая плат-
форма, на которой проводилось все тестирование перед
пересадкой на боевую конфигурацию: Gentoo Linux 2004.2,
и вся статья основана именно на ней.
Чтобы убедиться в том, что на вашей системе предло-
женное решение будет работать, требуется удостовериться,
что она поддерживает работу со следующими пакетами:
! Samba 3;
! Kerberos 5;
! Библиотеки PAM.
Если эти программные пакеты работают, то с большой
вероятностью можно сказать, что и предложенная связка
заработает, все зависит только от вас.
Алгоритм Kerberos
Информация, которую UNIX-машина получает от контрол-
лера домена, не должна ходить по сети в открытом виде,
так как она представляет большую ценность как для полу-
чателя, так и для возможных злоумышленников, поэтому
для поддержания должного уровня безопасности системы
в любом случае нужно использовать какую-либо криптог-
рафическую схему. В среде Windows ею является Kerberos5.
В реальной жизни два человека могут быть уверены в
личности друг друга при наличии паспортов у обоих. В дан-
ной ситуации человек доверяет не собеседнику, а паспорт-
ному столу, выдавшему документ. Это позволяет ему удос-
товериться в том, что он говорит именно с тем, кем являет-
ся собеседник на самом деле. В Kerberos используется та-
кая же схема: между сервером и клиентом есть посредник
под названием Центр распределения ключей (KDC, Key
Distribution Center), которому доверяют оба компьютера.
KDC также известны их секретные ключи. Криптографичес-
кий алгоритм, в котором они используются, является сим-
метричным, т.е. один и тот же ключ может быть использо-
ван как для кодирования, так и для декодирования сооб-
щения.
Для начала KDC и клиент должны удостовериться в лич-
ности друг друга:
! Клиент шлет KDC сообщение, в котором указывает свое
имя открытым текстом и зашифрованный секретным
ключом блок данных (аутентификатор) с двумя полями:
именем и текущим временем.
№11(24), ноябрь 2004
администрирование
! KDC расшифровывает этот блок известным ему клю-
чом клиента и сравнивает время, извлеченное из аутен-
тификатора, с локальным. Если разница между ними
составляет менее двух минут, то он может быть уверен
в том, что клиент знает секретный ключ.
! KDC отправляет клиенту точно такой же ответ с зашиф-
рованным блоком – своим именем и временем из пер-
вого запроса. Первое поле здесь необходимо для того,
чтобы избежать возможности простого копирования зло-
умышленником аутентификатора из запроса клиента.
! Клиент дешифрует полученный ответ, и если время из
него совпадает с отправленным, то и клиент, и KDC мо-
гут быть уверены в личности друг друга.
Далее, если клиент хочет обратиться к серверу:
! Клиент отправляет запрос на подключение к серверу.
! KDC отправляет ему в ответ сеансовый ключ (ключ, ко-
торый будет использоваться в дальнейшем для иденти-
фикации клиента) и блок данных под названием сеан-
совый мандат (session ticket), в составе которого есть
тот же сеансовый ключ для сервера и информация о
клиенте. Мандат шифруется секретным ключом серве-
ра, а все сообщение – секретным ключом клиента.
! Клиент извлекает из ответа сеансовый мандат и свою
копию сеансового ключа. При обращении к серверу он
отправляет ему сеансовый мандат, по-прежнему зашиф-
рованный секретным ключом сервера, и свой аутенти-
фикатор, зашифрованный сеансовым ключом.
! Сервер, получив сообщение клиента, извлекает из ман-
дата сеансовый ключ, которым расшифровывает аутен-
тификатор клиента. Если время, извлеченное из него,
соответствует текущему, то сервер может быть уверен
в личности клиента.
Для того чтобы клиент постоянно не использовал свой
секретный ключ для связи с Центром распределения клю-
33
 администрирование
чей, KDC выдает ему мандат на выдачу мандатов (ticket Тогда в переменной окружения HOSTNAME UNIX-маши-
granting ticket, TGT): ны должна находиться строчка «nix». В моем случае это
! Клиент посылает запрос KDC. потребовало исправления файла /etc/hostname.
! KDC отвечает специальным мандатом на самого себя, Не забудьте проверить, видят ли машины DNS-имена
в составе которого, как и в случае обычного сеансового друг друга и нет ли проблем с firewall.
мандата, находятся две копии сеансового ключа, одна Теперь можно приступить к созданию конфигурацион-
из них зашифрована секретным ключом клиента, вто- ного файла для библиотек kerberos, находящегося по ад-
рая – KDC. ресу /etc/krb5.conf. Сам файл состоит из пяти секций, каж-
! Клиент расшифровывает сеансовый ключ, после чего дая из которых может включать в себя либо имена и значе-
для связи между ним и KDC используется именно он, а ния отдельных переменных, например:
секретный ключ клиента удаляется из памяти.
[section]
key = value
Теперь система связи между клиентом и сервером выг- boolean1 = true
лядит так: boolean2 = false
! Клиент извлекает из TGT сеансовый ключ для связи с
KDC и отправляет запрос на сеансовый мандат для свя- либо информацию, объединенную в структуру с определен-
зи с сервером и зашифрованные им TGT с собствен- ным именем:
ным аутентификатором.
! Сервер в случае успеха отвечает требуемым сеансовым [section]
struct = {
мандатом, сеансовый ключ из которого будет впослед- key1 = value1
ствии использован клиентом для связи с сервером. key2 = value2
...
}
Как видите, для нормальной работы этой системы аутен-
тификации обязательно требуется синхронизация време-
ни на всех ее элементах. В журнале «Системный админис-
тратор» №4 за 2004 год была подробная статья Михаила
Платова о настройке сервера времени «NTP – атомные часы
на каждом столе».

Настройка Kerberos
Для UNIX-систем существует две реализации kerberos5,
совместимых со стандартом: Heimdal и MIT. В настройке
они отличаются не очень сильно, но второй гораздо более
популярен, поэтому будем рассматривать именно его. Уч-
тите, что на старых версиях MIT Kerberos (меньших или рав-
ных 1.3.1) возникали проблемы с Windows Kerberos Service
на Win2003, поэтому рекомендую использовать последнюю
доступную на данный момент версию. Пример файла:
В качестве открыто указанного имени клиента в описы-
ваемой связке Kerberos+Samba+AD используется доменное [logging]
default = FILE:/var/log/krb5libs.log
имя машины. Но зачастую бывает так, что ее реальное DNS- kdc = FILE:/var/log/krb5kdc.log
имя не соответствует тому, кем она себя считает. Предпо- admin_server = FILE:/var/log/kadmind.log
ложим, что nslookup говорит нам следующее: [libdefaults]
default_realm = DOMAIN.RU
C:\>nslookup 192.168.1.14 dns_lookup_kdc = false
Server: dns.domain.ru dns_lookup_realm = false
Address: 192.168.1.10
[realms]
Name: nix.domain.ru DOMAIN.RU = {
Address: 192.168.1.14 kdc = controller.domain.ru

34

admin_server = controller.domain.ru
default_domain = domain.ru
} ! host/NIX$@DOMAIN.RU – строка, обозначающая имя ма-
[domain_realm]
.domain.ru = DOMAIN.RU
domain.ru = DOMAIN.RU
domain = DOMAIN.RU
DOMAIN = DOMAIN.RU
Следующим шагом создадим пользователя в Active
Directory, имя которого UNIX-машина будет использовать
для Kerberos-аутентификации себя. Для этого на контрол-
лере домена в меню «Пуск» откройте «Administrative Tools →
Active directory Users and Computers», выберите нужный кон-
тейнер и создайте там пользователя. В качестве парамет-
ров можно запретить ему менять пароль (галочка «User
cannot change password») и убрать необходимость его ме-
нять со временем (галочка «Password never expires»). До-
пустим, что вы создали пользователя с именем unixuser и
паролем SuperPass667.
Далее создаем файл, в который экспортируем секрет-
ный ключ: для этого в консоли cmd.exe на контроллере до-
мена требуется выполнить команду:
C:\>ktpass -princ host/NIX$@DOMAIN.RU -mapuser unixuser ↵
-pass SuperPass667 -out nix.keytab
№11(24), ноябрь 2004
администрирование
где:
шины в терминологии kerberos. Знак доллара является
признаком машинного аккаунта в Active Directory, и его
забывать не следует. DOMAIN.RU – домен, на контрол-
лере которого вы сейчас работаете;
! unixuser – имя создаваемой учетной записи;
! SuperPass667 – соответственно его пароль;
! nix.keytab – имя файла, в который производится экспорт.
Теперь требуется переместить полученный файл на
UNIX-машину любым возможным способом. Это можно сде-
лать через ftp/sftp или забросить через веб-сервер, как вам
больше нравится. В консоли UNIX запустите программу ktutil
и в ее командной строке импортируйте keytab-файл:
# ktutil
> rkt /root/nix.keytab
> list
slot KVNO Principal
---- ---- -------------------------------------
1 3 host/NIX$@DOMAIN.RU
> wkt /etc/krb5.keytab
> quit
где /root/nix.keytab – путь к импортируемому файлу, а /etc/
krb5.keytab – файл со всеми секретными ключами для дан-
ного клиента.
После всех этих длительных манипуляций можно про-
верить работу клиентской части kerberos, выполнив следу-
ющую команду:
# kinit DomainUser
где DomainUser – имя любого доменного пользователя. Если
после этого не появилось сообщений об ошибках, значит,
библиотека функционирует исправно. Однако помните, что
эта команда не использует секретный ключ из /etc/krb5.keytab,
а генерирует свой на основе введенного вами пароля, так
что если на этом этапе ошибок не появилось, то это еще не
означает, что они не возникнут в дальнейшем.
Настройка samba
При установке этого программного продукта проблем воз-
никнуть не должно, поэтому конкретных указаний по уста-
новке здесь дано не будет, и вы можете руководствоваться
своими собственными вкусами: собирать из исходников
вручную, использовать готовые бинарные пакеты или за-
пускать специализированные программы обновления ваше-
го дистрибутива.
После установки следует создать конфигурационный
файл для самбы по адресу /etc/samba/smb.conf. Его струк-
тура содержит два блока:
! описание глобальных настроек сервера;
! параметры для отдельных shares.
Сами настройки рассмотрим на примере:
# Èìÿ äîìåíà, ñ êîòîðûì òðåáóåòñÿ ðàáîòàòü
workgroup = DOMAIN
# Äîìåííîå èìÿ ìàøèíû, êîòîðîå äîëæíî ñîâïàäàòü ñ dns-èìåíåì
# è ïåðåìåííîé ñðåäû HOSTNAME
netbios name = NIX
35
администрирование
# Îïèñàíèå ñåðâåðà, âèäèìîå â «Ñåòåâîì îêðóæåíèè» # Âëàäåëåö ôàéëà ïðè çàïèñè â ïàïêó
server string = Unix Server force user = root
# Ãðóïïà, íàçíà÷àåìàÿ ôàéëó ïðè çàïèñè
# Ðàçäåëèòåëü íàçâàíèÿ äîìåíà è ó÷åòíîé çàïèñè.  Windows force group = apache
# ýòî çíàê «\», íî â ýòîì ñëó÷àå îí ìîæåò âûçâàòü ïðîáëåìû
# êàê ñèìâîë íà÷àëà escape-ïîñëåäîâàòåëüíîñòè, ïîýòîìó # Ìîæíî ëè çàéòè íà ïàïêó áåç ïàðîëÿ
# åãî ïîòðåáóåòñÿ çàìåíèòü. Ïî óìîë÷àíèþ èäåò çíàê «+», public = no
# íî «/» ïðèâû÷íåå
winbind separator = / # Ìîæíî ëè â íåå ïèñàòü
writable = yes
# Èñïîëüçîâàòü äîìåí ïî óìîë÷àíèþ. Âíåøíå áóäåò ïðîÿâëÿòüñÿ
# îòñóòñòâèåì äîìåííîãî ïðåôèêñà ïåðåä ó÷åòíîé çàïèñüþ # ßâëÿåòñÿ ëè ïàïêà ïðèíòåðîì
winbind use default domain = yes printable = no
# Îáëàñòü èäåíòèôèêàòîðîâ ïîëüçîâàòåëåé, íà êîòîðóþ áóäóò # Ìàñêà ñîçäàâàåìûõ ôàéëîâ
# îòîáðàæàòüñÿ äîìåííûå àêêàóíòû create mask = 0640
idmap uid = 7000-10000
# Ïîëüçîâàòåëè, èìåþùèå ïîëíûé êîíòðîëü íàä ïàïêîé
# Îáëàñòü èäåíòèôèêàòîðîâ ãðóïï, íà êîòîðóþ áóäóò admin users = @"DOMAIN/Domain Admins"
# îòîáðàæàòüñÿ äîìåííûå ãðóïïû
idmap gid = 7000-10000
На следующем шаге потребуется проверить, не оста-
# Àâòîìàòè÷åñêè íóìåðîâàòü ïîëüçîâàòåëåé è ãðóïïû лось ли в Active Directory записей для подопытной машины.
winbind enum users = yes
winbind enum groups = yes Для этого просмотрите ветку Computers.
# Øàáëîí äîìàøíåãî êàòàëîãà äëÿ äîìåííûõ ïîëüçîâàòåëåé.
После этого включаем UNIX-машину в домен, исполнив
# Âïîñëåäñòâèè áóäåò ñîçäàâàòüñÿ àâòîìàòè÷åñêè на ней команду:
template homedir = /home/DOMAIN/%U

# Øàáëîí êîìàíäíîãî èíòåðïðåòàòîðà äëÿ äîìåííûõ ïîëüçîâàòåëåé # net ads join -U DomainAdministrator
template shell = /bin/bash

# Ðåæèì áåçîïàñíîñòè. Â ðåæèìå ads äëÿ àóòåíòèôèêàöèè
# samba èñïîëüçóåò èñêëþ÷èòåëüíî Active Directory,
# íå îáðàùàÿ âíèìàíèÿ íà ëîêàëüíûå àêêàóíòû
security = ads
# Øèôðîâàòü ëè ïàðîëè. Ïî óìîë÷àíèþ êîíòðîëëåð äîìåíà
# íå ðàáîòàåò ñ îòêðûòûìè ïàðîëÿìè.
encrypt passwords = yes
# Ðåàëì Kerberos, èñïîëüçóåìûé äëÿ àóòåíòèôèêàöèè
realm = DOMAIN.RU
# Ïàðàìåòð, âêëþ÷àþùèé ïîääåðæêó âûáîðà àëãîðèòìîâ øèôðàöèè
# â ïðîöåññå ðàáîòû. Íåîáõîäèìîñòü èñïîëüçîâàíèÿ çàâèñèò
# îò íàñòðîåê êîíòðîëëåðà äîìåíà. Íà Win2003 âêëþ÷åí
# ïî óìîë÷àíèþ
client use spnego = yes
# Àäðåñ êîíòðîëëåðà äîìåíà
password server = controller.domain.ru
# Øàáëîí èìåí ôàéëîâ ëîãîâ, ãäå %m – èìÿ ìàøèíû
log file = /var/log/samba3/%m.log
# Óðîâåíü ïîäðîáíîñòè ëîãîâ. Íà ïåðâûõ ïîðàõ æåëàòåëüíî
# ïîäíÿòü ýòî çíà÷åíèå äî 4, ÷òî ïîçâîëèò äîñòàòî÷íî òî÷íî
# äèàãíîñòèðîâàòü ïðîáëåìó.
log level = 2
Если в результате исполнения этой команды вы увиди-
те строчку «Joined domain DOMAIN.», то появился повод
открывать шампанское. Но в большинстве случаев на этом
шаге всплывают все ошибки, допущенные на предыдущих
этапах.
Вот несколько советов:
! Проверьте, нет ли сильного расхождения во времени у
UNIX-машины и контроллера домена.
! Правильно ли был создан keytab-файл (тот ли пароль,
совпадает ли имя машины, нет ли различий между зна-
чением переменной HOSTNAME и доменным именем).
! Нет ли в Active Directory уже существующего машинно-
го аккаунта для подопытной UNIX-машины.
! Что остается в файлах протоколов самбы и системных
логах контроллера домена.

# Ìàêñèìàëüíûé ðàçìåð ëîã-ôàéëîâ. 0 – íåîãðàíè÷åíî.

max log size = 0

# Ñïèñîê ñåòåâûõ èíòåðôåéñîâ, ñ êîòîðûìè áóäåò ðàáîòàòü

# äåìîí
interfaces = 192.168.1.14
# Íå òðîãàòü îñòàëüíûå ñåòåâûå èíòåðôåéñû
bind interfaces only = yes
# Ïðèìåð ïàïêè
# Íàçâàíèå
[html]
# Ñïèñîê ïîëüçîâàòåëåé, ó êîòîðûõ åñòü ïðàâî èñïîëüçîâàòü
# ýòó ïàïêó.  äàííîì ñëó÷àå ýòî âñå äîìåííûå ïîëüçîâàòåëè.
# Çíàê @ îáîçíà÷àåò ãðóïïó.
valid users = @"DOMAIN/Domain Users"
# Ïóòü, íà êîòîðûé ññûëàåòñÿ ñàìà ïàïêà
path = /var/www/htdocs

# ×óâñòâèòåëüíà ëè ïàïêà ê ðåãèñòðó áóêâ

case sensitive = no

# Áóäåò ëè âèäíà ïàïêà â «Ñåòåâîì îêðóæåíèè»

Если все прошло успешно, то самое время осуществить
browseable = yes первый запуск самбы. Как показывает практика, лучше для

36

этого использовать стартовые скрипты системы в /etc/init.d,
чтобы не изобретать велосипед при загрузке.
Для корректной работы всей системы должны старто-
вать следующие демоны:
! smbd
! nmbd
! winbindd
Настройка запуска именно трех демонов вместо обыч-
ных двух (smbd и nmbd) зависит от дистрибутива, в Gentoo
для этого следует отредактировать файл /etc/conf.d/samba,
руководствуясь находящимися в нем комментариями. Так-
же можно включить режим отладки, добавив в опции за-
пуска всех трех демонов ключ -D с параметром, который
определяет количество отладочной информации, записы-
ваемой в логи. Больше 4 его делать не стоит, так как в
противном случае логи станут очень быстро разрастать-
ся. В случае, если что-то не запустилось, то читаем лог
снова, исправляем выявленные ошибки, и запускаем –
этот цикл придется повторять до тех пор, пока все не прой-
дет успешно.
Теперь можно проверить, нормально ли работают рас-
шаренные папки, зайдя по адресу file://nix.domain.ru с лю-
бой Windows-машины, являющейся членом домена.
Аутентификация в системе
На данный момент с аутентификацией в Active Directory
полноценно работает только самба, остальные сервисы на
подопытной UNIX-машине о ней не ведают.
Проблема управления большим количеством аккаунтов
возникла значительно раньше появления AD, да и, пожа-
луй, появления Windows-систем в целом. Во времена рас-
света UNIX возникла идея централизованного хранения
информации о пользователях, чтобы избежать ее дубли-
администрирование
работы с доменными аккаунтами, следует привести этот
файл к следующему виду:
passwd: files winbind
group: files winbind
shadow: files
Теперь пора проверить работоспособность всей настра-
иваемой системы – умеет ли подопытная машина полно-
ценно работать с доменными аккаунтами (перед выполне-
нием следующей команды не помешает на всякий случай
перезапустить samba):
# getent passwd
Если на экране консоли, как в «Матрице», замелькала
разная информация, по структуре своей напоминающая
файл /etc/passwd, причем среди записей попадаются до-
менные аккаунты, то проверка прошла успешно, с этих пор
компьютер не знает различий между доменными и локаль-
ными пользователями. Но есть одно небольшое но.
Дело в том, что на многих UNIX-системах для аутенти-
фикации пользователей и назначения им идентификаторов
используется библиотека PAM (Pluggable Authentication
Modules). По умолчанию она настроена так, что проходить
аутентификацию имеют право только локальные пользова-
тели, да и то не все и не везде. Как видно из названия,
библиотека построена по модульному принципу, причем за
каждым сервисом, требующим аутентификации, можно зак-
реплять свой список используемых модулей.
Настройка PAM специфична для каждого дистрибутива
Linux, не говоря уже о BSD и прочих реализациях UNIX, так
что предлагать готовое решение для чего-то одного было
бы несправедливо. По этой причине рассмотрим основы
конфигурации, а конкретное их применение ка�