024 Системный Администратор 11 2004 by Dmitry Ushakov

№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

Павел Закляков Андрей Бешков tigrisha@sysadmins.ru

andrew@markelov.net

pheonix@sysattack.com

Виртуальные войны

platov@cs.vsu.ru

Антон Борисов a.borisov@tesv.tmb.ru

Обзор эмулятора mips64emul Александр Байрак x01mer@pisem.net

ОБРАЗОВАНИЕ Class Server 3.0. – новое решение Microsoft в области образования Андрей Филиппович fil@ics.bmstu.ru

Крис Касперски grinder@ua.fm

Танцуем самбу Роман Гребенников grv@cs.vsu.ru

val@linuxcenter.ru

Maxim_kostyshin@mail.ru

Разработка сценария регистрации пользователей в сети Часть 1 Иван Коробко

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

Использование программы nLite Максим Костышин

kk@sendmail.ru

ikorobko@prosv.ru

Заметки о Linare Валентин Синицын

Файловая система NTFS извне и изнутри Часть 1

Лейся песня, или Сервер потокового аудио своими руками Сергей Яремчук

ПРОГРАММИРОВАНИЕ 16 Создаем кроссплатформенное приложение на основе FLTK

Сравнительное тестирование VMWare Workstation и Cooperative Linux.

Михаил Платов

Владимир Мешков ubob@mail.ru

Пакетный фильтр OpenBSD Денис Назаров

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

Использование бездисковых Linux-станций с загрузкой по сети Андрей Маркелов

amdk7@mail.ru

stepan-razin@newmail.ru

42 BUGTRAQ

90 63

БЕЗОПАСНОСТЬ Иммунная система для компьютера Сергей Яремчук grinder@ua.fm

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

48 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. На данный момент идут работы по портированию netsnmp на Windows. В результате уже сейчас можно сказать,

что программа работает на 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. Обычно она по умолчанию входит во многие

администрирование дистрибутивы. В действии эта программа выглядит следующим образом.

репили за ним право передавать SNMP-команды только с помощью версии протокола 2с. Следующей строкой создали вид на определенную область SNMP-дерева. В данном случае с помощью запросов можно просматривать все, что лежит ниже .1 или .iso. Пользуясь этой опцией, можно ограничить дерево, доступное запросу до одной ветки или даже до единственного OID. И заключительной строкой указываем настройки безопасности для нашей группы MyROGroup. После этого не забываем перезапустить демон SNMP и проверить, как все работает. # snmpwalk –m ALL -c InK12345 -v2ñ penguin ↵ .iso.org.dod.internet.mgmt.mib-2.system

Для систем 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 none none

exact all

80 ↵

Стоит отметить, что опции rocommunity и rwcommunity – всего лишь оболочки вокруг более мощного набора команд VACM (Version-based Access Control Module), которым мы воспользовались ранее. Таким образом, мы сказали, что система, подвергаемая мониторингу, может принимать SNMP-запросы лишь от машины с адресом 10.10.21.55, которая является сервером мониторинга, и привязали этот адрес к внутреннему имени системы безопасности «nagios». Затем разрешили этому имени символизировать группу MyROGroup, а заодно зак-

Обратите внимание на опцию –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); }

Вставляем после него вот такие строки: else if ( strcmp (proto, "2c") == 0 ) { ↵ /* snmpv2c args */ asprintf(&proto, "%s", "2c"); asprintf(&authpriv, "%s%s", "-c ", community); }

Проводим перекомпиляцию, а затем и замену старого модуля новым. # make install

После этого команда с ключом -P 2c должна отработать

администрирование нормально. Вписываем в файл checkcommands.cfg описание команды check_snmp_oid, с помощью которой будем проводить мониторинг и вызывать модуль check_snmp. define command{ command_name check_snmp_oid command_line $USER1$/check_snmp -H $HOSTADDRESS$ ↵ -o $ARG1$ -C $ARG2$ -w $ARG3$ -c $ARG4$ ↵ -u $ARG5$ -l "" -P $ARG6$ }

Затем в файле hosts.cfg рассказываем о наших серверах. # Îïèñûâàåì øàáëîí õîñòà define host{ name notifications_enabled event_handler_enabled flap_detection_enabled process_perf_data retain_status_information retain_nonstatus_information max_check_attempts notification_interval notification_period notification_options register }

generic-host 1 1 1 1 1 1 10 120 24x7 d,u,r 0

define host{ use host_name alias address check_command }

generic-host Linux Standard Linux Server penguin check-host-alive

define host{ use host_name alias address check_command }

generic-host FreeBSD Standart FreeBSD Server reddaemon check-host-alive

И, конечно же, не забываем причислить их к группе хостов onix-servers, внеся следующие строки в файл host groups.cfg define hostgroup{ hostgroup_name alias contact_groups members }

Настройку оповещений и контактов пропускаем, так как эта тема обсуждалась ранее неоднократно. Самое время заняться описанием сервисов, за которыми мы будем следить.

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

1 1 onix-admins 0

Данный сервис показывает время работы системы с момента последней перезагрузки. Для этого используется OID .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0. Почти такого же эффекта можно добиться с помощью .iso.org.dod .internet.mgmt.mib-2.host.hrSystem.hrSystemUptime.0. Хотя тут стоит сделать маленькое примечание: второй OID показывает не время, прошедшее с последнего перезапуска системы, а момент последней инициализации SNMP. define service{ use generic-service host_name Linux service_description System Uptime is_volatile 0 check_period 24x7 check_command check_snmp_oid ↵ !.1.3.6.1.2.1.1.3.0!InK12345! ""! ""! ""!2c }

Следующим интересным для нас моментом будет совокупность сервисов, отображающих количество занятых блоков разделов /, home, и совокупный процент использованных блоков физической и своп-памяти. Для того чтобы понять, где находятся необходимые сведения, посмотрите ветку .iso.org.dod.internet.mgmt.mib-2.host.hrStorage.hrStorage Table. Принцип анализа ветви довольно прост. В hrStorage Index содержится список уникальных идентификаторов, описывающих каждое устройство. А hrStorageType в свою очередь хранит типы устройств. hrStorageDesc заполнен текстовыми описаниями объектов. Для моей системы это выглядит так: hrStorageDescr.2 hrStorageDescr.3 hrStorageDescr.4 hrStorageDescr.5 hrStorageDescr.6

= = = = =

STRING: STRING: STRING: STRING: STRING:

Real Memory Swap Space / /home /proc/bus/usb

В hrStorageAllocationUnits указан размер блока для каждого из устройств:

onix-servers Onix Servers onix-admins Linux, FreeBSD

# Îïèñûâàåì øàáëîí ñåðâèñà define service{ name active_checks_enabled passive_checks_enabled parallelize_check obsess_over_service check_freshness notifications_enabled event_handler_enabled flap_detection_enabled process_perf_data retain_status_information retain_nonstatus_information notification_interval notification_period notification_options max_check_attempts

}

normal_check_interval retry_check_interval contact_groups register

generic-service 1 1 1 1 0 1 1 1 1 1 1 120 24x7 w,u,c,r 3

hrStorageAllocationUnits.2 hrStorageAllocationUnits.3 hrStorageAllocationUnits.4 hrStorageAllocationUnits.5 hrStorageAllocationUnits.6

= = = = =

INTEGER: INTEGER: INTEGER: INTEGER: INTEGER:

1024 1024 4096 4096 1024

Bytes Bytes Bytes Bytes Bytes

Ну а hrStorageSize указывает, сколько блоков в каждом устройстве. hrStorageSize.2 hrStorageSize.3 hrStorageSize.4 hrStorageSize.5 hrStorageSize.6

= = = = =

INTEGER: INTEGER: INTEGER: INTEGER: INTEGER:

54156 216836 273087 196780 0

И наконец, самое интересное. Как вы уже, наверное, догадались, hrStorageUsed содержит данные о том, сколько блоков занято на каждом из устройств. hrStorageUsed.2 hrStorageUsed.3 hrStorageUsed.4 hrStorageUsed.5 hrStorageUsed.6

= = = = =

INTEGER: INTEGER: INTEGER: INTEGER: INTEGER:

52564 11220 235014 8755 0

администрирование Теперь дело за малым: высчитать, сколько блоков соответствуют заполнению устройств на 80% и 90%. И затем создать на основе этих данных правила проверки. В качестве примера приведем описание сервиса, показывающего, как обстоят дела с заполнением корневого раздела. define service{ use generic-service host_name Linux service_description Space on / is_volatile 0 check_period 24x7 check_command check_snmp_oid ↵ !.1.3.6.1.2.1.25.2.3.1.6.4! ↵ InK12345!218470!245778!blocks!2c }

Надеюсь, что на основе приведенного примера вы сможете создать описание всех необходимых сервисов. В мире UNIX-систем большинство задач можно решить разными способами. Сейчас вы в этом убедитесь. Давайте в очередной раз расширим функциональность демона snmpd, внеся в snmpd.conf следующие строчки. disk / 180000 disk /home 760000

Таким образом, мы указываем, что хотим следить за свободным местом на разделах / и home еще одним способом. Вышеуказанные строки говорят демону snmp, что мы хотим установить флаг ошибки в случае, если на разделе / занято 180 Мб, а /home заполнен на 760 Мб. Впрочем, ничего страшного не случится, если ограничения не устанавливать вовсе. Кстати, стоит отметить, что ограничение можно описывать не только в килобайтах, но и в процентах. Теперь интересующие нас данные находятся внутри ветви .iso.org.dod.internet.private.enterprises.ucdavis.dskTable.dskEntry. Принцип построения таблицы стандартен. Идентификатор dskPath содержит данные об именах разделов. dskPath.1 = STRING: / dskPath.2 = STRING: /home

dskDevice устанавливает соответствие между разделами и физическими устройствами диска. dskDevice.1 = STRING: /dev/sda1 dskDevice.2 = STRING: /dev/sda6

В dskMinimum dskMinPercent содержатся пороговые значения для поднятия флага ошибки. Соответственно, dskTotal, dskAvail, dskUsed отображают общее, доступное и задействованное пространство дисков. Следующая ветвь, называемая dskPercent, для нас наиболее интересна, так как содержит величину заполнения дисков в процентах. dskPercent.1 = INTEGER: 86 dskPercent.2 = INTEGER: 4

Именно ее мы и будем контролировать. Конечно, можно контролировать состояние ветвей dskErrorFlag и dskErrorMsg. dskErrorFlag.1 = INTEGER: 1 dskErrorFlag.2 = INTEGER: 0 dskErrorMsg.1 = STRING: /: less than 80% free (= 86%) dskErrorMsg.2 = STRING:

Но это не очень удобно, так как в этом случае у системы есть лишь два состояния – «нормальное» и «критическое». Соответственно, нет промежуточного перехода в виде состояния «предупреждение». Разобравшись с теорией, давайте создадим сервис, который будет контролировать состояние раздела / новым способом. define service{ use generic-service host_name Linux service_description Space on / check 2 is_volatile 0 check_period 24x7 check_command check_snmp_oid ↵ !.1.3.6.1.4.1.2021.9.1.9.1!InK12345!80!90!% }

Думаю, создать сервисы, выполняющие проверку остальных разделов, вы сможете сами. Идем дальше. Если мы хотим следить за загрузкой процессора, добавляем в snmpd.conf вот это: load 12 20 30

Этой строкой мы говорим демону, что желаем видеть статистику нагрузки на процессор за последнюю минуту, за пять и пятнадцать минут. К сожалению, интервалы жестко закодированы, и изменить их невозможно. И, как обычно, указываем необязательные пороговые ограничения в 12%, 20% и 30%, при превышении которых snmpd будет устанавливать флаг ошибки. Смотрим ветку .iso.org.dod. internet.private.enterprises.ucdavis.laTable.laEntry и понимаем, что нам наиболее интересны подветви laLoad, laLoadInt, laLoadFloat. В этих подветках содержатся одни и те же данные, но с разным округлением. Соответственно сервис для проверки загрузки процессора за последнюю минуту будет выглядеть вот так: define service{ use generic-service host_name Linux service_description CPU Load 1 min is_volatile 0 check_period 24x7 check_command check_snmp_oid ↵ !.1.3.6.1.4.1.2021.10.1.5.1!InK12345!60!90!% }

Следующей интересной для нас особенностью является возможность запускать сторонние скрипты при получении того или иного SNMP-запроса. И опять добавляем в snmpd.conf новые строки: exec users /bin/sh /usr/bin/count_users.sh exec mailqueue /bin/sh /usr/bin/count_mail.sh

Затем создаем файлы count_users.sh count_mail.sh:, с их помощью мы будем считать количество пользователей, работающих на данный момент в системе, и размер почтовой очереди postfix. Содержимое файла count_users.sh: who | wc -l exit 0

Содержимое файла count_mail.sh:

администрирование mailq | tail -n 1 | cut -f5 -d " " exit 0

Теперь смотрим, что у нас находится внутри ветки .iso.org.dod.internet.private.enterprises.ucdavis.extTable.extEntry. extNames.1 = STRING: users extNames.2 = STRING: mailqueue extCommand.1 = STRING: /bin/sh /usr/bin /count_users.sh extCommand.2 = STRING: /bin/sh / usr/bin/count_mail.sh extResult.1 = INTEGER: 0 extResult.2 = INTEGER: 0 extOutput.1 = STRING: 1 extOutput.2 = STRING: 2 extErrFix.1 = INTEGER: 0 extErrFix.2 = INTEGER: 0 extErrFixCmd.1 = STRING: extErrFixCmd.2 = STRING:

Нас интересует extOutput, в которой находится первая строка из того, что скрипт выводит на экран, и extResult с кодом возврата скрипта, переданным командой exit. Судя по приведенному выше списку значений, у нас в системе находится один пользователь, а в почтовой очереди есть два письма. Сервисы для проверки результатов работы обоих скриптов будут выглядеть так: define service{ use generic-service host_name Linux service_description Users is_volatile 0 check_period 24x7 check_command check_snmp_oid ↵ !.1.3.6.1.4.1.2021.8.1.101.1!InK12345!20!30!users } define service{ use generic-service host_name Linux service_description Mail queue is_volatile 0 check_period 24x7 check_command check_snmp_oid ↵ !.1.3.6.1.4.1.2021.8.1.101.2!InK12345!40!80!messages }

Конечно, в реальном мире скрипты-проверки могут быть гораздо сложнее и возвращать с помощью команды exit коды, указывающие на те или иные проблемы в сети. В этом случае есть возможность с помощью добавочной опции execfix указывать на программу, запускаемую snmpd и отвечающую за попытки автоматического исправления ошибок, обнаруженных проверочным скриптом. К примеру, таким образом можно описать программу исправления аварийного положения с почтовой очередью.

echo "first line" echo "second line" exit 5

В результате осмотра ветви .1.3.6.1.4.1.2021.50 можно увидеть следующие данные: .1.3.6.1.4.1.2021.50.1.1 = INTEGER: 1 .1.3.6.1.4.1.2021.50.2.1 = STRING: "multi_line_test" .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 .1.3.6.1.4.1.2021.50.101.1 = STRING: "first line" .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 .1.3.6.1.4.1.2021.50.103.1 = ""

Как видите, и такой функционал нам вполне доступен. Следующая возможность, на которую хотелось бы обратить ваше внимание, – функция проверки размера файла. Итак, добавляем в snmpd.conf вот такую надпись: file /tmp/tinka.txt 12

тем самым указывая, что файл не должен быть более 12 Кб. Затем смотрим, что хранит в себе ветка .iso.org.dod.internet .private.enterprises.ucdavis.fileTable.fileEntry: fileIndex.1 = INTEGER: 1 fileName.1 = STRING: /tmp/tinka.txt fileSize.1 = INTEGER: 15 kB fileMax.1 = INTEGER: 12 kB fileErrorFlag.1 = INTEGER: true(1) fileErrorMsg.1 = STRING: /tmp/tinka.txt: ↵ size exceeds 12kb (= 15kb)

Написать соответствующий сервис, в общем-то, несложно, если мы хотим самостоятельно проверять размер файла. define service{ use generic-service host_name Linux service_description size of /tmp/tinka.txt is_volatile 0 check_period 24x7 check_command check_snmp_oid ↵ !.1.3.6.1.4.1.2021.15.1.3.1!InK12345!12!20!kbytes }

Но есть и другой путь: можно опереться на появление кода и сообщения об ошибке в fileErrorFlag и fileErrorMsg. И все же мне кажется, что это не очень удобно. Напоследок хотелось бы рассказать о возможности слежения за количеством процессов того или иного приложения, работающих в системе.

execfix mailqueue /bin/sh /usr/bin/repair_mailqueue.sh

Конечно, эта возможность опциональна, но упомянуть о ней все же стоило. Любопытный читатель может спросить, а что делать, если мой скрипт выводит несколько строк полезной информации, и мне нужно считать их все до единой. Я отвечу, что это не проблема. Нужно всего лишь добавить в snmpd.conf вот такую строку: exec .1.3.6.1.4.1.2021.50 multi_line_test /bin/sh ↵ /tmp/mytest.sh

И создать скрипт /tmp/mytest.sh следующего содержания.

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

proc httpd 3 6 proc automount 1 1 proc csserver 2

Этими строками мы указываем snmpd, что в системе должно быть от двух до четырех процессов httpd и только один automount. В то же время программа csserver вообще может быть не запущена, но если она все же работает, то процессов не должно быть более двух. Если же минимальный и максимальный пороги не указаны, то процессов может быть сколько угодно. Давайте посмотрим, что snmpd нам скажет в ответ на такие приказания. Для этого открываем ветвь .iso.org.dod.internet.private.enterprises.ucdavis.prTable.prEntry.

администрирование prIndex.1 = INTEGER: 1 prIndex.2 = INTEGER: 2 prIndex.3 = INTEGER: 3 prNames.1 = STRING: httpd 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 prMax.3 = INTEGER: 3 prCount.1 = INTEGER: 1 prCount.2 = INTEGER: 1 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: prErrFixCmd.3 = STRING:

Надеюсь, смысл приведенных данных всем ясен. Тут, как всегда, возможно два пути для слежения: самим контролировать значения из подветви prCount, либо опираться на код ошибки prErrorFlag и сообщение в prErrMessage. По аналогии с execfix можно использовать ключевое слово procfix для описания программы, запускаемой в случае, если с тем или иным процессом стряслось что-то неладное. Я думаю, что на основе примеров, приведенных выше, вы сможете легко самостоятельно написать определения нужных сервисов. Следующей интересной для нас веткой является .iso.org.dod.internet.private.enterprises.ucdavis.memory. В ней хранятся подробные данные о состоянии оперативной памяти. Для моей машины эта ветвь выглядит так: memIndex.0 = INTEGER: 0 memErrorName.0 = STRING: swap memTotalSwap.0 = INTEGER: 216836 memAvailSwap.0 = INTEGER: 209784 memTotalReal.0 = INTEGER: 54156 memAvailReal.0 = INTEGER: 9320 memTotalFree.0 = INTEGER: 219104 memMinimumSwap.0 = INTEGER: 16000 memShared.0 = INTEGER: 0 memBuffer.0 = INTEGER: 5728 memCached.0 = INTEGER: 13832 memSwapError.0 = INTEGER: 0 memSwapErrorMsg.0 = STRING:

Наибольший интерес вызывают OID memTotalSwap mem AvailSwap, означающие общий размер свопа и его свободную часть. Затем стоит обратить внимание на memTotalReal и memAvailReal, указывающие на размер физической памяти. Перспективнее всего следить за memAvailReal и memAvailSwap. Но тут есть определенные проблемы. Дело в том, что исчерпание физической памяти еще не означает для системы каких-то ужасных последствий, все ненужное в данный момент будет складироваться в своп. Поэтому выводить предупреждения по поводу того, что физическая память закончилась, не стоит. Сервис, следящей за этим компонентом системы, должен выглядеть так: define service{ use host_name service_description

generic-service Linux Physical memory Free

}

is_volatile 0 check_period 24x7 check_command check_snmp_oid ↵ !.1.3.6.1.4.1.2021.4.6.0!InK12345!""!""!kbytes!2c

И соответственно мониторинг заполнения свопа можно реализовать так же. Но это решение, на мой взгляд, не очень изящно. Можно сделать гораздо лучше. Давайте будем следить за показателем memTotalFree, который показывает общее количество свободной памяти системы. Это весьма удобно, так как он равен сумме memAvailReal и memAvailSwap. Тут возникает некоторая проблема с нетривиальностью проверки. Обычно ситуация обстоит так, что чем больше проверяемая величина, тем ближе мы к критическому порогу, но сейчас все наоборот. Необходимо сказать модулю, что, чем больше памяти нам доступно, тем лучше. Поэтому сервис будет выглядеть так: define service{ use generic-service host_name Linux service_description Total memory Free is_volatile 0 check_period 24x7 check_command check_snmp_oid ↵ !.1.3.6.1.4.1.2021.4.11.0!InK12345!20000:10000 ↵ !9999:0!kbytes!2c }

Таким образом, сигнал «предупреждение» будет отправляться, если свободной памяти останется от двадцати до десяти тысяч байт, а критические оповещения появятся, как только планка опустится еще ниже. Также неплохо было бы следить за сетевыми интерфейсами с помощью ветки .iso.org.dod.internet.mgmt.mib-2. interfaces.ifTable.ifEntry. Думаю, что примеров, приведенных в статье, достаточно, чтобы сделать это самостоятельно. Разобравшись с проверками сервисов, работающих через snmp 2c, давайте посмотрим, как выполнить все то же самое с помощью третьей версии протокола. Зачем нам это нужно? Все очень просто: с точки зрения безопасности snmp 2с существенно лучше, чем версия 1, но, несмотря на это, в ней все же есть недостатки. Дело в том, что при ее использовании строки сообществ передаются по сети в открытом виде. Думаю, это не то, что нам хотелось бы получить. Изумленный читатель может сказать: «Давайте совсем откажемся от использования 2с». К сожалению, такой идеалистический подход не всегда возможно воплотить в жизнь. Иногда приходится использовать именно 2с, потому что не во всем имеющемся оборудовании есть поддержка третьей версии. К тому же, настройка snmpd для работы с третьей версией snmp – дело весьма нетривиальное. Ниже я расскажу как этого добиться «малой кровью». Итак, приступим. В основе идеологии безопасности для третьей версии лежит понятие модуля безопасности пользователей USM (User-based Security Module). Он отвечает за хранение списка пользователей и их атрибутов. Соответственно каждый пользователь обозначается уникальным именем в терминах snmp, оно называется securityName. К нему привязываются протокол аутентификации и ключ аутентификации, соответственно, authProtocol и authKey. Вдобавок к этому существует протокол шифрования privProtocol и ключ шифрования privKey. Стоит отметить, что authKey и

администрирование 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

all

none

Затем перезапускаем 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

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 следующие строки:

Или их аналог с расширенным описанием VACM: group MyRWGroup usm nagios group MyROGroup usm nagios group MyRWGroup usm initial access MyRWGroup "" any noauth exact all createUser initial MD5 t2inKES10er DES

Затем удаляем из snmpd.conf все упоминания о пользователей initial, а также все строки с MyRWGroup и rwuser. Тем самым мы лишили пользователя initial всех прав и отобрали у пользователя nagios возможность внесения изменений в данные snmp. Не забываем перезапустить демона snmpd, чтобы новые настройки вступили в силу. На сервере мониторинга для проверки выполняем команду:

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

администрирование

ИСПОЛЬЗОВАНИЕ БЕЗДИСКОВЫХ LINUX-СТАНЦИЙ С ЗАГРУЗКОЙ ПО СЕТИ

АНДРЕЙ МАРКЕЛОВ Постановка задачи Работа сотрудника отдела автоматизации – это постоянная борьба с проблемами и решение задач, которые попеременно подкидывают пользователи, разработчики эксплуатируемого программного обеспечения и руководство организации. И если два первых направления работы – это просто «борьба за живучесть корабля», то последнее, как правило, – поступательное движение вперед. Как раз в ходе решения одной из таких задач и появилась на свет данная статья. Итак, перед отделом автоматизации была поставлена задача в короткие сроки ввести в строй два новых удаленных офиса, каждый численностью в пять-десять человек. Оба офиса и «голову» связали посредством технологий VPN в одну сеть. Минимальная ширина канала между тремя точками составила 256 Кбит, что вполне удовлетворило наши потребности. В каждом из офисов был развернут дополнительный контроллер домена Windows 2000, а для минимизации трафика домен разделили на несколько сайтов. Все вышеописанное является стандартным решением, и здесь я не ожидал никаких сюрпризов. Главным вопросом для нас было, как поведет себя основной инструмент работы сотрудников организации – комплексная система автоматизации, при работе с которой и в пределах одной площадки хватало проблем. Изначально ориентированная на Novell/BTRIVE 6.15 после миграции сети на Windows, она работала под Windows/ Pervasive.SQL 7. После недели тестирования этого основного бизнес-приложения организации, оказалось, что разработчик и вовсе не оставил нам выбора, так как использование встроенного терминального режима автоматизированной системы по ряду причин нас не устроило. Опять же, из-за особенностей функционирования в качестве терминального сервера была выбрана платформа Microsoft Windows Server. Тестирование же решений компании Citrix мы не проводили, так как работа с «родными» терминальными службами Windows нас вполне удовлетворила, а использование надстроек только увеличивает стоимость всей системы.

Когда с серверной частью все определилось, встал вопрос по клиентской составляющей системы. В первую очередь хотелось бы снизить необходимость в администрировании пользовательских машин, так как постоянное присутствие системного администратора на удаленных площадках не планировалось. Кроме того, желательным представлялось уменьшить стоимость решения, которая возросла из-за необходимости покупки терминальных лицензий. Также необходимо было учесть намерение разместить в офисах устаревшие компьютеры класса 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-диска. К сожалению, отсутствует поддержка USBflash; ! работа на ПК класса 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-сервере. Постарайтесь избежать конфликтов между главным файлом настроек и специфическим к группе или конкрет-

администрирование ной станции. Кроме того, можно объединять одним конфигурационным файлом целые группы IP- и MAC-адресов. Это делается при помощи файла thinstation.hosts, имеющего следующий формат: # HOST ws-oper1 ws-oper2 ws-oper3

MAC 0002B3655065 0002B3651075 0002B365A021

GROUPS COMMENTS hi_res # Îïåðàöèîíèñò ¹1 hi_res # Îïåðàöèîíèñò ¹2 hi_res ssh_en # Îïåðàöèîíèñò ¹3

В данном примере предполагается, что имеются два файла thinstation.conf.group-hi_res и thinstation.conf.groupssh_en. Настройки, прописанные в первом файле, применяются ко всем трем станциям, а настройки из второго – только к компьютеру ws-oper3. То, как отображаются сессии терминальных клиентов в оснастке диспетчера терминальных служб, вы можете увидеть на рис. 2.

(16 bit color depth)" SESSION_0_TYPE=rdesktop SESSION_0_RDESKTOP_SERVER=192.168.0.1 SESSION_0_RDESKTOP_OPTIONS="-u Administrator ↵ -p password -a 16" SESSION_1_TITLE="VNC server" SESSION_1_TYPE=vncviewer SESSION_1_VNCVIEWER_SERVER=192.168.0.2 SESSION_2_TITLE="Telnet server" SESSION_2_TYPE=telnet SESSION_2_TELNET_SERVER=192.168.0.3 SESSION_3_TITLE="SSH server" SESSION_3_TYPE=ssh SESSION_3_SSH_SERVER=192.168.0.4 # Îáùèå îïöèè # # Ðàñêëàäêà êëàâèàòóðû. Â ñëó÷àå ðàáîòû ñ rdesktop îíà # ðîëè íå èãðàåò KEYBOARD_MAP=en_us # Îïöèè XServer # 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 SESSION_0_TITLE="Windows 2003 terminal server ↵

Ðèñóíîê 4. Ñàìîñòîÿòåëüíîå ïîñòðîåíèå îáðàçà ÷åðåç âåáèíòåðôåéñ TS-O-Matic

администрирование

ПАКЕТНЫЙ ФИЛЬТР 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, которая заставит ядро включить фильтр с пустыми настройками и без перезагрузки системы.

резервированные слова (pass, block, in, out и т. д.). Привыкайте сразу использовать макросы, это хороший стиль. Следование ему в дальнейшем позволит избежать многих проблем с пониманием работы и настройки фильтра.

Таблицы Именные структуры, хранящие адреса хостов и сетей. Использование таблиц предпочтительнее использования макросов в тех случаях, когда необходимо описать огромное количество адресов. Для обработки правил, использующих таблицы, требуется меньше ресурсов, чем для обычных правил, решающих ту же задачу. Таблицы также могут использоваться совместно с scrub (нормализация трафика), rdr (перенаправление пакетов), nat (трансляция адресов). И могут быть определены следующими способами: ! Вручную. Постоянные таблицы могут быть созданы командой add или replace утилиты pfctl до или после загрузки набора правил. ! pf.conf – для описания таблиц в файле используется директива table. Таблица, инициализированная с пустым листом { }, будет очищена при загрузке. Таблицы бывают двух видов:

! persist – этот флаг заставляет ядро хранить содержаПриступаем к конфигурации фильтра. Что же он умеет? Практически все. PF является очень серьезной альтернативой таким монстрам, как Checkpoint Firewall и Sun Screen, однако полностью бесплатен. Итак, PF имеет следующие возможности.

ние таблицы, даже если она не используется никакими правилами. Если таблица не помечена таким флагом, то ядро уничтожит ее после того, как последнее правило, ссылающееся на нее, будет удалено. ! const – этот флаг запрещает изменять содержание таблицы после того, как она была создана.

Макросы Макрос – очень удобная вещь, которая может сократить и оптимизировать ваш конфигурационный файл и избавит вас от проблем с частым использованием обьемных и часто повторяющихся директив. Я практически не представляю себе написание конфигурационных файлов для 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

Например: 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>.

Предыдущие статьи автора: «Введение в OpenBSD», №6, 2003 г., «OpenBSD. Первые шаги», №8, 2003 г.

администрирование # 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. Например:

Это основные понятия о 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 – когда количество «состояний» достигает 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

данного порога, все timeout-значения обнуляются и удаляют за собой все «состояния».

администрирование Все вышеперечисленные значения могут быть определены как глобально, так и для каждого правила в отдельности, это затронет и «состояния», созданные такими правилами. Например: set set set set

timeout tcp.first 120 timeout tcp.established 86400 timeout { adaptive.start 6000, adaptive.end 12000 } limit states 10000

Как только таблица будет содержать 9000 state, значения timeout снизятся до 50% (tcp.first 60, tcp.established 43200). Манипуляция данными значениями позволяет очень тонко настроить работу вашего фильтра в тех или иных ситуациях. Это полезно для больших сетей или сетей, через которые проходят огромные обьемы трафика. set loginterface – опция, которая позволяет указать, для какого интерфейса вы будете получать статистику по команде. Например, у меня статистика выглядит так: # pfctl -s i Status: Enabled for 0 days 04:16:28

Debug: Urgent

Hostid: 0xd5f48ad7 Interface Stats for em1 Bytes In Bytes Out Packets In Passed Blocked Packets Out Passed Blocked State Table current entries searches inserts removals Counters match bad-offset fragment short normalize memory bad-timestamp

IPv4 219620287 62229416

IPv6 72 352

759343 1273

0 1

807867 3

2 3

Total 344 3286659 37555 37211

Rate 213.6/s 2.4/s 2.4/s

182069 0 0 0 0 0 0

11.8/s 0.0/s 0.0/s 0.0/s 0.0/s 0.0/s 0.0/s

Идем дальше: set limit – позволяет установить жесткое ограничение на количество областей в памяти с фиксированным размером, используемых пакетным фильтром. Например: set limit states 20000

устанавливает максимальное значение для количества элементов, используемых для «состояний». set limit frags 20000

устанавливает максимальное значение для количества элементов, используемых для «fragment reassembly», генерируется при помощи scrub. set limit scr-nodes 2000

число IP-адресов, для которых будут создаваться «состояния». Используется опять же для тонкой настройки фильтра, генерируется sticky-address и source-track опциями в правилах. Наконец, все это можно обьединить в одну строчку: set limit { states 20000, frags 20000, src-nodes 2000 }

set optimization – опция, которая позволяет оптимизировать работу вашего фильтра для сетей следующего типа: ! normal – обычная сеть, подходит для большинства сетей. ! high-latency – соединение с большими обьемами трафика (например, спутниковое). ! satellite – синоним для high-latency. ! aggressive – аргессивный режим, позволяет очень сильно уменьшить использование памяти, однако ценой сбрасывания соединений, находящихся в состоянии idle, работает быстрее, чем обычная. ! conservative – обратное от aggressive. Соотвественно грузим больше – живем дольше. Я предпочитаю использовать на всех довольно загруженных серверах (порядка 150 Гб трафика в день на каждом) режим aggressive, в то время как в обычных сетях, конечно же, я использую normal. Вы спросите, а зачем это надо? Зачем нужны те лимиты и тайм-ауты, которые я описывал выше? Ответ очевиден, PF может быть настроен так тонко, как не каждый пакетный фильтр, существующий ныне. Порой стандартных уровней оптимизации либо «слишком мало», либо «очень много», вот и приходится играть с тайм-аутами и лимитами, чтобы достичь идеальной производительности и максимальной отдачи. set block-policy – определить, каким же будет ответ фильтра для действия block в правилах. ! drop – пакет просто отбрасывается. ! return – фильтр ответит пакетом с флагом RST для TCP или же пакетом ICMP UNREACHEBLE для UDP, и все остальные пакеты будут просто отброшены. set require-order – определить порядок обслуживания. По умолчанию фильтр пропускает пакет по следующей цепочке: Options → Normalization → Queueing → Translation → Filtering. То есть сначала применяются настройки для фильтра, потом нормализация трафика, затем распределение по очередям, дальше трансляция адреса и, наконец, сама фильтрация. Данная цепочка является идеальной с точки зрения разработчиков фильтра, но они оставляют вам возможность исправить ее на ваше усмотрение. set fingerprints – указать системе, где находится файл с определениями отпечатков (fingerprints) для различных операционных систем. Ну где вы еще видели пакетный фильтр, который умеет пропускать наружу или внутрь пакеты, приходящие от Linux, а от Windows 2003 отбрасывать? Мелочь, а очень приятно. Например: set fingerprints "/etc/pf.os.devel"

администрирование

! ! ! !

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 – любой адрес.

администрирование ! 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 – заменить адрес;

! ! ! !

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

There are three kinds of lies: lies, damned lies and benchmarks1

МИХАИЛ ПЛАТОВ В рассмотрении работы любых систем, в том числе и виртуальных машин, значительную роль играет производительность. Ведь для любой системы, работающей в реальных условиях, важна не только ее функциональность, но и общая скорость работы, в том числе и в сравнении с другими решениями, присутствующими на рынке. Для оценки производительности, как правило, используются пакеты, состоящие из различных тестов, измеряющих производительность всех основных компонентов системы. Тесты могут измерять как абсолютную производительность того или иного компонента (синтетические тесты), так и скорость работы определенной программы (тесты-приложения). Тесты первой категории позволяют измерить пиковую производительность системы, которая, скорее всего, никогда не будет достигнута при работе реальных программ. Тесты-приложения, напротив, показывают, насколько полно та или иная программа использует потенциал рассматриваемой системы. В данной статье эти и другие «азы тестирования» будут применены на практике. Речь пойдет о сравнительном тестировании VMWare и Cooperative Linux. Кроме того, их результаты будут также соотнесены с производительностью обычного Linux, работающего в монопольном режиме.

Методика тестирования Идея тестирования, в том числе и Linux, не нова. За все время своего существования Linux обзавелся огромным количеством тестов, измеряющих производительность не только различных компонентов системы, но и работающих в нем приложений. Некоторые из этих тестов уже де-факто стали стандартами тестирования, в то время как другие лишь завоевывают себе место под солнцем. Поэтому для того, чтобы в n-й раз не изобретать велосипед, разрабатывая пакеты тестов, специфичные для вир-

туальных машин, было принято решение использовать уже существующие и «проверенные» тестовые пакеты. В качестве основы для методики проведения тестов использовались 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.

«В компьютерном мире есть три вида лжи: ложь, наглая ложь и тесты производительности». (c) Бенжамин Дизраэли, Марк Твен и компьютерное сообщество.

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

администрирование Следует отметить, что ввиду архитектурных особенностей при тестах 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 тоже далека от совершенства. Однако, безусловно, этот вопрос требует дальнейшего изучения, которое выходит за рамки данной статьи.

С точки зрения производительности остальных компонентов ситуация неоднозначна. С одной стороны, 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, однако выигрыш является настолько несущественным, что вполне может быть списан на погрешности измерения.

а именно эмуляцией контроллера IDE чипсета Intel i440BX. С coLinux же ситуация обстоит несколько иначе: он не работает с устройствами напрямую (ядро собирается без поддержки шины PCI и соответственно без контроллера IDE). Диск эмулируется специальным драйвером блочных устройств, работающих с Windows-демоном coLinux. По этой причине было принято решение в пользу измерения производительности диска не низкоуровневыми утилитами (например, hdparm), а измерением скорости работы с файловой системой. Однако для того, чтобы уменьшить влияние файловой системы на результаты тестов, использовалась нежурналируемая (и соответственно более быстрая) файловая система ext2fs. При построении «виртуальной» системы можно использовать два основных подхода: ! создать образ root-файловой системы в файле на существующем ntfs- или fat-разделе; ! создать (или использовать уже существующий) ext2раздел и работать с ним напрямую. В первом случае на производительность дисковых операций в Linux накладывается дополнительное влияние файловой системы (скорость доступа, фрагментация и т. д.) и ее драйвера. Второй случай этих проблем лишен, поэтому производительность «виртуальных» систем на отдельном разделе должна быть выше. Итак, перейдем к первому тесту – последовательное чтение блока данных. В данном тесте с диска последовательно считывается файл размером 256 Мб (блоками по 4 Кб). Для имитирования ситуации многозадачности тест проводится для 1, 2, 4 и 8 потоков.

Дисковая подсистема Для тестирования дисковой подсистемы использовался второй жесткий диск, разбитый на два раздела. Первый раздел был отформатирован в файловую систему 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

Ðèñóíîê 3

Быстрее всех с диском работает «чистый» Linux, затем идут VMWare и coLinux, работающие с выделенным разделом. В случае одного потока производительность vmware выше coLinux, однако с увеличением количества потоков coLinux несколько вырывается вперед. Медленнее всего работают VMWare и coLinux, использующие образ root-файловой системы на существующем разделе, хотя VMWare все же показывает чуть более высокую производительность (см. рис .4). При произвольном чтении ситуация несколько меняется. Явно лидирует «чистый» Linux, все виртуальные машины показывают примерно одинаковую и достаточно низкую скорость.

администрирование

Ðèñóíîê 4

В следующем тесте измеряется скорость последовательной записи на диск.

Ðèñóíîê 5

«Чистый» Linux, как всегда, впереди. За ним идут coLinux и VMWare в различных конфигурациях дисковой подсистемы. С увеличением количества потоков производительность всех систем сравнивается. Тест произвольной записи:

Ðèñóíîê 7

Производительность TCP/IP Как VMWare, так и coLinux поддерживают различные типы организации взаимодействия между реальной и виртуальной машинами. Основными являются bridged и NAT (более подробное описание можно найти в статье [1]). Для получения более полного представления об обоих исследуемых виртуальных системах тестирование каждой их них проводилось как в режиме bridged, так и NAT. Отличительной особенностью «сетевых» тестов является то, что для измерения производительности всегда требуется «вторая сторона», выступающая при передаче в качестве партнера. Причем крайне желательно, чтобы такой партнер был заведомо быстрее, при этом он не будет являться узким местом и его производительность не окажет существенного влияния на производительность измеряемой системы. В роли такого партнера в данном тесте использовался заведомо более быстрый компьютер – Pentium-4 – 2.4 ГГц (сетевой интерфейс Intel PRO 100), также работающий под управлением Linux (дистрибутив Gentoo). В тестах использовался пакет ttcp, измеряющий производительность TCP- и UDP-передач. Тест запускался 5 раз, в качестве результата приводится среднее значение.

Ðèñóíîê 6

А вот и первая неожиданность: скорость записи у coLinux и VMWare оказалась больше, чем у «чистого» Linux. Причиной этому, скорее всего, является кэширование обращений к диску, производимое ОС Windows. Для проверки этой гипотезы проведем тест с помощью другой утилиты – bonnie++ (sequential output, per block, size 300 Мб) (см. рис. 7). Ситуация в целом такая же, хотя и имеются некие расхождения, причина которых, скорее всего, кроется в высокоуровневой природе тестов.

Ðèñóíîê 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 раза, на диаграмме приводится усредненное время компиляции (чем меньше, тем лучше):

Быстрее всех с задачей справился «чистый» 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-HOWTO3.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 рублей Доставка почтой БЕСПЛАТНО в любую точку России Ðèñóíîê 10

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

администрирование

ОБЗОР ЭМУЛЯТОРА 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. Берем с сайта разработчика последнюю версию про-

граммы. Я использовал версию 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 МГц. После запуска, без дополнительной настройки мы можем запустить Xwindows, выполнив команду 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 г.

администрирование

ЛЕЙСЯ ПЕСНЯ, ИЛИ СЕРВЕР ПОТОКОВОГО АУДИО СВОИМИ РУКАМИ Чтобы покончить с бардаком, нужно возглавить его самому. Если пользователи по утрам, вместо того чтобы работать, выходят в Интернет в поисках новостей, что подчас съедает большую долю трафика, то почему бы не организовать свою ленту новостей на корпоративном сайте, понемногу пользователи привыкнут, и нагрузка на внешний канал уменьшится. Но новости и прочая текстовая информация еще ничего по сравнению с гигабайтами музыки, видео и прочего материала, который хотят протащить в сеть через узкий канал. Можно организовать фильтрацию, установить лимиты, все это иногда помогает, но гигабайты информации, при этом часто одинаковой, все равно собираются на жестких дисках компьютера, затрудняя архивацию. Сегодня разберемся как создать сервер, который будет транслировать аудиопотоки. В настоящее время существует достаточно большое количество приложений, позволяющих организовать такую трансляцию. Написаны они на разных языках программирования, работающих под управлением разных операционных систем, отличающихся лицензией, поддерживаемыми форматами и прочими характеристиками. Самый большой список, который мне удалось найти, размещен на странице 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-подобных систем, гибок и легок в настройке, имеет толковую документацию, распространяется в исходных кодах.

Кто есть кто Механизм трансляции аудиопотоков имеет свои особенности, поэтому сначала разберемся, как это работает, и оп-

СЕРГЕЙ ЯРЕМЧУК

ределимся с терминами. Любой сервер аудиопотоков, будь то 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 и adminpassword содержат имя пользователя и пароль для администрирования сервера. Далее описываются параметры подключения источников информации (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-

администрирование playlist.xml вы найдете шаблон, используемый при трансляции из файлов, записанных в плейлист. Отличаются они только разделом input, в котором описывается источник информации. Все описывать тоже не буду, остановлюсь лишь на параметрах, требующих пояснения. Для запуска в качестве демона устанавливаем back ground в 1. <background>1</background>

Далее описываются параметры вывода логов, при первоначальной отладке установите consolelog в 1, при этом все ошибки будут выводиться на консоль. <consolelog>1</consolelog>

Секция stream описывает передаваемый поток. <stream> <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>

Для считывания входящей информации, например, с микрофона, или других устройств применяется другая конструкция. <input> <module>oss</module>

module может быть также alsa (device обычно plughw:0,0), stdinpcm (при считывании со стандартного входа, секции device не надо) и sun при работе Sun Solaris DSP.

name="rate">44100</param> name="channels">2</param> name="device">/dev/dsp</param> name="metadata">1</param> name="metadatafilename">test</param>

Далее следует большая секция instance, описывающая подключение к стримсерверу. При этом возможно задание нескольких параметров, что позволит отсылать информацию нескольким таким серверам или создавать несколько точек монтирования с разными параметрами на одном сервере. <instance>

Ниже определяем имя узла, порт и пароль, последний должен совпадать со значением в секциях source-password файла icecast.xml. <hostname> Çäåñü ïèøåì àäðåñ èëè èìÿ, êóäà îòïðàâëÿåì ïîòîê </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 Changed groupid to 65534. Changed userid to 65534.

И подаем информацию. # ices /usr/share/ices/ices-playlist.xml

администрирование Теперь, набрав в строке любимого проигрывателя:

то может выясниться, что такого каталога не существует, создайте его командой:

http://èìÿ_óçëà:8000/example.ogg mkdir

должны услышать музыку. На эту роль подходят как 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

/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

Вот и все. Как видите, создать свой сервер трансляции аудиопотоков не так уже и сложно. При внимательности на все про все у вас уйдет от силы час-два. Успехов.

администрирование

конкурсная статья

ТАНЦУЕМ САМБУ

РОМАН ГРЕБЕННИКОВ Любая операционная система имеет сильные и слабые стороны. В чем-то она получается удачнее других, в чем-то – нет, поэтому никогда нельзя однозначно расставить разные ОС по рангам. На таком «пьедестале почета» участники могут казаться идеальным решением для одной сферы применения, но в других областях на них вряд ли можно смотреть серьезно. Среди людей, вращающихся в IT-сфере, уже много лет идет религиозная война между сторонниками UNIX-подобных и Windows-систем. Это является неотъемлемой чертой человеческой натуры, которая выражается в бесконечном поиске идеала. Если же этот идеал вдруг находится, то закрываются глаза на все его отрицательные качества – ведь совершенству не положено их иметь. Несомненно, рациональнее всего беспристрастно смотреть на вещи и не бросаться в гущу сражений на вечную тему. Ведь если есть возможность использовать преимущества разных операционных систем в рамках одной сети, к чему нужны все эти религиозные предрассудки? Главным и основным качеством любого системного администратора по всеобщему признанию является чувство лени – стоит один раз правильно настроить систему, а дальше останется только пить чай, наблюдая за тем, как все работает без постороннего вмешательства. Шутка шуткой, но удобство работы очень часто влияет на результат в лучшую сторону. Как показывает практика, в первую очередь оно зависит от размера подконтрольной сети, причем чем больше компьютерная сеть, тем грамотнее следует продумывать ее внутреннее устройство в плане удобства последующего администрирования. В случае маленькой комнаты с дюжиной компьютеров при возникновении какой-нибудь проблемы вполне реально подойти и лично с ней разобраться или поменять требуемую настройку вручную на каждой машине, если есть такая необходимость. Но если компьютеров в сети далеко за сотню, а пользователей и того больше, то всех четырех рук системного администратора не хватит, с какой бы скоростью он не размахивал ими. В этом случае необходима мощная централизованная система управления и контроля за работой сети. Стандартным решением в случае большого количества пользователей и рабочих станций является объединение всех их в единый домен. Для этого, если верить статистике, чаще всего используются программные решения компании Microsoft. Понятие «домен» в последнее время стало неразрывно связано с сетями под управлением Windows.

Но не окнами едиными жив этот мир. Существует большое количество задач, работу которых по тем или иным причинам не доверяют этим операционным системам. Порой просто нет необходимости или возможности заводить какой-нибудь 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), в составе которого есть тот же сеансовый ключ для сервера и информация о клиенте. Мандат шифруется секретным ключом сервера, а все сообщение – секретным ключом клиента. ! Клиент извлекает из ответа сеансовый мандат и свою копию сеансового ключа. При обращении к серверу он отправляет ему сеансовый мандат, по-прежнему зашифрованный секретным ключом сервера, и свой аутентификатор, зашифрованный сеансовым ключом. ! Сервер, получив сообщение клиента, извлекает из мандата сеансовый ключ, которым расшифровывает аутентификатор клиента. Если время, извлеченное из него, соответствует текущему, то сервер может быть уверен в личности клиента. Для того чтобы клиент постоянно не использовал свой секретный ключ для связи с Центром распределения клю-

администрирование чей, KDC выдает ему мандат на выдачу мандатов (ticket granting ticket, TGT): ! Клиент посылает запрос KDC. ! KDC отвечает специальным мандатом на самого себя, в составе которого, как и в случае обычного сеансового мандата, находятся две копии сеансового ключа, одна из них зашифрована секретным ключом клиента, вторая – KDC. ! Клиент расшифровывает сеансовый ключ, после чего для связи между ним и KDC используется именно он, а секретный ключ клиента удаляется из памяти. Теперь система связи между клиентом и сервером выглядит так: ! Клиент извлекает из TGT сеансовый ключ для связи с KDC и отправляет запрос на сеансовый мандат для связи с сервером и зашифрованные им TGT с собственным аутентификатором. ! Сервер в случае успеха отвечает требуемым сеансовым мандатом, сеансовый ключ из которого будет впоследствии использован клиентом для связи с сервером.

Тогда в переменной окружения HOSTNAME UNIX-машины должна находиться строчка «nix». В моем случае это потребовало исправления файла /etc/hostname. Не забудьте проверить, видят ли машины DNS-имена друг друга и нет ли проблем с firewall. Теперь можно приступить к созданию конфигурационного файла для библиотек kerberos, находящегося по адресу /etc/krb5.conf. Сам файл состоит из пяти секций, каждая из которых может включать в себя либо имена и значения отдельных переменных, например: [section] key = value boolean1 = true boolean2 = false

либо информацию, объединенную в структуру с определенным именем: [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 используется доменное имя машины. Но зачастую бывает так, что ее реальное DNSимя не соответствует тому, кем она себя считает. Предположим, что nslookup говорит нам следующее: C:\>nslookup 192.168.1.14 Server: dns.domain.ru Address: 192.168.1.10 Name: nix.domain.ru Address: 192.168.1.14

Пример файла: [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = DOMAIN.RU dns_lookup_kdc = false dns_lookup_realm = false [realms] DOMAIN.RU = { kdc = controller.domain.ru

администрирование }

admin_server = controller.domain.ru default_domain = 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.

где: ! host/NIX$@DOMAIN.RU – строка, обозначающая имя машины в терминологии 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. Далее создаем файл, в который экспортируем секретный ключ: для этого в консоли cmd.exe на контроллере домена требуется выполнить команду: C:\>ktpass -princ host/NIX$@DOMAIN.RU -mapuser unixuser ↵ -pass SuperPass667 -out nix.keytab

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

Сами настройки рассмотрим на примере: # Èìÿ äîìåíà, ñ êîòîðûì òðåáóåòñÿ ðàáîòàòü workgroup = DOMAIN # Äîìåííîå èìÿ ìàøèíû, êîòîðîå äîëæíî ñîâïàäàòü ñ dns-èìåíåì # è ïåðåìåííîé ñðåäû HOSTNAME netbios name = NIX

администрирование # Îïèñàíèå ñåðâåðà, âèäèìîå â «Ñåòåâîì îêðóæåíèè» server string = Unix Server # Ðàçäåëèòåëü íàçâàíèÿ äîìåíà è ó÷åòíîé çàïèñè. Â Windows # ýòî çíàê «\», íî â ýòîì ñëó÷àå îí ìîæåò âûçâàòü ïðîáëåìû # êàê ñèìâîë íà÷àëà escape-ïîñëåäîâàòåëüíîñòè, ïîýòîìó # åãî ïîòðåáóåòñÿ çàìåíèòü. Ïî óìîë÷àíèþ èäåò çíàê «+», # íî «/» ïðèâû÷íåå winbind separator = / # Èñïîëüçîâàòü äîìåí ïî óìîë÷àíèþ. Âíåøíå áóäåò ïðîÿâëÿòüñÿ # îòñóòñòâèåì äîìåííîãî ïðåôèêñà ïåðåä ó÷åòíîé çàïèñüþ winbind use default domain = yes # Îáëàñòü èäåíòèôèêàòîðîâ ïîëüçîâàòåëåé, íà êîòîðóþ áóäóò # îòîáðàæàòüñÿ äîìåííûå àêêàóíòû idmap uid = 7000-10000 # Îáëàñòü èäåíòèôèêàòîðîâ ãðóïï, íà êîòîðóþ áóäóò # îòîáðàæàòüñÿ äîìåííûå ãðóïïû idmap gid = 7000-10000 # Àâòîìàòè÷åñêè íóìåðîâàòü ïîëüçîâàòåëåé è ãðóïïû winbind enum users = yes winbind enum groups = yes # Øàáëîí äîìàøíåãî êàòàëîãà äëÿ äîìåííûõ ïîëüçîâàòåëåé. # Âïîñëåäñòâèè áóäåò ñîçäàâàòüñÿ àâòîìàòè÷åñêè template homedir = /home/DOMAIN/%U # Øàáëîí êîìàíäíîãî èíòåðïðåòàòîðà äëÿ äîìåííûõ ïîëüçîâàòåëåé 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

# Âëàäåëåö ôàéëà ïðè çàïèñè â ïàïêó force user = root # Ãðóïïà, íàçíà÷àåìàÿ ôàéëó ïðè çàïèñè force group = apache # Ìîæíî ëè çàéòè íà ïàïêó áåç ïàðîëÿ public = no # Ìîæíî ëè â íåå ïèñàòü writable = yes # ßâëÿåòñÿ ëè ïàïêà ïðèíòåðîì printable = no # Ìàñêà ñîçäàâàåìûõ ôàéëîâ create mask = 0640 # Ïîëüçîâàòåëè, èìåþùèå ïîëíûé êîíòðîëü íàä ïàïêîé admin users = @"DOMAIN/Domain Admins"

На следующем шаге потребуется проверить, не осталось ли в Active Directory записей для подопытной машины. Для этого просмотрите ветку Computers. После этого включаем UNIX-машину в домен, исполнив на ней команду: # net ads join -U DomainAdministrator

Если в результате исполнения этой команды вы увидите строчку «Joined domain DOMAIN.», то появился повод открывать шампанское. Но в большинстве случаев на этом шаге всплывают все ошибки, допущенные на предыдущих этапах. Вот несколько советов: ! Проверьте, нет ли сильного расхождения во времени у UNIX-машины и контроллера домена. ! Правильно ли был создан keytab-файл (тот ли пароль, совпадает ли имя машины, нет ли различий между значением переменной HOSTNAME и доменным именем). ! Нет ли в Active Directory уже существующего машинного аккаунта для подопытной UNIX-машины. ! Что остается в файлах протоколов самбы и системных логах контроллера домена.

# Óðîâåíü ïîäðîáíîñòè ëîãîâ. Íà ïåðâûõ ïîðàõ æåëàòåëüíî # ïîäíÿòü ýòî çíà÷åíèå äî 4, ÷òî ïîçâîëèò äîñòàòî÷íî òî÷íî # äèàãíîñòèðîâàòü ïðîáëåìó. log level = 2 # Ìàêñèìàëüíûé ðàçìåð ëîã-ôàéëîâ. 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

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

администрирование этого использовать стартовые скрипты системы в /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 возникла идея централизованного хранения информации о пользователях, чтобы избежать ее дублирования на разных компьютерах. Как решение возникшей проблемы была создана система NIS/NIS+ – Network Information Service, позволявшая компьютеру-клиенту проводить аутентификацию пользователей, с помощью информации, хранящейся на центральном сервере. В Linux сама реализация NIS/NIS+ уходит глубоко в системные библиотеки glibc, поэтому для приложений, работающих на клиенте, нет никакой разницы, с каким пользователем они имеют дело: локальным или удаленным. К тому же реализация была сделана по модульному принципу, что много лет спустя и было использовано разработчиками samba. В дистрибутиве самбы есть модуль libnss_winbind.so, при помощи которого подопытная машина научится преобразовывать абстрактные идентификаторы пользователей, раздаваемые сервером winbindd, в привычные имена. Подключить этот модуль можно в файле /etc/nsswitch.conf. Интересующий нас фрагмент выглядит следующим образом: passwd: files group: files shadow: files

Каждая строчка файла отвечает за элемент системы аутентификации – разрешение числовых идентификаторов в привычные имена. Для того чтобы добавить возможность

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

работы с доменными аккаунтами, следует привести этот файл к следующему виду: passwd: files winbind group: files winbind shadow: files

Теперь пора проверить работоспособность всей настраиваемой системы – умеет ли подопытная машина полноценно работать с доменными аккаунтами (перед выполнением следующей команды не помешает на всякий случай перезапустить samba): # getent passwd

Если на экране консоли, как в «Матрице», замелькала разная информация, по структуре своей напоминающая файл /etc/passwd, причем среди записей попадаются доменные аккаунты, то проверка прошла успешно, с этих пор компьютер не знает различий между доменными и локальными пользователями. Но есть одно небольшое но. Дело в том, что на многих UNIX-системах для аутентификации пользователей и назначения им идентификаторов используется библиотека PAM (Pluggable Authentication Modules). По умолчанию она настроена так, что проходить аутентификацию имеют право только локальные пользователи, да и то не все и не везде. Как видно из названия, библиотека построена по модульному принципу, причем за каждым сервисом, требующим аутентификации, можно закреплять свой список используемых модулей. Настройка PAM специфична для каждого дистрибутива Linux, не говоря уже о BSD и прочих реализациях UNIX, так что предлагать готовое решение для чего-то одного было бы несправедливо. По этой причине рассмотрим основы конфигурации, а конкретное их применение каждый найдет для себя сам. PAM – центр всей безопасности системы. Неграмотная его настройка может привести к достаточно разнообразным последствиям: как к тому, что в систему сможет войти кто угодно, так и к тому, что в нее больше никто никогда не войдет, даже администратор. Для последнего случая стоит постоянно держать несколько открытых незадействованных терминалов, при помощи которых в любой момент можно будет исправить допущенную фатальную ошибку. Вероятность этого невелика, но все же такая предосторожность не помешает. Все параметры системы PAM указаны в нескольких файлах, находящихся в каталоге /etc/pam.d, так что перед внесением каких-либо изменений в конфигурацию стоит сделать ее резервную копию. Название файла – это имя программы, к которой следует применять находящиеся в нем настройки. Конфигурация PAM организована в виде стека, то есть модули работают цепочкой, и если один из модулей, имеющий влияние на весь ход процесса аутентификации, решил закрыть или предоставить доступ в систему, то модули, следующие за ним, останутся незадействованными. Для упрощения настройки существует способ заполнять стек модулей из соседних файлов конфигурации. Обычно это используется для указания глобальных параметров аутен-

администрирование тификации, единых для всех сервисов, а отдельные файлы лишь по необходимости дополняют существующие глобальные настройки. Если ваша система PAM изначально была настроена с использованием одного общего файла конфигурации system-auth и ссылками на него из соседних, то стоит править только его, чтобы доменные пользователи смогли входить в систему наряду с локальными. В противном случае придется редактировать все файлы конфигурации для необходимых сервисов. Структура самого файла состоит из построчного списка модулей. Формат строки каждого модуля следующий: [òèï] [âëèÿíèå] [íàçâàíèå ìîäóëÿ] [ïàðàìåòðû]

где:

auth sufficient likeauth nullok

/lib/security/pam_unix.so ↵

# Åñëè àóòåíòèôèêàöèÿ â AD ñðàáîòàëà, òî ðàçðåøàåì äîñòóï # (ýòî óñëîâèå äîñòàòî÷íî äëÿ âõîäà â ñèñòåìó) auth sufficient /lib/security/pam_winbind.so ↵ use_first_pass # Åñëè ïðåäûäóùèé ïóíêò íå ñðàáîòàë, òî çàïðåòèòü âõîä # (ìîäóëü âñåãäà âîçâðàùàåò îòðèöàòåëüíûé ðåçóëüòàò) auth required /lib/security/pam_deny.so

Параметр use_first_pass требуется для того, чтобы pam_winbind.so не переспрашивал у пользователя пароль, а использовал тот, который был введен для pam_unix.so. Настало время проверить работоспособность системы PAM: попробуйте в соседней консоли зайти в систему под любым доменным пользователем. В случае неудачи нужно попробовать войти под локальным пользователем, и если это тоже не сработает, то в настройках определенно допущена ошибка. О причинах возможных неполадок много информации можно почерпнуть из системных логов. Последним шагом является наведение порядка в плане безопасности, так как неразумно пускать на UNIX-машину всех пользователей домена. Для решения этой проблемы существует модуль pam_require.so, который, основываясь на членстве пользователя в определенной группе, решает, пустить ли его. Нужно лишь создать группу в AD, добавить в нее пользователей и подключить сам модуль: account required root @unixoids

/lib/security/pam_require.so ↵

Не переусердствуйте с длиной названия группы, так как glibc иногда не очень адекватно реагирует на длинные имена (более 8 символов).

Рассмотрим следующий пример: # ñðàçó çàãðóæàåì âñå ïîëüçîâàòåëüñêèå ïåðåìåííûå îêðóæåíèÿ # (ìîäóëü âñåãäà âîçâðàùàåò ïîëîæèòåëüíûé ðåçóëüòàò) auth required /lib/security/pam_env.so # Åñëè ïîëüçîâàòåëü åñòü â ëîêàëüíîé áàçå, òî ïóñêàåì åãî # (ýòî óñëîâèå äîñòàòî÷íî äëÿ âõîäà â ñèñòåìó) auth sufficient /lib/security/pam_unix.so ↵ likeauth nullok # Åñëè ïðåäûäóùèé ïóíêò íå ñðàáîòàë, òî çàïðåòèòü âõîä # (ìîäóëü âñåãäà âîçâðàùàåò îòðèöàòåëüíûé ðåçóëüòàò) auth required /lib/security/pam_deny.so

В дистрибутиве самбы есть PAM-модуль pam_winbind.so, который нам потребуется для дальнейшей работы. Стоит проверить, был ли он скопирован при установке в каталог /lib/security, и если его там нет, то поместить его туда руками. Основываясь на предыдущем примере, фрагмент конфигурации, позволяющий проводить аутентификацию при помощи samba, будет выглядеть следующим образом: auth

required

/lib/security/pam_env.so

# Åñëè ïîëüçîâàòåëü åñòü â ëîêàëüíîé áàçå, òî ïóñêàåì åãî # (ýòî óñëîâèå äîñòàòî÷íî äëÿ âõîäà â ñèñòåìó)

Пользователи из домена изначально не имеют домашнего каталога. О нем есть лишь небольшое упоминание в его атрибутах, и для того чтобы доменные пользователи не чувствовали себя обделенными, нужно автоматизированно создавать эти каталоги. Для этого существует модуль pam_mkhomedir.so, который берет шаблон домашнего каталога (по умолчанию /etc/skel), копирует его в надлежащее для него место и выставляет необходимые права: session required umask=0077

/lib/security/pam_mkhomedir.so ↵

Цель достигнута. UNIX-машина теперь может полноценно взаимодействовать с доменом и доменными пользователями. Остается только не забыть добавить самбу в список запускаемых при загрузке сервисов и с чувством выполненного долга начать ею пользоваться.

администрирование

ЗАМЕТКИ О LINARE

ВАЛЕНТИН СИНИЦЫН «Заметки о Linare» открывают цикл статей, посвященных настольным дистрибутивам Linux. Вопрос об использовании Linux на клиентских местах обсуждается сейчас очень широко – создается такое впечатление, что каждое уважающее себя аналитическое агентство считает своим долгом подготовить исследование, дающее исчерпывающий ответ на вопрос, когда Windows окончательно сдаст свои позиции, сколько это будет стоить и случится ли вообще. Не отстают и гиганты индустрии: «тяжеловесы» вроде Novell и Sun Microsystems выпускают собственные разработки с обязательной приставкой «Desktop». Мы же в свою очередь попробуем рассмотреть этот феномен с позиций конечного пользователя. Чем настольный Linux отличается от своих «ненастольных» аналогов? Как ведет себя в работе тот или иной дистрибутив, можно ли использовать его для решения определенного круга задач? Вот те вопросы, на которые мы попытаемся дать ответ. Начнем с банального. Настольный Linux позиционируется его создателем для использования на ПК. Как правило, под этим подразумевается, что входящие в дистрибутив приложения тесно интегрированы друг с другом, а все (или почти все) параметры системы настраиваются при помощи интерактивных графических мастеров, так что пользователю необязательно знать, что происходит «за кулисами». Последнее требование является весьма важным, поскольку целевая аудитория подобных продуктов –

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

люди, использующие компьютер не ради удовольствия, а как инструмент для эффективного решения возникающих перед ними проблем. Немаловажным является также наличие прочных контактов с OEM-поставщиками, поскольку, во-первых, внимание сторонней организации является лишним подтверждением качества программного продукта (ни один производитель не станет продавать компьютеры, о которых покупатели скажут: «Куда мышкой ни щелкни – ничего не работает»), а во-вторых, несмотря на последние исследования в данной области, кое-кто из пользователей предпочтет оставить на компьютере ту систему, которая была на нем в момент приобретения. И наоборот, многие побоятся менять уже имеющуюся ОС на другую, пусть даже самую распрекрасную. На современном Linux-рынке систем, удовлетворяющих этим требованиям, насчитывается четыре штуки: это Linare Linux (http://www.linare.com), Linspire (http://www.linspire.com), ранее известная как LindowsOS, Lycoris Desktop/LX (http:// www.lycoris.com) и Xandros Desktop OS (http://www.xandros.com). К ним вплотную примыкают SUSE Linux (http:// www.suse.com) от компании Novell, Mandrakelinux (http:// www.linuxmandrake.com) от фирмы Mandrakesoft и ряд других разработок. Несколько особняком стоят корпоративные решения типа Java Desktop System от Sun Microsystems и находящийся в стадии бета-тестирования Novell Linux Desktop. Эти продукты предназначены в первую очередь

администрирование для использования на предприятиях и допускают тесную интеграцию с серверными решениями соответствующих поставщиков.

Знакомьтесь: Linare Корпорация Linare Corporation (http://www.linare.com), зарегистрированная в США, штат Вашингтон, впервые заявила о себе в сентябре прошлого года. Именно тогда был анонсирован выход дистрибутива Linare Linux. Месяц спустя Linare открыла портал Linux.net, не так давно переименованный в LinuxTimes.net. Последняя версия системы, Linare Linux 2.0 Professional Edition, базируется на Fedora Core и была выпущена в минувшем августе. Политика компании в отношении распространения Linare Linux вызывает некоторую растерянность. Его первая версия продавалась как отдельно (по цене приблизительно 20 долларов за копию), так и в составе бюджетных PC в ряде крупных интернет-магазинов. После выхода Linare Linux 2.0 была объявлена рекламная акция – коробку (DVD-бокс) с дистрибутивом можно было заказать по почте, оплатив только стоимость доставки. Вскоре после ее окончания Linare, не сказав никому ни слова, опубликовала ISO-образ диска на сайте Ibiblio (ftp://ftp.ibiblio.org), и в настоящий момент его может загрузить любой желающий. Создается впечатление, что компания до сих пор не определилась, что будет ее основным источником дохода – прямые продажи или OEM-контракты. Перейдем собственно к продукту. Как и все настольные дистрибутивы, Linare Linux распространяется на одном компакт-диске, загрузившись с которого можно приступить непосредственно к установке системы. Некоторые производители считают удобным поместить на инсталляционный диск небольшую программу автозапуска (autorun) для Microsoft Windows, которая попросит пользователя сохранить все важные данные и перезагрузить компьютер для начала установки новой системы. На диске с Linare Linux Professional я ничего подобного не обнаружил. Видимо, производитель полагает, что пользователь, отважившийся на перестановку системы, должен сам неплохо представлять, как это делается. В качестве программы-инсталлятора Linare Linux использует Anaconda, что совсем неудивительно, особенно если принять во внимание его «наследственность». Установщик предельно прост в использовании и задает минимум вопросов, однако перевести его в экспертный режим (т.е. оказать сколько-нибудь существенное влияние на процесс) нет никакой возможности. Исключение составляет процедура разбиения жесткого диска, которую пользователь может доверить компьютеру или провести самостоятельно с помощью графической утилиты Disk Druid. Автоматически подготовить разделы на моей системе, к сожалению, не получилось: инсталлятор отказался использовать пустое пространство, оставшееся после установки Mandrakelinux 10.0. Несколько более досадным оказался тот факт, что после неудачной попытки определения будущей структуры разделов (отмечу, речь идет именно об их планировании, а не о записи таблицы на жесткий диск) программа не предложила мне пересмотреть свой выбор, а продемонстрировала диалог с сообщением, заканчивающим-

ся словами: «Press OK to reboot». Излишне говорить, что никаких других кнопок, кроме «OK», в этом диалоге не было. Запустив повторную инсталляцию, я осуществил разбиение диска вручную. На этот раз все прошло гладко, если не считать того, что Linare предложил мне на выбор всего три файловые системы: ext2, ext3 и vfat. На фоне обилия различных решений для организации данных, поддерживаемых ядром Linux напрямую (это и ReiserFS, и XFS компании Silicon Graphics, и JFS корпорации IBM), этот перечень смотрится несколько бледно. После указания часового пояса (здесь было достаточно просто щелкнуть мышью в нужной точке на карте мира) мне предложили ввести пароль для root. Желая проверить «интеллектуальные способности» инсталлятора, я набрал: «123456». К моему изумлению, этот канонически слабый пароль был принят системой безоговорочно. Это тем более странно, поскольку, в отличие от других дистрибутивов, Linare не предлагает создать непривилегированную учетную запись для повседневной работы, вынуждая пользователя, не слишком хорошо знакомого с Linux (а таких среди потенциальных клиентов Linare подавляющее большинство), всегда регистрироваться в системе как root, что весьма негативно сказывается на безопасности. Сразу же после ввода пароля инсталлятор переходит непосредственно к копированию пакетов на жесткий диск. Никаких специальных мер по их отбору не предусмотрено, однако это можно считать скорее плюсом, чем минусом: в состав Linare Linux входит вполне удачный комплект приложений для типичной SOHO-конфигурации, а все необходимое можно добавить в процессе использования системы с помощью утилиты Synaptic. Финальной фазой инсталляции является установка загрузчика (GRUB). К сожалению, инсталлятор не только не спросил меня, где я хотел бы его разместить (возможно, это было сделано для того, чтобы не травмировать неспециалиста терминами вроде MBR), но и переписал существующую загрузочную запись Mandrakelinux, не добавив эту ОС в свое меню. Подобная ситуация, на мой взгляд, является совершенно недопустимой для потенциальных пользователей Linare, многие из которых могут захотеть установить его рядом с Windows. С другой стороны, такое поведение не вызывает проблем при установке Linare Linux на «чистый» компьютер, например, на стенде OEM-производителя. В заключение отметим забавную особенность. Инсталлятор Linare Linux не предлагает пользователю ознакомиться с лицензионным соглашением и «подписать» его, щелкнув на соответствующую кнопку. По мнению автора, это следует рассматривать скорее как «реверанс» в сторону все тех же OEM-поставщиков, поскольку юридические отношения с ними, как правило, закреплены на бумаге.

Впечатления от работы Кодовое имя Linare Linux 2.0 Professional Edition – Shrek. Видимо, в честь всемирно известного огра интерфейс системы выдержан в зеленых тонах (см. рис. 1). Linare Linux 2.0 построен на базе ядра 2.6.5 и включает в себя: рабочий стол KDE 3.2.2, офисный пакет OpenOffice.org 1.1.0, персональный органайзер Ximian Evolution 1.4.6, пакет Mozilla 1.6, графический редактор GIMP 2, проигрыватели XMMS и

администрирование MPlayer, а также ряд несвободных приложений, например среду выполнения Java, RealPlayer 8 и Macromedia Flash. В отличие от других настольных дистрибутивов для просмотра документов в формате PDF Linare Linux предлагает не Adobe Acrobat Reader, использующий библиотеку Motif, а посему имеющий достаточно специфический интерфейс, характерный для старых UNIX-приложений, а достаточно свежую разработку KPDF, являющуюся частью KDE. Рабочий стол создает ощущение монолитности – дизайнеры корпорации Linare постарались на славу. Приложения Qt и GTK выглядят практически одинаково. Из общей картины выбиваются лишь Mozilla, использующая синюю тему «Modern», и OpenOffice.org, поддерживающий собственную библиотеку GUI (справедливости ради надо отметить, что уже существуют версии OpenOffice.org, элементы управления которых имитируют внешний вид виджетов KDE и GNOME. «KDE-фицированный» OpenOffice.org входит, например, в SUSE Linux и Yoper). В качестве frontend к MPlayer также используется GMPlayer (gtk+), хотя ряд других поставщиков Linux уже включил в свои дистрибутивы KPlayer, базирующийся на Qt/KDE. Иными словами, степень интегрированности рабочего стола в Linare Linux весьма высокая, но не идеальная.

Ðèñóíîê 1. Öâåòîâàÿ ãàììà ðàáî÷åãî ñòîëà – æåëòî-çåëåíàÿ, à èêîíêè è íàçâàíèÿ ïðèëîæåíèé ïîäîáðàíû òàê, ÷òîáû ìàêñèìàëüíî ñîîòâåòñòâîâàòü Windows XP

Система меню «Пуск» (в Linare оно называется «Explore») и пиктограммы по возможности повторяют Windows XP. Приложения Linux, такие как KEdit, KPaint и LinNeighborhood, получили привычные пользователям Windows названия – Notepad, Paint и Network Neighborhood. То же самое можно сказать и о иконках рабочего стола. Здесь можно встретить «My Linare PC» и «Connect to Internet», навевающие мысли о «Моем компьютере» и «Мастере подключения к Интернету». Однако не стоит обольщаться – первая пиктограмма является просто ссылкой на домашний каталог пользователя, который будет открыт в Konqueror, а щелчок по второй запустит утилиту KPPP, которая окажет неоценимую помощь в настройке dial-up соединения, но будет бесполезна, если вам необходимо создать подключение по локальной или беспроводной сети. Немаловажной частью настольной системы является также совместимость с Windows-машинами и приложениями. Здесь у Linare имеются определенные проблемы. Lin-

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

Neighborhood, входящий в состав дистрибутива, позволяет просматривать разделяемые ресурсы Windows, а стандартные средства KDE облегчают установку сетевого принтера. Однако ни WINE, ни CrossOver Office в Linare Linux нет, что делает запуск Windows-приложений невозможным. Опять же, WINE можно попробовать доустановить с помощью Synaptic, однако отсутствие средств совместимости с Windows выглядит для настольного дистрибутива несколько странно. Помимо этого, в Linare Linux не входит GCC, а значит, добавлять в систему можно только бинарные пакеты. К счастью, насколько можно судить, Linare Linux 2.0 сохраняет совместимость с Fedora Core 2. А теперь – главный минус для русскоязычных пользователей. Linare Linux не поддерживает никакие языки, кроме американского английского. Набрать что-либо кириллицей не представляется возможным ввиду отсутствия файлов локализации KDE. Подобные действия производителя можно объяснить только его желанием освободить место на компакт-диске и его ориентированностью на англоговорящие страны. Возможно, в будущем эта ситуация изменится к лучшему. Подведем итог. Linare Linux 2.0 Professional Edition представляет собой достаточно простой дистрибутив, по-видимому, ориентированный на OEM-поставки в англоязычные страны. В техническом смысле он ненамного дружественнее пользователю, чем оригинальная Fedora Core, если не считать более «молчаливого» инсталлятора. Linare не предоставляет собственных средств настройки, за исключением стандартного набора апплетов Red Hat. При всем этом пакеты, общий объем которых в распакованном состоянии составляет всего 2 Гб (не так уж много, по современным меркам), подобраны весьма удачно, видна работа дизайнеров и специалистов в области удобства использования (usability). Думается, что после включения хотя бы минимальной поддержки русского и других языков Linare Linux займет достойное место в ряду дружественных пользователю операционных систем. В следующем номере мы рассмотрим самый старый и, пожалуй, самый известный широкой публике настольный дистрибутив – Linspire/LindowsOS.

Ðèñóíîê 2. Ñîáñòâåííûõ ñðåäñòâ íàñòðîéêè â Linare Linux íåò, îäíàêî óòèëèòû Red Hat è Öåíòð óïðàâëåíèÿ KDE ïîçâîëÿþò äîáèòüñÿ ìíîãîãî (íà ýêðàíå – ìàñòåð óñòàíîâêè íîâîãî ïðèíòåðà)

администрирование

ИСПОЛЬЗОВАНИЕ ПРОГРАММЫ nLite

МАКСИМ КОСТЫШИН Желание Microsoft сделать свои программные продукты универсальными приводит к тому, что инсталляционные пакеты содержат порой изрядный процент ненужных для конечного пользователя возможностей, а также большое количество файлов для поддержки многообразного HardWare. Описание одного из способов, который поможет сформировать небольшой пользовательский дистрибутив операционной системы семейства Windows 2000, приводится в данной статье. Это решение позволит сэкономить возможности аппаратных ресурсов вашего компьютера, а значит, повысить эффективность решения действительно важных пользовательских задач, обеспечить повышенный уровень безопасности. Утилита nLite предназначена для формирования пользовательских дистрибутивов операционных систем Microsoft Windows версий 2000, XP, 2003 и решает следующие задачи: ! Оптимизация временных затрат при установке операционной системы на пользовательских компьютерах за счет: ! уменьшения размера дистрибутива и количества устанавливаемых компонентов; ! определения значений стандартных настроек, которые запрашиваются в процессе установки. ! Снижение загрузки оперативной памяти компьютеров путем исключения из инсталляционного пакета компонентов и возможностей, которые не будут востребованы пользователем в процессе работы. ! Повышение уровня безопасности устанавливаемой системы при помощи интеграции в инсталляцию последнего Service Pack, а также исключение из дистрибутива и, таким образом, уменьшения количества приложений Microsoft, которые могут потенциально содержать критические ошибки (например, Outlook Express, игры) и не понадобятся для работы конечному пользователю. Дополнительно программа предоставляет возможность избавиться от установки на пользовательские компьютеры Internet Explorer (с определенными оговорками, так как разработчики Windows настолько интегрировали IE в операционную систему и ее часть – Проводник, что полное избавление от всех следов IE, к сожалению, невозможно). При подготовке статьи была использована программа nLite версии 0.98 beta 2 (утилита является некоммерческим

продуктом и может быть скачана по адресу: http:// www.taekwondo-knin.hr/files/nlite-0.98.7b2i.exe, сайт производителя – http://nuhi.msfn.org). Дополнительно для работы небходимо, чтобы в системе было установлено приложение Microsoft .Net Framework (http://download.microsoft.com/ download/a/a/c/aac39226-8825-44ce-90e3-bf8203e74006/ dotnetfx.exe). Инсталляция nLite имеет общепринятые интуитивно очевидные подходы, поэтому выполнить установку не составит труда даже новичку, и описание процедуры в данной статье не приводится. Для самостоятельных проб рекомендуется учесть то, что в процессе создания дистрибутива с использованием утилиты данные инсталляции будут безвозвратно модифицированы, и вы можете потерять эталонную версию установочного пакета операционной системы. Так как одной из задач, которые решались с использованием nLite, было создание оптимальной инсталляционной версии операционной системы W2K, сохраняющей свои основные характеристики, имеющей минимальные размеры дистрибутива и ограниченные требования к аппаратным ресурсам компьютера, на котором должна производиться установка, то для тестирования была выбрана Microsoft Windows 2000 Professional сборки 5.00.2195 с интегрированным Service Pack 4. При этом объем занимаемого на диске места после установки с применением минимально возможной пользовательской инсталляции составил – 257 Мб (в стандартной установке – около 600 Мб, в расчет не брался размер файла подкачки – pagefile.sys), объем выделенной оперативной памяти – 32 Мб (в стандартной установке – 46 Мб). Сам дистрибутив занимает 178 Мб (в стандартной установке – 330 Мб).

Начало работы с программой Работу с программой nLite разработчики организовали в виде последовательного набора экранов, в которых пользователю предлагается произвести необходимый выбор режимов работы, определить размещения данных и т.п. При запуске утилиты на экран выводится ознакомительное окно, в котором приводится перечень основных функций программы и поддерживаемых операционных систем Microsoft Windows. В следующем экране (Prepare installation) необходимо выбрать каталог, содержащий установочный пакет Windows, который будет модифицироваться для по-

администрирование лучения в выбранном месте итоговой версии инсталляции (нельзя выбрать каталог, размещенный на CD-ROM).

трибутива с интегрированным SP и без использования nLite (что бывает весьма выгодно администраторам, для которых уменьшение времени, потраченного на переустановку системы, – весьма актуальная задача). Для этого достаточно выполнить три последовательных шага: ! Скопировать на жесткий диск каталог «I386» из исходного инсталляционного пакета Windows; ! Распаковать обновление в подходящий каталог, используя команду в указанном ниже формате: W2KSP4_rus.exe /u /x:íàçâàíèå_âðåìåííîãî_êàòàëîãà

! Из подкаталога Update обновления выполнить программу: update.exe /s:èìÿ_êàòàëîãà_äèñòðèáóòèâà

Ðèñóíîê 1

При этом автоматически детектируется наличие в выбранном каталоге подкаталога с названием «I386». Пользователю дополнительно предоставляется информация о том, установка какой операционной системы выбрана, номер внедренного Service Pack (SP) и размер инсталляционного пакета. В случае если у пользователя имеется версия более свежего SP, то следующий экран (Slipstream Service Pack) позволяет выполнить интеграцию в инсталляцию необходимого пакета обновления. Для этого следует после нажатия кнопки «Browse» выбрать файл, содержащий установку требуемого SP. После завершения процедуры в каталоге с инсталляцией, выбранном на втором шаге работы с программой, будет размещаться установочный пакет с интегрированным SP.

Ðèñóíîê 2

Кнопка «Make ISO» позволяет сформировать образ загрузочного диска без удаления каких-либо компонентов из инсталляционного пакета.

Об интеграции Service Pack в инсталляционный пакет Отметим, что при желании обладатель инсталляции W2K и последнего Service Pack может сформировать версию дис-

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

Перечень возможных ключей для выполнения обновления приведен на рисунке.

Ðèñóíîê 3

Опытные специалисты, которые умеют работать с ISOобразами дисков, обладающие знанием и практическими навыками, могут сформировать загрузочный диск на основе исходного инсталляционного диска W2K с использованием таких широко распространенных программных продуктов как Nero, UltraISO, CDRWin и т. п. Вообще говоря, тема создания указанного типа дисков достаточно обширна и может быть рассмотрена в рамках отдельной статьи. К сожалению, разработчики Windows не утруждали себя внедрением подобных механизмов в обновления, которые достаточно часто публикуются Microsoft и еще не включены в отдельный Service Pack, их выполнение предусматривается только после того, как операционная система будет установлена на компьютер. Для полноты изложения вопроса создания загрузочного диска Windows 2000 Professional в рамках основной темы статьи отметим, что в корне установочного пакета должны присутствовать следующие файлы: ! BOOTFONT.BIN (локализация русской версии); ! cdromsp4.tst (указывает на то, что используется версия с Service Pack 4); ! cdrom_ip.5 (указывает на то, что используется версия Windows 2000 Professional); ! cdrom_nt.5 (для всех версий W2K). Причем само содержимое всех файлов, кроме первого, не имеет никакого значения. Файл BOOTFONT.BIN может быть найден в каталоге «I386» установки операционной системы.

администрирование Выбор компонентов инсталляционного пакета После определения каталога дистрибутива и, возможно, интеграции в него последней версии SP, программа nLite предоставляет возможность просмотреть компоненты, которые присутствуют в пакете инсталляции и выбрать те, от которых следует отказаться.

Ðèñóíîê 4

Основную часть окна (Components Removal) занимает перечень разделов с компонентами дистрибутива. Приведем полный список разделов с указанием некоторых включающихся в состав компонентов: ! Application (Игры, WordPad, Калькулятор, ...); ! Drivers (Display Adapter, Ethernet (LAN), Modems, Printers, Sound Controllers, ...); ! Internet Utilities (Communication tools, Internet Explorer, Java Virtual Machine, Outlook Express, Network Monitor, Netmeeting, ...); ! Language Support (Cyrillic, Multilanguage Support (LANG dir), ...); ! Multimedia (Pant, Windows Media Player, Mouse Cursors, Windows Sounds, ...); ! Operating System Options (DR Watson, Disk Cleanup, Help, Task Scheduler, Web View, ...); ! Service (Fax Service, Telnet Service, Autoupdate, Messen ger, ...); ! Directories (в раздел вносится перечень каталогов, которые содержатся в каталоге дистрибутива, за исключением I386). Работа с элементами окна организована авторами программы таким образом, что при попадании курсора мыши на имя конкретного компонента справа отображается краткое пояснение о назначении и рекомендации разработчиков nLite о том, следует ли оставить выбранный компонент в составе формируемого дистрибутива. В нижней части окна расположено всплывающее меню, которое позволяет выбрать и зафиксировать набор удаляемых компонентов и операций, выполняемых над списком элементов, входящих в состав инсталляционного пакета операционной системы. Названия и некоторые пояснения автора статьи помогут получить общие представления о группах исключаемых из дистрибутива компонентов:

! Custom (Пользовательский); ! Last Session (Последняя сессия – данные о последних

! ! ! !

выбранных пользователем для удаления компонентах запоминаются в каталоге установки nLite в разделе Components файла settings.ini при успешном формировании дистрибутива); Safe (Безопасный); Lite (Маленький); Select All (Выбрать все); Clear (Очистить).

Фиксация отметки Experimental позволяет расширить список, из которого выбираются удаляемые компоненты, одноименным разделом (включает компоненты – Application compatibility path, Com+, Extra Fonts, Managеment Instrumentation, MDAC, Modem Support, Windows Picture and Fax Viewer). Заметим, что в программе имеются проблемы с организацией сохранения настроек параметров раздела Experimental. В связи с чем компоненты данного раздела необходимо при очередном сеансе работы с nLite повторно корректировать. Из раздела компонентов драйверов (Drivers) предлагается выбирать только те устройства, которые вам явно не понадобятся при использовании создаваемого пакета дистрибутива. В разделе поддержки языков (Language Support) рекомендуем оставить только поддержку русского языка и многоязычности, а в разделе Operation System Options – Printer Support. В следующем окне пользователю предоставляется возможность добавить файлы, содержащиеся в инсталляции, для удаления либо исключить из категорий удаляемых.

Ðèñóíîê 5

Здесь можно добавить в перечень удаляемых файлов такие категории редко используемых неспециалистами файлов как: ! утилиты работы с командной строкой – append.exe, attrib.exe, xcopy.exe, fc.exe, find.exe, findstr.exe, edlin.exe и т. п.; ! средства диагностики и отладки: ! dxdiag.exe – средство диагностики DirectX; ! perfmon.exe – средство оценки производительности; ! wbemtest.exe – тестер инструментария управления Windows;

администрирование ! winver.exe – вывод информации об установленной

! DefaultHide – предоставляет возможность при установ-

версии Windows; ! ipsecmon.exe – монитор IP-безопасности; ! discover.exe – программа, предназначенная для знакомства с Windows; ! файлы данных; ! %WinDir%\security\templates\*.inf – шаблоны конфигурации безопасности для Security Configuration Editor; ! %WinDir%\*.bmp – образцы рисунков для рабочего стола.

ке провести операции с разделами, задать диск, на который будет производиться установка, а также определить параметры в окне «Язык и стандарты» (рекомендуется автором статьи для проведения максимально быстрого процесса инсталляции); ! GuiAttended – не использует никаких предварительных настроек; ! ProvideDefault – обычный вариант установки с предустановленными значениями.

К слову сказать, после установки операционной системы с применением минимального возможного варианта пользовательского дистрибутива в системном каталоге и System32 размещалось свыше 300 исполняемых файлов, не говоря уже о dll-файлах. Вряд ли большинство из них будут востребованы пользователем и системой для работы. Информация о выбранных пользователем для удаления компонентах, исключаемых и оставляемых в инсталляции файлах, параметрах формирования ISO-образа пользовательской установки сохраняется в settings.ini, размещающемся в каталоге установки nLite.

! ! ! ! ! ! !

С помощью последней закладки (Personal) определяются: временная зона (часовой пояс); значение пароля администратора; язык; имя компьютера; полное имя; название организации; имя рабочей группы для настройки работы в сети.

Настройки параметров инсталляции Следующее окно настроек (Unattended setup) позволяет вам заранее определить значения по умолчанию для некоторых параметров инсталляции. Первая закладка (Info) предоставляет пояснения и возможность использовать или отказаться от представленного расширенного перечня настроек. Внося информацию в параметры второй закладки (General) можно определить данные, которые предлагаются для выбора в процессе установки, такие как: ! регистрационный номер для инсталляции; ! название каталога для установки; ! выбор процесса сопровождения процесса установки (UnAttended Mode); ! возможность определения автоматической регистрации администратора при входе в Windows.

Ðèñóíîê 6

Выбор UnAttended Mode может быть сделан из пяти предопределенных режимов. Поясню некоторые из них:

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

Ðèñóíîê 7

Заметим, что вся информация с настройками параметров инсталляции сохраняется в файле unattended.ini, размещающемся в каталоге установки программы nLite.

Завершающий этап Последнее окно определения параметров дистрибутива (Set up options) в закладках Options и Tweaks позволяет дополнительно задать некоторые завершающие настройки: ! отключить возможность использования системы защиты системных файлов (SFC) при работе операционной системы, которая предполагает резервное хранение кэша защищаемых файлов и автоматическое сканирование целостности системных файлов при перезапуске системы; ! удалить раскладки клавиатуры для исключенных из инсталляции поддержки иностранных языков, которые не будут использованы при работе; ! определить максимальное сжатие драйверов при формировании инсталляции; ! исключить возможность загрузки с формируемого образа; ! определить минимально разрешенный размер оперативной памяти, при котором процедура инсталляции будет разрешена.

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

Ðèñóíîê 10

Ðèñóíîê 8

Нажатие кнопки в окне (Set up options) позволяет начать процесс формирования пользовательского инсталляционного пакета и внесения изменений в исходный каталог с файлами дистрибутива. Последовательность и ход процесса можно наблюдать в очередном окне (Processing). При завершении формирования инсталляции с заданными параметрами внизу окна программы в статусной строке выводится информация о размере сформированного дистрибутива, данные о том, насколько он был уменьшен по сравнению с исходным.

В связи с тем, что при формировании пользовательского дистрибутива ссылки на удаляемые файлы исключаются, порой не во всех конфигурационных файлах вам, возможно, придется повторно отказаться от установки файлов, не обнаруженных в процессе выполнения инсталляции. После установки системы некоторые ссылки на программы или возможности могут остаться в пунктах меню «Пуск» – «Программы», «Панель управления», однако запуск не будет возможен ввиду отсутствия самих объектов, на которые предполагалось сделать отсылки. В состав прочих команд пакетного файла nLite.cmd, запускающегося при первой загрузке Windows, входит утилита Registry Console Tool For Windows 2000 (Reg.exe), которая присутствует, например, в Microsoft Windows 2000 Support Tools (входит в состав Windows 2000 Server) и Windows XP, однако отсутствует в стандартной поставке Windows 2000 Professional. Применение nLite не позволяет полностью удалить Internet Explorer (для эксперимента можно попробовать выполнить в урезанном варианте «Пуск» – «Найти» – «В Интернете…»).

Некоторые тонкости использования nLite

Ðèñóíîê 9

Предпоследнее окно nLite (Make bootable image) предоставляет возможность дополнительно сформировать ISOобраз дистрибутива для тестирования или записи на CDROM. Перед этим можно произвести необходимые операции с итоговым дистрибутивом, которые не были предусмотрены в ходе работы с программой nLite (добавить файлы, скорректировать содержимое), а также внести правки для устранения неточностей, выявленных в процессе работы с программой (рис. 10).

Ложка дегтя в бочке меда Несмотря на то что программа nLite оставляет приятное впечатление при использовании, имеется ряд моментов, которые подтверждают тот факт, что идеальных программных решений не бывает. Ниже приведены некоторые изъя-

Как уже указывалось, авторы программы предусмотрели, что при использовании дистрибутива, изготовленного с использованием утилиты, после завершения инсталляции выполняется запуск командного файла nLite.cmd (необходимая информация для этого вносится в файл HIVEDEF.INF). Формирование командного файла напрямую зависит от настроек заданных пользователем в процессе определения параметров установки в nLite. В связи с этим разработчики внедрили информацию, на основе которой корректируется содержание файла nLite.cmd в код самой программы. Информация дописывается в cmd-файл в процессе формирования дистрибутива. Ниже для примера приводится минимальный вариант содержимого файла nLite.cmd. @ECHO OFF TITLE nLite post cleanup - Please Wait... reg delete HKEY_USERS\.DEFAULT\Software\Microsoft\ ↵ Windows\CurrentVersion\RunOnce /v nlite /f del /f /q %SystemRoot%\inf\nlite.cmd

С использованием коррекции содержимого командного файла nLite.cmd можно решить некоторые дополнительные вопросы оптимизации процесса инсталляции Windows.

администрирование Следующие строки, включенные в nLite.cmd, позволяют скорректировать используемые по умолчанию параметры раскладки клавиатуры при регистрации в системе и при работе в Windows (Английская (США) – основная, Русская – дополнительная, переключение Ctrl+Shift). rem Êîððåêöèÿ ÿçûêà ïî óìîë÷àíèþ è ïåðåêëþ÷åíèÿ êëàâèàòóðû reg add "HKEY_CURRENT_USER\Keyboard Layout\Preload" ↵ /v "1" /t REG_SZ /d "00000409" /f reg add "HKEY_CURRENT_USER\Keyboard Layout\Preload" ↵ /v "2" /t REG_SZ /d "00000419" /f reg add "HKEY_CURRENT_USER\Keyboard Layout\Toggle" ↵ /v "Hotkey" /t REG_SZ /d "2" /f reg add "HKEY_USERS\.DEFAULT\Keyboard Layout\Preload" ↵ /v "1" /t REG_SZ /d "00000409" /f reg add "HKEY_USERS\.DEFAULT\Keyboard Layout\Preload" ↵ /v "2" /t REG_SZ /d "00000419" /f reg add "HKEY_USERS\.DEFAULT\Keyboard Layout\Toggle" ↵ /v "Hotkey" /t REG_SZ /d "2" /f

Для того чтобы воспользоваться заложенной в nLite.cmd возможностью применения утилиты Registry Console Tool For Windows 2000 (Reg.exe), для Windows 2000 Professional необходимо: ! найти и дополнить выбранный каталог «I386» для пользовательской инсталляции файлом Reg.exe; ! внести в файл TXTSETUP.SIF в раздел [SourceDisksFiles] строку следующего содержания: reg.exe

= 2,,,,,,_x,Ø,0,0

держимого файла UnAttend.txt, размещаемого в каталоге «I386»). В связи с этим грамотное использование содержимого файла WinNT.sif может позволить определить при установке максимально быстрый (UnattendMode = DefaultHide) режим инсталляции, предполагающий до 3 (в стандартном режиме – свыше 10) диалоговых экранов, требующих вмешательства оператора для продолжения процесса (эта особенность может быть использована в стандартных дистрибутивах Microsoft Windows 2000 и XP).

Продолжение следует? В статье был рассмотрен один из вариантов, позволяющий формировать на компьютере пользователя операционную систему Windows 2000, занимающую минимальные размеры как на жестком диске, так и при запуске – в оперативной памяти. Следует отметить, что для решения поставленной задачи могут быть использованы различные подходы, так, если в программе nLite используется вариант подготовки пользовательской инсталляции минимального варианта, то утилита 2000Lite Professional (коммерческий продукт LitePC Technologies Pty Ltd, сайт компании – http:// www.litepc.com) позволяет удалить лишние компоненты из уже установленной системы. C использованием 2000Lite Professional можно уменьшить размер занимаемого дискового пространства до 200 Мб (nLite – 257 Мб), размер используемой оперативной памяти может быть уменьшен до 42 Мб (nLite – 32 Мб).

где Ш – номер каталога, назначение которого приведено в размещенном выше разделе [WinntDirectories] (например, цифра 2 означает размещение файла в каталоге %WinDir%\system32). Используя в своих интересах нюансы механизмов работы инсталляции Microsoft Windows, можно, варьируя содержимое файлов, изменять значение переменных среды пользователя (например, TEMP и TMP), определять запуск при первом входе в Windows дополнительных программ, назначенных при подготовке дистрибутива, и т. п. Ниже приводятся отдельные фрагменты содержимого файла HIVEDEF.INF после формирования пользовательского дистрибутива с использованием nLite, которые могут быть взяты в качестве образца для решения указанных выше задач: … [AddReg] HKCU,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce", ↵ "nLite",0x00020000,"%%systemroot%%\inf\nlite.cmd" … HKCU,"Environment","TEMP",0x00020000,"%TEMP_DIR%" HKCU,"Environment","TMP",0x00020000,"%TEMP_DIR%" … [Strings] TEMP_DIR="%USERPROFILE%\Local Settings\Temp" …

Значения параметров, указываемых пользователем в процессе инсталляции, которые определяются во время работы с программой nLite, сохраняются в файле WinNT.sif. Использование sif-файла заложено Microsoft в механизм проведения стандартной установки операционной системы Windows для получения параметров проведения инсталляции (дополнительную информацию можно получить из со-

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

Ðèñóíîê 11

Возможность создания оптимизированной инсталляции существует и для других программных продуктов Microsoft, таких, например, как Microsoft Office. Для этого могут быть применены стандартные средства Microsoft, к примеру Office 2000 Resource Kit, Office XP Resource Kit. К моменту верстки статьи в Интернете появилась информация о выходе новой версии nLite – 0.99 beta, в которой возможности программы существенно расширены: ! добавлена поддержка интеграции hotfixes; ! включения в дистрибутив драйверов поддержки дополнительных устройств; ! увеличен перечень возможных для исключения из пакета компонентов (NWLink IPX/SPX/NetBIOS Protocol, Client for Netware Networks, SNMP Service, Command-Line tools (experimental), Event Log Service (experimental) и пр.); ! внедрены механизмы, позволяющие провести русификацию интерфейса работы с программой и пр.

безопасность

ИММУННАЯ СИСТЕМА ДЛЯ КОМПЬЮТЕРА

СЕРГЕЙ ЯРЕМЧУК Появление компьютеров послужило импульсом к развитию многих наук, но сразу стало понятно, что созданные искусственные алгоритмы не всегда в состоянии рационально решить задачу. Там, где человек сразу видит решение, компьютер лишь может перебирать варианты ответа. Между тем природа терпеливо оттачивает свои алгоритмы уже не один миллион лет, человечеству не сравниться с такими сроками. Именно поэтому в последнее время наметился большой интерес к «натуральным» алгоритмам. Нейронные сети и генетические алгоритмы уже нашли свое применение во многих сферах, в том числе применяют их и в деле защиты информации. Если посмотреть на сегодняшние решения по защите компьютерных систем, их можно сравнить с превентивными мерами по недопущению заболевания, вроде правил общей гигиены, либо с лекарствами, помогающими укрепить организм, как правило, только от определенной болезни. Но природа дала человеку более совершенное средство, помогающее справиться с неизвестными болезнями – иммунитет. Именно это свойство пытаются сейчас выработать у компьютерных систем специалисты. Такие системы, заимствующие у природы принцип иммунитета, называют искусственными иммунными системами (AIS – Artificial Immune System). Для понимания общего принципа работы такой системы необходимо вкратце напомнить, как работает естественная иммунная система, предохраняющая человека от опасных инородных тел. Их роль в организме аналогична таковой в компьютерных системах. Хотя имеется достаточно много различий между живыми организмами и компьютерными системами, но цель – обозначить подобия, переносимые в компьютерную защиту. Защита организма многослойна, здесь и кожа, второй барьер – pH, температура, делающая невозможной существование инородных организмов и, на-

конец, наиболее сложная из них, иммунная система человека. Иммунологи описывают проблему определения заразы внутри организма как сравнение неких шаблонов с попадающими внутрь организма телами (или антигенами) и выявления между ними различий. В роли шаблонов выступают лимфоциты, которые вырабатываются В- и Т-клетками спинного мозга и тимуса. Причем генные библиотеки эволюционируют постоянно, поэтому изменяется и содержащаяся в них информация. В этом процессе имеется несколько интересных моментов. Так, лимфоциты обнаруживают только некоторое ограниченное подмножество патологий, и поэтому для гарантированного обнаружения всех возможных вариантов во всем организме их должно быть достаточное количество (не говоря уже о том, что около 100 миллионов замещаются каждые 2-3 дня в процессе, называемом apoptosis). Иммунная система обладает двумя типами реакции: первичная и вторичная. Первичная реакция происходит, когда иммунная система сталкивается с антигеном впервые, при этом он изучается, и на основании составленного шаблона вырабатываются антитела, уничтожающие антиген. Это длительный процесс, занимающий около 3 недель. Но так как выработать одинаковые антитела довольно тяжело (телесная гипермутация), некоторые из них не вполне соответствуют антигену. Для устранения таких не соответствующих шаблону антител запускается механизм клональной селекции, позволяющий отобрать максимально соответствующие антигену антитела. Учитывая короткий срок жизни, и во избежание повторения всей процедуры с самого начала, информация запоминается. Процесс запоминания – тема больших дебатов, хотя многие сходятся в том, что некоторые B-ячейки выступают как ячейки памяти, но для нашего случая это, впрочем, и не важно. Теперь при повторном заражении запускается механизм вторичной реакции,

безопасность быстро реагирующий на вторжение. И еще один интересный (но редкий) процесс происходит в организме, называется clonal deletion и напоминает тестирование систем обнаружения атак. На стадии выработки лимфоцитов некоторые из них мутируют до такой степени, что начинают нападать на сам организм. Естественно, такие лимфоциты убиваются, но в результате в организме заранее создаются шаблоны, соответствие с которыми сразу же выдает чужеродность. Итак, иммунная система человека обладает некоторыми свойствами: ! индивидуальный подход к уникальным событиям; ! система является распределенной; ! без централизованного контроля; ! самообучаемая, обладающая памятью, ошибкоустойчивая и самотестирующаяся; ! относительно проста и легковесна. А как раз именно этими свойствами, по мнению специалистов, должна обладать эффективная система обнаружения атак. Даже такую упрощенную систему очень трудно полностью перенести в компьютерный мир, да и заниматься этим, очевидно, никто не будет, слишком большие различия. Компьютерные системы, моделирующие T-ячейки, используются для детектирования аномалий, например, при обнаружении компьютерных вирусов, в то время как системы, моделирующие поведение B-ячеек, ориентируются главным образом на проблемы распознавания образов и оптимизации. Отличий компьютерной реализации от биологической довольно много. Так, вместо многих видов датчиков, отвечающих за свой участок и обнаружение своего антигена, используется, как правило, один тип, совмещающий в себе сразу несколько функций. AIS строится, как правило, только на двух центральных положениях: антиген – антитело. Исходя из особенностей сервиса или протокола, выбираются исходные данные для формирования генной библиотеки, которая затем пополняется в процессе обнаружения аномальной активности (т.е. эволюции генной библиотеки). Кроме того, механизмы негативной селекции оперируют вероятностными характеристиками и вместо полного соответствия параметров довольствуются частичным. Изменение коэффициента соответствия изменяет количество ложных срабатываний системы. В качестве замены белку антигенов выступают системные вызовы или сетевые пакеты. Для уменьшения количества антител детекторы конкурируют между собой, подобно тому, как лимфоциты конкурируют при связывании инородного антигена, и такая система оставляет соответствующие только наиболее часто проявляющимся явлениям. Кроме того, такая система имитирует механизм негативной селекции, в результате которой генерируются ранее неизвестные сигнатуры, которые в свою очередь сравниваются с нормальным профилем. В итоге всего такая система создает минимально возможный набор детекторов, способных обнаруживать максимальное число аномалий. Один из компьютеров может играть роль тимуса, и при наличии вторичных IDS весь набор рассылается и на остальные узлы. Хотя в принципе такая централизация необязательна и лимфоциты при обнаружении аномалии могут самостоятельно копироваться на остальные узлы. При обнаружении проблем

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

возможна разная реакция. Например, проблемная машина или сервис может быть просто изолирован (перестройкой firewall, маршрутизатора, перезагрузкой, остановкой и пр.), или IDS пытается перестроиться на параметры атакующего. Сетевые реализации AIS имеют еще один компонент, называемый коммуникатором, оперирующий таким параметром, как уровень риска. При обнаружении аномалий коммуникатор поднимает свой уровень риска и отсылает значение на другие системы, которые также поднимают свой уровень. Поэтому при появлении аномалий сразу на нескольких системах общий уровень быстро растет, и администратор будет оповещен об опасности. Создание случайного набора антител 10001000111010….1000100111

Первичный (сырой) набор антител

Проверка на соответствие

Наблюдение

Зрелый набор

Превышение порога активации

Активация Случайное отмирание детекторов

Изменение Наблюдение Память

Без изменений

Отмирание

Ðèñóíîê 1

После прочтения всего вышеизложенного у многих может возникнуть вопрос, в чем же отличие и преимущество искусственных иммунных систем от искусственных нейронных сетей. Работы по изучению искусственных нейронных сетей (Artificial Neural Networks – ANN) ведутся сравнительно давно и отнюдь небезуспешно, основной пик работ приходится где-то на семидесятые-восьмидесятые. В результате разработано множество теорий и алгоритмов, теория Дарвинизма привела к появлению эволюционных алгоритмов (evolutionary algorithms – EA). Обе эти сети способны обучаться, ведя наблюдение за изменением параметров системы, и как результат достигать максимально возможной эффективности, имеют ассоциативную память, но в любом случае необходима первоначальная настройка и подгонка параметров. Однако отличие нервной и иммунной систем человека накладывает и свои отпечатки на алгоритмы работы. Для AIS характерны самоорганизация и эволюция, для ANN поведение во многом зависит от алгоритма. Количество ячеек AIS не является строго фиксированным, их положение изменяется динамически, происходит постоянное производство и отмирание ячеек, нейроны же имеют конкретное местоположение, и количество их фиксировано. Более того, для первой не характерно длительное взаимодействие между эле-

безопасность ментами, концентрация и характер их динамически изменяется, для второй оно постоянно и задается при подключении. Далее, для AIS, как правило, нехарактерно централизованное управление и даже более того, оно противоречит самой природе вопроса, в ANN всем заправляет мозг, настраивающий веса. Одна из проблем для изучающих ANN состоит в том, что иногда трудно выделить, что именно сеть сейчас «знает». Более подробно этот вопрос освещен в документах «Immune and Neural Network Models: ! Theoretical and Empirical Comparisons»: ftp://ftp.dca.fee. unicamp.br/pub/docs/vonzuben/lnunes/ijcia.pdf. ! «Comparing Immune and Neural Networks»: ftp://ftp.dca.fee. unicamp.br/pub/docs/vonzuben/lnunes/sbrn2002.pdf. Первые разработки по иммунным системам были известны еще в середине 70-х, но все же масштабные исследования начались совсем недавно, в конце 90-х годов. Поэтому стоит отметить, что практических реализаций в больших количествах ждать пока не приходится. Но алгоритмы AIS уже находят применение при распознавании образов, в некоторых оптимизационных задачах, поиске и устранении неисправностей, в том числе и аппаратных (http:// www.osp.ru/cw/2001/47/000_35.htm), обнаружении вирусов, биоинформатике и многих других задачах. Поиск информации о применении AIS в системах защиты при помощи поисковиков несколько затруднен, так как по запросам выводится большое количество ссылок, не всегда соответствующих искомому. Большая часть проектов сегодня предоставляет только теоретическую информацию, которая будет интересна в первую очередь математикам и программистам. В любом случае свои исследования стоит начинать с сайта проекта ARTIST – ARTificial Immune SysTems (http:// www.artificial-immune-systems.org), где вы найдете ссылки на проводимые конференции, новости и некоторую другую информацию. Задачей проекта ISYS (http://www.aber.ac.uk/ ~dcswww/ISYS) является разработка теории AIS, исследование возможности ее применения в конкретных областях и предоставление инструмента, позволяющего самому собрать и испытать такую систему. Самая большая коллекция ссылок по теме AIS расположена по адресу: http:// www.dca.fee.unicamp.br/~lnunes/immune.html, плюс здесь вы найдете руководство, и несколько алгоритмов, демонстрирующих работу AIS в Matlab. Единственным русскоязычным материалом по защите компьютеров при помощи AIS, является статья Алексея Гвозденко «Искусственные иммунные системы как средство сетевой самозащиты» (http://itc.ua/article.phtml?ID=4270). Computer Immune Systems (http://www.cs.unm.edu/ ~immsec) – единственный найденный проект по применению AIS для защиты компьютеров. Интересен он еще и потому, что предоставляет не только теоретические наработки, но и код. Идеи от иммунологии применительно к сегодняшним проблемам компьютерной безопасности нашли здесь реализацию в четырех методах детектирования, которые не только способны обнаружить аномалии, запоминают их и позволяют автоматически среагировать на вторжение. Сетевая система обнаружения атак Lisys для обнаруже-

ния сетевых аномалий контролирует проходящие TCP SYNпакеты. В случае обнаружения необычных TCP-связей, программа посылает предупреждение по e-mail. Далее решение принимает администратор. Если администратор ничего не предпринимает, то детектор, пометивший подключение как аномальное, исчезнет и не будет больше беспокоить. Если аномалия подтверждена, то детектор станет частью набора и будет предупреждать пользователя всякий раз при обнаружении подобного подключения. Состоит Lisys из распределенных детекторов размером 49 байт, контролирующих «data-path triple», т.е. IP-адресов источника и назначения, а также порт. Сначала детекторы генерируются случайно и в процессе работы соответствующие нормальному трафику постепенно убираются, кроме того, детекторы имеют время жизни, и в итоге весь набор, кроме записанных в память, через некоторое время регенерируется. При таком подходе возможно появление незаполненных мест в наборе, которое устраняется использованием масок перестановки, позволяющих повторно отобразить «data-path triple», замеченное различными детекторами. Для уменьшения количества ложных тревог используется порог активации, превышение которого приводит к срабатыванию датчика. Этот порог активации, как говорилось выше, общий на всю сеть. Process Homeostasis (pH) (рис. 2) представляет собой расширение к ядру Linux, позволяющее обнаруживать и при необходимости замедлять необычное поведение программы. Для обнаружения необычного поведения вначале автоматически создаются профили системных вызовов, сделанных различными программами. На создание такого профиля уходит некоторое время, после чего программа может действовать самостоятельно, вначале включая экспоненциальную задержку по времени для аномальных вызовов, а затем и вовсе уничтожая процесс. Так как контролировать все вызовы накладно и нерационально, то система работает только с системными вызовами, имеющими полный доступ к ресурсам компьютера.

Ðèñóíîê 2

STIDE (Sequence Time-Delay Embedding) – также был призван помочь в обнаружении внедрений, распознавая необычные эпизоды системных вызовов. В процессе обучения stide формирует базу данных из всех уникальных, непрерывных системных вызовов и затем делит их на части предопределенной фиксированной длины. Во время работы stide сравнивает эпизоды, полученные при новых трас-

безопасность сировках с уже имеющимися в базе данных, и сообщает о критерии аномалии, указывающем, сколько новых вызовов отличаются от нормы. RISE (Randomized Instruction Set Emulation Building) – эта разработка, основанная на документе «Diverse Computer Systems» (http://www.cs.unm.edu/~immsec/publications/hotos97.pdf) являет собой попытку решения еще одной из проблем – однородности компьютерных систем. Как и в природе, если какой-то вид становится доминирующим, то он становится подвержен болезням, заражению и пр. В компьютерном мире ситуация аналогична. Сегодня стараются делать компьютерные системы более совместимыми и более легкими для использования, и как результат, сейчас можно встретить в одной сети несколько сотен компьютеров практически одинаковой конфигурации, и когда уязвимость найдена, получается весьма благодатная почва для размножения компьютерных вирусов и для вторжения. Эффекта рандомизации можно достигнуть, изменяя исходные коды программы, при трансляции, в момент загрузки, комбинируя эти и другие способы. Все они имеют как положительные, так и отрицательные стороны. В RISE рандомизируются некоторые инструкции исполняемого двоичного файла в момент загрузки, для этого они складываются XOR с неким случайным числом. Этот способ имеет ряд преимуществ, так, не надо хранить измененные программы, возможно использование нового ключа при каждом исполнении, не требуется исходный код, не требуется настройка. Такой компьютер с «индивидуализированной» системой команд будет иметь большую устойчивость к уязвимостям, вроде переполнения буфера. Так как изменить системы команд процессора до-

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

вольно проблематично, то для реализации этой идеи используется x86 эмулятор Valgrind (http://valgrind.kde.org), первоначально предназначенный для отладки памяти. На нынешнем этапе RISE представляет собой скорее концепцию, так как Valgrind сильно замедляет процесс, и для нормальной работы эмулятору требуется большая оптимизация. Работает RISE (как и остальные утилиты, кроме lisys ) пока только с ядрами 2.2 и 2.4, поэтому при попытке собрать с ядром серии 2.6, скорее всего, получите такое сообщение. checking for the kernel version... unsupported (2.6.4-52-default) configure: error: Valgrind works on kernels 2.2 and 2.4

Еще один проект Computational Immunology for Fraud Detection (CIFD) (http://www.icsa.ac.uk/CIFD) занимается разработкой системы защиты на базе технологии AIS, которую затем планируется использовать в почтовой службе Англии, но на момент написания статьи проект предоставлял только общую информацию о разработках. AIS – относительно новая область исследований. Изучая и подражая механизмам естественной иммунной системы, можно получить довольно эффективные решения. Так, новый подход к обнаружению атак, примененный в компонентах Computer Immune Systems, позволяет выявить и остановить широкое разнообразие атак, при этом такие системы не требуют модификаций и минимальной администрации, так как способны самостоятельно адаптироваться к новым угрозам, при этом потребляют незначительное количество системных ресурсов. Остается надеяться, что подобные разработки в скором времени выберутся из концептуального состояния и станут доступны для широкого использования.

сети

ПАССИВНЫЙ ПЕРЕХВАТ ТРАФИКА

Данная статья рассказывает о том, как с помощью компьютера, оборудованного двумя сетевыми картами, организовать полностью пассивный перехват сетевого трафика Fast Ethernet.

ПАВЕЛ ЗАКЛЯКОВ Перехват сетевого трафика может использоваться по разным причинам, но цель у него одна – отслеживать всё происходящее на определённом участке в сети. Это может быть как мониторинг сети с целью выявления тех или иных нюансов в штатном режиме работы, так и обнаружение сетевых атак или выявление нежелательного трафика. Я думаю, читатель cталкивался не с одной задачей, где без перехвата трафика не обойтись. Реализация перехвата может быть осуществлена несколькими способами: 1. Программная реализация на одном из штатно используемых узлов. Например, можно запустить tcpdump, windump или подобные программы на исследуемых узлах и далее наблюдать за выводимой ими информацией. Этот способ хорош отсутствием дополнительных затрат, но плох тем, что, во-первых, потребляются ресурсы процессора, во-вторых, прослушивание трафика можно отследить и обойти. В-третьих, он платформо-зависимый, т.е. на разных платформах используются разные программы, порой несовместимые между собой даже по формату. По данной схеме, например, может быть организовано прослушивание трафика на базе шлюза.

Ðèñóíîê 1. Ïåðåõâàò òðàôèêà íà áàçå øëþçà ïîä óïðàâëåíèåì ÎÑ Linux

2. Использование отдельного компьютера для перехвата трафика совместно с коммутаторами, имеющими порт для мониторинга или концентраторами [4]. В разрыв исследуемого участка сети ставится коммутатор или концентратор, а уже к нему подключается отдельный компьютер, занимающийся анализом прошедшего трафика. Данный способ не зависит от других компьютеров в сети и используемого ими программного обеспечения.

Ðèñóíîê 2. Ïåðåõâàò òðàôèêà íà áàçå êîììóòàòîðà ñ ïîðòîì ìîíèòîðèíãà

3. Использование отдельного компьютера в мостовом включении на исследуемом участке. Этот способ несколько лучше предыдущего тем, что при желании можно организовать не только пассивный просмотр трафика, но и фильтрацию и подмену, т.е. влиять на проходящий трафик. Отличие от первого способа состоит в том, что работа с трафиком ведётся на более низком уровне (на канальном, против сетевого в случае шлюза). Как следствие, стандартными средствами вроде traceroute удалённо обнаружить факт подключения (прослушивания и фильтрации) невозможно.

сети

Ðèñóíîê 3. Ïåðåõâàò òðàôèêà íà áàçå ìîñòà ïîä óïðàâëåíèåì ÎÑ Linux

4. Использование пассивного подключения к кабелю без его разрыва на физическом уровне. Используется совместно с компьютером для обработки перехваченных данных. Так как физический уровень самый низкий из всех, то обнаружить такое подключение на канальном уровне и выше практически невозможно. Правильнее будет сказать, что программно такое подключение обнаружить нельзя.

рудования. Оборудование «посередине» может зависнуть. В случае использования разных по скорости сетевых карт или разных режимов работы может оказаться, что одна карта работает в режиме 100 Мбит/c в полном дуплексе, а составляющая ей пару на другом конце провода умудряется работать со скоростью 10 Мбит/c без дуплекса. Отключив кабель с одной стороны, можно долго удивляться тому, как на другой стороне индикатор «link» почему-то светится и не гаснет, и наоборот. Подозрение сразу перейдёт на кабель, а простое подёргивание его с любой стороны от загадочного места внутри стены рано или поздно приведёт к «секретной комнате» и перехват будет обнаружен. Если всё же исключить ситуации, описанные выше, а вероятность зависания оборудования «посередине» сделать очень низкой, использовав различные схемы контроля и перезапуска, то от задержек при передаче пакетов избавиться не получится. Любое активное оборудование вносит задержки в распространение пакетов [1, стр. 320], задержки малы, но их можно измерить и также заподозрить неладное. Четвёртый способ пассивного перехвата при правильной реализации обнаружить довольно сложно, если не сказать что невозможно при здравом уме и ограниченных финансах. Именно подобным образом я и предлагаю физически скрыть подключение1.

Ðèñóíîê 4. Ïåðåõâàò òðàôèêà íà áàçå ôèçè÷åñêîãî ïîäêëþ÷åíèÿ

Оценим эти способы с точки зрения осуществления скрытного перехвата. Первый способ однозначно не подходит, так как программу, осуществляющую просмотр трафика можно обнаружить и отключить. Даже если она хорошо спрятана и обнаружить её не получается, можно использовать «проверенный дедовский способ» – отформатировать винчестер и установить систему заново. Причём не важно, сервер это или клиентский компьютер – в любом случае работает одинаково хорошо. Второй способ, как и третий, легко обнаружить физически. Лишний бесхозный концентратор и/или компьютер быстро найдутся и привлекут к себе внимание, если их не спрятать в отдельной комнате. Возможно, подозрений не возникло бы, если не «активная составляющая» используемого обо1

Ðèñóíîê 5. Ñîêðûòèå ìåñòà ïîäêëþ÷åíèÿ â ñòåíå

Далее предлагаю на этом пункте не останавливаться, а перейти к технической реализации задуманного. Для наглядности выполним подключение на макете, использовав небольшой кусочек кабеля. Для всей операции нам понадобятся: ! кабель, к которому мы будем подключаться; ! кросскорд (для патчкорда придётся самостоятельно поменять пары местами);

Мой школьный классный руководитель (Чеботарёв А.А.) – умный человек, великолепный педагог и изобретатель, любящий дурачить людей. Именно у него я и позаимствовал нижеследующую логическую схему рассуждений. Так как кабинету физики городской телефон не полагался, а звонить удобнее из своего кабинета, не бегая этажом ниже, Александр Андреевич протащил свой провод и подключился к телефону в учительской. Но просто так (параллельно) не подключишься. Во-первых, во время набора номера параллельный телефон в учительской будет позвякивать, а во-вторых, там могут поднять трубку и услышать разговор, разоблачающий факт подключения. Чтобы этого не происходило, было решено поставить реле, дистанционно отключающее сигнал, идущий в учительскую на тот момент, пока телефоном пользовались из кабинета физики. При этом был решён непростой вопрос: «куда деть реле?». Логика рассуждений была такова. Если телефон в учительской периодически не будет работать, то рано или поздно вызовут телефониста, и первым делом он пойдёт к распределительной коробке, проверять, есть ли там «гудок» от АТС или нет. Убедившись, что сигнал в здание приходит, он пойдёт проверять телефонную розетку в учительской. Подёргав её, обнаружит, что телефон вдруг заработал. Если же, когда он будет проверять розетку, телефон ещё не будет работать (так как его ещё не успеют включить в кабинете физики), то дело может дойти до простого подёргивания и прослеживания провода от распределительной коробки до учительской с целью поиска обрыва. При этом, если где-то расположить самопальную схему с реле, то её найдут. Значит, реле и подключение к линии надо где-то спрятать. Лучше всего спрятать реле в трубу, идущую с этажа на этаж. А подключение сделать «на весу». (Так и было сделано и работает по сей день.) При этом произойдёт следующее: стену долбить не будут, а с этажа на этаж провод проходит нормально. Снизу потянули – вверху провод тянется, наоборот – аналогично. На видимых участках повреждений нет. Пока будут дёргать провод, перемещаясь к учительской, телефон включится. Телефонист подумает, что где-то был неконтакт, и уйдёт довольный, думая, что починил телефон. Хотя на самом деле он ничего не сделает, кроме как зря потратит своё время на пустые хождения.

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

сети ! кусачки; ! паяльник; ! изолирующие материалы. Вначале аккуратно счищаем изоляцию с подключаемого кабеля.

Ðèñóíîê 6. Êóñîê êàáåëÿ ñî ñíÿòîé îáùåé èçîëÿöèåé

Далее зачищаем места для подпайки отводов на белозелёной и бело-оранжевой парах и облуживаем их.

Ðèñóíîê 9. Ïîäïàÿííûå îòâîäû(ìåñòî ïàéêè óâåëè÷åíî)

Далее изолируем место пайки. На стенде это сделано с помощью изоленты, но если есть возможность сделать это более основательно (заранее), то можно использовать термоусаживающиеся кембрики. А вместо отвода использовать одну витую пару, сделав её расчленение на два разъёма уже на конце, затем, чтобы место подключения по возможности сильно не утолщалось.

Ðèñóíîê 7. Çà÷èùåííûå è îáëóæåííûå ìåñòà äëÿ ïîäïàéêè

Далее разрезаем кросскорд. Зачищаем у него соответствующие по цвету провода и подпаиваемся к основному кабелю так, чтобы цвета совпали и оранжевая пара пошла на разводку EIA/TIA T568A, а зелёная – на T568B. В результате подпаиваемые концы в обоих случаях должны приходить на 3-й и 6-й контакты разъёмов.

Ðèñóíîê 10.Çàèçîëèðîâàííîå ìåñòî ïîäêëþ÷åíèÿ

Ðèñóíîê 8. Ïîäïàÿííûå îòâîäû äëÿ ñíÿòèÿ ñèãíàëà

Если подключение не надо никуда прятать, то его можно сделать стационарным и обойтись без пайки, использовав для этих целей соответственно разведённую патч-панель с розетками. Схему разводки представить довольно несложно (см. рис. 11). Но если всё же непонятно, то наглядно и подробно это описано в [2]. Система готова к подключению и испытаниям. Но прежде чем это сделать, давайте рассмотрим, как это должно работать в теории. Если взять техническую спецификацию организации сети, то можно узнать, что для передачи данных используются только две пары, к которым мы подключились, при этом назначение части контактов на разъёмах сетевых карт следующее.

сети ! ! ! !

1 – передача + 2 – передача 3 – приём + 6 – приём -

Ðèñóíîê 11. Ñõåìà ðàçâîäêè äëÿ ÷åòûð¸õ ðîçåòîê è ôîòî îäíîé ðîçåòêè

То есть по четырём проводам (две пары) идут данные в прямом и обратном направлениях. К этим проводам можно подсоединить отводы. Один отвод будет снимать сигналы, идущие в одном направлении, другой – в обратном. Перевести обратно в «электронную форму» грубо снятый физический сигнал можно с помощью тех же сетевых плат, использовав только схему их приёмной части, подключив к ней отводы. При этом если сетевые карты перевести в режим прослушивания (promiscuous mode), то можно будет перехватывать проходящий сетевой трафик. Так как входы сетевых карт высокоомные, то подключение на передачу данных влиять не должно. Предполагаю, что если подключение сделать аккуратно, то волновых эффектов вроде отражённых и стоячих волн (что частенько встречались в коаксиальном Ethernet без терминаторов) можно избежать. На длинных (около 100 м) кусках кабеля подключаться я не пробовал. Выходы (сетевых карт, осуществляющих прослушивание), работающие на передачу, «висят в воздухе»,

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

поэтому влиять на передаваемый сигнал они никак не могут. Если, например, запустить tcpdump для прослушивания на одном интерфейсе, то он будет перехватывать только данные, передаваемые в одну сторону, если же на другом – в другую. Если запустить две копии tcpdump с разными конфигурациями, то потом создание одного лог-файла из двух потребует усилий. При этом невозможно использовать другие средства, работающие в реальном времени и отслеживающие трафик в обоих направлениях. Для объединения трафика «из двух в один» я предлагаю использовать технологию Linux bonding, описанную мной в [3]. После чего нет ничего проще запустить tcpdump, snort или любую другую программу стандартным способом: на интерфейсе bond0 и наслаждаться их работой. Замечание. В принципе, если не прибегать к Linux bonding, можно попытаться объединить снятые данные с помощью всё того же коммутатора с функцией мониторинга портов. Тогда он будет объединять данные с двух портов. Всё бы хорошо, но для данной реализации придётся поменять разводку А и B местами, так как в коммутаторах она обратная (контакты 1 и 2 работают на приём). Надо найти коммутатор с описанной выше функцией. Обычный не факт, что захочет работать. А самое главное, следует понимать, что сплошной поток в 200 Мбит передать в 100 Мбит никак не получится, поэтому при достаточной нагрузке это дело работать не будет, а использование концентраторов вообще невозможно по причине большой вероятности коллизий. Что и греха таить, больше половины хороших программистов вообще далеки от понимания сути происходящих процессов на физическом уровне. А каждая вторая книжка по безопасности, взять ту же [4], предлагает подключать сенсоры систем обнаружения атак, как показано на рис. 2. Естественно, при возрастании загрузки в сети за 50% часть атак уже принципиально не может быть обнаружена, даже если для всех атак будут записи в сигнатурной базе данных. Данные ведь передаются по обоим парам одновременно, а собирать их пытаются каналом вдвое меньшим. Только недавно стали широко доступны коммутаторы с портами на 1 Гбит. Да, по такому порту можно снимать данные со 100-мегабитной сети без потерь, но где гарантия что сеть тоже не будет работать на такой же скорости и тогда ситуация повторится. Половины пропускной способности в нужный момент не хватит. Вот и получается, что с финансовой точки зрения проще установить вторую простенькую сетевую карту и настроить Linux bonding. Дёшево и сердито.

Литература, ссылки: 1. Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы. – СПб: Питер, 2001 г. 2. Construction and Use of a Passive Ethernet Tap: http:// www.snort.org/docs/tap. 3. Закляков П. На пути повышения надёжности и скорости: Linux bonding. – Журнал «Системный администратор», №10, октябрь 2004 г. – 54-58 c. 4. Лукацкий А.В. Обнаружение атак. – СПб: БХВ-Петербург, 2001 г., 432-437 c.

hardware

ЗАПИСЬ ДИСКОВ CD-R/RW В LINUX ЧАСТЬ 1

ВЛАДИМИР МЕШКОВ В данной статье рассматриваются примеры использования мультимедийных команд стандарта SCSI (SCSI Multimedia Commands–4, MMC-4) для записи на лазерные диски CD-R/ RW различной информации – музыкальных треков и данных. В первой части статьи рассматриваются вопросы организации хранения данных на компакт-диске, порядок использования SCSI Generic-драйвера для доступа к устройству чтения/записи компакт-дисков, определения параметров конфигурации устройства и управления режимами работы устройства Работоспособность всех примеров программ была проверена для ОС Linux, ядро 2.4.27. Модель привода для чтения и записи компакт-дисков – TEAC CD-W524E Rev 1.0E. Привод подключен как Secondary Master, в ядре включены поддержка SCSI Generic-драйвера и режим SCSI-эмуляции для ATAPI-устройств (SCSI host adapter emulation for IDE ATAPI devices).

Физический формат данных на компакт-диске Данные, записанные на компакт-диск, представляют собой последовательность малых кадров, small frame.

Ðèñóíîê 1. Ôîðìàò ìàëîãî êàäðà

Малый кадр содержит:

! 3 байта кода синхронизации; ! 1 байт данных субканала; ! 24 байта данных основного канала (две группы по 12 байт);

! 8 байт помехоустойчивого корректирующего кода CIRC, Cross Interleaved Read-Solomon Code (две группы по 4 байта). Общая длина данных малого кадра составляет 36 байт. При записи на компакт-диск данные субканала, основного канала и CIRC кодируются 14-разрядными EFM-кодом (Eight to Fourteen Modulation). Дополнительно к каждому полю добавляются три связывающих бита. Итоговый размер малого кадра, записанного на компакт-диск, равен 588 бит (рис.1). 98 последовательно расположенных малых кадров образуют кадр (Frame), или сектор, минимально адресуемую единицу данных на компакт-диске. Один кадр содержит 24 x 98 = 2352 байт данных основного канала и 98 байт субканала. Эти 98 байт в свою очередь делятся на 2 байта синхронизации и 96 байт данных. Каждый байт дан-

ных субканала размечен на битовые позиции, и, таким образом, субканал делится еще на 8 субканалов.

Ðèñóíîê 2. Ôîðìàò áàéòà äàííûõ ñóáêàíàëà

В одном кадре для каждого из этих субканалов содержится по 96 бит (12 байт) информации. Из всех имеющихся в наличии субканалов основную информационную нагрузку несет Q-субканал. В нем содержится адресная информация кадра, информация о логической структуре компакт-диска, идентификационная информация диска или музыкального трека. Рассмотрим формат данных Q-субканала. Q-субканал содержит: ! 2 бита синхронизации (S0, S1); ! 4 бита поля управления (Control Field); ! 4 бита идентификатора режима данных Q-субканала (ADR); ! 72 бита (9 байт) данных (DATA-Q); ! 16 контрольной суммы полей управления, режима данных и поля данных (CRC). Поле Control Field определяет тип информации, которая находится в основном канале кадра. Это поле может принимать следующие значения: ! 00x0b – 2 аудиоканала без предыскажения; ! 00x1b – 2 аудиоканала, предыскажения 50/15 мкс; ! 10x0b – 4 аудиоканала без предыскажений; ! 10x1b – 4 аудиоканала, предыскажения 50/15 мкс; ! 01x0b – трек данных, непрерывный режим записи (Diskat-once, DAO); ! 01x1b – трек данных, инкрементный режим записи (Track-at-once (TAO), Session-at-once (SAO)); ! 11xxb – зарезервировано. Поле режима данных Q-субканала ADR определяет формат данных Q-субканала. Подробное описание форматов данных Q-субканала находится в спецификации SCSI MMC-4 ([1]), п. 4.2.4.4 «Q Sub-channel». Блок данных основного канала предназначен для хранения информации – аудио или данных. У компакт-дисков, используемых для хранения аудио-информации, все 2352 байт блока основного канала заняты аудиоданными. Для хранения данных используется 6 основных форматов блока основного канала. Наиболее широкое применение получили три формата: ! режим данных 1, Yellow Book Mode 1; ! форма 1 режима данных 2, CD-ROM XA Mode 2 Form 1;

hardware ! форма 2 режима данных 2, CD-ROM XA Mode 2 Form 2. Блок основного канала, содержащий данные, начинается с поля синхронизации Data Block Sync Pattern длиной 12 байт (рис. 3). За полем синхронизации находится заголовок блока Header данных длиной 4 байт. Заголовок блока содержит координаты блока данных в формате MSF (Minute/Second/Frame) и байт формата записи данных Data Mode. Значение формата блока содержат биты 0-1 байта Data Mode.

Ðèñóíîê 3. Ñòðóêòóðà ïîëÿ ñèíõðîíèçàöèè Data Block Sync Pattern

Формат данных Mode 1 представлен в таблице 1, форматы данных Mode 2 Form 1 и Mode 2 Form 2 – в таблицах 2 и 3. Òàáëèöà 1. Mode 1 data format

Ðèñóíîê 5. Îáùàÿ ñòðóêòóðà ìíîãîñåññèîííîãî êîìïàêò-äèñêà

Lead-In-область первой сессии является Lead-In-областью всего диска. Lead-Out-область последней сессии является Lead-Out-областью диска. В User Data-области любой сессии находятся треки с данными. Диски CD-R и CD-RW содержат две дополнительные области перед первой Lead-In-областью компакт-диска – Power Calibration Area (PCA) и Program Memory Area (PMA).

Òàáëèöà 2. Mode 2 Form 1 data format

Ðèñóíîê 6. Ñòðóêòóðà CD-R è CD-RW äèñêà

Òàáëèöà 3. Mode 2 Form 2 data format

Пространство CD-ROM делится на три области (рис. 4):

! Lead-In Area, входная область диска. ! User Data Area, область данных пользователя, или область программ.

! Lead-Out Area, выходная область диска. Ðèñóíîê 4. Îáùàÿ ñòðóêòóðà CD-ROM

Lead-In-область предназначена для хранения информации об организации данных на компакт-диске. Q-субканал Lead-In-области содержит таблицу содержания диска, Table Of Contents (TOC). В TOC хранится информация о сессиях и стартовых адресах треков. Пример чтения и описания формата Q-субканала Lead-In-области (TOC) приведен в [5]. В User Data Area находятся треки с данными пользователя. Минимальное число треков, которое может быть записано на компакт-диск, равно 1. Максимальное число треков на диске равно 99. Треки нумеруются начиная с единицы. Совокупность всех трех областей – Lead-In, User Data, Lead-Out – называется сессией. Любой CD-ROM, содержащий информацию, имеет минимум одну сессию. Максимальное число сессий зависит от используемого типа компактдиска. Нумерация сессий начинается с единицы.

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

The Power Calibration Area, PCA – область калибровки мощности пишущего лазера. Область присутствует только на CD-R и CD-RW дисках. В свою очередь, PCA делится на две области – тестовую область (test area) и область счетчика (count area). Тестовая область содержит 100 калибровочных участков. Область счетчика используется для учета количества использованных калибровочных участков. Для калибровки мощности пишущего лазера используется последовательность команд READ DISK INFORMATION/SEND OPC INFORMATION (см. [1]). The Program Memory Area, PMA – область памяти программ. Область присутствует только на CD-R и CD-RW дисках и предназначена для учета использования User Dataобласти носителя. Q-субканал области PMA используется в качестве временной TOC при записи треков в инкрементном режиме – Track-at-once (TAO), Session-at-once (SAO). При записи диска в режиме Disk-at-once (DAO) данные в PMA не записываются.

SCSI Generic-драйвер. Общие сведения SCSI Generic-драйвер (далее sg-драйвер) входит в состав ядра Linux и позволяет приложению пользователя посылать SCSI-команды устройству при условии, что устройство эти команды понимает. Доступ к sg-драйверу выполняется через специальные файлы устройства, которые находятся в каталоге /dev. Список некоторых файлов можно получить при помощи команды: # ls -l /dev/sg[01] crw------- 1 root root 21, 0 Apr 13 /dev/sg0 crw------- 1 root root 21, 1 Apr 13 /dev/sg1

Каждый файл соответствует одному подключенному SCSI-устройству.

hardware Обращение к SCSI-устройству через sg-драйвер выполняется при помощи системного вызова ioctl следующим образом:

! iovec_count – если это поле равно 0, то буфер для данных представляет собой простой линейный массив байт, и поле dxferp – указатель на этот массив. В противном случае dxferp указывает на массив структур типа:

ioctl(sg_fd, SG_IO, struct sg_io_hdr *)

Первый параметр sg_fd – это дескриптор файла sg-устройства /dev/sg*, открытого при помощи системного вызова open( ). Третий параметр – структура следующего типа:

typedef struct sg_iovec { void * iov_base; /* starting address */ size_t iov_len; /* length in bytes */ } sg_iovec_t,

а поле iovec_count – число структур в этом массиве. typedef struct sg_io_hdr { int interface_id; /*'S' for SCSI generic (required) */ int dxfer_direction; /* data transfer direction */ unsigned char cmd_len; /* SCSI command length ↵ ( <= 16 bytes) */ unsigned char mx_sb_len; /* max length to write to sbp */ unsigned short iovec_count; /* 0 implies no scatter ↵ gather */ unsigned int dxfer_len; /* byte count of data transfer */ void * dxferp; /* points to data transfer memory ↵ or scatter gather list */ unsigned char * cmdp; /* points to command to perform */ unsigned char * sbp; /* points to sense_buffer memory */ unsigned int timeout; /* MAX_UINT->no timeout ↵ (unit: millisec) */ unsigned int flags; /* 0 -> default, see SG_FLAG... */ int pack_id; /* unused internally (normally) */ void * usr_ptr; /* unused internally */ unsigned char status; /* scsi status */ unsigned char masked_status; /* shifted, masked scsi ↵ status */ unsigned char msg_status; /* messaging level data ↵ (optional) */ unsigned char sb_len_wr; /* byte count actually ↵ written to sbp */ unsigned short host_status; /* errors from host adapter */ unsigned short driver_status; /* errors from ↵ software driver */ int resid; /* dxfer_len - actual_transferred */ unsigned int duration; /* time taken by cmd ↵ (unit: millisec) */ unsigned int info; /* auxiliary information */ } sg_io_hdr_t; /* 64 bytes long (on i386) */

Данная структура определена в файле <scsi/sg.h>. Назначение основных полей структуры: ! interface_id – это поле должно содержать литеру «S»; ! dxfer_direction – направление передачи данных. Поле может принимать следующие значения (см. <scsi/sg.h>): ! #define SG_DXFER_NONE (-1) – нет обмена данными; ! #define SG_DXFER_TO_DEV (-2) – передача данных устройству; ! #define SG_DXFER_FROM_DEV (-3) – прием данных от устройства. ! cmdp – указатель на командный пакет, посылаемый устройству; ! cmd_len – размер командного пакета. Если для ATAPIустройств размер командного пакета фиксирован и равен 12 байт, то для SCSI-устройств размер пакета может принимать значения 6, 10, 12 и 16 байт; ! sbp – указатель на буфер SENSE DATA (данные о состоянии устройства после выполнения команды, [1, 5]); ! mx_sb_len – максимальный размер буфера SENSE DATA; ! sb_len_wr – реальный размер данных, сохраненных в буфере SENSE DATA; ! dxferp – указатель на буфер для данных, принимаемых от устройства или передаваемых устройству; ! dxfer_len – размер передаваемых/принимаемых данных;

Подробная информация о sg-драйвере приведена в SCSI-Generic-HOWTO [4]. Рассмотрим порядок использования sg-драйвера на примере чтения PMA (Program Memory Area) CD-R/RW диска. Для чтения PMA устройству необходимо послать команду READ TOC/PMA/ATIP. Формат этой команды описан в [1], пример использования был рассмотрен в [5]. Для чтения PMA поле Format должно содержать значение 0011b. В ответ на команду READ TOC/PMA/ATIP устройство вернет блок данных следующего формата:

Ðèñóíîê 7. Ôîðìàò äàííûõ PMA, Format Field = 0011b

Поле PMA Data Length содержит размер данных PMA, при этом длина самого поля (2 байта) не учитывается. Назначение каждого байта дескриптора PMA определяется значением поля ADR: Òàáëèöà 4

Заголовочные файлы: #include #include #include #include #include #include #include

<stdio.h> <fcntl.h> <errno.h> <scsi/scsi.h> <scsi/sg.h> <linux/types.h> <linux/byteorder/swab.h>

hardware #define SG_DEV "/dev/sg0" // èìÿ ôàéëà óñòðîéñòâà // Ìàêðîñ äëÿ ïåðåñ÷åòà êîîðäèíàò ñåêòîðà èç MSF ôîðìàòà â LBA #define MSF2LBA(Min, Sec, Frame) (((Min * 60 + Sec) * ↵ 75 + Frame) - 150) int sg_fd; // ôàéëîâûé äåñêðèïòîð

if(io_hdr.host_status) printf("Host_status=0x%x\n", ↵ io_hdr.host_status); if(io_hdr.driver_status) printf("Driver_status=0x%x\n", ↵ io_hdr.driver_status); return -1;

Следующая структура описывает формат данных PMA, представленный на рис. 7: typedef struct { __u8 rez; // reserved __u8 ctrl :4; // Control __u8 adr :4; // ADR __u8 tno; // TNO (always 0) __u8 point; // POINT __u8 min; // AMIN __u8 sec; // ASEC __u8 frame; // AFRAME __u8 zero; // 0 __u8 pmin; // PMIN __u8 psec; // PSEC __u8 pframe; // PFRAME } __attribute__ ((packed)) pma_t;

Обмен данными с sg-драйвером выполняет функция send_cmd(). Параметры функции: ! cmd – указатель на командный пакет; ! cmdlen – длина командного пакета; ! direction – направление передачи данных; ! data – указатель на блок памяти для данных, передаваемых устройству или принимаемых от устройства. Если обмен данными не предусмотрен, этот параметр содержит значение NULL; ! datalen – размер блока данных, на который указывает data. Если data == NULL, то datalen == 0 ! timeout – значения time-out. int send_cmd(__u8 *cmd, __u8 cmdlen, unsigned int direction, ↵ __u8 *data, __u32 datalen, unsigned int timeout) { int k = 0; sg_io_hdr_t io_hdr; /* Â sense_buffer áóäåò ñîõðàíåíà èíôîðìàöèÿ î ñîñòîÿíèè * óñòðîéñòâà ïîñëå âûïîëíåíèÿ êîìàíäû */ __u8 sense_buffer[32]; /* Ôîðìèðóåì çàïðîñ ê sg-äðàéâåðó – çàïîëíÿåì ïîëÿ * ñòðóêòóðû sg_io_hdr_t íåîáõîäèìûìè çíà÷åíèÿìè */ memset(&io_hdr, 0, sizeof(sg_io_hdr_t)); io_hdr.interface_id = 'S'; io_hdr.cmd_len = cmdlen; // äëèíà êîìàíäû io_hdr.mx_sb_len = sizeof(sense_buffer); io_hdr.dxfer_direction = direction; // íàïðàâëåíèå ↵ ïåðåäà÷è äàííûõ io_hdr.dxfer_len = datalen; // ðàçìåð äàííûõ io_hdr.dxferp = data; // óêàçàòåëü íà áëîê äàííûõ io_hdr.cmdp = cmd; // óêàçàòåëü íà êîìàíäíûé ïàêåò io_hdr.sbp = sense_buffer; io_hdr.timeout = timeout; /* Ïîñûëàåì óñòðîéñòâó êîìàíäó */ if(ioctl(sg_fd, SG_IO, &io_hdr) < 0) { perror("SG_IO ioctl"); return -1; } /* Îòîáðàçèì ñîäåðæèìîå sense_buffer, åñëè ïðè âûïîëíåíèè * êîìàíäû ïðîèçîøëà îøèáêà. Ýòî ïîçâîëèò óñòàíîâèòü * ïðè÷èíó îøèáêè */ if((io_hdr.info & SG_INFO_OK_MASK) != SG_INFO_OK) { if (io_hdr.sb_len_wr > 0) { printf("Sense data: "); for (k = 0; k < io_hdr.sb_len_wr; ++k) { if ((k > 0) && (0 == (k % 10))) printf("\n "); printf("0x%02x ", sense_buffer[k]); } printf("\n"); } if(io_hdr.masked_status) printf("SCSI status=0x%x\n", io_hdr.status);

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

}

} return 0;

Проверку готовности устройства к приему команды выполняет функция test_unit_ready(): int test_unit_ready() { __u8 testCmdBlk[6]; /* Prepare TEST UNIT command */ memset(testCmdBlk, 0, 6); if(send_cmd(testCmdBlk, 6, SG_DXFER_NONE, NULL, ↵ 0, 20000) < 0) { printf("Unit not ready\n"); return -1; } return 0; }

Чтение PMA выполняет функция read_pma(): int read_pma() { int i, k; __u8 read_pma_cmd[10]; __u8 *pma_data_buff; // çäåñü áóäóò ñîõðàíåíû ↵ ðåçóëüòàòû ÷òåíèÿ PMA __u16 buff_size = 0xFFFF; // ðàçìåð áëîêà ïàìÿòè ↵ äëÿ õðàíåíèÿ ñ÷èòûâàåìûõ äàííûõ __u16 pma_data_length = 0; // ðåàëüíàÿ äëèíà çàïèñåé PMA __u32 lba; int pma_entries = 0; // ÷èñëî çàïèñåé PMA pma_t *pma; /* Ïðîâåðÿåì ãîòîâíîñòü óñòðîéñòâà ê ïðèåìó êîìàíäû */ if(test_unit_ready() < 0) exit(-1); pma_data_buff = (__u8 *)malloc(buff_size); memset(pma_data_buff, 0, buff_size); /* Ôîðìèðóåì êîìàíäíûé ïàêåò */ memset(read_pma_cmd, 0, 10); read_pma_cmd[0] = 0x43; // êîä êîìàíäû READ_TOC/PMA/ATIP read_pma_cmd[2] = 3; // ïîëå Format Field = 011b, ↵ ÷èòàåì PMA read_pma_cmd[7] = 0xFF; read_pma_cmd[8] = 0xFF; /* Ïîñûëàåì óñòðîéñòâó êîìàíäó */ if(send_cmd(read_pma_cmd, 10, SG_DXFER_FROM_DEV, ↵ pma_data_buff, buff_size, 20000) < 0) return -1; /* Ñ÷èòûâàåì äëèíó çàïèñåé PMA. Ðàçìåð ïîëÿ PMA Data Length * (2 áàéòà) íå ó÷èòûâàåòñÿ */ memcpy(&pma_data_length, pma_data_buff, 2); pma_data_length = __swab16(pma_data_length); printf("PMA data length - %d\n", pma_data_length); /* Îïðåäåëÿåì ÷èñëî çàïèñåé PMA */ pma_entries = (pma_data_length - 2)/11; printf("PMA entries - %d\n", pma_entries); /* Ðàçìåð äàííûõ PMA òî÷íî èçâåñòåí è ðàâåí pma_data_length. * Âûäåëÿåì áëîê ïàìÿòè äëÿ äàííûõ PMA è êîïèðóåì èõ òóäà * èç pma_data_buff. Ïîñëå ýòîãî ìîæíî îñâîáîäèòü áëîê * ïàìÿòè, íà êîòîðûé óêàçûâàåò pma_data_buff */ pma = (pma_t *)malloc(pma_data_length); memset((void *)pma, 0, pma_data_length); memcpy((void *)pma, pma_data_buff + 4, pma_data_length); free(pma_data_buff); /* Îòîáðàæàåì äàííûå PMA */ printf("Entry\tADR\tCTRL\tPoint\tZero\tMin\tSec\ ↵ tFrame\tPMin\tPsec\tPFrame\tLBA\n"); for(i = 0; i < pma_entries; i++) { printf("%d\t", i); printf("%X\t", (pma + i)->adr); printf("%X\t", (pma + i)->ctrl); printf("%X\t", (pma + i)->point); printf("%d\t", (pma + i)->zero); printf("%d\t", (pma + i)->min); printf("%d\t", (pma + i)->sec);

hardware printf("%d\t", (pma + i)->frame); printf("%d\t", (pma + i)->pmin); printf("%d\t", (pma + i)->psec); printf("%d\t", (pma + i)->pframe); lba = MSF2LBA((pma + i)->pmin, (pma + i)->psec, ↵ (pma + i)->pframe); if((pma + i)->adr != 1) printf("---\n"); else printf("%u\n", lba);

}

} free(pma); return 0;

Вызов функции read_pma() для чтения данных PMA выполняется из главной функции: Открываем файл устройства. Обратите внимание на режим открытия – чтение/запись. Если устройство открыто в режиме «Только чтение» (O_RDONLY), то оно воспринимает команды (см. [4]): ! INQUIRY ! TEST UNIT READY ! REQUEST SENSE ! READ CAPACITY ! READ BUFFER ! READ(6) (10) and (12) ! MODE SENSE(6) and (10) int main() { if((sg_fd = open(SG_DEV, O_RDWR)) < 0) { perror("open"); return -1; } /* Ñ÷èòûâàåì PMA */ if(read_pma() < 0) printf("Cannot read PMA\n"); close(sg_fd); return 0; }

Point 0 1 2 3

Zero 0 0 0 0

Min 54 5 8 12

Sec 88 3 28 30

Frame 82 16 58 21

PMin 0 0 5 8

Psec 0 2 5 30

PFrame 0 0 16 58

Ðèñóíîê 8. Ôîðìàò áëîêà äàííûõ, âîçâðàùàåìîãî ïî êîìàíäå GET CONFIGURATION

Ðèñóíîê 9. Ôîðìàò çàãîëîâêà ñâîéñòâà

Полный текст данной программы находится в файле SG/ read_pma.c. Устанавливаем в устройство диск CD-RW, на котором записано 3 аудиотрека, и запускаем программу на выполнение. Результаты работы программы: PMA data length - 46 PMA entries - 4 Entry ADR CTRL 0 2 0 1 1 0 2 1 0 3 1 0

Одно устройство может поддерживать несколько свойств. Базовый набор свойств устройства называется профилем (Profile). Перечень всех существующих свойств и профилей приведен в спецификации SCSI MMC-4, п. 5 «Features and Profiles for Multi-Media Device». Для того чтобы выяснить, обладает ли устройство тем или иным свойством, ему необходимо послать команду GET CONFIGURATION. Данная команда определена в спецификации [1] и позволяет получить полный список свойств, поддерживаемых устройством и текущий профиль устройства. Текущий профиль определяет, какие именно свойства доступны на данный момент. По команде GET CONFIGURATION устройство вернет блок данных, состоящий из заголовка свойства (Feature Header) и списка дескрипторов свойств (Feature Descriptors):

Поле Data Length содержит размер считанных данных, следующих за эти полем, в поле Current Profile находится значение текущего профиля устройства. Если свойство не поддерживается устройством, то команда GET CONFIGURATION вернет только заголовок свойства, и поле Data Length будет содержать значение 4 (2 поля Reserved по одному байту каждое + 2 байта поля Current Profile).

LBA --0 22741 38158

Для анализа полученных результатов воспользуемся таблицей 4.

Ðèñóíîê 10. Îáùèé ôîðìàò äåñêðèïòîðà ñâîéñòâà

Назначение полей дескриптора свойства:

! Feature Code – код свойства. Каждое свойство имеет

Свойства, профили и страницы режимов устройства Свойства и профили устройства Прежде чем послать устройству какую-либо команду, надо убедиться в том, что устройство способно эту команду выполнить. Для этого необходимо установить, какие именно команды поддерживает устройство. Набор команд, поддерживаемых устройством, называется свойством (Features).

свой уникальный код. Список всех кодов приведен в спецификации [1], п. 5.3 «Feature Definitions». ! Persistent – если этот бит установлен в 0, то данное свойство может менять текущий статус. Если бит равен 1, то свойство всегда активно. ! Current – если бит установлен в 1, то данное свойство активно, т.е. устройство поддерживает набор команд, определенный этим свойством. ! Feature Dependent Data – данные, специфичные для указанного свойства. Назначение полей командного пакета:

! RT – определяет тип данных, возвращаемых устройством. Поле может принимать следующие значения:

hardware ! 00b – устройство возвращает заголовок свойства и дескрипторы всех свойств, поддерживаемых устройством, даже если свойство не является активным. ! 01b – устройство возвращает заголовок свойства и дескрипторы активных свойств устройства (у которых бит Current установлен в единицу). ! 10b – устройство возвращает заголовок и дескриптор свойства, номер которого задан в поле Starting Feature Number. Если запрашиваемое свойство не поддерживается устройством, возвращается только заголовок свойства Feature Header (рис. 9). ! 11b – зарезервировано. ! Allocation Length – размер памяти, выделенной для данных.

/* Ïîñûëàåì óñòðîéñòâó êîìàíäó */ if(send_cmd(get_conf_cmd, 10, SG_DXFER_FROM_DEV, ↵ data_buff, 16, 20000) < 0) return -1; /* Îïðåäåëÿåì äëèíó ñ÷èòàííûõ äàííûõ */ memcpy((void *)&data_length, data_buff, 4); data_length = __swab32(data_length); printf("\nFeature data length - %u\n", data_length); /* Åñëè äëèíà ñ÷èòàííûõ äàííûõ ðàâíà 4, òî çàïðàøèâàåìîå * ñâîéñòâî íå ïîääåðæèâàåòñÿ */ if(data_length == 4) return -1; /* Îïðåäåëÿåì çíà÷åíèå òåêóùåãî ïðîôèëÿ */ memcpy((void *)&current_prof, data_buff + 6, 2); current_prof = __swab16(current_prof); printf("Current profile - 0x%.4X\n", current_prof); /* Êîä ñâîéñòâà, çíà÷åíèå äîëæíî ñîâïàäàòü * ñ ïàðàìåòðîì f_num */ memcpy((void *)&f_code, (data_buff + 8), 2); f_code = __swab16(f_code); printf("Feature Code - 0x%.4X\n", f_code); printf("Byte 4: 0x%X\n", data_buff[12]); /* Ïðîâåðÿåì çíà÷åíèå áèòà CD-RW. Åñëè áèò óñòàíîâëåí * â åäèíèöó – çàïðàøèâàåìîå ñâîéñòâî óñòðîéñòâîì * ïîääåðæèâàåòñÿ */ if(data_buff[12] & 0x02) ↵ printf("Feature CD TAO support\n\n"); else return -1; return 0; }

Устанавливаем в привод CD-RW диск и запускаем программу на выполнение. Результаты работы: Ðèñóíîê 11. Ôîðìàò êîìàíäû GET CONFIGURATION

Рассмотрим пример. Необходимо выяснить, может ли устройство выполнить запись треков на компакт-диск в режиме TAO. Для этого надо установить, обладает ли устройство свойством «СD Track at Once». Код этого свойства равен 0x002D (см. [1]).

Ðèñóíîê 12. Ôîðìàò äåñêðèïòîðà ñâîéñòâà «ÑD Track at Once»

Устройство способно выполнить запись трека на компакт-диск в режиме TAO в том случае, если бит CD-RW установлен в единицу. Рассмотрим функцию, выполняющую проверку наличия у устройства свойства «СD Track at Once» и значение бита CD-RW. Функция принимает один параметр – код свойства. Полный текст программы приведен в файле SG/get_conf.c. int get_conf(__u16 f_num) { __u8 get_conf_cmd[10]; __u8 data_buff[16]; // ðåçóëüòàòû ÷òåíèÿ __u32 data_length = 0; // ðåàëüíàÿ äëèíà äàííûõ __u16 current_prof = 0; // çíà÷åíèå òåêóùåãî ïðîôèëÿ __u16 f_code = 0; // êîä ñâîéñòâà /* Æäåì ãîòîâíîñòü óñòðîéñòâà */ if(test_unit_ready() < 0) exit(-1); /* Ôîðìèðóåì êîìàíäíûé ïàêåò */ memset(data_buff, 0, 16); memset(get_conf_cmd, 0, 10); get_conf_cmd[0] = 0x46; // êîä êîìàíäû GET CONFIGURATION get_conf_cmd[1] = 2; // RT= 10b get_conf_cmd[8] = 16; /* Â ïîëå Starting Feature Number çàíîñèì êîä ñâîéñòâà */ f_num = __swab16(f_num); memcpy((get_conf_cmd + 2), (void *)&f_num, 2);

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

Feature data length - 12 Current profile - 0x000A Feature Code - 0x002D Byte 4: 0x6 Feature CD TAO support

Текущий профиль устройства – CD-RW, см. п. 5.4.10 «Profile 000Ah: CD-RW» спецификации SCSI MMC-4 ([1]). Список свойств, соответствующих данному профилю, приведен в этом же пункте, в таблице 192 «Mandatory Feature for CD-RW». Свойство «CD Track at Once» входит в их число. Теперь установим в привод диск CD-ROM и опять запустим программу на выполнение. Результаты работы программы: Feature data length - 12 Current profile - 0x0008 Feature Code - 0x002D Byte 4: 0x6 Feature CD TAO support

Свойство «CD Track at Once» приводом поддерживается, но текущий профиль – 0x0008, CD-ROM – не позволяет это свойство применять. Список свойств, соответствующих профилю «CD-ROM», приведен в таблице 188 «Mandatory Feature for CD-ROM», п. 5.4.8 спецификации SCSI MMC-4 ([1]).

Страницы режимов Для установки или определения параметров работы устройства используются страницы режимов (Mode Page). Каждая страница режима характеризуется кодовым номером, длиной и набором параметров. В таблице 5 приведен список кодов некоторых страниц режимов. Полный перечень находится в спецификации SCSI MMC-4, п. 7.1.3 «Mode Pages». Òàáëèöà 5

hardware Прием и передача страниц осуществляется при помощи списка параметров режима Mode Parameter List. Список страниц начинается с заголовка (Mode Parameter Header), за которым могут следовать одна или несколько страниц режимов (рис. 13).

! Page Length – размер страницы в байтах. ! Write Type – используемый режим записи: ! 01 – Track-at-once (TAO); ! 02 – Session-at-once (SAO); ! 03 – RAW.

! Test Write – режим имитации записи данных на носи! Ðèñóíîê 13. Ôîðìàò ñïèñêà Mode Parameter List

Ðèñóíîê 14. Ôîðìàò çàãîëîâêà ñïèñêà ñòðàíèö (Mode Parameter Header)

Поле Mode Data Length содержит размер блока данных, следующего сразу за этим полем, т.е. 6 оставшихся байт заголовка плюс длину запрашиваемой страницы. Если страница передается устройству, то значение поля Mode Data Length не используется (зарезервировано).

Страница параметров режима записи Рассмотрим подробнее, что из себя представляет страница режима, на примере страницы параметров режима записи, Write Parameters Mode Page.

тель. Бит имеет значение только для режимов TAO и SAO. Track Mode – содержит значение поля управления Control Field Q-субканала при ADR = 1 (см. «Физический формат данных на компакт-диске»). В данной статье будет использовано только два значения этого поля: ! 0 – аудио-трек; ! 4 – трек данных. Multi-session – показывает, как закрытие текущей сессии влияет на открытие следующей: ! 00b – указатель B0 отсутствует в TOC, открытие новой сессии запрещено ([3, 5]); ! 01b – указатель B0 содержит значение FF:FF:FF, открытие новой сессии запрещено; ! 11b – открытие новой сессии разрешено. Указатель B0 содержит координаты начала следующей области программ. Data Block Type – определяет тип блока данных и его размер. Перечень всех значений этого поля находится в таблице 619 «Data Block Type Codes» спецификации MMC-4. В данной статье будет использовано только два значения: ! 0 – блок «сырых» данных размером 2352 байт (блок аудиоданных); ! 8 – блок данных размером 2048 байт, формат блока данных Mode 1. Session Format – формат сессии. Это значение записывается в поле PSEC указателя A0 таблицы содержания диска TOC. Поле может принимать следующие значения: ! 00h – диск CD-DA или CD-ROM ! 01h – диск CD-I ! 20h – диск CD-ROM XA

В поле Sub-Header устройству передается информация для заполнения подзаголовка сектора при записи на диск данных в формате Mode 2 Form 1/2 (см. табл. 2 и 3). Во второй части статьи будут рассмотрены примеры программ, выполняющих запись на компакт-диск CD-R/RW различной информации, музыкальных треков и данных.

Литература, ссылки:

Ðèñóíîê 15. Ôîðìàò ñòðàíèöû ïàðàìåòðîâ ðåæèìà çàïèñè

Назначение полей:

! Page Code – код страницы, содержит значение 0x05.

1. Спецификация SCSI Multimedia Commands-4 (SCSI MMC-4), http://www.t10.org/ftp/t10/drafts/mmc4/mmc4r03d.pdf 2. Спецификация SCSI-3 Multimedia Commands, http:// www.t10.org/ftp/t10/drafts/mmc/mmc-r10a.pdf 3. Specification for ATAPI DVD Devices, ftp.seagate.com/sff/ INF-8090.pdf 4. SCSI-Generic-HOWTO, http://www.linux.org/docs/ldp/ howto/SCSI-Generic-HOWTO/index.html 5. Мешков В. Пакетные команды интерфейса ATAPI. – Журнал «Системный администратор», № 9(22), сентябрь 2004 г. – 70-84 с.

bugtraq Отказ в обслуживании в Sun Java System Application Server Программа: Sun Java System Application Server 7 Standard Edition Update 4 и более ранние версии, 7 Platform Edition Update 4 и более ранние версии, 7 2004Q2. Опасность: Высокая. Описание: Удаленный атакующий может аварийно завершить работу службы. Уязвимость существует при обработке сертификатов в Sun Java System Application Server. Удаленный атакующий может специальным образом создать сертификат, который при проверке уязвимым сервером приведет к отказу в обслуживании. Также сообщается о множественных ошибках при обработке ASN.1. URL производителя: www.sun.com. Решение: Установите обновление.

Отказ в обслуживании в Kerio Personal Firewall Программа: Kerio Personal Firewall версии до 4.1.2. Опасность: Высокая. Описание: Удаленный атакующий может вызвать отказ в обслуживании системы. Уязвимость существует при обработке определенных пакетов. Удаленный атакующий может послать специально сформированный пакет и заставить службу потреблять все доступные ресурсы на системе. URL производителя: www.kerio.com/kpf_home.html Решение: Установите обновление: http://www.kerio.com/ kpf_download.html.

Уязвимость протокола DHCP в оборудовании Cisco Программа: 12.2(18)EW, 12.2(18)EWA, 12.2(18)S, 12.2(18)SE, 12.2(18)SV, 12.2(18)SW,12.2(14)SZ. Опасность: Высокая. Описание: 11 ноября 2004 опубликован бюллетень CERT, сообщающий о наличии уязвимости в различных версиях Cisco IOS, используемых в маршрутизаторах, коммутаторах и линейных интерфейсах. Проблема связана со способом обработки пакетов DHCP в системах Cisco IOS. Используя уязвимость реализации протокола, можно организовать атаку на службы (DoS). Обработка пакетов DHCP по умолчанию включена, что повышает уровень опасности. Реализация протокола DHCP в операционной системе Cisco IOS содержит ошибки, позволяющие использовать пакеты DHCP некорректного формата для организации атаки на службы, которая может привести к полной остановке обработки устройством входящего трафика. Маршрутизаторы, коммутаторы и линейные интерфейсы Cisco поддерживают обработку пакетов DHCP по умолчанию. Устройства Cisco также могут работать как серверы DHCP, обеспечивая выделение адресов и установку конфигурационных параметров хостов. Кроме того, устройства могут пересылать пакеты DHCP и BootP, работая в этом случае как трансляторы. При получении пакета DHCP он помещается во входную очередь для последующей обработки. Пакеты DHCP, которые не удалось доставить, могут сохраняться в очереди. При заполнении очереди уст-

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

ройство будет прекращать прием всех пакетов из данной сети. Для переполнения очереди достаточно просто передать множество некорректно сформированных пакетов, которые будут сохраняться в очереди по причине невозможности их доставки. Как было отмечено выше, сервис DHCP по умолчанию включен в IOS. Для запрета DHCP требуется явное включение команды no service dhcp в конфигурационный файл устройства. Отсутствие в конфигурационном файле устройства команды service dhcp не означает, что сервис не поддерживается устройством, его нужно явно отключить с помощью приведенной выше команды. Таким образом, уязвимость устройств сохраняется независимо от того, используются ли они в качестве серверов или трансляторов DHCP. Передавая специально сформированные пакеты DHCP атакуемому устройству, злоумышленник может полностью блокировать обработку этим устройством входящего трафика и для восстановления работоспособности устройства потребуется его перезагрузка. URL производителя: www.cisco.com. Решение: Обновление версии IOS.

DoS-атака в Apache Программа: Apache 2.0.52 и более ранние версии 2.0.x. Опасность: Высокая. Описание: Удаленный атакующий может заставить службу потребить все доступные ресурсы на системе. Уязвимость существует при обработке пробелов в HTTP GET-запросе. Удаленный атакующий может создать большое количество запросов, содержащих большое количество пробелов в заголовках запроса. Пример: GET / HTTP/1.0\n [space] x 8000\n [space] x 8000\n [space] x 8000\n 8000 ðàç

URL производителя: httpd.apache.org. Решение: Установите последнюю версию.

Неавторизованный доступ к сетевым ресурсам в Cisco ACS Программа: Cisco Secure ACS for Windows и Cisco Secure ACS Solution Engine версии 3.3.1. Опасность: Высокая. Описание: Уязвимость существует при обработке сертификатов в Cisco Secure Access Control Server при использовании EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) для авторизации пользователей. Удаленный атакующий может создать криптографически корректный сертификат (сертификат соответствующего формата с валидными полями, не зависимо от его срока жизни и от того, выдан ли он доверенным CA) и пройти авторизацию на Cisco ACS. URL производителя: www.cisco.com. Решение: Установите обновление: http://www.cisco.com/ pcgi-bin/tablebuild.pl/cs-acs-win.

Составил Александр Антипов

программирование

СОЗДАЕМ КРОССПЛАТФОРМЕННОЕ ПРИЛОЖЕНИЕ НА ОСНОВЕ FLTK

АНТОН БОРИСОВ Четкого типажа IT-специалиста не существует, ему часто приходится вторгаться в области деятельности, смежные с его основным профилем. Например, программистам приходится иногда производить конфигурацию системы и выступать в роли администратора. В свою очередь, администраторы в рамках своих полномочий не всегда занимаются лишь администрированием – они умеют составлять программы для своих подзадач. Однако не стоит смешивать административную работу и работу программиста, хотя зачастую на многих предприятиях на сегодняшний день характерна ситуация, когда администратор и швец, и жнец и на дуде игрец. Однако не буду концентрировать ваше внимание на неправильном подходе к организации IT-работы на предпри-

ятии. Замечу, что ситуации, когда необходимо обработать информацию и сформировать из нее новые данные, не являются единичными как для системных инженеров, администраторов, так и для программистов. Сооружать некий айсберг ради кратковременной и нетребовательной задачи я считаю нерациональным решением. Использовать готовые шаблоны также не всегда удобно (затрачивается время на изучение требований к этим шаблонам и т. п.). Кроме того, полученный код хотелось бы использовать на нескольких ОС. Поэтому я остановил свой выбор на продукте, предназначенном для создания кроссплатформенных приложений FLTK (Fast Light ToolKit). Почему он называется именно так, и чем интересен, вы узнаете, ознакомившись с данным материалом.

программирование Краткая предыстория Изначально пакет разрабатывал Bill Spitzak как удобную и быструю альтернативу существовавшим тогда монстрам. Во время работы в Sun Microsystems и Digital Domain концепция FLTK неоднократно перерабатывалась и дополнялась. Некоторые идеи были заимствованы из NeXT, NeWS, Forms. Само название несколько раз трансформировалось, была даже попытка назвать продукт как FL, но из-за того, что в поисковых машинах слово FL в первую очередь интерпретировалось как обозначение штата Флорида (FL), было решено придумать другое название. В итоге получилось то, что известно под акронимом FLTK (Full-Tick). Для сегодняшнего обзора необходимо вооружиться следующим инструментарием – самим пакетом FLTK, компилятором gcc, интегрированной средой разработки Eclipse, продуктом для Win32 платформы Microsoft Visual Studio 6.0 и симпатичной кроссплатформенной библиотекой для работы с PNG-графикой – pngwriter. Будем использовать версию 1.1.5 (последняя стабильная ветка) [1]. Что касается компилятора, то надеюсь, что инструментарий разработчика вы уже поставили. Если нет, то следует поставить пакеты gcc и g++. А также пригодится make. Следует сказать огромное спасибо фирме IBM за интегрированную среду разработки Eclipse. Мало того, что компания предоставляет исходники продукта на всеобщее обозрение, так он еще и предназначен для работы на нескольких аппаратных и программных платформах. Среди них: Windows 98/ME/2000/XP, Linux (x86/Motif, GTK 2), Linux (AMD 64/GTK 2), Solaris 8 (SPARC/Motif), AIX (PPC/Motif), HPUX (HP9000/Motif), Mac OSX (Mac/Carbon). Данное ПО основано на Java, поэтому убедитесь, что в вашей системе установлена версия JRE не ниже 1.4. Среди недостатков решений, основанных на Java, стоит отметить жадность к ресурсам и не блещущее быстродействие. Я использовал при работе Eclipse версии 2.1.3. На момент написания статьи выпущена версия 3.0.1, но для наших ознакомительных целей вполне подойдет и вторая версия. Информация о том, с каких сайтов можно загрузить данное ПО, есть по адресу: http://download.eclipse.org/downloads, ht tp://download.eclipse.org/downloads/drops/R-2.1.3200403101828/eclipse-SDK-2.1.3-linux-gtk.zip (65 Мб). Это только основное ядро. Теперь заберем дополнительный пакет для C/C++ разработки. Он называется CDT (C/C++ Development Tool): http://www.eclipse.org/tools/downloads.html, http://download.eclipse.org/tools/cdt/updates/release/dist/cdtfull-1.2-linux-gtk.zip (3 Мб). Также для второй версии Eclipse существует пакет русификации. Насколько хорошо он переведен, не берусь судить, т.к. причин опробовать его пока не возникало. По умолчанию в Eclipse не используется CDT. Его нужно устанавливать дополнительно. То есть распаковать архив cdt-full-1.2-linux-gtk.zip и положить содержимое из каталогов «plugins» и «features» в установленную директорию с Eclipse. В главной директории Eclipse уже существуют такие каталоги – в них и нужно положить распакованные файлы. Однако вышел вот какой казус – Eclipse не распознал добавленных расширений по неизвестной для меня причине. Поэтому я поступил следующим образом. Создал сим-

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

волические ссылки на файлы CDT, и вот что получилось в директории features: drwxr-xr-x org.eclipse.cdt_1.2.1 lrwxrwxrwx org.eclipse.cdt_2.1.3 -> org.eclipse.cdt_1.2.1 drwxr-xr-x org.eclipse.cdt.linux.gtk_1.2.1 lrwxrwxrwx org.eclipse.cdt.linux.gtk_2.1.3 -> org.eclipse.cdt.linux.gtk_1.2.1 drwxr-xr-x org.eclipse.cdt.linux.motif_1.2.1 lrwxrwxrwx org.eclipse.cdt.linux.motif_2.1.3 -> org.eclipse.cdt.linux.motif_1.2.1 drwxr-xr-x org.eclipse.cdt.make_1.2.1 lrwxrwxrwx org.eclipse.cdt.make_2.1.3 -> org.eclipse.cdt.make_1.2.1 drwxr-xr-x org.eclipse.cdt.managedbuilder_1.2.1 lrwxrwxrwx org.eclipse.cdt.managedbuilder_2.1.3 -> org.eclipse.cdt.managedbuilder_1.2.1 drwxr-xr-x org.eclipse.cdt.qnx.photon_1.2.1 lrwxrwxrwx org.eclipse.cdt.qnx.photon_2.1.3 -> org.eclipse.cdt.qnx.photon_1.2.1 drwxr-xr-x org.eclipse.cdt.solaris.motif_1.2.1 lrwxrwxrwx org.eclipse.cdt.solaris.motif_2.1.3 -> org.eclipse.cdt.solaris.motif_1.2.1 drwxr-xr-x org.eclipse.cdt.source_1.2.1 lrwxrwxrwx org.eclipse.cdt.source_2.1.3 -> org.eclipse.cdt.source_1.2.1 drwxr-xr-x org.eclipse.cdt.win32_1.2.1 lrwxrwxrwx org.eclipse.cdt.win32_2.1.3 -> org.eclipse.cdt.win32_1.2.1 drwxrwxr-x org.eclipse.jdt_2.1.3 drwxrwxr-x org.eclipse.jdt.source_2.1.3 drwxrwxr-x org.eclipse.pde_2.1.3 drwxrwxr-x org.eclipse.platform_2.1.3 drwxrwxr-x org.eclipse.platform.linux.gtk_2.1.3 drwxrwxr-x org.eclipse.platform.linux.gtk.source_2.1.3 drwxrwxr-x org.eclipse.platform.source_2.1.3 drwxrwxr-x org.eclipse.sdk.linux.gtk_2.1.3

Аналогичным образом следует поступить и для директории plugins. При таком варианте уже возможно создание проекта на C/C++. Что касается графики, то я решил выбрать pngwriter по следующим причинам: отсутствует проблема с лицензированием, формат PNG на сегодняшний день широко распространен, и понравились функции для работы с графикой в данном пакете. Документация, идущая с pngwriter [2], достаточно широко освещает аспекты сборки как под Linux, так и под Win32. С другими ОС проблем не будет, если в системе есть компилятор: http://heanet.dl.sourceforge.net/sourceforge/ pngwriter/pngwriter-0.5.0.tgz (640 Кб). Также, надеюсь, у вас не возникнет проблем с Microsoft Visual Studio 6.0. Теперь главный герой сегодняшнего эпоса – FLTK. tar xzvf fltk-1.1.5-source.tar.bz2 cd fltk-1.1.5 ./configure --prefix=/usr/local/fltk-1.1.5 --enable-xft ↵ --enable-threads

Если мультипоточность в FLTK не нужна, то можно не использовать опцию «--enable-threads». То же самое касается и улучшенной поддержки шрифтов (антиалиасинг) – опция «--enable-xft». make && make install

В итоге получились следующие библиотеки в директории /usr/local/fltk-1.1.5/lib: -rw-r--r-- libfltk.a -rw-r--r-- libfltk_forms.a lrwxrwxrwx libfltk_forms.so -> libfltk_forms.so.1.1 -rwxr-xr-x libfltk_forms.so.1.1 -rw-r--r-- libfltk_gl.a lrwxrwxrwx libfltk_gl.so -> libfltk_gl.so.1.1 -rwxr-xr-x libfltk_gl.so.1.1 -rw-r--r-- libfltk_images.a lrwxrwxrwx libfltk_images.so -> libfltk_images.so.1.1 -rwxr-xr-x libfltk_images.so.1.1 lrwxrwxrwx libfltk.so -> libfltk.so.1.1 -rwxr-xr-x libfltk.so.1.1

Сборка pngwriter еще проще.

программирование tar xzvf pngwriter-0.5.0.tgz cd pngwriter make && make install

Пакет устанавливается в /usr/local/lib/ и в /usr/local/ include. Для более подробной информации обращайтесь к файлу README из этого пакета. Теперь немного забежим вперед и создадим наше первое приложение на FLTK. В первую очередь следует обращаться к демо-программам, которые скомпилировались вместе с самим пакетом FLTK. Их можно найти в директории fltk-1.1.5/test. Написано доступно и просто. Тем, кто сталкивался с программированием на MFC или на QT/GTK, будет понятна идеология callback (т.е. реакция на события). В частности, в QT используется аналог системы callback – пара сигнал/слот. Фактически это более гибкое решение (нежели реальные callback-функции), которое позволяет любому объекту присвоить свойство реагировать на сигнал. В GTK также используется система callback, так называемая пара signal/callback. Более полную информацию можно почерпнуть из [7-10]. Если нужен справочник классов и методов, то fltk-1.1.5/ documentation – хороший источник получения информации. В принципе на самом сайте FLTK можно забрать справочник в PDF-формате. Рассмотрим самый простой файл на FLTK. My_CPP_Test.cpp // HEADERS #include <FL/Fl.H> #include <FL/Fl_Window.H> #include <FL/Fl_Menu_Bar.H> #include <FL/Fl_File_Chooser.H> // GLOBALS Fl_Menu_Bar Fl_File_Chooser #define

*m; *fc;

FONT_SIZE

void fc_callback(Fl_File_Chooser *fc, void *data) { if(fc->value()) { printf( "Chosen file: \"%s\"\n", fc->value() ); } }

return;

void open_cb(Fl_Widget*, void*) { fc->callback(fc_callback); fc->show(); while(fc->shown()) Fl::wait(); if( fc->count() == 1 ) { printf("File was selected\n"); } } void quit_cb(Fl_Widget*, void*) { exit(0); } Fl_Menu_Item MenuEng[] = { { "&File", { "&Open", { "&Save",

0, 0, 0, FL_SUBMENU }, FL_CTRL + 'o', (Fl_Callback *)open_cb }, FL_CTRL + 's', 0 },

{ "E&xit", { 0 },

};

FL_CTRL + 'q', (Fl_Callback *)quit_cb, 0 },

{ "&Help", 0, 0, 0, FL_SUBMENU }, { "&About", FL_CTRL + 'a' , 0 }, { 0 }, { 0 }

int main(int argc, char **argv) { Fl_Window *window = new Fl_Window(300, 300, "Sample"); window->color(FL_WHITE); m = new Fl_Menu_Bar(0, 0, 640, 25); m->copy(MenuEng); m->box(FL_UP_BOX); m->textcolor(FL_BLUE); m->textfont(FL_TIMES); m->textsize(FONT_SIZE); fc = new Fl_File_Chooser(".", "*.{txt,cpp}", ↵ Fl_File_Chooser::SINGLE, "File_Chooser_Dialog"); window->show(); window->callback( (Fl_Callback *)quit_cb, window ); return Fl::run(); }

Кто есть кто в данном примере? Подключаются только необходимые файлы из комплекта FLTK. В нашем случае – это Fl.H, Fl_Window.H, Fl_Menu_Bar, Fl_File_Chooser.H. Первый файл необходимо включать при создании любого приложения на FLTK, второй отвечает за создание объекта Fl_Window *window. Понятно, что для создания объекта Fl_Menu_Bar *m мы подключили FL_Menu_Bar. Идеология достаточно понятна на данном этапе. Далее мы объявляем глобальные переменные m, fc – доступ к классам этих объектов будет производиться не только из функции main(). Следующим шагом идет объявление callback-функций. Они отвечают за реакцию на события. В нашем примере fc_callback(), open_cb() участвуют в процессе открытия файлового диалога, а функция quit_cb() отвечает за завершение всего приложения. Далее мы заполняем структуру меню. {"&File", { "&Open", { "&Save", { "E&xit", { 0 },

0, 0, 0, FL_SUBMENU }, FL_CTRL + 'o', (Fl_Callback *)open_cb }, FL_CTRL + 's', 0 }, FL_CTRL + 'q', (Fl_Callback *)quit_cb, 0 },

В частности данный элемент означает следующее – создается пункт в меню под названием «File». При этом быстрый вызов осуществляется по клавише <Alt+F> (на что указывает знак амперсанда – «&File»). В состав пункта «File» входят следующие подпункты – «Open», «Save», «Exit». Горячая клавиша указывается в шаблоне вида FL_CTRL + «X», где «X» – название клавиши. В данном случае при нажатии на клавишу <Ctrl+O> будет вызвана callback-фунция open_cb(). Если на месте callback-функции «0», то никакая функция не привязана к данному событию. Переходим к функции main(). В её теле мы создаем объект окна Fl_Window *window. Инициализируем его с параметрами (300, 300, «Sample») – соответственно ширина, высота, заголовок окна. Также создается и инициализируется

программирование объект типа меню. В этом объекте изменяются тип шрифта и его размер. Инициализируем объект Fl_File_Chooser. Показываем созданное творение – window → show(). Привязываем callback-фунцию quit_cb() на закрытие приложения. И наконец вызываем обработчик событий для всего созданного приложения – return Fl::run(). Если некоторые параметры остались для вас непонятными – обращайтесь к документации. Вполне возможно, что в версии, которую вы будете использовать, будут изменены некоторые параметры (это характерно для следующей версии FLTK 2.0). Оформим данный файл как My_CPP_Test.cpp. И создадим make-файл для компиляции программы.

Как видите, некоторые символы дистрибутива того времени (4 года назад) не были определены, поэтому я вижу 2 варианта решения проблемы: собирать программу полностью со статическими библиотеками либо собирать FLTK на основе старого дистрибутива и там же компилировать. Насколько это удобно в каждом конкретном случае, решать всё-таки разработчику. Итак, мы знаем, как написать программу, но по мере накопления дополнительных свойств она разрастается, и встает вопрос удобства и функциональности дальнейшей разработки. В этой связи удобнее будет использовать IDE Eclipse.

Makefile FLTK=/usr/local/fltk/bin/fltk-config OPTIONS=--compile My_CPP_Test: $(FLTK) $(OPTIONS) My_CPP_Test.cpp clean: rm My_CPP_Test rebuild: make clean; make My_CPP_Test

Теперь, запустив команду make, вы скомпилируете это тестовое приложение. У меня оно получилось размером примерно в 400 Кб. Посмотрим на него чуточку внимательнее. bash-2.05b$ file My_CPP_Test My_CPP_Test: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

Уберем лишнюю отладочную информацию и посмотрим, от каких библиотек зависит наше новое приложение. bash-2.05b$ strip My_CPP_Test

В итоге приложение теперь «похудело» до 240 Кб.

Ðèñóíîê 1. Îáùèé âèä Eclipse

Для создания проекта на C или C++ следует поступить следующим образом – выбрать меню «Window → Open Perspective → C/C++ Development». Тем самым мы настраиваем в Eclipse подсветку синтаксиса, характерную для языковых конструкций С/С++. Создадим пробный проект. «File → New → Project».

bash-2.05b$ ldd My_CPP_Test libm.so.6 => /lib/libm.so.6 (0x40025000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40049000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40057000) libc.so.6 => /lib/libc.so.6 (0x4011e000) libdl.so.2 => /lib/libdl.so.2 (0x40254000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Достаточно симпатично, на мой взгляд. Вполне вероятно, что удастся запустить даже на дистрибутивах Linux, основанных на ядре 2.0.X, не говоря про современные. Что и было протестировано на дистрибутиве SUSE Linux с ядром версии 2.2.18 и сопутствующими библиотеками (libc-2.1.3, ld-2.1.3). Радужные ожидания растаяли при запуске программы ldd: bash-2.05b$ ldd -vr My_CPP_Test libm.so.6 => /lib/libm.so.6 (0x40016000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40033000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4003f000) libc.so.6 => /lib/libc.so.6 (0x400e0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) My_CPP_Test: /lib/libc.so.6: version `GLIBC_2.2.4' not found (required by My_CPP_Test) My_CPP_Test: /lib/libc.so.6: version `GLIBC_2.3' not found (required by My_CPP_Test) symbol __ctype_tolower_loc, version GLIBC_2.3 not defined in file libc.so.6 with link time reference (My_CPP_Test) symbol dl_iterate_phdr, version GLIBC_2.2.4 not defined in file libc.so.6 with link time reference (My_CPP_Test) symbol __ctype_b_loc, version GLIBC_2.3 not defined in file libc.so.6 with link time reference (My_CPP_Test)

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

Ðèñóíîê 2

Выбираем создание проекта на C++ категории Managed Make C++ Project (см. рис. 3). Выбираем имя для проекта «My_Test» (см. рис. 4). А затем придумываем имя для главного файла проекта (см. рис. 5). Проект сконструирован, файл My_CPP_Test.cpp создан, но он пуст и находится в следующей директории ~/eclipse/ workspace.

программирование

Ðèñóíîê 3

Ðèñóíîê 6

Ðèñóíîê 4

Ðèñóíîê 7

Ðèñóíîê 5

Файл My_CPP_Test.cpp создался пустым, поэтому либо скопируем в буфер содержимое нашего примера и вставим из буфера в этот файл. Либо перенесем файл примера в директорию нашего проекта. Eclipse высветит предупреждение о том, что содержимое файла изменилось. Отлично, теперь в настройках проекта нам следует указать, где искать заголовочные файлы (в частности, где расположены заголовочные файлы для FLTK). Заходим «Project → Properties». Заполняем поля, указанные на рис. 6 и 7.

Спрашивается, откуда автор знает, какие именно библиотеки следует использовать. Очень просто. Необходимо запустить программу из комплекта FLTK под названием fltk-config со следующими флагами: «--cflags», «--ldflags» («--ldstaticflags»). В итоге при сборке проекта («Project → Rebuild All») вы должны увидеть показанное на рис. 8. Для того чтобы запустить новое приложение из интегрированной среды, необходимо настроить пункт в меню «Run» (см. рис. 9). В поле «C/C++ Application» указать исполняемый файл (см. рис. 10). Так как сборка производится не со статической библиотекой, а с динамической, то надо указать путь к библиотеке libfltk.so (см. рис. 11). В итоге сборка и дальнейшая разработка вашего продукта приобретает более удобные очертания. Теперь добавим поддержку для pngwriter. Добавим в My_CPP_Test.cpp следующие строки: #include

<pngwriter.h>

программирование void save_cb(Fl_Widget*, void*) { pngwriter iris(300,300,0,"iris.png"); for(int a = 1; a < 301; a++) for(int b = 1; b < 301; b++) iris.plotHSV( a, b, double(a)/500.0, double(b)/500.0, 1.0); iris.setgamma(0.7); iris.close(); }

Ðèñóíîê 11

Потребуется для объявления функций библиотеки pngwriter. Файл фактически находится в /usr/local/include/, поэтому в Makefile надо будет добавить следующую конструкцию: -I/usr/local/include -L/usr/local/lib Ðèñóíîê 8

Добавляем новую процедуру сохранения файла PNGформата. И меняем структуру меню. { "&Save", FL_CTRL + 's', (Fl_Callback *)save_cb },

Теперь осталось изменить Makefile, т.к. pngwriter использует C++ синтаксис. Новый Makefile выглядит следующим образом. FLTK=/usr/local/fltk/bin/fltk-config INCLUDE=`$(FLTK) –cflags` INCLUDE2=-I/usr/local/include -L/usr/local/lib LIBS=`$(FLTK) --ldstaticflags` LIBS2=-lm -lXext -lX11 -lsupc++ -lpng -lpngwriter -lz ↵ –lfreetype FLAGS=-O3 -Wall -Wno-deprecated FLAGS2=-lsupc++ CC=g++

Ðèñóíîê 9

My_CPP_Test: $(CC) $(INCLUDE) $(INCLUDE2) ↵ -o My_CPP_Test My_CPP_Test.cpp $(LIBS) $(LIBS2) clean:# rm My_CPP_Test rebuild: make clean; make My_CPP_Test

Ðèñóíîê 10

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

Библиотека freetype потребовалась из-за того, что сам FLTK собрался с данной поддержкой. На вашей машине может быть по-другому. Предлагаю переключить внимание на Windows и собрать пакет FLTK с использованием компилятора от Microsoft. Смысла компилировать с помощью Microsoft Visual Studio .NET я не увидел и решил воспользоваться предыдущей версией 6.0. Приступим. С помощью WinRAR распакуем архив. Запускаем файл проектов fltk.dsw (он находится в каталоге fltk-1.1.5/visualc) в Microsoft Visual Studio. Выбираем для сборки нужный проект fltk (см. рис. 12).

программирование

Ðèñóíîê 12

Если мы хотим создать DLL-библиотеку, то следует выбрать проект fltkdll. В этом случае программа после компиляции будет меньше, но при этом потребуется внешняя DLLбиблиотека fltkdll.dll. Можно поступить другим образом – собрать LIB-библиотеку. При этом необходимый код будет включен в вашу программу при компиляции. И соответственно программа будет состоять фактически из одного EXE-файла. Следующим шагом нужно определить, какой тип библиотеки необходим – с отладочными символами («Debug») или без отладочных символов («Release»). Допустим, мы хотим собрать без отладочных символов, поэтому выбираем тип библиотеки «Release»:

Ðèñóíîê 13

Запускаем процесс сборки. Конечный результат в виде файла fltk.lib смотрите в каталоге fltk-1.1.5/lib:

Полученные библиотеки необходимо положить в Program Files\Microsoft Visual Studio\VC98\Lib, а заголовочные файлы от FLTK следует положить в Program Files\ Microsoft Visual Studio\VC98\Include (предварительно создав там директорию FL). В общем-то, среда готова для написания программ. Как именно вы организуете представление графической информации – дело вашего вкуса. Импорт графических файлов с помощью FLTK возможен для файлов JPEG, PNG, BMP, XPM. Экспортировать в формате PNG можно в том случае, если вы подключите библиотеку libpngwriter. На основе FLTK развилось несколько проектов. Это и расширение FLTK – проект EFLTK, который умеет работать с базами данных MySQL. Это и SPTK, разрабатываемый, кстати сказать, нашим соотечественником Алексеем Паршиным [5]. С помощью SPTK вы получаете доступ к данным как в Excel-, Access-форме, так и к MySQL-данным. FLU, обладающий некоторыми расширенными опциями для построения виджетов [6]. Среди достоинств FLTK хочу подчеркнуть особенность ясного и понятного построения кода программ. За счет простоты достигаются скорость составления каркаса программы и дальнейшая скорость её выполнения. В некоторой степени программы на основе FLTK являются «мобильными», т.к. вы четко представляете, от каких системных библиотек зависит FLTK. Поэтому разобраться, что требуется для запуска программы в новых условиях, получается намного быстрее, нежели, например, на основе QT. Характерный минус разработки на основе FLTK заключается в его же простоте – некоторых конструкций, которые есть в других средствах разработки, просто нет. Или же они находятся на такой стадии разработки, когда продукт называется unstable (в частности, поддержка UTF8 всё еще находится на стадии разработки). В целом FLTK можно предлагать как продукт для получения начального опыта программирования GUI-приложений. В частности, примеры, расположенные по адресам [11], [12], [13], помогут разобраться в составлении программ на FLTK. Надеюсь, данный опыт покажет вам дальнейшие пути для поиска необходимого инструментария.

Ссылки: 1. 2. 3. 4. 5. 6. 7. 8.

Ðèñóíîê 14

Компилировать библиотеку следует как статическую (расширение файла – .LIB). Полученный итог – файлы pngwriter.lib, zlib.lib, png.lib.

http://www.fltk.org/software.php?SOFTWARE=v1_1 http://pngwriter.sourceforge.net http://pngwriter.sourceforge.net/howto_msvc.php http://yaroslav-v.chat.ru http://sptk.tts-sf.com/index.php http://www.osc.edu/~jbryan/FLU/ http://www.cs.wisc.edu/~cs559-1/tutorials/tutorial4.html http://ib.cnea.gov.ar/~poo/gtkmm-devel-1.2.10/docs/tutorial/ gtkmm-tut-html/tutorial-2.html 9. http://inti.sourceforge.net/tutorial/libinti/advanced eventand signalhandling.html 10. http://www.jtz.org.pl/Inne/QT-Tutorial/signalsandslots.html 11. http://www.cs.virginia.edu/~gfx/Courses/2004/Intro. Spring.04/ProgrammingAssignments/Exercise1 12. http://www.soe.ucsc.edu/classes/cmps160/Spring04 13. http://www.cs.wisc.edu/~cs559-1

образование

CLASS SERVER 3.0 – НОВОЕ РЕШЕНИЕ MICROSOFT В ОБЛАСТИ ОБРАЗОВАНИЯ АНДРЕЙ ФИЛИППОВИЧ 28 октября 2004 г. на презентации в офисе Microsoft было объявлено о выходе русскоязычной версии нового продукта Class Server 3.0. Microsoft позиционирует продукт как новую активно развивающуюся платформу для управления учебным процессом, которая направлена на организацию управления учебными материалами и планами (включая их хранение и распространение), проведение тестирования учащихся, сбор данных об успеваемости и взаимодействие всех участников учебного процесса через Интернет. Несмотря на то что доклад Дмитрия Старостина (консультанта Microsoft Consulting Services) был практически полностью построен на иллюстрации возможностей использования продукта в рамках школьного обучения, Роман Кузнецов (менеджер по работе с образовательными и правительственными организациями) особо подчеркнул возможность использования Class Server в высшем образовании, в корпорациях и органах управления образованием. Надо отметить, что понимание учебного процесса в рамках системы очень узко – оно подразумевает только четыре абстрактные роли пользователей (администрация, учителя, учащиеся и родители) и простейшую схему взаимодействия, представленную на рисунке.

Под учебным планом подразумевается программа (содержание) курса или дисциплины, которая не содержит ни разбиения на виды учебной нагрузки, ни привязки к часам или кредитам. Последний факт особенно удивителен, т.к. по утверждению специалистов Microsoft продукт активно внедряется на Западе, где повсеместно используется кредитно-модульная система образования. Class Server на данный момент времени нельзя отнести к классу автоматизированных систем управления учебным

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

заведением (АСУ вуз, АСУ колледж, АСУ школа и т. д.) или считать перспективной платформой для их построения, однако новый продукт Microsoft сочетает в себе черты систем дистанционного образования, электронного обучения (elearning) и построения портальных решений. Системы дистанционного и электронного обучения достаточно широко представлены на российском рынке программных продуктов и по возможностям сильно превосходят решение Microsoft. Однако ни одно из них не может выступать в качестве платформы, интегрированной с множеством средств разработки. Class Server входит в состав платформы Microsoft.Net и предоставляет все ее возможности, имеет широкий набор XML веб-сервисов и совместим с такими международными стандартами, как SIF (Schools Interoperability Framework), SCORM (Sharable Content Object Reference Model), IMS (Instructional Management Standards). Другим важным преимуществом Class Server является его непосредственная связь с Microsoft Learning Gateway – порталом, выступающим в качестве базовой структуры для объединения через Интернет разнообразных решений в области образования в единую, полностью управляемую среду, содержащую до 1 млн. пользователей. Портал построен на основе платформ Microsoft Office SharePoint Portal Server 2003 и SharePoint Services, предоставляет необходимые сведения и услуги в соответствии с настроенными пользовательскими ролями. Для организации обмена сообщениями электронной почты, управления личной информацией, включая календарь и список задач, а также предоставления других услуг в области обмена данными используется Microsoft Exchange Server 2003. Microsoft Live Communications Server обеспечивает взаимодействие в режиме реального времени с помощью немедленных сообщений. В заключение следует отметить, что, на мой взгляд, новая разработка Microsoft прежде всего ориентирована на использование в рамках учебного процесса школы и мало адаптирована для применения в высших учебных заведениях. Это вызвано наличием в вузах большого количества сложных бизнес-процессов, включающих множество участников, схем оценивания, средств мониторинга и методик управления. Возможность эффективного использования Class Server у корпоративных заказчиков пока маловероятна, так как вопрос взаимодействия с ERP- и CRM-системами предприятий в рамках интеграции с отдельными модулями еще не решен. Более подробную информацию о продукте можно узнать по адресу: http://www.microsoft.com/rus/education/ClassServer.

образование

ФАЙЛОВАЯ СИСТЕМА NTFS ИЗВНЕ И ИЗНУТРИ Покажи мне свои структуры данных, и я скажу, кто ты! Народная программистская мудрость

В этой статье мы рассмотрим основные структуры данных файловой системы NTFS, определяющие ее суть – главную файловую запись MFT, файловые записи FILE Record и последовательности обновления (update sequence или fix-ups), без знания которых осмысленная работа с редактором диска и ручное/полуавтоматическое восстановление данных просто невозможны!

КРИС КАСПЕРСКИ Файловую систему NTFS принято описывать как сложную реляционную базу данных, обескураживающую грандиозностью своего архитектурного замысла не одно поколение начинающих исследователей. NTFS похожа на огромный, окутанный мраком лабиринт, в котором очень легко заблудиться. Хакеры давно разобрались с основными структурами данных, осветив магистральные коридоры лабиринта светом множества факелов. Боковые ответвления разведаны намного хуже и все еще находятся по власти тьмы, хранящей множество смертоносных ловушек, ждущих своих исследователей. В общем, если NTFS-«читалку» можно запрограммировать буквально за один вечер (с отладкой!), писать на NTFS-тома еще никто не рисковал. К счастью, никто не требует от нас написания полноценного NTFS-драйвера! Наша задача значительно скромнее – вернуть разрушенный том в состояние, пригодное для восприятия операционной системой (задача-максимум) или извлечь из него все ценные файлы (задача-минимум). Вникать в структуру журналов транзакций, дескрипторов безопасности, двоичных деревьев индексаций для этого совершенно необязательно! Реально нам потребуется разобраться лишь с устройством главной файловой записи – MFT и нескольких дочерних подструктур.

Обзор NTFS с высоты птичьего полета Основным структурным элементом всякой файловой системы является том (volume), в случае с FAT совпадающий с разделом (partition), о котором мы говорили в прошлой ста-

тье [1, 2]. NTFS поддерживает тома, состоящие из нескольких разделов. Подробнее схему отображения томов на разделы мы обсудим в следующей статье этого цикла, а пока же будем для простоты считать, что том представляет собой отформатированный раздел (т.е. раздел, содержащий служебные структуры файловой системы).

Ðèñóíîê 1. Îáû÷íûé (ñëåâà) è ðàçðÿæåííûé (ñïðàâà) òîìà

Большинство файловых систем трактуют том как совокупность файлов, свободного дискового пространства и служебных структур файловой системы, но в NTFS все служебные структуры представлены файлами, которые (как это и положено файлу) могут находиться в любом месте тома, при необходимости фрагментируя себя на несколько частей.

образование Самым главным служебным файлом является $MFT – Master File Table (главная файловая таблица) – своеобразная база данных, хранящая информацию обо всех файлах тома – их именах, атрибутах, способе и порядке размещения на диске (каталог также является файлом особого типа, со списком принадлежащих ему файлов и подкаталогов внутри). Важно подчеркнуть, что в MFT присутствуют все файлы, находящиеся во всех подкаталогах тома, поэтому для восстановления диска наличия $MTF-файла будет вполне достаточно. Остальные служебные файлы (кстати говоря, называемые метафайлами или метаданными – metafile/metadata соответственно и всегда предваряются знаком доллара «$») носят сугубо вспомогательный характер, интересный только самой файловой системе. К ним в первую очередь относятся: $LogFile – файл транзакций, $Bitmap – карта свободного/занятого пространства, $BadClust – перечень плохих кластеров и т. д. (Подробнее о назначении каждого из файлов будет рассказано в следующей статье). Текущие версии Windows блокируют доступ к служебным файлам с прикладного уровня (даже с правами администратора!), и всякая попытка открытия/создания такого файла в корневом каталоге обречена на неуспех. Классическое определение, данное в учебниках информатики, отождествляет файл с именованной записью на диске. Большинство файловых систем добавляет к этому понятие атрибута (attribute) – некоторой вспомогательной характеристики, описывающей время создания, права доступа и т. д. В NTFS имя файла, данные файла и его атрибуты полностью уравнены в правах. Можно сказать, что всякий NTFS-файл представляет собой совокупность атрибутов, каждый из которых хранится как отдельный поток (streams) байтов, поэтому во избежание путаницы атрибуты, хранящие данные файла, часто называют потоками. Каждый атрибут состоит из тела (body) и заголовка (header). Атрибуты делятся на резидентные (resident) и нерезидентные (non-resident). Резидентные атрибуты хранятся непосредственно в $MTF, что существенно уменьшает грануляцию дискового пространства и сокращает время доступа. Нерезидентные – хранят в $MTF лишь свой заголовок, описывающий порядок размещения атрибута на диске. Назначение атрибута определяется его типом (type) – четырехбайтовым шестнадцатеричным значением. При желании атрибуту можно дать еще и имя (name), состоящее из символов, входящих в соответствующее пространство имен. Подавляющее большинство файлов имеет по меньшей мере три атрибута: стандартная информация о файле (время создания, модификации последнего доступа, права доступа и т. д.) хранится в атрибуте типа 10h, ус-

ловно обозначаемом $STANDARD_INFORMATION. Ранние версии Windows NT позволяли обращаться к атрибутам по их условным обозначениям, однако Windows 2000 и Windows XP лишены этой возможности. Полное имя файла (не путать с путем!) хранится в атрибуте типа 30h ($FILE_NAME). Если у файла есть одно или более альтернативных имен (например, MS-DOS-имя), таких атрибутов может быть несколько. Здесь же хранится ссылка (file reference) на материнский каталог, позволяющая разобраться, к какому каталогу данный файл/подкаталог принадлежит. Данные файла по умолчанию хранятся в безымянном атрибуте типа 80h ($DATA), однако при желании прикладные приложения могут создавать дополнительные потоки данных, отделяя имя атрибута от имени файла знаком двоеточия, например: ECHO xxx > file:attr1; ECHO yyy > file:attr2; ↵ more < file:attr1; more < file:attr2

Изначально в NTFS была заложена способность индексации любых атрибутов, значительно сокращающая время поиска файла по заданному списку критериев (например, времени последнего доступа). Внутренние индексы хранятся в виде двоичных деревьев, поэтому среднее время выполнения запроса оценивается как O(lg n). Однако в текущих NTFS-драйверах реализована индексация лишь по одному атрибуту – имени файла. Как уже говорилось выше, каталог представляет собой особенный файл – файл индексов (INDEX). В отличие от FAT, где файл каталога представляет единственный источник данных об организации файлов, в NTFS он используется лишь для ускорения доступа к содержимому директории и не является обязательным, поскольку ссылка на материнский каталог всякого файла в обязательном порядке присутствует в атрибуте его имени ($FILE_NAME). Каждый атрибут может быть зашифрован, разряжен или сжат. Однако техника работы с такими атрибутами выходит далеко за рамки первичного знакомства с организацией файловой системы и будет рассмотрена позднее. А пока же мы углубимся в изучение фундамента файловой системы – структуры $MFT.

Главная файловая запись (master file table) В процессе форматирования логического раздела, в его начале создается так называемая MTF-зона (MFT-zone), по умолчанию занимающая 12,5% от емкости тома (а вовсе не 12%, как утверждается во многих публикациях), хотя в зависимости от значения параметра NtfsMftZoneReservation она может составлять 25%, 37% или 50%. В этой области расположен $MFT-файл, изначально занимающий порядка 64 секторов и растущий от начала

Версии NTFS Служебные структуры файловой системы NTFS не остаются постоянными, а слегка меняются от одной версии Windows NT к другой (см. таблицу 1). Этот факт следует принять во внимание при использовании автоматизированных «докторов». Попав на более свежую версию NTFS, «доктор», не оснащенный мощным AI, может запутаться в

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

измененных структурах и разрушить вполне здоровый том. Òàáëèöà 1. Îïðåäåëåíèå âåðñèè NTFS ïî îïåðàöèîííîé ñèñòåìå

образование MFT-зоны к ее концу по мере создания новых пользовательских файлов/подкаталогов. Таким образом, чем больше файлов содержится на дисковом томе, тем больше размер MFT. Приблизительный размер $MFT-файла можно оценить по следующей формуле: sizeof(FILE Record) N Files, где sizeof(FILE Record) обычно равен 1 Кб, а N Files – полное количество файлов/подканалов раздела, включая недавно удаленные. Для предотвращения фрагментации $MFT-файла MFTзона удержится зарезервированной вплоть до полного исчерпания свободного пространства тома, затем незадействованный «хвост» MFT-зоны усекается в два раза, освобождая место для пользовательских файлов. Этот процесс может повторяться многократно, вплоть до полной отдачи всего зарезервированного пространства. Решение красивое, хотя и не новое. Многие из файловых систем восьмидесятых позволяли резервировать заданное дисковое пространство в хвосте активных файлов, тем самым сокращая их фрагментацию (причем любых файлов, а не только служебных). В частности, такая способность была у DOS 3.0, разработанной для персональных компьютеров типа Агат. Может, кто помнит такую машину? Когда $MFT-файл достигает границ MFT-зоны, в ходе своего последующего роста он неизбежно фрагментируется, вызывая обвальное падение производительности файловой системы, причем подавляющее большинство дефрагментаторов $MFT-файл не обрабатывают! А ведь API дефрагментации, встроенное в штатный NTFS-драйвер, это в принципе позволяет! Подробности (вместе с самой утилитой дефрагментации) можно найти на сайте Марка Руссиновича. Но, как бы то ни было, заполнять дисковый том более чем на 88% его емкости категорически не рекомендуется! При необходимости $MFT-файл может быть перемещен в любую часть диска, и тогда в начале тома его уже не окажется. Стартовый адрес $MFT-файла хранится в Boot-секторе по смещению 30h байт от его начала (см. «boot-сектор», описанный в предыдущей статье данного цикла) и в подавляющем большинстве случаев этот адрес ссылается на 4-й кластер.

Ðèñóíîê 2. Ñòðóêòóðà äèñêîâîãî òîìà ïîä NTFS

$MFT-файл представляет собой массив записей типа FILE Record (или в терминологии UNIX – inodes), каждая из которых описывает соответствующий ей файл или подкаталог (подробнее см. раздел «Файловые записи»). В подавляющем большинстве случаев файл/подкаталог полностью описывается одной-единственной записью FILE

Record, хотя теоретически этих записей может потребоваться и несколько. Для ссылки на одну файловую запись из другой используется ее порядковый номер (он же индекс) в $MFT-файле, отсчитываемый от нуля. Файловая ссылка (file reference) состоит из двух частей (см. таблицу 2) – 48-битного индекса и 16-битного номера последовательности (sequence number). При удалении файла/каталога соответствующая ему файловая последовательность помечается как неиспользуемая. При создании новых файлов записи, помеченные как неиспользуемые, могут задействоваться вновь, при этом счетчик номера последовательности, хранящийся внутри файловой записи, увеличивается на единицу. Этот механизм позволяет отслеживать «мертвые» ссылки на уже удаленные файлы – очевидно, sequence number внутри file reference будет отличаться от номера последовательности соответствующей файловой записи (этой проверкой занимается утилита chkdsk и автоматически, насколько мне известно, она не выполняется). Òàáëèöà 2. Ñòðóêòóðà ôàéëîâîé ññûëêè (file reference)

Первые 12 записей в MFT всегда занимают служебные метафайлы: $MFT (собственно, сам $MFT), $MFTMirr (зеркало $MFT), $LogFile (файл транзакций), $Volume (сведения о дисковом томе), $AttrDef (определенные атрибуты), «.» (корневой каталог), $Bitmap (карта свободного пространства), $Boot (системный загрузчик), $BadClus (перечень плохих кластеров) и т. д. Первые четыре записи настолько важны, что продублированы в специальном $MFTMirr-файле, находящемся приблизительно посередине диска (точное расположение хранится в boot-секторе по смещению 38h байт от его начала). Вопреки своему названию, $MFTMirr – это отнюдь не зеркало всего $MFT-файла, это всего лишь копия первых четырех элементов. Записи с 12 по 15 помечены как используемые, но в действительности же они пусты (как нетрудно догадаться, это задел на будущее). Записи с 16 по 23 не задействованы и честно помечены как неиспользуемые. Начиная с 24-й записи располагаются пользовательские файлы и каталоги. Четыре метафайла, появившихся в W2K – $ObjId, $Quota, $Reparse и $UsnJrnl, могут располагаться в любой записи, номер которой равен 24 или больше (как мы помним, номера файловых записей отсчитываются начиная с нуля). Для знакомства с MFT запустим DiskExplorer от Runtime Software, не забывая о том, что он требует прав администратора, в меню «File» найдем пункт «Drive» и в открывшемся диалоговом окне выберем логический диск, который мы хотим редактировать. Затем в меню «Goto» выберем пункт «Mft», заставляя DiskExplorer перейти к MFT, автоматичес-

Полезный совет Как быстро узнать тип текущего раздела – FAT или NTFS? Да очень просто – достаточно попробовать создать в его корневом каталоге файл $mft – если он будет создан успешно, то это FAT и соответственно наоборот. Если файл $Extend будет создан успешно, то версия файловой системы 3.0 или выше.

образование ки меняя режим отображения на наиболее естественный (см. рис. 3). Как вариант можно нажать <F6> (View as File Entry) и промотать несколько первых секторов клавишей <Page Down>. Для каждого из файлов DiskExplorer сообщает: ! номер сектора, к которому данная файловая запись принадлежит (обратите внимание, что номера секторов монотонно увеличиваются на 2, подтверждая тот факт, что размер одной файловой записи равен 1 Кбайту, однако вы можете столкнуться и с другими значениями). Для удобства информация отображается сразу в двух системах исчисления – шестнадцатеричной и десятичной; ! основное имя файла/каталога (т.е. имя файла из заголовка файловой записи, некоторые файлы имеют несколько альтернативных имен). Если имя файла/каталога зачеркнуто, значит, он был удален, но соответствующая ему файловая запись все еще цела. Чтобы извлечь файл с диска (не важно, удаленный или нет) подведите к нему курсор и нажмите <Ctrl-T> для просмотра его содержимого в шестнадцатеричном виде или <CtrlS> для сохранения файла на диск. То же самое можно сделать и через контекстное меню (раздел «recovery»). При нажатии на <Ctrl-C> в буфер обмена копируется последовательность кластеров, занятых файлом (например, «DISKEXPL:K:1034240-1034240»). ! тип файловой записи – файл это или каталог? ! атрибуты файла/каталога – a = архивный файл, r = только на чтение, h = скрытый, s = системный, l = метка тома, d = каталог, c = сжатый файл; ! размер файла в байтах в десятичной системе исчисления (не для каталогов!); ! дату и время модификации файла/каталога; ! номер первого кластера файла/каталога (или «resident» для полностью резидентных файлов/каталогов); ! перечень типов NTFS-атрибутов, имеющихся у файла/ каталога, записанных в шестнадцатеричной нотации (обычно эта строка имеет вид 10 30 80 – атрибут стандартной информации, атрибут имени и атрибут данных файла); ! индекс файловой записи в MFT, выраженный в шестнадцатеричной и десятичной системах исчисления и следующий за словом «No:» (сокращение от Number – номер); ! индекс файловой записи материнского каталога, выраженный в шестнадцатеричной и десятичной системах исчисления (5h – если файл принадлежит к корневому каталогу). Для быстрого перемещения по файловым записям выберите в меню «Goto» пункт «Mft no» и введите требуемый индекс в шестнадцатеричной или десятичной форме; ! для нерезидентных файлов/каталогов – перечень кластеров, занятых файлов в недекодированном виде (а зря – могли бы и декодировать!). Схема кодирования кластеров будет описана в следующей статье. Прежде чем продолжать чтение статьи, попробуйте поэкспериментировать с $MFT-файлами (особенно фрагментированными). Посмотрите, как создаются и удаляются за-

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

писи из MFT. Лучше всего это делать на диске, содержащем небольшое количество файлов/каталогов. Чтобы не форматировать логический диск, создайте виртуальный (благо количество оперативной памяти современных компьютеров это позволяет).

Ðèñóíîê 3. DiskExplorer îòîáðàæàåò ãëàâíóþ ôàéëîâóþ çàïèñü â åñòåñòâåííîì âèäå

Файловые записи (FILE Record) Благодаря наличию Disk Explorer от Runtime Software с файловыми записями практически никогда не приходится работать вручную, тем не менее знание их структуры нам не помешает. Структурно файловая запись состоит из заголовка (header) и одного или нескольких атрибутов (attribute) произвольной длины, завершаемых маркером конца (end marker) – четырехбайтовым шестнадцатеричным значением FFFFFFFFh (см. листинг 1). Несмотря на то что количество и длина атрибутов меняется от одной файловой записи к другой, размер самой структуры FILE Record строго фиксирован и в большинстве случаев равен 1 Кбайту (это значение хранится в $boot-файле, не путать с boot-сектором!). Причем первый байт файловой записи всегда совпадает с началом сектора. Если реальная длина атрибутов меньше размеров файловой записи, ее хвост просто не используется. Если же атрибуты не вмещаются в отведенное им пространство, создается дополнительная файловая запись (extra FILE Record), ссылающаяся на свою предшественницу. Ëèñòèíã 1. Ñòðóêòóðà ôàéëîâîé çàïèñè FILE Record Header Attribute 1 Attribute 2 ... Attribute N End Marker (FFFFFFFFh)

; ; ; ; ; ;

çàãîëîâîê àòðèáóò 1 àòðèáóò 2 … àòðèáóò N ìàðêåð êîíöà

Первые четыре байта заголовка оккупированы магической последовательностью «FILE», сигнализирующей о том, что мы имеем дело с файловой записью типа FILE Record. При восстановлении сильно фрагментированного $MFT-файла это обстоятельство играет решающую роль, поскольку позволяет отличить сектора, принадлежа-

образование щие MFT, от всех остальных. Следом за сигнатурой идет 16-разрядный указатель, содержащий смещение последовательности обновления (update sequence, см. раздел «Последовательности обновления»). Под «указателем» здесь и до конца раздела подразумевается смещение от начала сектора, отсчитываемое от нуля и выраженное в байтах. В NT и W2K это поле всегда равно 002Ah, поэтому для поиска файловых записей можно использовать сигнатуру «FILE*\x00», что уменьшает вероятность ложных срабатываний. Правда, в XP и более старших системах последовательность обновления хранится по смещению 002Dh, и поэтому сигнатура приобретает следующий вид «FILE-\x00». Размер заголовка (кстати сказать, варьирующийся от одной операционной системы к другой) в явном виде нигде не хранится, вместо этого в заголовке присутствует указатель на первый атрибут, содержащий его смещение в байтах относительно начала FILE Record, расположенный по смещению 14h байт от начала сектора. Смещения последующих атрибутов (если они есть) определяются путем сложения размеров всех предыдущих атрибутов (размер каждого из атрибутов содержится в его заголовке) со смещением первого атрибута. За концом последнего атрибута находится маркер конца – FFFFFFFFh. В добавок к этому длина файловой записи хранится в двух полях – 32-разрядное поле реального размера (real size), находящееся по смещению 18h байт от начала сектора, содержит совокупный размер заголовка, всех его атрибутов и маркера конца, округленный по 8-байтной границе. 32-разрядное поле выделенного размера (allocated size), находящееся по смещению 1Сh байт от начала сектора, содержит действительный размер файловой записи в байтах, округленный по размеру сектора. Документация LinuxNTFS Project (версия 0.4) утверждает, что allocated size должен быть кратен размеру кластера, однако в действительности это не так. В частности, на моей машине allocated size равен четвертинке кластера. 16-разрядное поле флагов, находящееся по смещению 16h байт от начала сектора, в подавляющем большинстве случаев принимает одно из трех следующих значений: 00h – данная файловая запись не используется или ассоциированный с ней файл/каталог удален, 01h – файловая запись используется и описывает файл, 02h – файловая запись используется и описывает каталог. 64-разрядное поле, находящееся по смещению 20h байт от начала сектора, содержит индекс базовой файловой записи. Для первой файловой записи это поле всегда равно нулю, а для всех последующих, расширенных (extra) записей – индексу первой файловой записи. Расширенные файловые записи могут находиться в любых частях MFT, не обязательно рядом с основной записью. А раз так, необходим какой-то механизм, обеспечивающий быстрый поиск расширенных файловых записей, принадлежащих данному файлу (просматривать весь MFT целиком не предлагать). И этот механизм основан на ведении списков атрибутов $ATTRIBUTE_LIST. Список атрибутов представляет собой специальный атрибут, добавляемый к первой файловой записи и содержащий индексы расширенных записей.

Остальные поля заголовка файловой записи не столь важны и поэтому здесь не рассматриваются. При необходимости обращайтесь к документации «Linux-NTFS Project». Òàáëèöà 3. Ñòðóêòóðà çàãîëîâêà ôàéëîâîé çàïèñè (FILE Record)

Последовательности обновления (update sequence) Будучи очень важными компонентами файловой системы, $MFT, INDEX и $LogFile нуждаются в механизме контроля целостности своего содержимого. Традиционно для этого используются ECC/EDC-коды, однако во времена проектирования NTFS процессоры были не настолько быстрыми, как теперь, и расчет корректирующих кодов занимал значительное время, существенно снижающее производительность файловой системы. Поэтому от них пришлось отказаться. Вместо этого разработчики NTFS применили так называемые последовательности обновления (update sequence), так же называемые fix-up. В конец каждого из секторов, слагающих файловую запись (INDEX Record, RCRD Record или RSTR Record) записывается специальный 16-байтовый номер последовательности обновления (update sequence number), дублируемый в заголовке файловой записи. При каждой операции чтения два последних байта сектора сверяется с соответствующим полем заголовка, и если NTFS-драйвер обнаруживает расхождение, данная файловая запись считается недействительной. Основное назначение последовательностей обновления – защита от «обрыва записи». Если в процессе записи сектора на диск исчезнет питающее напряжение, может случиться так, что половина файловой записи будет успешно записана, а другая половина – сохранит прежнее содержимое (файловая запись, как мы помним, обычно состоит из двух секторов). После восстановления питания драйвер

образование файловой системы не может уверенно сказать – была ли файловая запись записана целиком или нет. Вот тут-то последовательности обновления и выручают! При каждой перезаписи сектора update sequence увеличивается на единицу, и потому, если произошел обрыв записи, значение последовательности обновления находящейся в заголовке файловой записи, не будет совпадать с последовательностью обновления, расположенной в конце сектора. Оригинальное содержимое, расположенное «под» последовательностью обновления, хранится в специальном массиве обновления (update sequence array), находящимися в заголовке файловой записи непосредственно за концом update sequence number. Для восстановления файловой записи в исходный вид мы должны извлечь из заголовка указатель на update sequence number (он хранится по смещению 04h байт от начала заголовка) и сверить лежащее по этому адресу 16-байтное значение с последним словом каждого из секторов, слагающих файловую запись (INDEX Record, RCRD Record или RSTR Record). Если они не совпадут, значит соответствующая структура данных повреждена и использовать ее следует с очень большой осторожностью (а на первых порах лучше не использовать вообще). По смещению 006h от начала сектора находится 16разрядное поле, хранящее совокупный размер номера последовательности обновления вместе с массивом последовательности обновления: (sizeof(update sequence number) + sizeif(update sequence array))

выраженный в словах (не в байтах!). Поскольку размер номера последовательности обновления всегда равен одному слову, то размер массива последовательности обновления, выраженный в байтах, равен:

Ëèñòèíã 2. Îðèãèíàëüíàÿ ôàéëîâàÿ çàïèñü äî âîññòàíîâëåíèÿ

Сигнатура «FILE» указывает на начало файловой записи. А раз так, по смещению 04h байт будет расположен 16разрядный указатель на номер последовательности обновления. В данном случае он равен 002Ah. ОК! Переходим по смещению 002Ah и видим, что здесь лежит слово 0006h. Перемещаемся в конец сектора и сверяем его с последними двумя байтами. Как и предполагалось, они совпадают. Повторяем ту же самую операцию со следующим сектором. Собственно говоря, количество секторов может и не равняться двум. Чтобы не гадать на кофейной гуще, необходимо извлечь 16-разрядное значение, расположенное по смещению 06h от начала файловой записи (в данном случае оно равно 0003h) и вычесть из него единицу. Действительно, получается два (сектора). Теперь нам необходимо найти массив последовательности обновления, хранящий оригинальное значение последнего слова каждого из секторов. Смещение массива обновления рассчитывается по следующей формуле: offset of (update sequense number) + 2, т.е. в данном случае 002Ah + 02h == 002Ch. Извлекаем первое слово (в данном случае равное 00h 00h) и записываем его в конец первого сектора, затем делаем то же самое со вторым. В результате чего восстановленный сектор будет выглядеть так: Ëèñòèíã 3. Âîññòàíîâëåííàÿ ôàéëîâàÿ çàïèñü

(update sequence number & update sequence array - 1)*2

Соответственно смещение массива оригинального содержимого равно: (offset to update sequence number) + 2

Заключение В NT и W2K update sequence number всегда располагается по смещению 2Ah от начала FILE Record Header/ INDEX Header, а update sequence array – по смещению 2Сh. В XP же и более старших системах – по смещениям 2Dh и 2Fh соответственно. Первое слово массива последовательности обновления соответствует последнему слову первого сектора FILE Record/INDEX. Второе – последнему слову второго сектора и т. д. Для восстановления сектора в исходный вид мы должны вернуть все элементы массива последовательности обновления на их законные места (естественно, модифицируется не сам сектор, а его копия в памяти). Продемонстрируем это на следующем примере:

Вооруженные джентльменским набором знаний об устройстве файловой записи, в следующей статье этого цикла мы сможем погрузиться внутрь атрибутов, рассмотрев, как хранятся резидентные и нерезидентные потоки данных на жестком диске.

Литература: 1. Касперски К. Востановление данных на NTFS-разделах. – Журнал «Системный администратор», №9, сентябрь 2004г. 2. Касперски К. Востановление данных на NTFS-разделах. Часть 2. – Журнал «Системный администратор», №10, октябрь 2004г.

Внимание! FILE Record, INDEX Record, RCRD Record или RSTR Record искажены последовательностями обновления и в обязательном порядке должны быть восстановлены перед их использованием, в противном случае вместо актуальных данных вы получите мусор!

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

образование

конкурсная статья

РАЗРАБОТКА СЦЕНАРИЯ РЕГИСТРАЦИИ ПОЛЬЗОВАТЕЛЕЙ В СЕТИ ЧАСТЬ1

ИВАН КОРОБКО На протяжении года в своих статьях я рассказывал о том, как автоматизировать различные процессы в сети, упростить администрирование. Решение поставленной задачи нетривиально и состоит из нескольких частей. Одной из них является сценарий регистрации пользователей в сети. Этот вопрос был частично рассмотрен в одной из предыдущих статей [1]. Она носила концептуальный характер, однако на форуме читатели дали понять, что концепция – это хорошо, но необходимо привести конкретный пример – скрипт. Пришла пора сложить недостающие кусочки мозаики в одно целое и подробно рассказать о теоретических и практических аспектах его создания, особенностях внедрения. Назовем основные из них: ! Инвентаризация. Включает в себя сбор информации о регистрирующемся в сети пользователе, рабочей станции и формирование файла отчета. ! Автоматическое подключение сетевых ресурсов: принтеров и дисков. ! Автоматическое конфигурирование рабочих станций. ! Обеспечение интерактивности работы скрипта. В ходе выполнения скрипта на экране отображается соответствующая информация. После его выполнения пользователь может ознакомиться с подключенными ресурсами, информацией о рабочей станции и т. д. Прежде чем приступить к созданию скрипта, необходимо сказать несколько слов о языке программирования, с помощью которого он будет создан.

KIXTart Для создания сценариев регистрации пользователей существует множество языков, однако остановим свой выбор на языке KIXTart. Он является стандартным языком программирования сценариев компании Microsoft. Его дистрибутив можно найти в Microsoft Resource Kit или бесплатно загрузить последнюю версию из сети Интернет (http://kixtart.org). Замечание. Сценарии, созданные вами ранее на VBScript, Jscript могут быть легко переписаны под KIXtart. Все примеры в этой статье написаны на языке KIXTart. Думаю, что нет необходимости описывать преимущества этого языка перед VBScript или каким-нибудь другим языком. Стоит лишь отметить, что KIXtart разрабатывался исключительно для создания сценариев, с помощью которых пользователи регистрировались бы в сети. KIXTart версии 4.21 поддерживает около 100 функций, столько же макросов-функций и обладает следующими возможностями: 1

! ! ! ! ! ! ! ! ! !

вывод информации в виде диалоговых сообщений; подключение сетевых ресурсов; чтение информации из входного потока; расширенная поддержка редактирования реестра (работа с локальным и удаленным реестром, поддержка операций с кустами (hives)); поддержка INI-файлов; расширенная поддержка операций со строками и массивами (поддержка статических и динамических, многомерных массивов); сбор информации о пользователе и рабочей станции; поддержка OLE-объектов; операции с файлами и каталогами; создание ярлыков Windows.

Решение задачи инвентаризации Введение Решение этой задачи состоит из нескольких частей – сбора, записи на носитель в определенном формате и обработки информации. Две первые подзадачи можно реализовать с помощью сценария загрузки, третья реализуется с помощью дополнительного программного обеспечения. Собираемая информация касается программного и аппаратного обеспечения, характеристик учетной записи пользователя, регистрирующегося в сети. Собираемые данные можно условно разделить на две части. К первой части относится информация об аппаратном и программном обеспечении. Данные об аппаратном обеспечении черпаются из WMI, а о программном – из реестра либо с помощью WMI, либо с помощью KIXTart1. Вторая часть – информация, характеризующая положение рабочей станции в сети. К ней также относятся свойства учетной записи текущего пользователя. Эта половина реализуется с помощью макросов, встроенных в KIXTart, и чтения полей Active Directory. Для решения задачи инвентаризации нам необходимо осветить следующие темы. ! чтение разделов WMI; ! управление реестром с помощью KIXTart; ! использование макросов KIXTart; ! чтение полей из Active Directory; ! формирование файла отчета. Вопреки ожиданиям читателя я начну описывать решение задачи инвентаризации с конца, т.е. с формирования файла отчета. Это позволит избежать лишних вопросов и недопонимания излагаемого материала при иллюстрировании теории наглядными примерами.

Рекомендуется использовать встроенные функции KIXTart, поскольку нет смысла искусственно усложнять и увеличивать листинг скрипта.

образование Формирование файла отчета. Теория

Формирование файла отчета. Практика

Отчеты о работе сценария регистрации пользователей в сети рекомендуется формировать в формате XML. Основная причина, по которой стоит обратить внимание на XML, заключается в том, что он используется как базами данных, так и интернет-приложениями при работе с браузером. При использовании XML на рабочую станцию пользователя отдельно передаются данные и отдельно правила интерпретации этих данных для отображения с помощью, например, Jscript или VBScript. В нашем случае XML-файл будет содержать только данные. Как и HTML, XML является независимым от платформы стандартом. С полным вариантом спецификации XML можно ознакомиться на http://www.w3c.org/xml. Внешне XML-документ очень похож на HTML-документ, т.к. XML-элементы также описываются с помощью ключевых слов – тегов. Однако, в отличие от HTML, в XML пользователь может создавать собственные элементы. Теги XML определяют структурированную информацию. Синтаксис элементов (тегов), составляющих структуру XML-файла, в общем виде можно представить следующим образом:

Процесс формирования отчета состоит из двух частей: накопления данных в переменную и запись значения переменной в XML-файл.

Приведем несколько основных правил, которыми необходимо руководствоваться при создании XML-документов: ! Документ состоит из элементов разметки (markup) и непосредственно данных (content). ! Все элементы описываются с помощью тегов. ! В заголовке документа должны быть идентификационные данные: используемый язык разметки, его версия, кодировка страницы и т. д. Заголовок описывается с помощью тега <%..... %>. ! В XML учитывается регистр символов. ! Все значения атрибутов должны быть заключены в кавычки. Любой файл в формате XML, как уже говорилось, имеет обязательный заголовок и заглавный тег, в котором расположены все остальные теги. Приведем структуру XMLфайла в общем виде: <?xml version=”1.0” encoding=”windows-1251” ?> <main_element> <Element1> [attr1=”val1” [attr2=”val2”…]] </Element1> <Element2> [attr1=”val1” [attr2=”val2”…]] </Element2> …………………………. </main_element>

Пример XML-файла, соответствующего приведенному шаблону, смотрите на http://www.samag.ru/source. Замечание. Этот шаблон включает в себя только информацию, необходимую для успешной обработки файла отчета. Он не содержит упоминания о стилях, о возможности вставки в XML-файл программного кода. Полную версию шаблону можете найти на сайте http://www.w3c.org/xml.

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

Накопление данных в переменной Как отмечалось в теоретической части, XML-файл должен иметь заголовок, в котором описана версия используемого языка и указана кодировка. Если не указывать кодировку, то при наличии, например, русских символов созданный файл не будет открываться и обрабатываться ни одним браузером. Данные рекомендуется накапливать в любую переменную строкового типа. Замечание. Чтобы при просмотре записанного в любом из тестовых редакторов (например, NOTEPAD.EXE) файла данные были поделены на строки, добавьте в конце строки следующий код: "chr(13)+chr(10)"

В теоретической части была приведена структура XMLфайла. Приведем листинг, позволяющий сформировать файл в формате XML (пример смотрите далее по тексту). Напомню, что в названии файла и главного тега должно быть использовано имя рабочей станции, а не учетной записи пользователя. Это связано с тем, что с одной рабочей станции в сети может зарегистрироваться только один пользователь, в то время как один и тот же пользователь с помощью своей учетной записи может зарегистрироваться на нескольких рабочих станциях. Таким образом, чтобы системный администратор получил исчерпывающую информацию о каждой из рабочих станций, зарегистрированных в сети, о свойствах учетных записей пользователей и др., в имени файла и главного тега рекомендуется использовать имя рабочей станции, которое возвращает макрос @wksta. В синтаксисе XML-файла есть одно ограничение – тег не может начинаться с цифр, поэтому, если в вашей сети рабочие станции имеют цифровые имена, например, 1130pc, 2310nb (pc – Personal Computer, nb - Notebook), то главный тег рекомендуется предварять каким-нибудь символом, например символом подчеркивания – «_». Необходимо напомнить еще об одном важном правиле: в названии тегов необходимо учитывать регистр. Теперь, когда рассмотрены все теоретические аспекты, приведем пример: $en=chr(13)+chr(10) ‘ ïåðåõîä íà íîâóþ ñòðîêó ; íàêîïëåíèå ïåðåìåííîé $t=”<?xml version=””1.0”” encoding=””windows-1251”” ?>” $t=$t+"<_@wksta>"+$en $t=$t+"”<Parameter1> @ProductType </ Parameter1>"+$en $t=$t+"< Parameter2> “+var1+ “</ Parameter2>"+$en …… $t=$t+"</_@wksta>" ; ôîðìèðîâàíèå XML-ôàéëà $filename=@wksta+".xml" $fso = CreateObject("Scripting.FileSystemObject") $MyFile = $fso.CreateTextFile($filename, True, TRUE) $MyFile.WriteLine($t) $MyFile.Close

образование WMI. Теория Основы WMI Чтение информации об аппаратной конфигурации рабочей станции рекомендуется обеспечивать стандартными средствами Microsoft Windows. Одним из таких средств является Microsoft Windows Management Instrument (WMI). WMI, разработанный в 1998 году, предоставляет разработчикам программного обеспечения и администраторам сети стандартизированные способы наблюдения и управления как локальными, так и удаленными ресурсами сети. Исполняемым файлом, обеспечивающим функционирование WMI, является файл winmgmt.exe, находящийся в каталоге c:\WINNT\system32\wbem\ Microsoft Windows 200x. Механизм работы WMI следующий: ! На первом этапе происходит подключение к службе WMI локального или удаленного компьютера: при обращении приложения к WMI запросы приложения пересылаются диспетчеру CIMOM (Common Information Model Object Manager), который обеспечивает первоначальное создание объектов и однообразный способ доступа к управляемым объектам. Наиболее простым способом подключения к удаленному компьютеру является вызов функции языка VBScript GetObject(). Подключение к удаленному компьютеру происходит с помощью протокола winmgmts. ! На втором этапе происходит проверка хранилища объектов. Затем запрос передается поставщику объекта. Поставщик (provider) – это интерфейс между управляемым устройством и диспетчером CIMOM. Поставщик собирает информацию об устройствах и делает ее доступной для диспетчера. ! На третьем этапе, после окончания обработки запроса, поставщик пересылает результаты исходному сценарию или приложению.

$strNameSpace=”” $strClass=”” $objWMIService = GetObject("winmgmts: ↵ {ImpersonationLevel=Impersonate }!// " & $strComputer ↵ & ”/ ” & $strNameSpace) $colItems = objWMIService.ExecQuery(“SELECT ïîëå_1, ↵ ïîëå_2, …, ïîëå_n FROM” & $strClass ) For Each $Element in$colItems $Temp=$Element.Value Next

В приведенных примерах значением переменной $str Computer является имя удаленного компьютера. Если компьютер локальный, то вместо имени указывается символ «.» (точка): $strComputer=”.”

Переменная $strNameSpace содержит пространство имен. $strClass – переменная, включающая в себя название класса. Например, для Win32 Provider одним из классов является Win32_BIOS, соответственно переменная $strName Space принимает значение Root\Cimv2. Инструкция {ImpersonationLevel=Impersonate}! заставляет выполнить сценарий с привилегиями пользователя, вызывающего сценарий, а не с привилегиями пользователя, который в настоящий момент зарегистрирован на рабочей станции. Таким образом, осуществляется подстановка, которая полезна при выполнении сценариев удаленного доступа на таких ОС, как Microsoft Windows 200x, где эта инструкция является выражением подстановки по умолчанию, поэтому для этого семейства ее можно опустить. Варианты доступа A и Б к объектной модели WMI отличаются лишь формой записи. В варианте B обращение к классу строится с помощью SQL-запроса, что позволяет экономить трафик. В общем случае запрос SQL выглядит следующим образом: SELECT ïîëå_1, ïîëå_2, …, ïîëå_n FROM strClass

Способы доступа к объектам WMI На практике доступ к объектам WMI получают одним из способов, проиллюстрированных в следующих шаблонах: A) $strComputer=”” $strNameSpace=”” $strClass=”” $objElements = GetObject( "winmgmts: ↵ {ImpersonationLevel=Impersonate}!//" & $strComputer ↵ & ”/ ” &$strNameSpace & ”: ” & $strClass) For each $Element in $objElements $Temp=$Element.Value Next

В поле SELECT указываются поля, по которым идет выборка. Поля перечисляются через запятую, «пробелы» после запятой обязательны. Если выборка должна идти по всем полям, то вместо названий полей указывается символ «*». В поле FROM указывается один из ранее перечисленных поставщиков: SELECT * FROM $strClass. В зависимости от способа доступа к хранилищу размер пересылаемых данных разный. Òàáëèöà 1

Á) $strComputer=”” $strNameSpace=”” $strClass=”” $objWMIService = GetObject( "winmgmts: ↵ {ImpersonationLevel=Impersonate}!//" & $strComputer ↵ & ”/ ” & $strNameSpace) $colItems = $objWMIService.InstancesOf($strClass ) For Each $Element in $colItems $Temp=$Element.Value Next Â) $strComputer=””

Вывод: видно, что на практике лучше всего использовать вариант В. Несмотря на то что код получится несколько громоздким, уменьшится сетевой трафик, сократится время работы сценария.

WMI. Практика Для сбора информации различного характера необходимо использовать Win32 Provider, которому соответствует пространство имен Root\Cimv2. Win32 Provider соответствует

образование массив, состоящий из двух частей: идентификатора и названия ресурса, которые разделены знаком подчеркивания. Идентификатором всегда является «WIN32». С объектной моделью WMI можно ознакомиться с помощью утилиты WMI Object Browser (см. рис. 2), входящей в пакет WMI Tools. Набор утилит WMI Tools можно найти на сайте компании Microsoft: http://msdn.microsoft.com/developer/ sdk/wmisdk/default.asp. На практике для доступа к WMI-объектам рекомендуется использовать нечто среднее между шаблонами, приведенными в теоретической части: $strComputer=”” $strNameSpace=” Root\Cimv2” $strClass=”Win32_Value” $objWMIService = GetObject( " winmgmts: // " ↵ & $strComputer & ”/ ” & $strNameSpace) $colItems = objWMIService.ExecQuery(“SELECT ïîëå_1, ↵ ïîëå_2, …, ïîëå_n FROM” & $strClass ) For Each $Element in $colItems $Temp=$Element.Value Next

Приведем пример чтения информации BIOS материнской платы с помощью WMI на Kixtart на основе обобщенного варианта 3 рабочей станции ComputerName. Массив данных, в котором содержится информация о материнской плате, называется WIN32_BIOS:

$PC = @WKSTA $en=chr(10) $objWMIService = GetObject( "winmgmts://" + $pc+"/Root/Cimv2") $colItems = $objWMIService.ExecQuery( "Select * ↵ from Win32_BIOS") For Each $objItem in $colItems ? ? ? ? Next

" " " "

BIOS Name : " + $objItem.Name Version : " + $objItem.Version Manufacturer : " + $objItem.Manufacturer SMBIOS Version : " + $objItem.SMBIOSBIOSVersion

Необходимо отметить, что все переменные, которые использованы в данном примере, – строковые (см. рис. 2). Если переменная является числом, то ее необходимо преобразовать в строковую переменную с помощью функции Сstr(). Если переменная представляет собой массив, то необходимо прочитать элементы массива и преобразовать их в строки в том случае, если элементы массива не являются строковыми переменными. Результатом выполнения данной программы будет сообщение вида:

Ðèñóíîê 1

Ðèñóíîê 2

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

образование Поскольку вышеприведенный механизм используется многократно, то рекомендуется оптимизировать программный код, сформировав из имен классов массив: $wmi_array="Win32_BIOS","Win32_Processor",……" $æ=… for $a=0 to $æ $objWMIService = GetObject( "winmgmts://@wksta/root/cimv2" ) $colItems = $objWMIService.ExecQuery( "Select * from ↵ "+ $wmi_array[$æ]) For Each $objItem in $colItems select case $a=0 $mb1=$objItem.Name $mb2=$objItem.Manufacturer $mb3=$objItem.SMBIOSBIOSVersion $mb4=$objItem.Version $lx1="<mb> <bios> $mb1 </bios>" $lx2="<manufacture> $mb2 </manufacture>" $lx3="<version> $mb3 </version> " $lx4="<data_release> $mb4 </data_release> </mb> " $t="$t $lx220 $en $lx222 $en $lx224 $en $lx226 $en" case $a=1 $cpu_arhitect="x86","MIPS","ALPHA", "Power PC" $cpu_socket="","Other","Unknown","Daughter Board", ↵ "ZIF Socket","Replacement/Piggy Back","None", ↵ "LIF Socket","Slot 1", "Slot 2", "370 Pin Socket", ↵ "Slot A", "Slot M","","","Socket 478" $i=$objItem.Architecture $ii=$cpu_arhitect[$i] $cpu1=$objItem.Name + ", " + $objItem.MaxClockSpeed + " Mhz" $cpu2=$objItem.Version + ", Level " + $objItem.Level $i=$objItem.UpgradeMethod $ii=$cpu_socket[$i] $cp1=$objItem.ExtClock+"Mhz" $cp2=$objItem.L2CacheSize+"Kb" $lx5="<cpu> <processor> $cpu1 </processor>" $lx6="<version> $cpu2 </version> " $lx7="<socket> $ii </socket>" $lx8="<external_clock> $cp1 </external_clock>" $lx9="<l2_cache> $cp2 </l2_cache> </cpu> " $t="$t $lx230 $en $lx232 $en $lx234 $en $lx236 $en $lx238 $en" case $a=2 ………………………… End Select Next

Реестр. Теория2 Истоки реестра Реестр – это иерархическая база данных, содержащая настройки аппаратного и программного обеспечения компьютера. Для обеспечения высокой скорости доступа к записям реестра информация в нем хранится в двоичном формате, а сам реестр состоит из нескольких файлов. В Microsoft Windows 3.x все настройки программного обеспечения располагались в конфигурационных файлах, имеющих расширение INI. Настройки программного обеспечения и операционной системы располагались в двух файлах: 2

SYSTEM.INI и WIN.INI. Однако размер INI-файлов не мог превышать 64 Кб, поэтому, чтобы обойти это ограничение, для каждой программы создавался свой INI-файл. Со временем из-за большого количества конфигурационных файлов производительность операционной системы значительно понизилась. В 1993 году была создана операционная система Microsoft Windows NT, в которой множество INI-файлов было заменено единой базой данных – реестром. С точки зрения файловой системы реестр представляет собой файл с расширением DAT. Для Windows NT/200x реестр хранится в файле NTUSER.DAT, который находится в каталоге %Windir%\Profiles3. В Windows 9x реестр состоит из двух файлов: USER.DAT и SYSTEM.DAT, которые хранятся в каталоге %Windir%. USER.DAT содержит настройки индивидуального пользователя, а SYSTEM.DAT – настройки компьютера. Реестры Windows 9x, NT, 2000 несовместимы друг с другом, однако идея построения реестров едина.

Ветви реестра Реестр состоит из разделов верхнего уровня, называемых кустами (или ульями, в оригинале hives): ! HKEY_CLASSES_ROOT (HKCR); ! HKEY_CURRENT_USER (HKCU); ! HKEY_LOCAL_MACHINE (HKLM); ! HKEY_USER (HKU); ! HKEY_CURRENT_CONFIG (HKCC). Структура реестра такова: в каждом из разделов находятся ключи, в которых содержатся параметры, имеющие определенные значения. Рассмотрим подробнее назначение каждого из разделов реестра. В разделе HKLM находится информация об аппаратном, программном обеспечении, а также сведения о системе безопасности. Раздел HKCR представляет собой виртуальную ссылку на раздел HKLM\Software\Classes и является одним из самых больших разделов реестра. В нем находится информация обо всех расширениях файлов, определениях типов, ярлыках, привязке, классах идентификаторов и т. д. Раздел HKU содержит настройки пользователя по умолчанию, в которые входят описания переменных среды, цветовых схем, шрифтов, сетевых настроек и т. д. Во время регистрации нового пользователя на рабочей станции на жестком диске для него создается новый профиль. Настройки, содержащиеся в профиле, копируются из раздела HKU. Изменения в разделах HKU и HKLM можно сделать с помощью утилиты REGEDT32.EXE в том случае, если у вас ОС Windows 2000, и REGEDIT.EXE – если Windows XP. Пользователь, от имени которого запускаются эти утилиты, должен обладать правами администратора. Раздел HKCU содержит сведения о текущем пользователе и имеет название, соответствующее значению идентификатора безопасности (SID) данного пользователя. Каждый раз при перезагрузке компьютера этот раздел создается заново.

Информация, приведенная в этом разделе, также является теоретической частью для разделов, в которых описываются автоматизированное подключение сетевых принтеров и процесс автоматизации конфигурирования рабочих станций. В Microsoft Windows принято использовать переменные среды. %WinDir% содержит полный путь к каталогу, в котором установлена ОС, например, C:\Windows.

образование Раздел HKCC является ссылкой на текущий профиль оборудования, хранящейся в HKLM. С помощью профиля оборудования определяют список устройств, драйвера которых будут подгружены в данном сеансе работы пользователя. Профили изначально предназначены для переносных компьютеров. Раздел HKDD (HKEY_DYN_DATA) не хранится в реестре, а динамически создается при загрузке операционной системы. В нем содержатся сведения о самонастраивающихся устройствах (Plug-and-Play). Как и любая база данных, реестр поддерживает несколько типов данных, которые перечислены в таблице: Òàáëèöà 2

Результат работы примера приведен на рис. 5. Зная имена папок, для каждой из них можно считать значения параметра «DisplayName». Следует отметить, что не все установленные приложения содержат этот параметр в соответствующей папке, поэтому в «Control Panel» отображаются не все установленные программы. Для обеспечения полноты предоставляемой информации в том случае, если запись «DisplayName» отсутствует, будет считываться название папки. В приведенном примере в переменную t будут записываться данные, предназначенные для XML-файла: $en=chr(10)+chr(13) $t=$t+" <Installed_Programs> " $i=1 $path="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ ↵ CurrentVersion\Uninstall" do $loop = ENUMKEY($path, $Index) $name=readvalue($path+" \"+$loop,"DisplayName") if $name<>"" $t=$t+" <Program"+$I +"> " +$name+ " </Program"+$I +"> "$en ? " <Program"+$i +"> " +$name+ " </Program"+$I +"> " Else

Реестр. Практика Отображаемый в «Add and Remove Programs» cписок установленных программ на рабочей станции формируется на основе информации из ветви реестра HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ Uninstall. Рассмотрим подробнее структуру, содержащуюся в папке Uninstall. При установке любой программы на жесткий диск компьютера в Windows 2000 или Windows XP в ней создается подпапка. Ее имя совпадает либо с GUID4, либо с названием программы. Внутри этой папки создается ряд записей, содержащих информацию об установленном продукте (см. рис. 4). Необходимо отметить, что в подразделе «Add and Remove Programs» панели «Control Panel» список установленного программного обеспечения формируется на основе значений, содержащихся в переменной «DisplayName» для каждого приложения. При выборе кнопки «Remove» операционная система выполняет команду, являющуюся значением переменной «UninstallString». В том случае, если значение этого параметра неверно, вы никогда не сможете удалить это приложение через «Control Panel». Однако вернемся к папкам. Для того чтобы считать из реестра названия установленных программ, сначала необходимо получить доступ к подпапкам – узнать их названия, которые содержатся в папке «Uninstall». Для этого следует использовать функцию EnumKey(): $path="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ ↵ CurrentVersion\Uninstall" do $loop = ENUMKEY($path, $Index) ? $loop until $loop="" 4

if $loop<>"" $t=$t+" <Program"+$I +"> " +$loop + " </Program"+$I +"> "$en ? " <Program"+$I +"> " +$loop + " </Program"+$I +"> " endif endif $Index = $Index + 1 $i=$Index+1 until $loop="" $t=$t+" </Installed_Programs> " MessageBox($t, "",0,0)

Active Directory.Теория Active Directory Active Directory (AD) – это служба каталогов, которая является иерархической базой данных, обеспечивающей централизованное управление сетью. Active Directory хранит в себе информацию об объектах сети и обеспечивает доступ к этой информации пользователям, компьютерам и приложениям. Active Directory обладает следующими особенностями: ! Масштабируемость. В отличие от большинства других баз данных (БД), которые являются реляционными, Active Directory является иерархической базой. В БД взаимосвязи между записями определяются при помощи ключей, которые хранятся совместно с данными. В иерархической базе данных взаимосвязи между записями имеют характер «родитель-потомок»: каждая запись, за исключением корневой, имеет родительскую запись (родителя). У каждой родительской записи может быть один или несколько потомков. Иерархическая база данных позволяет хранить большое количество объектов, при этом быстро получать доступ к необходимым объектам.

GUID (globally unique identificator, глобальный уникальный идентификатор) – 128-разрядный номер, служащий идентификатором. Присваивается объекту в момент его создания и не может быть изменен.

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

образование ! Active Directory объединяет в себе концепцию пространства имен Интернета со службой каталогов Windows NT, что позволяет объединить и управлять различными пространствами имен в разноразрядных аппаратных и программных средах. Для управления пространством имен Active Directory используется библиотека интерфейса службы активного каталога (Active Directory Service Interface – ADSI). ! Поддержка стандартных форматов имен. Active Directory поддерживает несколько общих форматов имен. Этот факт позволяет приложениям и пользователям получать доступ к каталогу, применяя наиболее удобный для них формат: UPN (RFC 882), LDAP URL (RFC 1779, 2247), UNC(RFC 1123).

ратами обозначены классы, а кружками подклассы. Методы доступа к каждому из перечисленных протоколов отличаются, однако можно привести пример, который наглядно иллюстрирует приведенную схему: $obj=GetObject("Protocol://ClassName") For each $SubClass in $ClassName ? $SubClass.Property Next

Объектная модель ADSI Наглядная схема объектной модели ADSI приведена на рис. 3. Схема условно поделена на три части. Используя клиента – язык программирования, скрипт получает доступ к COM-объектам. Объекты могут быть двух видов – классами и подклассами. Обращение к подклассам осуществляется через классы, однако на схеме этого не показано, чтобы не загромождать рисунок. С помощью COM-объекта через протокол LDAP или WinNT сценарий загрузки получает доступ к выбранному элементу объектной модели. Пространство имен условно обозначено треугольником; квад-

Ðèñóíîê 4

Ðèñóíîê 3

Провайдеры ADSI Интерфейс ADSI поддерживает следующие провайдеры, с помощью которых осуществляется программное администрирование (см. таблицу 4). Для определения всех доступных в сети провайдеров необходимо использовать службу ADS:

образование $obj=GetObject("ADs:") For Each $provider IN $obj $t=$t + $provider.name + chr(13) Next MessageBox($t, "",0,0)

Òàáëèöà 3

боты с принтерами. Причина проста: в отличие от провайдера LDAP, провайдер WinNT рассматривает принтер не как сетевое, а как локальное устройство. Только с помощью провайдера WinNT можно управлять состоянием и очередями принтеров. Совместное использование обоих провайдеров позволит осуществлять мониторинг и управление сетевыми принтерами домена [2]. Порядок построения запроса для провайдера WinNT в формате UNC следующий: WinNT:[//DomainName[/ComputerName[/ObjectName[,className]]]]

Объектная модель провайдера LDAP Из всех перечисленных провайдеров будут рассмотрены только: LDAP и WINNT. Провайдер ADSI LDAP выполняется на клиенте ADSI и обеспечивает доступ к Active Directory. Кроме служб каталогов Active Directory Windows 2000, LDAP-провайдер обеспечивает доступ к: ! Netscape Directory Server; ! Microsoft Exchange Server 5.x и выше; ! Microsoft Commercial Internet System (MCIS) Address Book Server. Для реализации программного управления Active Directory часто используется именно этот провайдер. Запрос провайдеру LDAP составляется в формате LDAP URL (см. RFC 1779, RFC 2247): LDAP://HostName[:PortNumber][/DistinguishedName]

Провайдер WinNT ADSI поддерживает доступ к каталогам Microsoft Window 4.0/3.x, обеспечивает связь с PDC и BDC. Провайдер WinNT в основном используется для ра-

Для программного управления Active Directory с помощью провайдера LDAP необходимо использовать его объектную модель. Объектная модель представляет собой совокупность объектов, которые взаимосвязаны друг с другом и образуют между собой иерархическую структуру. Каждый из этих объектов имеет набор свойств, характерный исключительно для объектов данного типа. Существует несколько видов (идентификаторов) объектов: CN, DС, OU. Расшифровка и назначение каждого объекта смотрите в таблице. Òàáëèöà 4

Имена LDAP URL (см. RFC 1779, RFC 2247) построены на основе протокола X.500 и используются для связывания с объектами. Идентификаторы объектов DC, OU, CN образуют полное составное имя (Distinguished Name, DN), а имя самого объекта – относительное составное имя (Relative Distinguished Name, RDN). Полное составное имя объекта включает в себя имя объекта и всех его родителей, начиная с корня домена.

Ðèñóíîê 5

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

образование

Ðèñóíîê 6

Существует две формы доступа к ADSI: развернутая и сокращенная. Рассмотрим принципы построения путей к ресурсу обоими способами на примере домена domain.com (см. рис. 3). ! Развернутая форма. При использовании этого вида формы строка связывания начинается с описания верхнего элемента структуры. Затем происходит переход вниз по иерархии. Необходимо помнить, что при написании пути к объекту необходимо исключать пробелы. В качестве шаблона может служить выражение вида: $obj = GetObject ("LDAP://DC=Domain_name1 ↵ /DC=Domain_name2/DC=Domain_name3/ ↵ OU=OU_Name_Level1/OU=OU_Name_Level2…/ ↵ OU=OU_Name_Level/CN=CN_Name")

где DC=Domain_name1/DC=Domain_name2/DC=Domain_ name3 образуют полное имя контроллера домена, элементы OU=OU_Name_Level1/OU=OU_Name_Level2…/ OU=OU_ Name_Level представляют собой вложенные друг в друга элементы. В развернутой форме доступа объект CN является «дном колодца» в иерархии. Пример: запрос к объекту CN=User3 выглядит следующим образом (см. рис. 3):

Active Directory Viewer (Microsoft) и LDAP Browser 2.5.3 (Softerra). Active Directory Viewer (ADV) является графической утилитой, позволяющей выполнять операции чтения, модифицирования, осуществлять поиск в любых совместимых каталогах, таких как Active Directory, Exchange Server, Netscape Directory, Netware Directory. Active Directory Viewer входит в состав SDK для Active Directory Services Interface, который можно бесплатно загрузить с сайта Microsoft: http:// www.microsoft.com/ntserver/nts/downloads/other/adsi25. После установки SDK for ADSI утилита Active Directory Viewer (AdsVw.exe) будет находиться в c:\Program Files\ Microsoft\ADSI Resource Kit, Samples and Utilities\ADsVw. Программа работает в двух режимах: ObjectViewer и Query.

Ðèñóíîê 7

Для просмотра объектной модели провайдера необходимо использовать режим ObjectViewer. Режим Query используется для осуществления поиска объектов в выбранной объектной модели. В данной статье режим Query рассматриваться не будет. Просмотр и редактирование объектной модели программой ADV в режиме ObjectViewer. После выбора режима ObjectViewer появится диалоговое окно.

$obj = GetObject ("LDAP://DC=RU/DC=Domain1/ ↵ OU=Group1/OU=Group4/CN=User3")

! Сокращенная форма. Характеризуется тем, что строка запроса строится в соответствии с обратной иерархией структуры организации. Шаблон выглядит следующим образом: $obj=GetObject("LDAP://CN=CN_Name,OU=OU_Name_Level…, ↵ OU=OU_Name_Level2 ,OU=OU_Name_Level1/DC=…")

Соответственно запрос к объекту CN=User3 с помощью сокращенной формы доступа выглядит следующим образом: $obj=GetObject("LDAP://CN=User3,OU=Group4,OU=Group3, ↵ DC=Domain1, dc=RU")

Active Directory. Практика Объектная модель AD Управление объектами Active Directory невозможно без знания объектной модели. Существует несколько программ, предназначенных для нее. Рассмотрим лишь две из них:

Ðèñóíîê 8

Для получения доступа к каталогу необходимо указать путь и параметры учетной записи, обладающей правами администратора (имя и пароль). Путь к каталогу должен быть построен в соответствии со следующим шаблоном: <Provider_Name:>//<Server_Name>/<Full_Domain_Name>

Обратите внимание на две особенности шаблона, в нем не должно быть пробелов, «слэши» должны быть прямыми – «/». Невыполнение хотя бы одного из перечисленных условий приведет к ошибке в соединении с каталогом. Для доступа к серверу server домена domain.ru с помощью протокола LDAP используется следующий запрос:

образование LDAP://server/DC=domain,DC=ru

После соединения с каталогом на экране будет отображена его иерархическая структура.

Запрос строится по следующему шаблону: SELECT ïîëå 11,ïîëå 21...ïîëå n1 FROM ïóòü ↵ WHERE objectClass="òèï_îáúåêòà"

где «путь» – путь к интересующему объекту AD в формате LDAP URL. На практике поиск объектов осуществляется следующим образом: $DomainName=”Domain” $objConnection = CreateObject("ADODB.Connection") $objCommand = CreateObject("ADODB.Command") $objConnection.Provider = "ADsDSOObject" $objConnection.Open "Active Directory Provider" $objCommand.ActiveConnection = $objConnection $objCommand.CommandText = "SELECT printerName, serverName ↵ FROM " _ & " 'LDAP://"& $DomainName & "' ↵ WHERE objectClass='printQueue'" $objCommand.Properties("Cache Results") = False $objRecordSet = $objCommand.Execute $objRecordSet.MoveFirst

Ðèñóíîê 9

В левой части экрана отображается иерархическая структура каталога. В правой части – характеристики объекта, на котором установлен курсор. Список свойств объекта и соответствующих им значений приведен в «Properties» и «Property Value». LDAP Browser 2.5.3 является бесплатной программой (http://www.ldapadministrator.com). По своим возможностям программа превосходит Active Directory Viewer. В процессе создания соединения с каталогом могут быть заданы фильтры, параметры административной учетной записи, порт TCP, по которому осуществляется соединение, и другие параметры. Общий вид программы приведен на рис. 10.

Причины использования провайдера LDAP

! Провайдер LDAP (Lightweight Directory Access Protocol) рассматривает принтер как сетевое устройство5, в то время как провайдер WinNT рассматривает принтер исключительно как локальное устройство. ! Вторым принципиальным отличием провайдеров являются расширенные возможности поиска провайдера LDAP. Используя провайдер WinNT, можно было осуществлять поиск, применяя различные фильтры, которые позволяют осуществлять поиск всех объектов, принадлежащих к одному из классов – computer, user, service и др. С помощью LDAP можно найти конкретный объект, например пользователя, и прочитать его свойства.

Поиск объектов осуществляется с помощью OLE Distributed Query (DB) интерфейса, который вызывается прямо из службы активного каталога (Active Directory Service Interface – ADSI). Он осуществляется на основании запроса и его параметров. В качестве его параметров могут быть: уровень поиска, диапазон поиска, ограничение по размеру, сортировка и т. д. Форма запроса (Distributed Query) заимствована из Microsoft SQL Server. 5

Do Until $objRecordSet.EOF $temp=$temp & "Printer Name: " ↵ & $objRecordSet.Fields("printerName").Value & " ↵ Server Name: " & $objRecordSet.Fields ↵ ("serverName").Value & chr(13) $objRecordSet.MoveNext Loop Messagebox($tem,””,0,0)

В приведенном примере осуществляется поиск всех зарегистрированных в AD принтеров. У найденных принтеров происходит чтение двух полей: название принтера и сервера печати. Поиск объектов с помощью провайдера LDAP осуществляется по следующему шаблону: ! устанавливается соединение с Active Directory Provider через ADODB; ! составляется запрос; ! осуществляется поиск по заданным критериям. В том случае если искомые объекты найдены, происходит чтение указанных в запросе полей. Результат выводится на экран. Объектами могут быть строки и массивы. Следует отметить, что вместо названия свойства, которое необходимо прочитать, можно указать порядковый номер поля, под которым оно обозначено в запросе. Нумерация полей начинается с 0. Таким образом, основываясь на приведенном примере, вместо $objRecordSet.Fields(«server Name»).Value можно записать $objRecordSet.Fields(1).Value. В файле отчета, по мнению автора статьи, следует размещать следующую информацию о пользователе: имя, отчество, подразделение, должность и телефон. Набор этих параметров может меняться в зависимости от специфики фирмы, в которой функционирует скрипт. Приведем пример, выполняющий чтение этих полей: $objRoot = GetObject("LDAP://RootDSE") $strDefaultDomainNC = $objRoot.Get("DefaultNamingContext") $strGetArg=@userid ; îïðåäåëåíèå èìåíè ïîëüçîâàòåëÿ. $strADSQuery = "SELECT department, ↵ physicaldeliveryofficename, telephonenumber, ↵ title FROM 'LDAP:// " + $strDefaultDomainNC + "' ↵

В одном скрипте желательно использовать один провайдер, чтобы не загромождать листинг. Управление принтерами может быть реализовано только с помощью провайдера LDAP.

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

образование WHERE samAccountName = '" + $strGetArg + "'" $objADOConn = createObject("ADODB.Connection") $objADOConn.Provider = "ADsDSOObject" $objADoConn.Open ("Active Directory Provider") $objADOCommand = CreateObject("ADODB.Command") $objADOCommand.ActiveConnection = $objADOConn $objADOCommand.CommandText = $strADSQuery $objQueryResultSet = $objADOCommand.Execute $objRoot_m1=$objQueryResultSet.Fields("department") $objRoot_m2=$objQueryResultSet.Fields("physicaldeliveryofficename") $objRoot_m3=$objQueryResultSet.Fields("telephonenumber") $objRoot_m4=$objQueryResultSet.Fields("title")

Как видно из примера, имя пользователя определяется с помощью встроенного в KIXTart макроса @userid. Определение значения необходимых полей осуществляется с помощью процедуры поиска объекта, в данном случае учетной записи, и чтения необходимых свойств. Стоит отметить, что этой проблемы быть не должно, поскольку Windows по умолчанию использует кодировку cp1251. Однако при взаимодействии KIXTart с Windows кодировка «съезжает». С решением этой проблемы, пусть не самым изящным, но эффективным, читатель только что ознакомился. Обратите внимание, несмотря на то что значения, прочитанные из AD, имеют тип данных либо «строка», либо «массив», при попытке записать их в файл отчета выдается ошибка несоответствия типа. По непонятным причинам функции преобразования типов данных не дают желаемого результата. Предлагается следующее решение возникшей задачи, которое состоит их двух этапов. На первом этапе данные из AD записываются в INI-файлы с помощью функции WriteProfileString(). Затем осуществляется считывание этих данных из INI-файлов и их запись в накапливаемую переменную, содержание которой представляет собой записываемую информацию в XMLфайл.

Ðèñóíîê 10

Таким образом, осуществляется смена кодировки, в которой записывается информация: $ini_file="@wksta.ini" $user_name="user" $user1=writeprofilestring("$ini_file", ↵ $user_name,"department",$objRoot_m1) $user2=writeprofilestring("$ini_file", ↵ $user_name,"location",$objRoot_m2) $user3=writeprofilestring("$ini_file", ↵ $user_name,"telephone",$objRoot_m3) $user4=writeprofilestring("$ini_file", ↵ $user_name,"title",$objRoot_m4) $user5=writeprofilestring("$ini_file", ↵ $user_name,"User ID","@userID") $user6=writeprofilestring("$ini_file", ↵ $user_name,"Full Name","@fullname") $objRoot1=readprofilestring("$ini_file", $user_name,"department") $objRoot2=readprofilestring("$ini_file", $user_name,"location") $objRoot3=readprofilestring("$ini_file", $user_name,"telephone") $objRoot4=readprofilestring("$ini_file", $user_name,"title")

↵ ↵ ↵ ↵

$t=$t+"<department> $objRoot1 </department>" $t=$t+"<Locations> $objRoot2 </Locations>" $t=$t+"<Telephone> $objRoot3 </Telephone>" $t=$t+"<Title> $objRoot4 </Title> </information>" …… del "$ini_file"

В следующей статье будут рассмотрены вопросы астоматического подключения сетевых ресурсов, визуализации скрипта, внедрение его в эксплуатацию.

Литература: 1. Коробко И. Автоматизация процессов в сети. – Журнал «Системный администратор», N8, август 2004 г. 2. Коробко И. Управление сетевыми принтерами. – Журнал «Системный администратор», №10, октябрь 2003 г.

образование

СОЗДАНИЕ И НАСТРОЙКА СЕРВЕРА ТЕРМИНАЛОВ

РОМАН МАРКОВ В предыдущем номере журнала [1] была опубликована детальная инструкция по установке и настройке Windows 2000 Server и повышении его роли до контроллера домена. В этой статье мы продолжим развитие темы и подробно опишем установку и настройку на нашем сервере сервера терминалов с расширением до Citrix Metaframe Presentation Server XP. Если в процессе установки Windows 2000 Server мы добавили в устанавливаемые компоненты «Лицензирование служб терминалов» и «Службы терминалов», то пропускаем этот шаг и переходим к п. 2. Иначе: ! Заходим в «Панель управления → Установка и удаление программ → Добавление и удаление компонентов Windows» и устанавливаем эти компоненты. Описание настройки режима работы описано в 1 части статьи [1]. Перезагружаемся. Если вы добавили их только сейчас – рекомендуется переустановить Service Pack и пакеты критических обновлений. Опять перезагружаемся. ! «Пуск → Программы → Администрирование → Лицензирование служб терминалов». Выделяем наш сервер. Правой клавишей – «Активировать сервер». Жмем «Далее». Выбираем метод подключения «Веб». Далее следуем инструкции на экране. Идем на сайт https://activate. microsoft.com, выбираем русский язык. Далее отмечаем пункт «Активация сервера лицензий» и жмем «Далее». Вводим выданный нам в окне активации код продукта. Заполняем обязательные (отмеченные звездочкой) поля – «Фамилия», «Имя», «Организация», «Страна». Остальные заполнять необязательно. Жмем «Далее». Внимательно запоминаем, как мы заполнили эти поля, так как это еще может понадобиться (лучше всего страницу подтверждения распечатать). Проверяем корректность данных и опять жмем «Далее». Нам выдают код активации сервера. Распечатываем страницу (или внимательно записываем). Оставляем веб-страницу запроса кодов открытой. Переходим к мастеру активации. Вводим полученный код в нашем окне активации и жмем «Далее». Если все ввели правильно, сервер лицензий сообщит об успешной активации. Этот процесс абсолютно бесплатен. Затем будет предложено активировать клиентские лицензии (галочка «Установить лицензии сейчас»). Выставляем ее и жмем «Далее». Для активации этих лицензий вам необходимо приобрести пакет лицензий «Windows Terminal Svr CAL». Скорее всего, вы приобрели пакет лицензий типа OLP или специальный пакет лицензий в виде номера соглашения о покупке. Рассмотрим второй вариант.

! В уже открытом окне запроса лицензий на вопрос «Установить маркеры лицензий в данное время?» отвечаем «Да». Выбираем программу лицензирования «Другое соглашение». Остальные поля будут заполнены автоматически из предыдущей формы, если продолжаем начатую активацию. Если мы активируем только клиентские лицензии, то входим на https://activate.microsoft.com и выбираем русский язык, ставим галочку «Установка маркеров лицензий CAL» и нажимаем «Далее». Вручную заполняем наши данные. Поля «Фамилия», «Имя», «Организация» и «Страна» должны быть заполнены в точности, как при активации сервера лицензий. Нажимаем «Далее». Выбираем «Тип продукта». Обратите внимание на указанный здесь тип. Нам необходим «Windows 2000 Server Terminal Services Client Access License (TS CAL) (на устройство)» в случае, если мы используем Windows 2000, или «Windows Server 2003 Terminal Server Per Device Client Access License» для Windows Server 2003. Затем вводим количество приобретенных нами лицензий и номер соглашения. Нажимаем «Далее» и проверяем корректность введенных данных. Опять нажимаем «Далее». Если все сделано правильно, то мы получим очередной код активации, который распечатываем (записываем) и вводим в мастер активации клиентских лицензий. При корректной настройке будет выдано сообщение об успешном добавлении пакета клиентских лицензий. Закрываем окно «Лицензирование служб терминалов».

Установка и настройка Citrix Metaframe XP Наша система готова к установке пакета Citrix Metaframe XP. Проверьте, установлен ли у вас Windows 2000 Service Pack не ниже 3-го (в него входит необходимый для установки Citrix MF XP пакет Windows Installer 2.0 и другие важные обновления системы). Сам Citrix Metaframe Presentation Server XP поставляется либо на дистрибутивных дисках, либо скачивается с официального FTP-ресурса ftp.citrix.com Прямые ссылки на продукты: ! ftp://ftp.citrix.com/metaXP/W2K/SP3/FR3CD_MFXP10_ W2K.exe – для Windows 2000 Server. ! ftp://ftp.citrix.com/metaXP/W2K3/FR3CD_MFXP10_ WS2K3.exe – для Windows Server 2003.

образование Это самораспаковывающиеся архивы оригинальных дистрибутивов. Распаковываем их в нужное место. Помните, что в режиме терминального сервера все приложения должны устанавливаться только через меню «Установка и удаление программ → Установка новой программы». Для справки: есть возможность переключать режим и из командной строки. Переключение между режимами установки и выполнения программ осуществляется командами change user /install и change user /execute соответственно. Итак, переходим в указанное меню. Выбираем «CD или дискеты». Нажимаем «Далее». При помощи кнопки «Обзор» меняем тип файлов на «Программы» и выбираем файл Autorun.exe. Нажимаем «Далее». Ждем запуска программы. Ни в коем случае не трогаем появившееся окно «После установки нажмите кнопку Далее» – ее необходимо нажимать, когда установка полностью завершена. В появившемся меню выбираем «Install or Update Metaframe XP Server», затем «Metaframe XP Feature Release 3». Нажимаем «Next», принимаем лицензионное соглашение. Затем выбираем ту конфигурацию, которую хотим установить – Metaframe XPa, Metaframe XPe или Metaframe XPs. Для обычных задач достаточно версии XPs. Она включает в себя сам сервер Citrix Metaframe XP и веб-интерфейс к нему. Версия XPa имеет средства для балансировки нагрузки при создании систем из нескольких серверов Citrix MF. Версия XPe также включает дополнительные средства управления и установки. Мы рассмотрим вариант установки версии XPs. Итак, выбираем Metaframe XPs и нажимаем Next. Версию оставляем Retail. В окне компонентов по умолчанию выбраны Web-interface, Management Console и Program Neighborhood. Оставляем как есть. Тут же можно задать путь для установки, можно оставить по умолчанию. Жмем «Next», на вопрос о сквозной аутентификации (PassThrough) отвечаем «Yes». Дальше «Create a New Farm → Next → Farm Name» – вводим понятное нам имя, например, Firma, оставляем галку «Use a local database on this server», Use default Zone Name (там будет наш диапазон адресов типа 192.168.0.0) и жмем «Next». Проверяем, входит ли предложенное имя пользователя в группу Domain Admins (скорее всего да, так как автоматически будет подставлена ваша учетная запись), и жмем «Next». Оставляем галку «Allow shadowing session on this server». Расположенные ниже галочки не устанавливаем! Порт для TCP/IP-соединений с сервером IIS оставляем по умолчанию (Default). «Next». Соглашаемся сделать стартовую страницу веб-сервера такой, как предлагает мастер. После этого начнется установка, по окончании которой будет предложено перезагрузить компьютер. Перезагружаемся. Не обращаем внимания на предупреждение системы об отсутствии лицензирования Citrix – мы введем лицензии позже. Скачиваем все последние хотфиксы и скрипт для их автоматической установки отсюда: http://www.citrix4ge.de/ tipps/fr3fix.htm. В правой части страницы выложены ссылки на все хотфиксы, включая кумулятивные (т.е. полный набор с автоматической установкой). Запускаем cmd-файл и ждем, пока все обновления установятся. Затем перезагружаем сервер, если скрипт не сделал это автоматически.

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

Приступим к лицензированию Citrix MF XP. После установки у нас появилась панель «ICA Administration Toolbar». Если этого не произошло, то можно вручную вставить ее в автозагрузку из меню «Пуск → Программы → Citrix → Metaframe XP». Хотя это необязательно. Все действия по администрированию Citrix MF производятся из консоли Management Console. Если ICA Administration Toolbar присутствует на экране, то это самая нижняя кнопочка в ней. Иначе – через меню «Пуск → Citrix → Management Console». Запускаем. Нам предложат сквозную (Pass Through) аутентификацию. Ставим галочку на «Enable Pass Through authentication» и «Connect to this server». Жмем «ОК». Откроется консоль администрирования Citrix. Переходим на закладку Licenses и начинаем добавлять необходимые лицензии. Все лицензии добавляются путем щелчка правой клавишей мыши по закладке Licenses и выбора «Add license». Программа запрашивает серийный номер лицензии. Для полной функциональности нам необходимо приобрести следующие лицензии (напоминаю, мы установили версию XPs с Feature Release 3): ! MetaFrame XPs 1.0 for Windows – базовая лицензия. ! MetaFrame XPs 1.0 Connection Pack – лицензия на подключения. ! Citrix User License Pack – лицензия на подключения. ! MetaFrame XP 1.0 for Windows, Feature Release 3 – лицензия на сам Feature Release. ! MetaFrame XP 1.0, Feature Release 3 Connection Pack – лицензия на подключения к Feature Release. Некоторые лицензии требуют активации. Тогда при добавлении лицензии вам предложат ее активировать, введя код активации. Активация лицензий доступна, например, на веб-ресурсе www.citrix.com/activate. Добавляя лицензии, не обращайте внимания на возможные сообщения о том, что набор лицензий неполный, даже после добавления и активации последней. Процесс регистрации лицензий может занимать некоторое время. Добавив и активировав все описанные лицензии, закройте Management Console и подождите 5 минут. Затем заново откройте Management Console, перейдите на закладку Licenses и нажмите <F5> (обновить). Если сообщение о недостаточности лицензий снова появляется, попробуйте перезагрузить компьютер. Если оно будет появляться и после перезагрузки – какая-то из лицензий добавлена некорректно или не активирована. Проверьте еще раз. Если не получается – удалите все лицензии в закладке Licenses – License Numbers и попробуйте установить заново. При написании этой статьи автор для проверки проделал все описанные действия – все работало. Теперь приступим к опубликованию приложений. Для примера возьмем самый часто используемый вариант применения сервера терминалов в России: программы семейства 1С:Предприятие 7.7. Итак, устанавливаем 1С:Предприятие в режиме «Локальная установка». Помните, что когда сервер находится в режиме сервера приложений, установка программ производится только через меню «Установка и удаление программ → Установка новой программы». Затем устанавливаем менеджер лицензий ключа защиты (сервер защиты).

образование Внимание! Менеджер лицензий необходимо устанавливать в режиме системной службы. Входящий в состав поставки «Сервер защиты» не имеет режима работы в качестве «системной службы», поэтому в «Автозагрузке» он бесполезен. Необходимый нам дистрибутив можно скачать с официального сайта производителя ключей HASP – www.alladin.ru. Нам необходим файл LMSetup.exe. При установке соглашаемся со всеми его предложениями и (это важно!) выбираем режим установки «Service». В конце перезагружаем компьютер. Если вы не установите менеджер лицензий как описано выше, то при попытке запустить опубликованное приложение «1С:Предприятие» на клиенте вы получите сообщение «Не обнаружен ключ защиты». Все, мы готовы к опубликованию приложения. Копируем необходимую нам базу на локальный диск сервера. Внимание! Если вы используете файл-серверную версию программы, то максимальные преимущества терминального решения достигаются только при расположении базы данных на локальном дисковом массиве этого же сервера. Это происходит из-за того, что система Windows отключает кэширование дисковых операций при подключении к сетевому ресурсу более чем 1 пользователя. При расположении базы на локальном диске сервера никакого обращения по сети к ней не происходит, и скорость работы становится максимальной. Не предоставляйте общего сетевого доступа к папке с базами данных, так как совместное использование ее по сети значительно замедлит работу. То есть с одной и той же базой все должны работать в терминальном режиме, независимо от ресурсов клиентской рабочей станции. Итак, открываем Management Console и выделяем опцию «Applications». Щелкаем по ней правой клавишей и выбираем «Publish Application». Открывается мастер публикации. Задаем имя нашего приложения (произвольно), например, 1C-Terminal (чтобы не путать в дальнейшем с локальной установкой у клиента). Поле «Description» можно оставить пустым или добавить комментарий к этому приложению. Полезно, если у нас будет много однотипных опубликованных приложений. Нажимаем «Next». Ставим галку «Application» и в поле «Command line» нажимаем «Browse». Выбираем наш сервер и указываем путь к запускаемому файлу (в нашем случае это 1cv7.exe или 1cv7s.exe). Путь «Working Directory» оставляем по умолчанию. Нажимаем «Next». На следующем экране имеется возможность создать подпапку для окружения «Program Neighborhood». Используем эту возможность, если нам необходимо разделить множество публикуемых приложений. Иначе – оставляем поле пустым. Если мы хотим автоматически добавлять ярлыки запуска на рабочий стол и в меню «Пуск» наших клиентов (что очень удобно), то выставляем галки «Add to the client’s Start Menu» и «Add shortcut to the client’s Desktop». Галку «Place under Programs Folder…» не устанавливаем. Нажимаем «Next». Выбираем размер окна и цветовую гамму приложения. Для запуска приложения во весь экран (панель задач при этом остается!) выбираем Session window size «Full Screen» и Colors «High Color (16 bit)». Галку «Hide Application title bar» снимаем, а «Maximize application at startup» – устанавливаем. Нажимаем «Next». Снимаем галку «Enable audio». При необходимости устанавливаем шиф-

рование данных (используется, например, при реализации предоставления доступа к основной базе для филиалов через интернет (будет описано далее). Если мы включаем шифрование, скорее всего, понадобится дополнительная лицензия для Citrix – Citrix Secure ICA Services. Устанавливаем галку «Printing» – Start this application without waiting for printers to be created». Нажимаем «Next». Определяем серверы для поставленных задач. В нашем случае сервер только один, поэтому выделяем его в левом поле и нажимаем «Add». Нажимаем «Next». Распределяем права пользователей на доступ к опубликованному приложению. Снимаем галку «Allow anonymous Connections» и добавляем нужные нам группы, например, «Администраторы домена» и «Пользователи домена». Если терминальный доступ необходимо предоставлять избранным пользователям, то удобнее всего создать в нашем домене (рабочей группе) дополнительную группу и помещать туда нужных пользователей. Нажимаем «Finish». Мы создали опубликованное приложение. Если наш сервер приложений является контроллером домена (при наличии возможности их разделить – не стоит объединять роли контроллера домена и сервера приложений), то нам необходимо отредактировать политику безопасности, предоставив доступ к самому серверу группе пользователей, которой мы разрешили доступ к опубликованному приложению. Для этого открываем консоль редактирования политики безопасности контроллера домена: «Пуск → Программы → Администрирование → Политика безопасности контроллера домена». В консоли «Политика безопасности контроллера домена» раскрываем «Параметры безопасности → Локальные политики → Назначение прав пользователя» и изменяем политику «Локальный вход в систему». Добавляем туда группу, которой мы предоставили доступ к нашему опубликованному приложению. Теперь добавим администраторов Citrix. В Management Console выделяем Citrix Administrators, правой клавишей «Add Citrix Administrator». В нашем домене находим группу «Администраторы домена» и добавляем ее. Ставим галку «Add local administrators». Нажимаем «Next», и выбираем «Full Administration». Нажимаем «Finish». Начиная с Citrix Feature Release 2, права администраторов Citrix можно настраивать очень гибко, делегируя своим заместителям выполнение только необходимых задач. Это очень полезно для предоставления ответственным за работу Citrix сотрудникам таких возможностей, как принудительное завершение сеансов пользователей во время вашего отсутствия. Более подробную информацию вы сможете получить, посетив интернет-ресурс, ссылка на который приведена в конце статьи. Все! Далее нам необходимо настроить клиентов. Итак, рассмотрим два варианта: клиенты локальной сети и удаленные клиенты.

Настройка клиентов локальной сети Citrix Metaframe имеет специальное средство – ICA Client Creator. Его описание можно найти по приведенной в конце статьи ссылке.

образование Мы рассмотрим тривиальный способ – установка клиентов из дистрибутива и последующая настройка для соединения. Еще раз акцентирую внимание на том, что данная статья не описывает максимальную автоматизацию подобного внедрения, а предназначена для получения опыта начального уровня. Дистрибутив клиента берем либо с дистрибутивных дисков Citrix, либо скачиваем последнюю версию с сайта производителя: www.citrix.com. Замечу лишь, что при обновлении клиента до версии 8.0.xx они почему-то потеряли возможность пользоваться в терминальных сессиях колесиком мышки. Сам автор использует версию клиента 6.30.1051 как наиболее стабильную (тестировалось исключительно по личному опыту и касается только версии Citrix XP for Windows 2000). Итак, заходим на клиентский компьютер с правами администратора и запускаем ica32.exe. В процессе выполняем стандартные действия по принятию лицензионного соглашения, указания пути и программной группы. Сравниваем, корректно ли установщик определил имя клиента, и разрешаем использовать локальные имя и пароль клиента для аутентификации (отвечаем «Yes»). После установки – не соглашаемся перезагрузить компьютер – сделаем это чуть позже. Вместо этого открываем редактор реестра командой regedt32.exe (regedit.exe – не годится!) и находим ветку HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\MSLicensing. Выделяем ее и выбираем меню «Безопасность → Разрешения». Проходимся по всем перечисленным там пользователям и группам, выставляя всем галочку «Полный доступ». Жмем «ОК» и выходим из программы редактирования реестра. Перезагружаем клиента. Подразумевается, что в домене уже заведены учетные записи пользователей и клиентские компьютеры введены в домен. Заходим в систему с учетной записью пользователя, работающего на этом компьютере. Запускаем с рабочего стола или из меню «Пуск» Citrix Program Neighborhood. На предложение ввести имя и пароль жмем Cancel и соглашаемся, что хотим прервать подключение. Меню «Tools → ICA-Settings». Устанавливаем две нижние галочки – Pass-Through authentication и Use Local Credentials for log on и жмем OK. Завершаем сеанс пользователя (Logoff) и вновь входим с его учетной записью. Снова открываем Citrix Program Neighborhood. Если наш значок «1C-Terminal» не появился автоматически, то следуем дальнейшим инструкциям. Выбираем «Find New Application Set». Если ярлыка «Find New Application Set» не видно, тогда нажимаем кнопку «UP» и затем «Find New Application Set». Выбираем «Local Area Network», «Далее», кликаем по галочке справа на поле «Click below to locate the Application Set to add». Там должно отобразиться имя созданной нами фермы приложений. Если этого не произошло (такое бывает, когда у нас в сети несколько серверов Citrix или по причине отсутствия мультиадресной рассылки информации о серверах) и мы получили сообщение о невозможности найти что-либо, то выполняем следующие действия: Кнопка «Server Location», Network Protocol → TCP/IP, Address List → Add… Вводим IP-адрес нашего сервера и нажимаем «ОК», затем снова «ОК». Опять кликаем по галочке справа на поле «Click below to locate the Application Set to add».

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

Выбираем ее и жмем «Далее». Следующее окно оставляем без изменений (Colors → Use server Default, Windows Size → Seamless Window). «Далее» → «Готово». Найденная ферма появится в нашем окне Citrix Program Neighborhood. Правой клавишей кликаем по ней и выбираем «Set as default». Затем снова правой клавишей – «Application Settings → Logon Information». Проверяем, чтобы были установлены галки Local User и Pass-Through Autentification. Жмем «ОК» и дважды кликаем по нашей ферме. Если мы все сделали правильно, то в списке приложений появится наше опубликованное (1C-Terminal), а его ярлык будет автоматически добавлен на рабочий стол пользователя и в меню «Пуск → Citrix Program Neighborhood». Если вместо этого появилось окно запроса имени пользователя и пароля – закрываем все окна и перезагружаем компьютер. Если все нормально – закрываем окно Citrix Program Neighborhood и запускаем с рабочего стола или из меню «Пуск» наше опубликованное приложение. Внимание! Приложения в терминальном режиме могут запускаться гораздо дольше обычного, зато работают потом намного быстрее. Поэтому, запустив приложение один раз, дождитесь его загрузки. Объясните это пользователям, так как на опыте проверено, что жать они будут на ярлык до посинения, запуская все новые и новые сессии. В итоге все подвиснет. После запуска приложения в системном трее появляется значок подключения к серверу Citrix. Он и сигнализирует, что приложение уже запущено. Если же запуска не произошло в течение продолжительного времени (более минуты), то стоит проверить права на ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ MSLicensing. Об этом мы говорили в самом начале этой главы. Итак, наше приложение 1C-Terminal запустилось, и мы готовы к добавлению пользователю рабочих баз данных. Тут все почти стандартно. Единственное замечание – при попытке прописать базу через «Обзор» система выдаст сообщение «ICA Client File Security». Ответим «Full Access» и «Never ask me again for any application». Данный вопрос задается, если пользователь является локальным администратором на своей рабочей станции или данный пользователь имеет право на подключение к общим системным ресурсам <DriveLetter>$, так как по умолчанию в Citrix MF XP включен режим присоединения клиентских дисков. После этого можно спокойно прописывать все необходимые базы. Если базы у всех пользователей одинаковы и неизменны, можно импортировать каждому пользователю ветку реестра при входе, что позволит каждому новому пользователю автоматически получать список баз. Например, для системы 1С:Предприятие 7.7 список баз хранится в ветке реестра: HKEY_CURRENT_USER\Software\1C\1Cv7\7.7\ Titles. Сохраните ее, например, в файле Titles.reg и пропишите в Logon-script строку: regedit -s Titles.reg

Однако подобные вопросы автоматизации выходят за рамки данной статьи. Итак, помните, что самый главный смысл терминального решения, если вы ждете от него ускорения работы при-

образование ложений, работающих, например, с dbf-базами, – это локальное расположение рабочих данных! Все, можно работать.

Настройка удаленных клиентов Теперь реализуем подключение удаленных клиентов через Интернет к нашему серверу приложений. Для начала рассмотрим методику настройки подключения к самому серверу, а затем настроим клиентов. Подразумевается, что сеть с настроенным нами сервером приложений имеет интернет-подключение с выделенным внешним IP-адресом. О его наличии необходимо проконсультироваться у провайдера. На сервере нам необходимо указать так называемый «альтернативный адрес», с которым будут работать удаленные клиенты. Это тот самый внешний IP-адрес. Открываем командную строку и вводим команду: Altaddr /SET <IP-address>

где <IP-address> – наш внешний IP-адрес. Например: Altaddr /SET 195.131.101.xxx

Затем необходимо разрешить прохождение нужных нам пакетов на межсетевом экране (Firewall), а также предоставить нашему серверу выход наружу по технологии NAT, либо напрямую. Порты, которые мы должны открыть: Входящие соединения: ! Источник: IP-удаленных клиентов (или Any, если мы его не знаем или он динамический). ! Порты источника: >1024. ! Получатель: наш внешний IP. ! Порты получателя: UPD-1604, TCP-1494. Исходящие соединения:

! Источник: внутренний IP нашего сервера (если он напрямую не подключен к Интернету).

! Порты источника: UPD-1604, TCP-1494. ! Получатель: IP-удаленных клиентов (или Any, если мы его не знаем или он динамический).

! Порты получателя: > 1024. Если наш сервер подключен к Интернету с использованием технологии NAT, то необходимо организовать перенаправление пакетов по указанным портам с внешнего интерфейса Firewall на внутренний интерфейс сервера. То есть необходимо указать, что сигналы, приходящие на порт 1604 по протоколу UPD и на порт 1494 по протоколу TCP, – необходимо перенаправлять на те же порты внутреннего IP-адреса сервера. Применяйте для этого средства, при помощи которых вы организовали реализацию технологии NAT – почти наверняка они там присутствуют. Ранее автором была написана статья по реализации этого решения – технологии общего доступа в Интернет, защиты при помощи межсетевого экрана и организации доступа внутрь сети извне при помощи продукта WinRoute Pro 4.2. On-line редакция статьи находится здесь: http://www.kuban.ru/forum_new/ forum10/modpage/FAQ/wr/index.shtml .

К сожалению, стандартными средствами Firewall, встроенного в Windows, проброс портов внутрь сети выполнить невозможно, поэтому необходимо воспользоваться одним из дополнительных средств. Теперь настроим удаленных клиентов. Их конфигурирование практически аналогично клиентам локальной сети, за исключением описанных ниже моментов. На этапе выбора адреса для подключения выбираем «Wide Area Network», жмем «Далее», кнопка «Server Location», «Network Protocol → TCP/IP, Address List → Add…». Вводим внешний IP-адрес нашего подключения в основном офисе, затем опцию «Firewalls» и устанавливаем галку «Use Alternate address for firewall connection». Нажимаем дважды «ОК». Кликаем по галочке справа на поле «Click below to locate the Application Set to add». Если мы корректно настроили межсетевой экран, то должно вывалиться имя созданной нами фермы приложений. Далее все так же, как и при настройке клиентов локальной сети. Рекомендуется после добавления нашей фермы приложений кликнуть по ней правой клавишей мыши, перейти на закладку Default Option и установить четыре самых верхних галки (Use data compression, Use cache for bitmap, Queue mouse movement and keystrokes, Turn off desktop integration for this application set), а также выставить параметр Speed Screen Latency Reduction в положение «ON» и установить справа две галки: «Mouse click feedback» и «Local Text Echo». Настройки глубины цвета выбираем, исходя из ширины нашего канала и необходимости экономии трафика. Для минимализации объемов передаваемых данных и обеспечения максимально возможной скорости на тонких каналах связи выбираем 16 или 256 цветов. Наиболее комфортный вид обеспечивается при глубине цвета не менее 16 бит. На работе самой программы это никак не отразится – будет лишь изменена отображаемая цветовая гамма. Помним, что клиенты удаленного офиса должны также иметь либо прямое подключение к Интернету, либо использовать технологию NAT, а на межсетевом экране должно быть разрешено подключение этих клиентов на порты UDP1604 и TCP-1494 для внешнего IP-адреса основной сети, где расположен сервер терминалов. В данном случае имеется в виду Firewall, стоящий в клиентской сети. В завершение хотелось бы привести полезную ссылку. Несмотря на то, что во время написания статьи автор не пользовался приведенным ниже ресурсом, а основывался на личном опыте, все равно крайне рекомендуется его изучить, так как данная статья является средством Step-byStep, а информация по приведенной ниже ссылке – наиболее полным руководством по продуктам Citrix в России. Все мы так или иначе ее использовали при изучении данной технологии: http://citrix.1th.ru/admin3/index.html. Автор выражает признательность всем коллегам, которые помогали в редактировании этой статьи на этапе ее тестирования.

Литература: 1. Марков Р. Установка и настройка W2K Server. – Журнал «Системный администратор», №10, октябрь 2004 г. – 88-94 с.

подписка на I полугодие 2005 Российская Федерация ! Подписной индекс: 81655

Каталог агентства «Роспечать»

Объединенный каталог «Пресса России» Адресный каталог «Подписка за рабочим столом» Адресный каталог «Библиотечный каталог» Альтернативные подписные агентства: Агентство «Интер-Почта» (095) 500-00-60, курьерская доставка по Москве Агентство «Вся Пресса» (095) 787-34-47 Агентство «Курьер-Прессервис» Агентство «ООО Урал-Пресс» (343) 375-62-74 Подписка On-line http://www.arzy.ru http://www.gazety.ru http://www.presscafe.ru

! Подписной индекс: 87836

! Казахстан

! !

СНГ В странах СНГ подписка принимается в почтовых отделениях по национальным каталогам или по списку номенклатуры АРЗИ: ! Азербайджан – по объединенному каталогу российских изданий через предприятие по распространению печати «Гасид» (370102, г. Баку, ул. Джавадхана, 21)

– по каталогу «Российская Пресса» через ОАО «Казпочта» и ЗАО «Евразия пресс» Беларусь – по каталогу изданий стран СНГ через РГО «Белпочта» (220050, г.Минск, пр-т Ф.Скорины, 10) Узбекистан – по каталогу «Davriy nashrlar» российские издания через агентство по распространению печати «Davriy nashrlar» (7000029, Ташкент, пл.Мустакиллик, 5/3, офис 33) Армения – по списку номенклатуры «АРЗИ» через ГЗАО «Армпечать» (375005, г.Ереван, пл.Сасунци Давида, д.2) и ЗАО «Контакт-Мамул» (375002, г. Ереван, ул.Сарьяна, 22) Грузия – по списку номенклатуры «АРЗИ» через АО «Сакпресса» ( 380019, г.Тбилиси, ул.Хошараульская, 29) и АО «Мацне» (380060, г.Тбилиси, пр-т Гамсахурдия, 42) Молдавия – по каталогу через ГП «Пошта Молдавей» (МД-2012, г.Кишинев, бул.Штефан чел Маре, 134) по списку через ГУП «Почта Приднестровья» (МD-3300, г.Тирасполь, ул.Ленина, 17) по прайслисту через ООО Агентство «Editil Periodice» (2012, г.Кишинев, бул. Штефан чел Маре, 134) Подписка для Украины: Киевский главпочтамп Подписное агентство «KSS» Телефон/факс (044)464-0220

Подписные индексы:

81655 по каталогу агентства «Роспечать»

87836 по каталогу агентства «Пресса России»

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

СИСТЕМНЫЙ АДМИНИСТРАТОР №11(24), Ноябрь, 2004 год РЕДАКЦИЯ Исполнительный директор Владимир Положевец Ответственный секретарь Наталья Хвостова sekretar@samag.ru Технический редактор Владимир Лукин Редактор Андрей Бешков РЕКЛАМНАЯ СЛУЖБА тел./факс: (095) 928-8253 Константин Меделян reсlama@samag.ru Верстка и оформление imposer@samag.ru maker_up@samag.ru Дизайн обложки Николай Петрочук

ЧИТАЙТЕ В СЛЕДУЮЩЕМ НОМЕРЕ: Защита сетевых сервисов с помощью stunnel Как защитить от прослушивания и вмешательства извне данные, передаваемые сервисами POP3, IMAP, MySQL, syslog? Предлагаем решить эту задачу с помощью SSL и stunnel – для этого вам не придется прилагать больших усилий.

Linspire одним глазком

Developers Edition, датированной январем 2004 года. С тех пор было выпущено несколько исправлений, однако базовая функциональность системы не претерпела существенных изменений.

Единая учетная запись для Windows и Linux/UNIX в Active Directory В данной статье пойдет речь о том, как управлять единой учетной записью пользователя посредством MS Active Directory и Services For Unix, независимо от того, на какой платформе работает пользователь, будь то Windows или Linux/UNIX.

ИЗДАТЕЛЬ ЗАО «Издательский дом «Учительская газета»

Фирма Linspire – ветеран движения за популяризацию Linux, хотя самой торговой марке едва насчитывается пять месяцев. Между тем, компания была основана в далеком 2001 году. С тех пор и по сей день ее бессменным управляющим является всемирно известный авантюрист-инноватор Майкл Робертсон, создатель портала MP3.com. Первоначально компания называлась Lindows, а ее основное детище и герой сегодняшней статьи, настольный дистрибутив Linux – LindowsOS. Такое явное созвучие с «окнами» не могло понравиться корпорации Microsoft и очень быстро стало предметом многочисленных судебных разбирательств, как на территории США, так и за их пределами… В данном обзоре мы рассмотрим основные возможности Linspire 4.5.189

Отпечатано типографией ГП «Московская Типография №13» Тираж 7000 экз.

Вы можете приобретать журналы в магазинах и торговых точках г. Москвы по адресам:

103045, г. Москва, Ананьевский переулок, дом 4/2 стр. 1 тел./факс: (095) 928-8253 Е-mail: info@samag.ru Internet: www.samag.ru РУКОВОДИТЕЛЬ ПРОЕКТА Петр Положевец УЧРЕДИТЕЛИ Владимир Положевец Александр Михалев

Журнал зарегистрирован в Министерстве РФ по делам печати, телерадиовещания и средств массовых коммуникаций (свидетельство ПИ № 77-12542 от 24 апреля 2002г.) За содержание статьи ответственность несет автор. За содержание рекламного обьявления ответственность несет рекламодатель. Все права на опубликованные материалы защищены. Редакция оставляет за собой право изменять содержание следующих номеров.

Идеальный карманный компьютер для системного администратора Часть 2 Продолжаем знакомить читателей с карманным компьютером, работающим под управлением операционной системы Linux от компании Sharp. Из заключительной части статьи вы узнаете об особенностях установки и сборки программ для КПК, а также о возможностях, которые он предоставляет системному и сетевому администратору.

! ! ! !

Магазин «Компьютерная и деловая книга» (Ленинский проспект, строение 38). Выставочный компьютерный центр «Савеловский» (Киоск у главного входа). Выставочный компьютерный центр «Буденовский». Книжная ярмарка «Центральная». Mагазин «Деловая и учебная литература» (м. Тульская, Варшавское шоссе, д.9. эт. 5, павильон 515-09). ! ТЦ «Электроника на Пресне». Mагазин «Техкнига» (павильон 8-9). ! Редакция «Учительская газета» (Ананьевский переулок, д. 4/2, стр. 1).

On-line магазины: ! ! ! !

Уважаемые читатели! www.allsoft.ru www.linuxcenter.ru www.linuxshop.ru www.bolero.ru

НЕ ПРОПУСТИТЕ ПОДПИСКУ на первое полугодие 2005 года подробная информация на стр. 95