WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 | 2 || 4 | 5 |   ...   | 7 |

«Perl для системного администрирования Дэвид Я. Бланк-Эделъман Canlm /iCj Lx Lx '/ Дэвид Н. Бланк-Эдельман Perl для системного ...»

-- [ Страница 3 ] --

Некоторые инсталляторы можно запускать в так называемом режиме» для полной автоматизации установки. В этом режиме они йе задают никаких вопросов и не просят нажимать кнопки «ОК», осво бождая администратора от необходимости сидеть нянькой при инстал ляторе. Если такой режим не поддерживается механизмом установки (а подобных случаев очень много), это сильно усложняет жизнь сис темного администратора. Win32: : Setupsup помогает справиться с таки ми трудностями. Он позволяет найти информацию о работающих про' павление процессами в NT/ цессах и работать с ними (либо завершить эти процессы, если вы того пожелаете).

Обратитесь к разделу «Информация о модулях из этой главы», чтобы узнать, как получить и установить модуль Win32 : : Setupsup.

Используя Win32: : Setupsup, получить список выполняемых процессов очень просто. Вот слегка измененная версия примера, который можно увидеть в последнем разделе:

use Win32: :Setupsup;

$rnachine = "";

# получаем список на текущей машине Win32:

-.Setupsup: :GetProcessList($machine, \@processlist, \@threadlist) or die "Ошибка получения списка процессов: ".Win32: :Setupsup: :Getl_astError(). "\n";

pop(@processlist);

ft удалить фальшивую запись, всегда и добавляемую к списку foreach $processlist (@processlist){ $pid = $processlist->{pid};

$name = $processlist->{name};

write;

format STDOUT_TOP = Process ID Process Name format STDOUT = @<««« $pid, $name Завершение процессов тоже очень просто:

KillProcess($pid, $exitvalule, Ssystemprocessflag) or die "Невозможно завершить процесс: ".Win32::Setupsup::GetLastError()."\n";

Два последних аргумента необязательны. Первый завершает процесс и, соответственно, устанавливает его код завершения (по умолчанию это 0). Второй аргумент позволяет вам завершать системные процессы (при условии, что у вас есть право Debug Prog rams).

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

Win32::Setupsup::EnumWindows(\@windowlist) or die "Ошибка получения списка процессов:

".Win32::Setupsup::GetlastError()."\n";

132 Глава 4. Действия пользователе^ @windowlist теперь содержит список дескрипторов окон, лъторые вы глядят как обычные числа, если их напечатать. Чтобы узнать больще о каждом окне, можно использовать несколько различных функций Например, чтобы прочитать заголовки всех окон, воспользуемся функцией GetWindowText( ) :

use Win32: :Setupsup;

Win32: :Setupsup: :EnumWindows(\@windowlist) or die "Ошибка получения списка процессов:

".Win32: : Setupsup: :GetLastError(). "\n";

foreach Swhandle (@windowlist){ if (Win32: : Setupsup: :GetWindowText($whandle,\$text)){ print "$whandle: $text","\n";

} else { warn "Невозможно получить текст для Swhandle".

Win32:

-.Setupsup: :GetLastError(). "\n";

Вот небольшой отрывок получаемых данных:

66130: chapter02 - Microsoft Word 66184: Style 194905150:

66634: setupsup - WordPad 65716: Fuel 328754: DDE Server Window 66652:

66646:

66632: OleMainThreadWndName Как видите, у некоторых окон есть заголовки, а у некоторых их нет.

Внимательные читатели могли заметить в этом отрывке еще кое-что любопытное. Окно 66130 принадлежит сеансу Microsoft Word, запущен ному в настоящий момент (в нем набиралась эта глава). Окно 661 84 смут но напоминает название еще одного окна, связанного с Microsoft Word.

Как мы можем узнать, действительно ли эти окна взаимосвязаны?

В Win32: :Setupsup также есть функция EnumChildWindowsO, которая п°' зволяет вывести список дочерних окон для любого окна. Использует ее для вывода иерархии текущего окна:

use Win32: :Setupsup;

ft получаем список окон Win32: :Setupsup: :EnumWindows(\@windowlist) or die "Ошибка получения списка процессов:

".Win32: :Setupsup: :Getl_astError(). "\n";

.

управление процессами в NT/2000 # превращаем список дескрипторов окон в хэш # ЗАМЕЧАНИЕ: в результате преобразования # элементами хэша становятся обычные числа, # а не дескрипторы окон. Некоторые функции, # например GetWindowProperties # (которую мы скоро рассмотрим), # не могут использовать эти преобразованные числа.

# Будьте осторожны.

for (@windowlist){$windowlist{$_}++;

} Я проверяем наличие дочерних окон для каждого окна foreach $whandle (@windowlist){ if (Win32: :Setupsup: :EnumChildWindows($whandle,\@children)){ # сохраняем отсортированный список дочерних окон $children{$whandle} = [sort {$a <=>$b} ^children];

# удаляем все дочерние окна из главного хэша, # в результате всех итераций %windowlist будет # содержать только родительские окна без О соответствующих дочерних foreach $child (@children){ delete $windowlist{$child};

ft обходим в цикле список родительских окон # и тех окон, у которых нет дочерних, # и рекурсивно печатаем дескриптор каждого Я окна и его дочерние окна (если они есть) foreach my $window (sort {$a <=> $b} keys %windowlist){ &printfamily($window,0);

ff выводим дескриптор заданного окна и его дочерних окон # (рекурсивно) sub printfamily { и начальное окно, насколько глубоко мы ушли по дереву?

my($startwindow,$level) = @_;

# выводим дескриптор окна с соответствующим отступом print((" " х $level). "$startwindow\n");

return unless (exists $children{$startwindow});

и дочерних окон нет, # дело сделано Авторский комментарий здесь выглядел так: «# remove all children from the hash, we won't iterate over them» (удаляем все дочерние окна из хэша, мы не будем напрямую рассматривать их в цикле). - Примеч. науч. ред.

т 134 Глава 4. Действия пользователей К в противном случае мы должны рекурсивно обойти дочерние окна $level++;

foreach $childwindow (@{$children{$startwindow}}){ &printfamily($childwindow,$level);

Есть еще одна функция, о которой надо сказать, перед тем как двига ться дальше: GetWindowProperties(). Функция GetWindowProperties() вме щает в себя остальные свойства окон. Например, используя GetWindow PropertiesO, можно получить идентификатор процесса, создавшего конкретное окно. Это разумно совместить с некоторыми из только что рассмотренных возможностей модуля Win32: : IP гос.

В документации к модулю W i n 3 2 : : Setupsup есть список свойств, и к ним можно обратиться. Используем одно из них для написания очень прос той программы, которая выведет размеры окна на экране. GetWindow PropertiesO принимает три аргумента: дескриптор окна, ссылку на массив, содержащий имена запрашиваемых свойств, и ссылку на хэш, где будут храниться результаты запроса. Вот какой код мы применим для этого:

Win32::Setupsup::GetWindowProperties($ARGV[0],["rect","id"],\%info);

print "\t". $info{rect}{top}. "\n";

print $info{rect}{left}. " -". $ARGV[0].

"- ". $info{rect}{right}. "\n";

print "\t". $info{rect}{bottom}. "\n";

Вывод получается несколько вычурным. Вот как выглядит вывод раз меров (координат верхнего, левого, правого и нижнего края) окна с де скриптором 66180:

272 -66180- GetWindowPropertiesO возвращает специальную структуру данных только для одного свойства rect. Все остальные будут представлены в хэше в виде обычных ключей и значений. Если вы не уверены в свойст вах, возвращаемых Perl для конкретного окна, воспользуйтесь утили той windowse, которую можно найти на http://greatis.virtualave.net/ products.htm.

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

ение процессами в NT/2000 авл "Prestidigitation In Progress... 32% complete" Чтобы внести эти изменения, достаточно одного вызова функции:

Win32::Setupsup::SetWindowText($handle,$text);

Свойство rect тоже можно установить таким образом. Следующие строки заставляют указанное окно переместиться в заданную позицию экрана:

use Win32::Setupsup;

$info{rect}{left} = 0;

$info{rect}{right} = 600;

$info{rect}{top} = 10;

$info{rect}{bottom}= 500;

Win32::Setupsup::SetWindowProperties($ARGV[0],\%info);

Самую впечатляющую функцию я приберег напоследок. При помощи SendKeysO можно послать произвольные комбинации клавиш любому окну на рабочем столе. Например:

use Win32::Setupsup;

Stexttosend = "\\DN\\Low in the gums";

Win32::Setupsup::SendKeys($ARGV[0], Stexttosend, ",0);

В результате, в указанное окно будет послан текст, предваряемый сим волом «курсор вниз». Аргументы SendKeysO очень просты: дескриптор окна, посылаемый текст, флаг, определяющий, нужно ли активизиро вать окно для каждого сочетания клавиш, и необязательный интервал между сочетаниями клавиш. Коды специальных символов, таких как «курсор вниз», окружаются обратными слэшами. Список допустимых кодов можно найти в документации к модулю.

С помощью этого модуля мы попадаем на иной уровень управления процессами. Теперь мы можем удаленно управлять приложениями (и частями операционной системы), не взаимодействуя явно с этими при ложениями. Нам не нужна поддержка командной строки или специ альных API. У нас есть возможность писать сценарии для GUI, что очень полезно во множестве задач системного администрирования.

Для создания сценариев по графическому интерфейсу может быть полезен модуль Win32Guitest Эрнесто Гуисадо (Ernesto Guisado). Он поддерживает те же возможности, что и Win32: :Setupsup.

136 Глава 4. Действия пользователе^ Использование инструментария управления окнами (Window Management Instrumentation, WMI) Перед тем как перейти еще к одной операционной системе, рассмот рим последний подход к управлению процессами в NT/2000. Этот под ход следовало бы назвать «Страной будущего», поскольку в нем ис пользуется пока еще не очень распространенная, но уже пробивающа яся технология. Инструментарий управления окнами (WMI) доступен в Windows 2000 (и в NT4.0 с установленным SP4+).1 Со временем, ког да Windows 2000 широко распространится, WMI вполне может стать важной частью администрирования NT/2000.

К сожалению, WMI относится к числу технологий не для слабонерв ных, потому что очень быстро становится чересчур сложной. Она осно вана на объектно-ориентированной модели, которая позволяет пред ставить не только данные, но и отношения между объектами. Напри мер, можно создать связь между веб-сервером и дисковым массивом RAID, в котором хранятся данные с этого сервера, обеспечивающую, в случае неисправности массива RAID, сообщение и о проблеме с веб сервером. Не желая вдаваться во все эти сложности, мы дадим здесь лишь поверхностный обзор WMI в небольшом и простом введении, сопровождаемом примерами.

Если вы хотите познакомиться с этой технологией подробнее, я реко мендую загрузить документацию по WMI, обучающее руководство «LearnWBM» и WMI SDK из раздела «WMI» сайта http:/ /msdn.micro soft.com/developer/sdk. Также взгляните на информацию, представ ленную на веб-сайте Distributed Management Task Force на http:// www.dtmf.org. Тем временем, начнем с краткого экскурса.

WMI - это реализация и расширение (от Microsoft) неудачно назван ной инициативы Web-Based Enterprise Management или WBEM. И хо тя такое название вызывает в воображении что-то связанное с броузе рами, эта технология не имеет практически ничего общего с World Wi de Web. Компании, входившие в состав Distributed Management Task Force (DMTF), хотели придумать что-то, что могло бы упростить вьт полнение задач управления при помощи броузеров. Забыв про назва ние, можно сказать, что WBEM определяет модель данных для инфор' мации управления. WBEM обеспечивает спецификацию для организа ции, доступа и перемещения этих данных. WBEM также предлагает связующий интерфейс для работы с данными, доступными из других протоколов, например, Simple Network Management Protocol (SNMPI (о котором мы будем говорить в главе 10 «Безопасность и наблюдение за сетью») и Common Management Information Protocol (CMIP).

Раздел «Download SDK» из секции о WMI на http://msdn.microsoft.com/de' veloper/sdk позволяет загрузить библиотеки, необходимые для запуск WMI на машине с NT4.0SP4 (или выше).

фавление процессами в NT/ Данные в WBEM организованы при помощи Общей информационной модели (Common Information Model, CIM). CIM - источник силы и сложности в WBEM/WMI. Она предоставляет расширяемые модели данных, содержащие объекты и классы объектов для любой физичес кой или логической сущности, которой можно захотеть управлять.

Например, в ней есть классы объектов для целых сетей и объекты для отдельного слота машины. Существуют объекты для настроек как ап паратного обеспечения, так и приложений программного обеспечения.

Помимо этого CIM позволяет определять классы объектов, описываю щие связи между другими объектами.

Модель данныхлокументирована в двух частях: в спецификации CIM и схеме CIM. Первая описывает, как (как данные определяются, их связь с другими стандартами управления и т. д.);

вторая - что (т. е.

сами объекты). Это деление может напомнить о связи SNMP SMI и MIB (подробный материал в главе 10).

На практике вы будете чаще обращаться к схеме CIM, чем к специфи кации, когда вы освоитесь с тем, как представляются данные. Формат схемы, названный форматом управляемых объектов (Managed Object Format, MOF), довольно просто читать.

Схема CIM состоит из двух слоев:

• Центральная модель (core model) для объектов и классов, полезна для всех типов взаимодействия WBEM.

• Общая модель (common model) для объектов, которые не зависят от создателя и операционной системы. Внутри общей модели в настоя щее время определены пять областей: системы, устройства, прило жения, сети и физический уровень.

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

Самая важная часть WMI, которая отличает ее от обычных реализа ций WBEM, - это схема Win32, расширенная схема для информации, специфичной для Win32, построенная на центральной и общей моде ли. WMI также добавляется к общей структуре WBEM, обеспечивая механизмы доступа к данным CIM, специфичные для Win32. 1 Исполь зуя это расширение схемы и набор методов доступа к данным, мы мо жем выяснить, как управлять процессами из Perl средствами WMI.

Два из этих методов доступа: ODBC (открытый интерфейс взаимодейст вия с базами данных) и COM/DCOM (модель составных компонентов/ распределенная модель составных компонентов) будут более полно До тех пор пока Microsoft будет стремиться сделать эти механизмы повсе местными, вероятность найти их не в Win32-OKpy>KeHHH очень мала. Вот почему я называю их « специфичными для Win32 ».

138 Глава 4. Действия пользователей рассмотрены в других главах этой книги. В примерах будет использо ваться модель COM/DCOM, поскольку ODBC разрешает лишь запра шивать информацию у WMI (хотя и в простой, похожей на присущу^ базам данных манере). COM/DCOM позволяет и запрашивать инфор мацию, и взаимодействовать с ней, что очень важно для «управляю щей» части контроля над процессами.

Приведенные далее примеры программ на Perl не выглядят такими у^ трудными, и вас могут удивить слова «очень быстро становится черес чур сложным». Приведенный ниже код выглядит простым, потому что:

• Мы касаемся только поверхности WMI. Мы даже не затрагиваем таких понятий, как «ассоциации» (т. е. связи между объектами и классами объектов).

• Мы выполняем только простые операции управления. Управление процессами в таком контексте состоит из опроса исполняемых про цессов и возможности их завершения. Эти операции легко осущест вляются в WMI при использовании расширения схемы Win32.

• В наших примерах спрятана вся сложность перевода документации WMI и примеров программ с VBscript/JScript на Perl.

• В примерах скрыта неясность процессов отладки. Когда код на Perl, имеющий отношений к WMI, завершается с ошибками, выда ется очень мало информации, которая могла бы помочь найти их причину. Да, вы получите сообщения об ошибках, но в них никогда не будет сказано ОШИБКА: ПРОБЛЕМА ЗАКЛЮЧАЕТСЯ В СЛЕДУЮЩЕМ,.. Скорее всего, вы получите что-нибудь подобное w b e m E r r F a i l e d 0x8004100 или вообще пустую структуру данных. Справедливости ради надо ска зать, что большая часть такой неясности возникает благодаря уча стию Perl в этом процессе. Он действует в качестве интерфейса к це лому ряду довольно сложных многоуровневых операций, которые не утруждают себя передачей содержательных сообщений в случае возникновения проблем.

Это звучит довольно мрачно. Поэтому позвольте предложить совет, воспользоваться которым стоит перед тем, как рассматривать сами примеры:

• Изучите любые примеры, использующие модуль W i n 3 2 : :OLE, кото рые сможете найти. Список рассылки Win32-Users на ActiveState и его архивы на http://www.activestate.com - хороший источник по добной информации. Если сравнить их с эквивалентными примера' ми на VBscript, то станут понятны необходимые идиомы транслЯ' ции. Кроме того, вам может помочь раздел «ADSI (Интерфейсы ак тивных служб каталогов)» главы 6.

• Подружитесь с отладчиком Perl и используйте его для тщательной проверки фрагментов кода в качестве части процесса обучения Другой способ тестирования на платформе Win32 отрывков кода на Perl - применение программы TurboPerl Вильяма Смита (William управление процессами в NT/2000 P. Smith), ее можно найти на http://users.erols.com/turboperl/, сов местно с модулями dumpvar.pl или D a t a : : D u m p e r. E ней бывают сбои (я советую чаще сохранять исправления), но обычно она может по мочь в создании заготовок кода на Perl. Другие инструменты интег рированной среды разработки также могут обладать подобными возможностями.

• Всегда держите под рукой копию WMI SDK. Его документация и примеры кода на VBscript очень полезны.

• Чаще используйте броузер объектов WMI в WMI SDK. Он поможет вам разобраться со структурой.

Теперь перейдем к Perl. Первоначальная наша задача - определить, какую информацию о процессах в Win32 можно получить и как ее ис пользовать.

Сначала нужно установить соединение с пространством имен (names pace) WMI. Пространство имен определяется в WMI SDK как «едини ца для группировки классов и экземпляров для управления их облас тью действия и видимостью». Нам необходимо соединение с корнем стандартного пространства имен cimv2, в котором содержатся все инте ресующие нас данные.

Кроме того, потребуется установить соединение с соответствующим уровнем привилегий. Программа должна иметь право отлаживать процесс и представлять нас;

другими словами, она должна выполнять ся от имени пользователя, запустившего сценарий. Установленное со единение позволит получить объект Win32_Process (как это определяет ся в схеме Win32).

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

use Win32: :OLECirT);

Sserver = '';

# соединение с локальной машиной О получаем объект SWbemLocator $lobj = Win32::OLE->new('WbemScripting.SWbemLocator') or die "Невозможно создать объект локатор: ".Win32::OLE->LastError()."\n";

# определяем, что сценарий выполняется с правами пользователя $lobj->{Security_}->{impersonationlevel} = 3;

ft используем это для получения объекта SWbemServices Ssobj = $lobj->ConnectServer($server, 'root\cimv2') or die "Невозможно создать объект сервер:

".Win32: :OLE->l_astError(). "\n";

140 Глава 4. Действия пользователей и получаем объект схемы Sprocschm = $sobj->Get('Win32_Process');

Сложный способ включает в себя:

• Получение объекта локатора, используемого для нахождения со единения с объектом-сервером • Установку прав, т. е. программа будет выполняться с нашими при вилегиями • Использование этого объекта для получения соединения с cimv2 пространством имен WMI • Применение этого соединения для получения объекта Win32_Process Все это можно сделать за один шаг, если использовать COM moniker's display name. В соответствии с WMI SDK, «в модели составных объек тов (СОМ) моникер - это стандартный механизм для инкапсуляции местоположения другого СОМ-объекта и связи с ним. Текстовое пред ставление моникера называется отображаемым именем». Вот и прос той способ в действии:

use Win32::OLE('in');

Sprocschm = Win32::OLE->GetObject( 'winmgmts: {impersonationl_evel=impersonate}!Win32_Process') or die "Невозможно создать объект сервера: ".Win32::OLE->LastError()."\n";

Теперь, когда у нас есть объект Win32_Process, можно с его помощью по лучить нужные части схемы, представляющие собой процессы в Win32. В их число входят все доступные свойства и методы Win32_Pro cess, которые годятся к употреблению. Применяемая программа до вольно проста;

единственно, что не вполне очевидно, - это использова ние оператора in в Win32: :OLE. Чтобы объяснить это, нам придется не много отклониться от темы.

Объект Sprocschm имеет два специальных свойства: Properties_ и Met hods. В каждом из них хранится специальный дочерний объект, из вестный как collection object в терминологии СОМ. Объект collection ob ject является родительским контейнером для других объектов;

в этом случае в них хранятся объекты описания свойств (Properties..) и мето дов (Methods_) схемы. Оператор in возвращает массив ссылок на каЖ' дый дочерний объект контейнера. Располагая таким массивом, можно обойти все его элементы в цикле, возвращая на каждой итераций свойство Name каждого дочернего объекта. О других известных приме' нениях in можно узнать из раздела «ADSI (Интерфейсы активных служб каталогов)» главы 6. Вот как выглядит сама программа:

use Win32::OLE('in );

# соединяемся с пространством имен, даем указание действовать # с правами пользователя и получаем объект Win32_process, управление процессами в NT/2000 # просто используя отображаемое имя Iprocschm = Win32::OLE->GetObject( 'winmgmts:{impersonationLevel=impersonate}!Win32_Process') or die "Невозможно создать объект сервера: ".Win32::OLE->LastError()."\n";

print "--- Properties —\n";

print join("\n",map {$_->{Name}}(in $procschm->{Properties_}));

print "\n— Methods ---\n";

print join("\n",map {$_->{Name}}(in $procschm->{Methods_}));

Вывод (на машине с NT4.0) выглядит примерно так:

--- Properties -- Caption CreationClassName CreationDate CSCreationClassName CSName • Description ExecutablePath ExecutionState Handle InstallDate KernelModeTime MaximumWorkingSetSize MinimumWorkingSetSize Name OSCreationClassName OSName PageFaults PageFileUsage PeakPageFilellsage PeakWorkingSetSize Priority Processld QuotaNonPagedPoolUsage OuotaPagedPoolUsage QuotaPeakNonPagedPoolUsage QuotaPeakPagedPoolUsage Status TerminationDate UserModeTime WindowsVersion WorkingSetSize --- Methods -- Create Terminate GetOwner GetOwnerSid 142 Глава 4. Действия пользователей Рассмотрим это подробнее. Чтобы получить список запущенных про цессов, нужно запросить все экземпляры объектов Win32_Process :

use Win32: :OLE( 'in' );

# выполняем все первоначальные шаги в одном цикле $sobj = Win32: :OLE->GetObject( 'winmgmts: {impersonationLevel=impersonate} ' ) or die "Невозможно создать объект сервера: ".Win32: :OLE->LastError(). "\n";

foreach Sprocess (in $sobj->InstancesOf("Win32_Process")){ print $process->{Name}. " имеет pid #".$process->{Process!d}, "\n";

} Первоначальное отображаемое имя не включает путь к определенному объекту (т. е. мы отбросили ! Win32_Process). Итак, получен объект свя зи с сервером. В результате вызова метод InstancesOf () возвращает объект-коллекцию (collection object), который содержит все экземпля ры конкретного объекта. Наш код обращается к каждому объекту и выводит его свойства Name и Processld. В итоге, у нас есть список всех запущенных процессов.

Чуть менее великодушный подход к обойденным в цикле процессам позволил бы использовать один из методов, указанных в приведенном выше списке:

foreach Sprocess (in $sobj->InstancesOf("Win32_Process")){ $process->Terrrinate(1 ) ;

В результате, все работающие процессы будут завершены. Я не реко мендую вам запускать эту программу в таком виде;

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

Теперь у вас есть необходимые знания, чтобы начать использовать WMI для управления процессами. В WMI есть \т32-расширения для многих других частей операционной системы, включая реестр и жур" нал событий.

Вот и все, что мы хотели сказать об управлении процессами в WinNT и 2000. Теперь перейдем к последней операционной системе.

Управление процессами в Unix Стратегии управления процессами в Unix представляют собой ину ситуацию, включающую несколько вариантов для выбора. К счастью» эти варианты даже отдаленно по своей сложности не напоминают то, что мы видели в NT, В разговоре об управлении процессами в Unix еле' дует иметь в виду три операции:

управление процессами в Unix 1. Нумерацию списка запущенных на машине процессов.

2. Изменение их приоритета или группы.

3. Завершение работы процесса.

Для последних двух операций в Perl существуют функции setpri o r i t y O, setpgrpQ и k i l l ( ). В случае с первой у нас есть несколько воз можностей. Чтобы вывести список запущенных процессов, можно:

• Вызвать внешнюю программу, например ps Поломать голову над расшифровкой /dev/kmem • • Изучить файловую систему /ргос Использовать модуль Ргос: : ProcessTable • Обсудим каждый из этих подходов. Нетерпеливым читателям могу сказать прямо сейчас, что я сам предпочитаю модуль Р г о с : : ProcessTab le, и вы можете пропустить все рассуждения и перейти сразу к расска зу о его использовании. Но рекомендую все же прочитать материал и о других технологиях, т. к. в будущем они могут вам пригодиться.

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

Однако в каждом конкретном случае она расположена в различных местах, а аргументы командной строки, которые она принимает, тоже не совпадают. Отсюда и проблема с ее применением: она недостаточно переносима.

Еще более неприятная проблема - это сложность анализа вывода (ко торый тоже отличается в различных версиях). Вот как выглядит вы вод команды ps на машине с SunOS:

PID USER %CPU %MEM SZ RSS TT STAT START TIME COMMAND IW Jul 2 0 :00 /bin/zsh 0. dnb 385 0.0 268 0 p 24103 0.0 35 :49 emacs dnb S Aug 2.610504 1092 P 389 0.0 60 :16 emacs dnb 2.5 3604 1044 p S Jul -zsh (zsh) remy 15396 0.0 IW 0.0 252 Jul 7 0.: 0 p 0:02 in. identd sys 393 0.0 0.0 28 IW Jul 29488 screen dnb 0.0 0.0 68 IW 20:15 0: 0 P 20: dnb 0.4 24 148 P7 R 0 :00 less 29544 0. -zsh (zsh) dnb 0 p6 IW Jul 24 0 : 5707 0.0 0.0 0 7 IW root 13:20 0:00 -:0 (xdm) 28766 0.0 0.0 Обратите внимание на третью строку. Два столбца в ней слились вмес те и при анализе вывода разобраться в этом будет непросто. Нет, это возможно, но просто действует на нервы. В некоторых вариантах Unix дела обстоят лучше, но это обстоятельство следует учитывать.

Программа на Perl, применяемая в этом случае, прямолинейна: в ней используются о р е п ( ) для запуска ps, while(){...} для чтения вывода 144 ' Глава 4. Действия пользователей и splitO, unpack() или s u b s t r ( ) для анализа данного вывода. Совет по этому поводу можно найти в книге Тома Кристиансена (Tom Christian sen) и Натана Торкингтона (Nathan Torkington) «Perl: Библиотека программиста», изд-во «Питер», 2000 г. («Perl Cookbook», O'Reilly).

Изучение структуры ядра Я упомянул эту возможность только для полноты картины. Можно на писать программу, которая будет открывать устройство, подобное /dev/ kmem, и обращаться к структурам памяти ядра. Таким образом можно добраться до текущей таблицы процессов и прочитать ее. Учитывая, что сделать это трудно (разобраться вручную в сложной двоичной структуре), а полученный результат не будет обладать абсолютно ни какой переносимостью (любое изменение даже версии операционной системы сделает, скорее всего, вашу программу неработоспособной), я настоятельно рекомендую не пользоваться такой возможностью.

Тем, кто все же не прислушается к этому совету, придется вспомнить документацию по функциям packQ, u n p a c k ( ) и заголовочным файлам для вашего ядра. Откройте файл памяти ядра (часто это /dev/kmem), затем выполняйте r e a d ( ) и u n p a c k ( ). Вам может понадобиться изучить исходники таких программ, как top (ищите на ftp://ftp.groupsys.com/ pub/top), выполняющих эти же задачи, используя большое количество кода на С. В следующем разделе мы рассмотрим слегка улучшенную версию этого метода.

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

Это действительно мудрая идея и это замечательно. Плохо то, что каж дый производитель/команда разработчиков, поддержав эту мудрУ концепцию, разбежались каждый в своем направлении. В результате файлы, которые можно найти в каталогах /ргос, часто специфичны для различных вариантов операционной системы, отличаясь как по именам, так и по формату. Описание того, какие файлы доступны и что в них хранится, вам придется искать на страницах руководства (обычно в разделах 4, 5 или 8) по proofs или mount_procfs.

Единственное переносимое использование файловой системы /ргос " это нумерация запущенных процессов. Если нам нужно только пере управление процессами в Unix числить идентификаторы процессов и их владельцев, мы можем при менять операторы Perl по работе с каталогами и lstat():

opendir(PROC, "/proc") or die "Невозможно открыть /proc:$!\n";

while (defined($_= readdir(PROC))){ next if ($_ eq "." or $_ eq "..");

next unless /"\d+$/;

# отфильтровываем все случайные файлы, названия ft которых могут являться идентификаторами процессов print "$_\t". getpwuid((lstat Yproc/$_")[4])."\n";

} closedir(PROC);

Для того чтобы получить подробную информацию о процессе, следует ;

открыть нужный двоичный файл из каталогов в /ргос и воспользовать ся функцией u n p a c k ( ). Обычно это файл status или psin/o. На страни цах только что упомянутых руководств есть подробная информация о С-структуре, которую можно найти в этом файле, или, по крайней ме ре, есть ссылка на включаемый (include) файл, в котором эта структу ра документирована. Поскольку эти форматы зависят от операцион ной системы (и версии ОС), вы снова столкнетесь с проблемами перено симости программы.

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

Использование модуля Proc::ProcessTable Дэниел Дж. Урист (Daniel J. Urist) (с помощью нескольких доброволь цев) написал модуль Р г о с : : ProcessTable, предоставляющий единый ин терфейс к таблице процессов для всех основных вариантов операцион ной системы Unix. Он скрывает от вас причуды различных реализа ций /ргос и kmem, позволяя писать более переносимые программы.

Просто загрузите модуль, создайте объект Ргос: :ProcessTable: :Process и используйте методы этого объекта:

use Proc::ProcessTable;

$tobj = new Proc::ProcessTable;

Этот объект использует механизм связанных переменных (tied variab le) для представления текущего состояния системы. Для обновления этого объекта не требуется вызывать специальную функцию — он пере читывает таблицу процессов при каждом обращении к нему. Это похо же на хэш %Process, знакомый нам по обсуждению модуля Мае: : Proces ses ранее в этой главе.

Чтобы получить нужную информацию, следует вызвать метод table():

Глава 4. Действия пользователе;

Sproctable = $tobj->table();

table() возвращает ссылку на массив, элементы которого представда.

ют собой ссылки на объекты процессов. Каждый из этих объектов име.

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

катеров процессов и их владельцев:

use Proc: :ProcessTable;

$tobj = new Proc: : ProcessTable;

Sproctable = $tobj->table();

for (@$proctable){ print $_->pid."\t". getpwuid($_->uid). "\n";

Список методов, доступных в вашей операционной системе, можно по лучить при помощи метода fieldsO объекта Proc: iProcessTable (т.е.

$tobj).

В Proc : : ProcessTable также есть три дополнительных метода у каждого объекта процесса: kill(), p r i o r i t y O и pgrp(), которые являются всего лишь интерфейсом к встроенным функциям, упомянутым в начале этого раздела.

Чтобы опять вернуться к общей задаче, посмотрим на применение спо собов контроля над процессами. Мы начали изучать управление про цессами в контексте действий пользователя, поэтому сейчас рассмот рим несколько маленьких сценариев, посвященных этим действиям, В примерах мы будем использовать Proc : : ProcessTable в Unix, но сами идеи не зависят от операционной системы.

Первый пример из документации по Proc: : ProcessTable:

use Proc: : ProcessTable;

$t = new Proc: :ProcessTable;

foreach $p (@{$t->table}){ if ($p->pctmem > 95){ Эта программа «отстреливает» все процессы, занимающие 95% ти в тех вариантах операционной системы Unix, где поддерживаете* метод pctmemQ (а он поддерживается в большинстве случаев). В такс* виде пример, вероятно, слишком «безжалостен», чтобы использовать его в реальной жизни. Было бы благоразумно добавить перед к дои kill () что-то подобное:

print "собираемся убрать ". $p->pid. "\t". getpwuid($p->uid). "\n";

print "выполнять? (yes/no) ";

авление процессами в Unix chomp($ans = о);

next unless ($ans eq "yes");

Здесь может возникнуть состояние перехвата: не исключено, что во время задержки, вызванной вопросом к пользователю, состояние сис темы изменится. Учитывая, что мы в данном случае работаем только с «большими» процессами, которые вряд ли меняют свое состояние в те чение короткого времени, такой вариант, скорее всего, пройдет нор мально. Если вы хотите подойти к этому вопросу более педантично, вам, наверное, стоит получить сначала список процессов, которые вы 'хотите завершить, спросить пользователя, а затем проверить еще раз состояние таблицы процессов и только потом их завершать.

Бывают случаи, когда завершение процесса - это слишком легкая рас плата. Иногда важно засечь, что процесс действительно работает, что бы предпринять необходимые меры (скажем, поставить пользователя на место). Например, политика нашего сайта запрещает применять IRC-роботы. Роботы - это процессы-демоны, которые соединяются с IRC-серверами и выполняют автоматические действия. И хотя роботы могут использоваться в благих целях, в настоящее время они, в основ ном, играют асоциальную роль в IRC. Кроме того, мы обращали вни мание на взлом системы безопасности из-за того, что первое (и часто единственное), что делал взломщик, - это запускал ШС-робота. Коро че говоря, нам важно заметить присутствие таких процессов, а не за вершать их работу.

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

use Proc::ProcessTable;

open(LOG, "»$logfile") or die "Невозможно открыть журнал для дозаписи:$!\n";

$t = new Proc::ProcessTable;

foreach $p (@{$t->table}){ if ($p->fname() =" /eggdrop/i){ print LOG time."\t".getpwuid($p->uid).

"\t".$p->fname()."\n";

} } close(LOG);

Тот, кто подумает: «Эта программа не так уж и хороша! Все, что нужно сделать, чтобы ускользнуть от этой проверки, так это всего лишь пере именовать исполняемый файл», будет абсолютно прав. Мы попытаем ся написать менее простодушный код, ищущий роботов, в самом по следнем разделе этой главы.

А пока рассмотрим еще один пример, в котором Perl помогает управ лять процессами пользователей. До сих пор все наши примеры каса 148 Глава 4. Действия пользователей лись отрицательных явлений. Рассмотренные программы имели дело со злонамеренными или жадными к ресурсам процессами. Теперь по смотрим на что-нибудь более жизнерадостное.

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

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

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

Если точность не важна и достаточно знать только приблизительную оценку набора работающих программ, можно применить Р г о с : : Р г о cessTable. Ниже приведена программа, которая активизируется каж дые пять минут и проверяет состояние текущих процессов. Она просто ведет учет всех найденных имен процессов, причем те процессы, кото рые встречались в предыдущий раз, она во второй раз не учитывает.

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

use Proc: :ProcessTable;

$interval = 600;

и 5 минут перерыва Spartofhour = 0;

# отмечаем позицию часа, в которой мы находимся $tobj = new Proc: :ProcessTable;

и создаем новый объект # вечный цикл, сбор данных каждые Sinterval секунд П и сброс этих данных один раз в час &collectstats;

&dumpand reset if (Spartofhour >= 3600);

sleep($interval);

П сбор статистики по процессу sub collectstats { управление процессами в Unix my(Sprocess);

foreach $process (@{$tobj->table}){ # мы должны игнорировать себя next if ($process->pid() == $$);

# сохраняем информацию о процессе для следующего запуска push(@last,$process->pid(), $process->fname());

# игнорируем процесс, если мы его уже видели next if ($last{$process->pid()} eq $process->fname());

# если не видели, запоминаем его $collection{$process->fname()}++;

} и устанавливаем хэш %last, используя текущую таблицу %last = @last;

Spartofhour += Sinterval;

и выводим результаты и сбрасываем значения счетчиков sub dumpandreset{ print scalar Iocaltime(time).("-"x50)."\n";

for (sort reverse_value_sort keys %collection){ write;

undef %collection;

Spartofhour = 0;

# (обратная) сортировка ло значениям хэша %collection и по # именам ключей sub reverse_value_sort{ return $collection{$b} <=> $collection{$a} || $a crop $b;

format STDOUT = $collection{$_} format STDOUT_TOP = Name Count Существует множество способов улучшить эту программу. Она могла бы отслеживать процессы для каждого пользователя (т. е. записывать один экземпляр вызова программы для каждого пользователя), соби 150 Глава 4. Действия пользователей рать ежедневную статистику, выводить информацию в виде диаграм мы и т. д. Все зависит только от того, где вы хотите ее применять.

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

Помимо этого они выполняют операции с файловыми системами и от имени пользователей загружают сеть. Администрирование пользова телей требует не забывать и об этом.

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

Отслеживание операций в Windows NT/ Попытка найти файлы, открытые другими пользователями, вернее всего сработает, если применять программу, работающую в командной строке, - nthandle Марка Руссиновича (Mark Russinovich), ее можно найти на http://www.sysinternals.com. Она позволяет показать все от крытые дескрипторы на определенной системе. Вот как выглядит ее вывод:

System pid: 10: File C:\WINNT\SYSTEM32\CONFIG\SECURITY 84: File C:\WINNT\SYSTEM32\CONFIG\SAM.LOG cc: File C:\WINNT\SYSTEM32\CONFIG\SYSTEM dO: File С:\WINNT\SYSTEM32\CONFIG\SECURITY.LOG d4: File C:\WINNT\SYSTEM32\CONFIG\DEFAULT e8: File C:\WINNT\SYSTEM32\CONFIG\SYSTEM.ALT fc: File C:\WINNT\SYSTEM32\CONFIG\SOFTWARE.LOG 118: File C:\WINNT\SYSTEM32\CONFIG\SAM 128: File C:\pagefile.sys 134: File C:\WINNT\SYSTEM32\CONFIG\DEFAULT.LOG 154: File C:\WINNT\SYSTEM32\CONFIG\SOFTWARE 1bO: File \Device\NamedPipe\ 294: File C:\WINNT\PROFILES\Administrator\ntuser.dat.LOG 2a4: File C:\WINNT\PROFIlES\Administrator\NTUSER.DAT SMSS.EXE pid: 27 (NT AUTHORITY-.SYSTEM) 4: Section C:\WINNT\SYSTEM32\SMSS.EXE c: File C:\WINNT 28: File C:\WINNT\SYSTEM Отслеживание операций с файлами и сетью Можно также запросить информацию по конкретным файлам и ката логам:

> nthandle c:\temp Handle V1. Copyright (С) 1997 Mark Russinovich http://www.sysinternals.com WINWORD.EXE pid: 652 C:\TEMP\"DFF2B3.tmp WINWORD.EXE pid: 652 C:\TEMP\~DFA773.tmp WINWORD.EXE pid: 652 C:\TEMPVDF913E.tmp Программа nthandle позволяет получить эту информацию по конкрет ному процессу при помощи ключа -р.

Использовать ее из Perl очень просто, поэтому не будем приводить примеры. Вместо этого посмотрим на подобную, но более интересную операцию - аудит.

NT/2000 позволяет эффективно отслеживать изменения в файлах, ка талогах или иерархии каталогов. Вы могли бы учитывать постоянное повторение операции stat() над нужным объектом, но это потребовало бы слишком больших затрат процессорного времени. В NT/2000 от слеживание изменений можно поручить операционной системе.

Относительно безболезненно эту работу выполняют два модуля:

W i n 3 2 : : C h a n g e N o t i f y Кристофера Мадсена (Christopher J. Madsen) и W i n 3 2 : : A d v N o t i f y Амина Мюлей Рамдана (Amine Moulay Ramdane).

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

Работа с модулем W i n 3 2 : : A d v N o t i f y - это многошаговый процесс. Для начала следует загрузить модуль и создать новый объект AdvNotify:

# также импортируем две постоянные, которые скоро будем # использовать use Win32::AdvNotify qw(All %ActionName);

use Data::Dumper;

Saobj = new Win32::AdvNotify() or die "Невозможно создать новый объект\п";

На следующем шаге нужно создать следящий поток (monitoring thre ad) для интересующего нас каталога. W i n 3 2 : :AdvNotify позволяет сле дить сразу за набором каталогов, для этого необходимо лишь создать несколько потоков. Мы же будем следить только за одним каталогом:

Sthread = $aobj->StartThread(Directory => 'C:\temp', Filter => All, WatchSubtree => 0) or die "Невозможно начать поток\п";

152 Глава 4. Действия пользователей Первый параметр этого метода говорит сам за себя;

рассмотрим ос тальные.

Установив Filter в одно из приведенных значений (табл. 4.1) или в их комбинацию (SETTING1 | SETTING2 | SETTINGS...), можно следить за раз личными типами изменений.

Таблица 4.1. Параметры Filter в Win32::AdvNotify Параметр Отмечает FILE_NAME Создание, удаление, переименование файла(ов) DIR_NAME Создание или удаление каталога(ов) ATTRIBUTES Изменение атрибутов любого каталога SIZE Изменение размера любого файла LASTJWRITE Изменение даты модификации файла(ов) CREATION Изменение даты создания файла(ов) SECURITY Изменение информации безопасности (ACL и пр.) файла(ов) Значение A l l из приведенного примера- это всего лишь постоянная, объединяющая все варианты выбора. Если не указать параметр Filter при вызове метода, то по умолчанию будет использоваться A l l. Пара метр WatchSubtree определяет, необходимо ли следить только за указан ным каталогом или за каталогом и всеми его подкаталогами.

Sta rtTh read () создает поток, но проверка начинается только после того, как поступает распоряжение об этом:

$thread->EnableWatch() or die "Невозможно начать наблюдение\п";

Существует также функция DisableWatch(), которую необходимо ис пользовать в программе для завершения проверки.

Мы следим за нужным объектом, но как узнать, изменилось ли что нибудь? Надо придумать что-то, что позволило бы потоку сообщить нам об изменениях, за которыми мы наблюдаем. Здесь тот же подход, что и в главе 9 «Журналы» при обсуждении сетевых сокетов. Обычно следует вызывать функции, которые заблокированы до тех пор, пока ничего не происходит:

while($thread->Wait(INFINITE)){ print "Что-то изменилось!\п";

last if ($changes++ == 5);

} Этот цикл w h i l e ( ) вызовет метод WaitQ для нашего потока. До тех пор пока потоку нечего сообщить, вызов будет заблокирован. Обычно Wait() принимает в качестве параметра число миллисекунд, равное времени ожидания. Мы же передаем специальное значение, которое соответст' вует «бесконечному ожиданию». Когда W a i t ( ) возвращает значение.

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

$thread->Terminate();

undef $aobj;

Наша программа пока еще не очень полезна. Нам известно, что что-то изменилось, но мы не знаем ни что изменилось, ни как это произошло.

Чтобы исправить эту ситуацию, изменим тело цикла while( ) и добавим определение формата:

while($thread->Wait (INFINITE) ){ while ($thread->Read(\@status)){ foreach $event (@status)< $filename = $event->{FileName};

$time = $event->{DateTime};

Section = $ActionName{$event->{Action}};

write;

format STDOUT = @<««««««««« §«<«««««««« @«««««««<«« $filename, $time, Saction format STDOUT_TOP = File Name Date Action Основное изменение- это добавление метода ReadQ. Он получает ин формацию об изменении и заполняет элементы списка @status ссылка ми на хэш. Каждая ссылка указывает на анонимный хэш, который выглядит примерно так:

{'FileName' => "GLF2425.TMP', 'DateTime' => '11/08/1999 06:23:25р', 'Directory' => 'C:\temp', 'Action' => 3 } Для каждого изменения могут произойти несколько событий, отсюда и необходимость вызывать Read() в цикле while(). Если соответствую щим образом разыменовать содержимое этих хэшей и применить к ним форматирование, то получатся примерно такие данные:

File Name Date Action "DF40DE.tmp 11/08/1999 07:29:56p FILE_ACTION_REMOVED ~DF6E5C.tmp 11/08/1999 07:29:56p FILE_ACTION_ADDED 154 Глава 4. Действия пользоватеж ;

~DF6E66.tmp 11/08/1999 07:29:56р FILE_ACTION_ADDED "DF6E5C.tmp 11/08/1999 07:29:56р FILE_ACTION_REMOVED К сожалению, отслеживание операций с сетью в NT/2000 впечатляет намного меньше. В идеале, как администратор вы хотели бы знать, ка кой процесс (а, следовательно, какой пользователь) открыл сетевой порт. Печально, но я не знаю ни одного модуля и ни одного инструмен та, которые могли бы предоставить такую информацию. Существует один коммерческий инструмент, работающий в командной строке, ц0д названием TCPVstat, который может показать связь процессов с ис пользованием сети. TCPVstat можно найти в пакете TCP View Professi onal Edition, который доступен на http://www.winternals.com.

Если использовать только некоммерческие инструменты, то придется иметь дело лишь со списком сетевых портов, открытых в настоящее время. Для этого следует применять другой модуль Рамдана Win32: :IpHelp. Вот как выглядит код, печатающий нужную информа цию:

use Win32: : IpHelp;

и замечание: в данном случае регистр "IpHelp" имеет значение my $iobj = new Win32: : IpHelp;

и заполняем список хэшем хэшей Siobj ->GetTcpTable(\@table, 1 ) ;

foreach Sentry ( ©table) { print $entry->{LocalIP)->{Value}. ":".

$entry->{LocalPort}->{Value}. " -> ";

print $entry->{RemoteIP}->{Value}. ":".

$entry->{RemotePort}->{Value}."\n";

Посмотрим, как можно сделать то же самое в Unix.

Отслеживание операций в Unix Для отслеживания операций с файлами и сетью в Unix можно исполь' зовать один и тот же подход. Это один из тех редких случаев, когда вы зов внешней программы намного предпочтительней. Вик Абель О Abell) преподнес чудесный подарок системным администраторам, ^ "писав программу Isof (LiSt Open Files), которую можно найти на ftp'-i vic.cc.purdue.edu/pub/tools/unlx/lsof. Isof позволяет отобразить по?

робную информацию об открытых в настоящий момент файлах и сет вых соединениях на Unix-машине. По-настоящему удивительной э^ Следует отметить, что регистр в Perl всегда имеет значение. - Примеч- " уч. ред.

156 Глава 4. Действия пользователе netscape 21065 dnb Зи VCHR 13,12 OtO 5821 /devices/ pseudo/mm@0:ze гс netscape 21065 dnb 7u FIFO Ox6034d264 Ot1 47151 PIPE-> Ox6034d1eO netscape 21065 dnb 8u inet Ox6084cb68 Oxfb210ec TCP host.ccs.neu edu:46575->host2.ccs.neu. edu:6000 (ESTABLISHED) netscape 21065 dnb 29u inet 0x60642848 Ot215868 TCP host.ccs.neu edu:46758-> www.mind-bright.se:80 (CLOSE_ WAIT) Из этого примера можно понять, насколько мощна эта команда. Мы можем увидеть текущий рабочий каталог (VDIR), обычные файлы (VREG), символьные устройства (VCHR), каналы (FIFO) и сетевые соедине ния (inet), открытые этим процессом.

Самый простой способ применить программу Isof из Perl - вызвать ее в специальном режиме «field» (-F). В этом режиме вывод программы делится на специальным образом отмеченные и разделенные поля, вместо использования колонок в стиле ps. Это позволяет надежно про анализировать и распознать вывод.

У этого способа вывода результатов есть одна особенность. Вывод орга низован в виде «наборов процессов» (process sets) и «наборов файлов» (file sets), как их называет автор. Набор процессов - это набор полей, относящихся к одному процессу;

набор файлов - это подобный же на бор для файла. Все приобретет больший смысл, если включить режим разбивки на поля с параметром 0. В этом случае поля будут разделены символом NUL (ASCII 0), а наборы - символом N1 (ASCII 12). Вот как бу дет выглядеть предыдущий вариант вывода команды, если использо вать режим разбивки на поля (NUL представлен в виде символов ~@):

p21065~@cnetscape~@u6700"@Ldnb~@ fcwd~@a "@1 ~@tVDIR~@DOx2bOOb4b"@s8192~@i12129~@n/home/dnb~@ ftxt"@a "И ~tVREG~@DOx2b004de~@s14382364~@i656749~@n/net/arch-solaris (fileserver:/vol/systems/arch-solaris)~@ ftxt"@a ~@1 ~@tVREG"@DOx800006~@s54656~@i35172~@n/usr (/dev/dsk/cOtOdOs6)"@ ftxfda "@1 "@tVREG~@DOx800006~@s146740~@i6321~@n/usr/lib/libelf.so.r@ ftxt~@a "@1 "@tVREG~@DOx800006~@s40184"(°>i6089~@n/usr (/dev/dsk/cOtOdOs6)~@ ftxt~§a ~@1 "@tVREG~@DOx800006"@s69292"@i1026ir@n/usr (/dev/dsk/cOtOdOs6)"g ftxt~@a "@1 "@tVREG"@DOx800006~@s21376~@i79751~@n/usr/lib/locale/en_US/ en_US.so.1"@ ftxt"@a "@1 ~@tVREG"@DOx800006"@s19304"ia)i5804"ian/usr/lib/libmp. so. 2"@ ftxt"@a ~@1 ~@tVREG~@DOx800006~@s98284"@i22860~@>n/usr/openwin/lib/ libICE.so.6"@ живание операций с файлами и сетью сле ftxt~@a ~@1 ~@tVREG"@DOx800006"@s46576"@i22891"@n/usr/openwin/lib/ libSM.so.6"@ ftxt"@a ~@1 "@tVREG"@DOx800006"@s1014020"@i5810"@n/usr/lib/libc.so.Г@ ftxt"@a ~@1 "@tVREG"@DOx800006"@s105788"@i5849"ian/usr/lib/libm. so. 1"@ ftxt"@a ~@1 "@tVREG"@DOx800006~@s721924"<5>i5806~@n/usr/lib/libnsl.so. Г@ ftxt~@a "@1 "«VREG^)Ox800006"(3>s166196~(s>i5774~@n/usr/lib/ld. so. 1"@ fO"@au"@l "@tVCHR"@DOx600003"@o73"@i5863"@n/devices/pseudo/ ):3->ttcompat->ldterm->pteni->pts~@ f3"@au~@l ~@tVCHR~@DOx34000c~@oO~@i582r@n/devices/pseudo/mm@0:zero~@ f7"@au~@l "@tFIFO"@dOx6034d264"@oT@i47151"@nPIPE->Ox6034d1eO"@ f8"@au"@l "@tinet"@dOx6084cb68"@o270380692"isPTCP"@nhost. ccs.neu.edu:46575-> host2.ccs.neu.edu: 6000"@TST=ESTABLISHED"@ f29~@au~@l "@tinet"@dOx60642848"@o215868"@PTCP"@nhost.ccs.neu.edu:46758-> www.mindbright.se: 80"@TST=CLOSE_WAIT"@ Давайте разберемся с этими данными. Первая строка - это набор про цессов (это можно понять по первому символу р):

p21065"@cnetscape~@u6700~@Ldnb~@ Каждое поле начинается с буквы, определяющей его содержимое (р идентификатор процесса (pid), с - команда, и - идентификатор пользо вателя (uid) и L - имя пользователя (login)), и заканчивается символом разделителя. Все поля в строке создают набор процесса. Все последую щие строки вплоть до очередного набора процесса описывают открытые файлы/сетевые соединения процесса, описываемого своим набором.

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

use Text::Wrap;

Slsofexec = "/usr/local/bin/lsof";

fl путь к Isof it режим (F)ield, разделитель NUL (0), показывать (L)ogin, # тип файла (t)ype и имя файла (n)ame Slsofflag = "-FLOtn";

open(LSOF,"$lsofexec $lsofflag|") or die "Невозможно запустить $lsofexec:$!\n";

while(){ № работаем с набором процесса if (substr($_,0,1) eq "p"){ ($pid,$login) = split(/\0/);

$pid = substr($pid,1,length($pid));

158 Глава 4. Действия пользователей ft работаем с набором файла.

8 Замечание: мы интересуемся только обычными файлами if (substr($_,0,5) eq "tVREG"){ ($type,$pathname) = split(/\0/);

8 процесс может дважды открыть один и тот же файл, 8 поэтому мы должны убедиться, что запишем его # только один раз next if ($seen{$pathname} eq $pid);

$seen{$pathname} = $pid;

Spathname = substr($pathname,1,length($pathname));

push(@{$paths{$pathname}},$pid);

close(LSOF);

for (sort keys %paths){ print "$_:\n";

print wrap("\t","\t",join(" ",@{$paths{$_}})), "\n";

В этом случае Isof будет показывать только некоторые из полей. Мож но обойти в цикле весь вывод, собирая имена файлов и идентификато ры процессов в хэш списков. Когда будут обработаны все выведенные данные, следует ввести имена файлов в виде отформатированного списка процессов (спасибо Дэвиду Шарноффу (David Muir Sharnoff ) за модуль Text : :Wrap):

/usr (/dev/dsk/cOtOdOs6):

115 117 128 145 150 152 167 171 184 191 200 222 232 247 251 276 285 286 292 293 296 297 298 4244 4709 4993 14697 20946 21065 24530 25080 27266 /usr/bin/tcsh:

4246 4249 5159 14699 /usr/bin/zsh:

24532 25082 27292 /usr/dt/lib/libXn.so.3:

21065 /usr/lib/ld.so.1:

115 117 128 145 150 152 167 171 184 191 200 222 232 247 251 267 276 285 286 292 293 296 297 298 4244 4249 4709 4991 4993 5159 14697 14699 20946 20949 21080 24530 24532 25080 25082 25947 27266 27273 27292 27306 27307 27308 27563 27564 /usr/lib/libc.so. 1:

267 4244 4246 4249 4991 4993 5159 14697 14699 21065 21080 24530 24532 25080 25082 25947 27273 27292 27306 27307 27308 27563 27564 ^еживание операций с файлами и сетью Чтобы показать последний код, относящийся к отслеживанию опера ций с файлами и сетью в Unix, вернемся к поиску запущенных ШС-ро ботов из приведенного ранее примера. Существует более надежный способ найти такие процессы-демоны, чем изучение таблицы процес сов. Пользователь может скрыть имя робота, переименовав исполня емый файл, но для того чтобы спрятать сетевое соединение, ему при дется очень хорошо потрудиться. В большинстве случаев это соедине ние с сервером на портах 6660-7000. Программа Isof позволяет без труда отыскивать такие процессы:

$lsofexec = "/usr/local/bin/lsof";

$lsofflag = "-FLOc -iTCP:6660-7000";

160 Глава 4. Действия пользователе^ • Применить методы управления процессами для проверки того, что пользователь запускает программу из существующего интерпрета.

тора. Если это единственный процесс, запущенный пользователем (т. е. если пользователь оставил его, а сам завершил работу), он, ве роятно, является демоном, а значит и роботом.

Игра в кошки-мышки привела нас к точке, позволяющей заверщить эту главу. В главе 3 мы говорили, что пользователи совершенно не предсказуемы. Они делают такие вещи, которые системные админист раторы не могут даже предвидеть. Известно старое изречение: «Защи ты от дураков не существует, потому что дураки изобретательны», с этим фактом придется считаться при программировании на Perl для администрирования пользователей. В итоге вы будете писать более на дежные программы. Когда одна из ваших программ начнет «ругаться» из-за того, что пользователь сделал что-то неожиданное, вы сможете спокойно сидеть и наслаждаться человеческой изобретательностью.

Информация о модулях из этой главы Идентифи Версия катор на Модуль CPAN Mac: '.Processes (входит в состав MacPerl;

изменен- CNANDOR 1. ную версию можно найти в пакете Mac-Glue) Win32: :АР1 0. 1. Win32 ::ISync (можно найти на http://www.generati on.net/~aminer/Perl/) Win32: :IProc (можно найти на http://www.genera.ti- 1. on.net/~aminer/Perl/) Win32:

-.Setupsup (можно найти на ftp-./lftp.roth.net/ pub/NTPerl/Others/SetupSup/ или на http://Jen da.Krynichy.cz) Win32: :Lanman (можно найти на ftp: / /ftp.roth.net/ 1. pub /ntperl/ Others /Lanman/) Win32 : : OLE (входит в состав ActiveState Perl) 1. JDB 0. Proc: :ProcessTable DURIST 1. Win32: :AdvNotify (можно найти на http://www.gene ration.net/~aminer/Perl/) 2. Data: : Dumper GSAR 1. Win32: :IpHelp (можно найти на http:/ /www.generati on.net/~aminer/Perl/) 98.1129^, MUIR Text : : Wrap (входит в состав Perl) мформация о модулях из этой главы установка Win32::IProc Получение и установка модуля Win32 ::1Ргос происходят несколько сложнее, чем бывает с другими модулями. Сам модуль вместе с осталь ными модулями Рамдэна можно найти на http://www.generation.net/ -aminer/Perl/. Чтобы использовать Win32: :1Ргос, вам также понадо бится загрузить еще два модуля: Win32: :ISync Рамдэна и Win32:.'API Алдо Калпини (Aldo Calpini). Первый можно найти на сайте Рамдэна, второй в репозитории модулей ActiveState или на http://dada.perl.it/.

Некоторые из модулей Рамдэна устанавливаются вручную без помощи команды ррт и требуют небольших изменений исходного кода. Вот полный рецепт для установки. Я считаю, что вы распаковали дистри бутивы и собираетесь устанавливать их в Perl, скомпилированный ActiveState и установленный в каталоге C:\Perl:

1. ррт install Win32-API 2. md c:\Perl\site\lib\auto\Win32\Sync и C:\Perl\site\lib\auto\Win32\ Iproc 3. Скопируйте timer.dll и sync.dll в c:\Perl\site\lib\auto\Win32\Sync 4. Скопируйте iprocnt.dll, psapi.dll и iproc.dll в C:\Perl\site\lib\auto\ Win32\Iproc 5. Скопируйте iproc.pm, iipc.pm и isync.pm в C:\Perl\site\lib\Win32\ 6. Измените строки DLLPath в iproc.pm на следующие:

my($DLLPath) ="C:\\Perl\\site\\lib\\auto\\Win32\\Iproc\\IProc.dll";

my($DLLPath1)="C:\\Perl\\site\\lib\\auto\\Win32\\Iproc\\IprocNT.dll";

my($DLLPath2)="C:\\Perl\\site\\lib\\auto\\Wln32\\Sync\\Sync.dll";

7. Измените строку DLLPath в iipc.pm на:

my($DLLPath)="C:\\Perl\\site\\lib\\auto\\Win32\\Sync\\sync.dll";

8. Измените строки DLLPath в isync.pm на:

my($OLLPath) ="C:\\Perl\\site\\lib\\auto\\Win32\\Sync\\sync.dll";

my($DLLPath1)="C:\\Perl\\site\\lib\\auto\\Win32\\Sync\\timer.dll";

Остановка Win32::Setupsup Если вы хотите установить модуль Win32: :Setupsup вручную и/или из учить его исходный код, вы можете найти ZIP-архив модуля на ftp:// ftp.roth.net/pub/NTPerl/Others/SetupSup/. Если же вы предпочитаете установить его простым способом в существующий ActiveState, то мо жете соединиться с архивом модулей Йенды Крыницки (Jenda Kry nicky) и установить его, используя обычный способ ррт. Инструкции о том, как это сделать, можно найти на сайте http://Jenda.Krynicky.cz.

-J52 Глава 4. Действия пользователей Сложность з том, что документация в формате pod неверно форматиру ется, если вызывать ее при помощи реrldoc или устанавливать в HTML.

Документация в конце setupsup.pm (вероятнее всего, вы найдете ее в <ваш каталог Perl >\site\lib\Win32\) гораздо более верная. Если вы попытаетесь узнать, как использовать этот модуль, я советую открыть сам файл в обычном текстовом редакторе и просмотреть те части, кото рые являются документацией.

Рекомендуемая дополнительная литература http://pudget.net/macperl - домашняя страница модулей Криса Нан дора (Chris Nandor). Нандор один из самых активных разработчи ков модулей MacPerl (и соавтор книги, ссылка на которую приведе на ниже).

http://www.activestate.com/support/mailing_lists.htm. Здесь находятся списки рассылки Perl-Win32-Admin и Perl-Win32~Users. Оба списка и их архивы - просто бесценные ресурсы для программистов Win32.

http://www.microsoft.com/management - домашняя страница всех тех нологий управления Microsoft, включая WMI.

http://www.sysinternals.com - домашняя страница программы nthan dle (на этом сайте она называется просто Handle) и многих других полезных утилит для NT/2000. На родственном сайте http:// www.winternals.com продаются отличные коммерческие утилиты.

«MacPerl:Power and Ease», Vicki Brown, Chris Nandor (Prime Time Freeware, 1998) - лучшая книга о модулях для MacPerl. Стоит так же обратить внимание на веб-сайт издателя http://www.macperl.com.

http://www.dmtf.org- домашняя страница Distributed Management Task Force и просто хороший источник информации по WBEM.

http://www.mspress.com - издатели Microsoft NT Resource Kit. Можно зарегистрироваться и получить доступ к последним утилитам из RK.

• Файлы узлов • NIS.NIS+uWINS • Служба доменных имен (DNS) • Информация о модулях из этой главы • Рекомендуемая дополнительная литература Службы имен TCP/IP В настоящее время большая часть «разговоров» между компьютерами происходит по протоколу управления передачей (Transmission Control Protocol), который, в свою очередь, выполняется на более низком уров не, называемом межсетевым протоколом (Internet Protocol)1. Эти два протокола обычно объединяются в один акроним TCP/IP. Каждой ма шине в TCP/IP-сети должен быть присвоен хотя бы один уникальный численный идентификатор, называемый IP-адресом. IP-адреса обыч но записываются в формате NNN.NNN.N.N, например, 192.168.1.9.

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

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

В этой главе мы будем говорить о версии IPv4, являющейся в настоящее время стандартом. Вероятно, IPv6 (следующее поколение IP) вскоре ее за менит.

164 Глава 5. Службы имен TCP/IP Файлы узлов Первый подход, используемый для решения проблемы связи 1Р-адре сов с именами, является самым простым и очевидным: он заключается в создании специального файла, в котором хранится таблица соответ ствий IP-адресов и имен компьютеров. В системах Unix это файл /etc/ hosts, в MacOS это Macintosh HD:System Folder:Preferences:hosts % \$systemroot$\System32\Drivers\Etc\hosts в NT/2000. В NT/ также есть файл Imhosts, назначение которого несколько иное, но об этом мы поговорим позже. Вот как выглядит файл узлов в Unix:

127.0.0.1 localhost 192.168.1.1 everest.oog.org everest 192.168.1.2 rivendell.oog.org rivendell Ограниченность такого подхода очень быстро становится очевидной.

Если в домене oog.org TCP/IP-сети есть две связанные между собой ма шины, а менеджер сети хочет добавить третью, к которой надо обра щаться по имени, ему придется отредактировать соответствующий файл на всех машинах. Если в oog.org появится еще одна машина, то придется поддерживать четыре файла узлов (по одному на каждой ма шине).

И хотя такое решение кажется совершенно непригодным, именно оно использовалось на заре появления Internet/ARPAnet. Если к сети до бавлялись новые сайты, то файлы узлов необходимо было обновлять на всех сайтах, которые хотели общаться с новым. Центральный репо зиторий, называемый информационным центром сети (NIC) (а точнее SRI-NIC, т. к. находился тогда на SRI), обновлял и распространял файл узлов для всей сети с именем HOSTS.TXT. Системные админист раторы периодически загружали этот файл по FTP из каталога NETIN FO на сервере SRI-NIC.

Файлы узлов используются и по сей день, несмотря на их ограничен ность и замену технологиями, которые нам предстоит обсудить. Су ществуют ситуации, когда файлы узлов даже необходимы. Например, в SunOS машина обращается к собственному файлу /etc/hosts, чтобы определить свой IP-адрес. Файлы узлов также решают проблему «ку~ рицы и яйца», возникающую при загрузке машины. Если использу емые машиной сетевые серверы имен определяются именами, то дол жен существовать способ определить их IP-адреса. Если же сетевые службы имен еще не действуют, то не существует способа (кроме как применять в поисках помощи широковещательные сообщения) полу" чить эту информацию. Обычное решение - создать файл (в нем пере" числено только несколько узлов), который будет использоваться ДЛЯ загрузки.

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

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

Обратите внимание на то, что анализ файлов узлов может быть очень простым:

open(HOSTS, "/etc/hosts") or die "Невозможно открыть файл узлов:$!\п";

while (defined ($_ = )) { next if /"#/;

в пропускаем строки, являющиеся комментариями next if /"$/: в пропускаем пустые строки s/\s*#.*$//;

П удаляем комментарии и it предваряющие их пробелы ($ip, @names) = split;

die "IP-адрес Sip уже встречался! \п" if (exists $addrs{$ip});

$addrs{$ip} = [©names];

for (@names){ die "Имя узла $_ уже встречалось! \п" if (exists $names{$_});

$names{$_} = $ip;

close(HOSTS);

В этом примере просматривался файл /etc/hosts (пропускались пустые строки и комментарии) и были созданы две структуры данных для дальнейшего использования. Первая структура данных - это хэш списков имен узлов, ключами которого являются IP-адреса. Вот как будет выглядеть такая структура данных для рассмотренного файла узлов:

$addrs{ '127. 0.0.1'} = ['localhost'];

$addrs{'192.168.1.2' } = [' rivendell.oog.org',' rivendell' ];

$addrs{ '192. 168. 1. 1 ' } = [ 'everest.oog.org', 'everest ];

Вторая структура данных - хэш-таблица имен узлов, ключами кото рой являются имена. Для того же самого файла хэш %names будет вы глядеть так:

Snamesf 'localhost' }='127.0.0. 1 ' $names{ ' eve rest '} = ' 192. 168. 1.1 • 166 Глава 5. Службы имен ТСР/|р $names{'eve rest.oog.org'}='192.168.1.1' $names{'rivendell1}='192.168.1.2' $names{'rivendell.oog.org'} = '192.168,1.2' Заметьте, что в простой процесс анализа этого файла мы добавили д0.

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

Генерирование файлов узлов Теперь можно заняться более интересным делом - генерированием файлов узлов. Пусть у нас есть следующий файл базы данных для всех узлов в сети:

name: shimmer address: 192.168.1. aliases: shim shimmy shimmydoodles owner: David Davis department: software building: main room: manufacturer: Sun model: Ultra name: bendir address: 192.168.1. aliases: ben bendoodles owner: Cindy Coltrane department: IT building: west room: manufacturer: Apple model: 7500/ name: Sulawesi address: 192.168.1. aliases: sula su-lee.

owner: Ellen Monk department: design building: main room: manufacturer: Apple model: 7500/ файлы узлов name: sander address: 192.168.1. aliases: sandy micky mickydoo owner: Alex Rollins department: IT building: main room: manufacturer: Intergraph model: TD- Формат очень простой: имя_поля: значение, причем -=- используется в качестве разделителя между записями. Вероятно, вам потребуются иные поля или у вас будет слишком много записей, чтобы хранение их в одном «плоском» файле было оправдано. И хотя в этой главе приме няется один плоский файл, принципы, приведенные здесь, не зависят от используемой базы данных.

Вот пример программы, которую можно применять для анализа по добного файла и генерирования файла узлов:

Sdatafile =",/database";

$recordsep = "-=-\n";

open(DATA,Sdatafile) or die "Невозможно открыть файл с данными:$!\п";

$/=$recordsep;

# подготовка к чтению файла базы данных по одной записи print "#\nfl host file - GENERATED BY $0\n# DO NOT EDIT BY HAND!\n#\n";

while () { chomp;

# удалить разделитель записей П разбить на key1,value1,...bingo, хэш записей %record = split /:\s*|\n/m;

print "$record{address}\t$record{name} $record{aliases}\n";

} close(DATA);

Вот что получается:

n П host file - GENERATED BY createhosts ft DO NOT EDIT BY HAND!

« 192.168.1.11 shimmer shim shimmy shimmydoodles 192.168.1.3 bendir ben bendoodles 192.168.1.12 Sulawesi sula su-lee 192.168.1.55 sander sandy micky mickydoo Теперь посмотрим на некоторые более интересные Perl-технологии из этого небольшого отрывка программы. Первое необычное наше дейст вие - установка переменной $/. Начиная отсюда, Perl считает кусочки текста, заканчивающиеся символами -=-\п, одной записью. Это озна Глава 5. Службы имен ТСР/|р чает, что while за один раз прочитает всю запись и присвоит ее пере менной $_.

Вторая интересная вещь - это технология присвоения значений сред ствами split. Наша цель состоит в получении хэша, ключами которого являются имена полей, а значениями - значения полей. Зачем нам это надо, станет понятно позже, когда мы будем расширять пример. Пер вый шаг заключается в разбиении $_ на части при помощи split().

Массив, который получается в результате работы s p l i t ( ), приведен в табл. 5.1.

Таблица 5.1. Массив, возвращенный функцией split() Элемент Значение $record[0] Name $record[1] Shimmer $record[2] Address $record[3] 192.168.1. $record[4] Aliases $record[5] Shim shimmy shimmydoodles Owner $record[6] $record[7] David Davis $record[8] Department $record[9] Software Building $record[10] Main $record[11] Room $record[12] $record[13] $record[14] Manufacturer Sun $record[15] $record[16] Model $record[17] Ultra Присмотримся внимательно к содержимому списка. Начиная с эле мента $record[0], у нас есть список пар ключ-значение (т. е. ключ=Ма те, значение=згаттег\п, iwno4=Address, значение=192.168.1.11\п...), ко торый следует просто присвоить хэшу. После создания хэша можно напечатать нужные нам части.

узлов Вы уже приняли религию «Базы данных для системного администрирования»?

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

Использование базы данных для узлов в сети выгодно по целому ряду причин. В этом случае вносить изменения нужно только в один файл или источник данных. Вносите изменения, запус кайте определенные сценарии и, пожалуйста, у вас есть конфи гурационные файлы для множества служб. В таких конфигура ционных файлах почти наверняка не будет мелких синтаксичес ких ошибок (скажем, пропущенных точек с запятыми или сим волов комментариев), поскольку их не коснулись человеческие руки. Если правильно написать код, то практически все ос тальные ошибки можно обнаружить на стадии обработки дан ных анализатором (parser).

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

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

$datafile ="./database";

Srecordsep = "-=-\n";

open(DATA,$datafile) or die "Невозможно открыть файл с данными:$!\n";

$/=$recordsep;

tt готовы прочитать данные из файла базы данных 170 Глава 5. Службы имен ТСР/|р И по одной записи за один раз print "Я\п\# host file - GENERATED BY $0\n# DO NOT EDIT BY HAND! \ntt\n";

while () { chomp;

я удаляем разделитель записей Я разбиваем на key1,value1,...bingo, хэш записей %record = split /:\s*[\n/m;

# проверка на неверные имена узлов if ($record{name) =" /["-.a-zA-ZO-9]/) { warn "!!!! $ record {name} содержит недопустимые для имени узла символы, пропускаем... \п";

next;

и проверка на неверные псевдонимы if ($record{aliases} =" /["-.a-zA-ZO-9\s]/) { warn "!!!! $record{name} содержит недопустимые для псевдонима символы, пропускаем..,\п";

next;

# проверка на пропущенные адреса if (! $record{address}) { warn "!!!! $record{name} не имеет IP-адреса, пропускаем...\n";

next;

Я проверка. на одинаковые адреса if (defined $addrs{$record{address}}) { warn "!!!! Дублируется IP-адрес: $record{name} & $addrs{$record{address}}, пропускаем...\n" next;

} else { $addrs{$record{address}} = $ record {name};

print "$record{address}\t$record{name} $record{aliases}\n";

} close(DATA);

Улучшение полученного файла узлов Позаимствуем из главы 9 «Журналы» процесс анализа выполняемого преобразования. Мы можем автоматически добавить полезные загс' ловки, комментарии и разделители к получаемым данным. Вот выглядит результат преобразования той же самой базы данных:

и Я host file - GENERATED BY createhosts файлы узлов _ « DO NOT EDIT BY HAND!

» ft Converted by David N. Blank-Edelman (dnb) on Sun Jun 7 00:43:24 ft П number of hosts in the design department: 1.

# number of hosts in the software department: 1.

и number of hosts in the IT department: 2.

# total number of hosts: # Я Owned by Cindy Coltrane (IT): west/ 192.168.1.3 bendir ben bendoodles # Owned by Alex Rollins (IT): main/ 192.168.1.55 sander sandy micky mickydoo # Owned by Ellen Monk (design): main/ 192.168.1.12 Sulawesi sula su-lee # Owned by David Davis (software): main/ 192.168.1.11 shimmer shim shimmy shimmydoodles А вот программа (с комментариями), которая позволяет создать такой файл узлов:

Sdatafile =". /database";

# выясняем имя пользователя как в WinNT/2000, так и в Unix $user = ($"0 eq "MSWin32")? $ENV{USERNAME} :

(getpwuid($<))[6]." (". (getpwuid($<))[0]. ")";

open(DATA, $datafile) or die "Невозможно открыть файл с данными:$!\п";

$/=$recordsep;

# считываем из базы данных по одной записи while () { chomp;

# удаляем разделитель записи # разбиваем на key1,value ©record = split /:\s*|Wm;

$record ={};

я создаем ссылку на пустой хэш %{$record} = ©record;

n заполняем этот хэш значениями # из массива ©record # проверка на неверные имена узлов if ($record->{name} =" /["-.a-zA-ZO-9]/) { warn "! ! ! ! ". $record->{name}.

содержит недопустимые для имени узла символы, пропускав... \п";

next;

П проверка на неверные псевдонимы 172 _ Глава 5. Службы имен ТСР/щ" if ($record->{aliases} =" /r-.a-zA-ZO-9\s]/} { warn " ! ! ! ! ".$record->{name}.

" содержит недопустимые для псевдонима символы, пропускаем.. Д П ".

next;

# проверка на пропущенные адреса if (!$record->{address}) { warn "!!!! ". $record->{name>.

" не имеет IP-адреса, пропускаем.. Дп";

next;

и проверка на совпадающие адреса if (defined $addrs{$record->{address}}) { warn "!!!! Дублируется IP-адрес :".$record->{name}.

" & ".$addrs{$record->{address}}. ", пропускаем.. Дп" next;

} else { $addrs{$record->{address}} = $record->{name};

$entries{$record->{name}} = Srecord;

ft добавляем это е хэш и хэшей close(DATA);

# печатаем симпатичный заголовок print "#\n\# host file - GENERATED BY $0\n« DO NOT EDIT BY HAND!\n#\n";

print "tt Converted by $user on ".scalar(localtime). "\n#\n";

tf подсчитываем число записей для каждого отдела # и сообщаем об этом foreach my Sentry (keys %entries){ $depts{$entries{$entry}->{department}}++;

foreach my Sdept (keys %depts) { print "ft number of hosts in the Sdept department;

$depts{$dept}.\n" print "ft total number of hosts: ".scalar(keys %entries)."\n«\n\n";

tt обходим в цикле все узлы, выводя комментарий и саму запись foreach my Sentry (keys %entries) { print "tt Owned by ", $entries{$entry}->{owner), " (", $entries{$entry}->{department},"): ", $entries{$entry}->{building},"/", Sentries{$entry}->{room},"\n";

print $entries{$entry}->{address}, "\t", $entries{$entry}->{name}," ", $entries{$entry}->{aliases},"\n\n";

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

Можно было сохранять отдельную хэш-таблицу для каждого поля (по добно тому, как это было сделано в примере needspace из главы «Файловые системы»), но красота приведенного метода состоит в его поддерживаемости. Если затем понадобится добавить в базу данных поле s e r i a l _ n u m b e r, нам не придется менять используемый для анализа файла код, это поле само по себе появится как $ r e c o r d - > { s e r i a l _ n u m b e r }.

Недостаток же в том, что синтаксис Perl таков, что наш код выглядит более сложным, чем он есть на самом деле.

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

Анонимные хэши ничем не отличаются от обычных, только обращать ся к ним приходится не по имени, а по ссылке.

Чтобы построить большую структуру данных (хэш хэшей), достаточно связать каждый новый анонимный хэш с основной хэш-таблицей %entries и создать ключ со связанным с ним значением, являющимся ссылкой на этот только что заполненный анонимный хэш. Когда каж дый хэш пройдет обработку, ключами %entries будут имена всех ма шин, а значениями - ссылки на хэш-таблицы, содержащие значения всех полей, связанных с этим именем (IP-адрес, номер кабинета и т. д.).

Вероятно, вам бы хотелось, чтобы вывод был отсортирован по IP-адре сам? Никаких вопросов, просто добавьте процедуру сортировки, изме нив:

foreach my Sentry (keys %entries) { на:

foreach my Sentry (sort byaddress keys %entries) { и добавьте:

sub byaddress { @a = split(/\./,$entries{$a}->{address});

@b = split(/\./,$entries{$b}->{address});

($a[0]<=>$b[0]) || ($a[2]<=>$b[2]) | ($a[3]<=>$b[3]) ;

174 Глава 5. Службы имен TCP/ip Вот как будут выглядеть отсортированные данные:

tt Owned by Cindy Coltrane (IT): west/ 192.168.1.3 bendir ben bendoodles ft Owned by David Davis (software): main/ 192.168.1.11 shimmer shim shimmy shimmydoodles 8 Owned by Ellen Monk (design): main/ 192.168.1.12 Sulawesi sula su-lee # Owned by Alex Rollins (IT): main/ 192.168.1.55 sander sandy micky mickydoo Сделайте так, чтобы полученные данные вам нравились. Пусть Perl поддержит ваши профессиональные и эстетические стремления.

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

Самый элегантный способ создать подобную машину времени - доба вить к процессу систему контроля исходного кода. Такой контроль ис пользуется разработчиками с целью:

• Регистрации всех изменений важных файлов.

• Предотвращения ситуации, когда несколько человек одновременно изменяют один и тот же файл, тем самым ненамеренно уничтожая действия друг друга.

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

Подобные средства контроля очень полезны для системного админист ратора. Проверка ошибок, добавленная в разделе «Проверка ошибок в процессе генерирования файла узлов», поможет справиться лишь с не которыми опечатками и синтаксическими ошибками, но не спасет of семантических ошибок (таких как удаление важного имени узла!

присвоение ошибочного IP-адреса, ошибка в имени узла). В процесс преобразования можно добавить проверку и семантических ошибок но отловить все возможные погрешности все равно не удастся. Мы у?ке говорили, что защиты от дураков не существует, потому что они изоб' Файлыузлов Можно, наверное, предположить, что было бы лучше применить сис тему контроля исходного кода к процессу редактирования первона чальной базы данных, но есть две веские причины, по которым очень важно применить ее к данным, получаемым в результате:

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

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

В качестве системы контроля исходного кода я выбрал систему конт роля версий RCS. У RCS есть несколько возможностей, дружествен ных к Perl и системному администрированию:

• RCS работает на многих платформах. Существуют версии GNU RCS 5.7 для большинства Unix-систем, Windows NT, MacOS и т. д.

• У нее вполне определенный интерфейс командной строки. Все дейст вия можно выполнить из командной строки даже в операционной системе, где в основном применяется графический интерфейс.

• Ее очень легко использовать. Небольшой набор команд для выпол нения основных операций можно выучить за пять минут (приложе ние А «Пятиминутное руководство по RCS»).

• В RCS есть ключевые слова. В текст файлов, находящихся под кон тролем RCS, можно добавлять магические строки, которые будут автоматически раскрываться. Например, любое вхождение в файл строки $Date: $ будет заменено датой последнего помещения файла в систему RCS.

• RCS бесплатна. Исходный код GNU-версии RCS распространяется свободно, кроме того, доступны уже скомпилированные версии для большинства систем. Исходный код RCS можно найти на ftp:// ftp.gnu.org/gnu/rcs.

Если вы никогда не работали с RCS, загляните сначала в приложение А. Впредь будем считать, что вы знакомы с основным на бором команд RCS.

Крэйг Фретер (Craig Freter) написал объектно-ориентированный мо дуль Res, который упрощает применение RCS из Perl. Для этого необ ходимо:

Глава 5. Службы имен TCP/ip 1. Загрузить модуль.

2. Указать, где расположены команды RCS.

3. Создать новый объект Res, настроить его в соответствии с файлом который вы используете.

4. Вызвать необходимые методы объекта (названные в соответствии с командами RCS).

Добавим модуль Res в программу генерации файла узлов, чтобы уви деть, как он работает, и применим другой способ вывода данных. Те перь они будут записываться в определенный файл, а не в стандарт ный поток вывода STDOUT, как было раньше. Ниже приведен только из мененный код. Пропущенные строки, представленные в виде «... », можно найти в предыдущем примере:

$outputfile="hosts.$$";

ft временный файл для вывода $target="hosts";

ft где сохранить преобразованные данные open(OUTPUT,"> Soutputfile") or die "Невозможно записать в файл $outputfile:$!\n";

print OUTPUT "«\n\ft host file - GENERATED BY $0\n ft DO NOT EDIT BY HAND!\nft\n";

print OUTPUT "ft Converted by Suser on ".scalar(localtime)."\ntf\n";

foreach my $dept (keys %depts) { print OUTPUT "# number of hosts in the $dept department:

$depts{$dept}.\n";

} print OUTPUT "8 total number of hosts: ".scalar(keys %entries). "\nft\n\n" ft обходим в цикле все узлы и выводим комментарий # вместе с самой записью foreach my Sentry (sort byaddress keys %entries) { print OUTPUT "ft Owned by ",$entries{$entry}->{owner}, " (", $entries{$entry}->{department}, "): ", Sentries! Sent ry}->{building},"/", Sent ries{$entry}->{ room}, "\n";

print OUTPUT $entries{$entry}->{address}, "\t", $entries{$entry}->{name}, " ", Sent ries{ Sent ry}->{aliases}, "\n\n";

close(OUTPUT);

use Res;

fl путь к RCS Rcs->bindir( '/usr/local/bin' );

ft создаем новый RCS-объект MIS, NIS+MWINS my Srcsotrj = Rcs->new;

ft передаем ему имя получаемого файла $rcsobj->file($target);

и получаем его из репозитория RCS (он уже должен быть там) $rcsobj->co('-!');

и переименовываем вновь созданный файл rename($outputfile,$target) or die "Невозможно переименовать $outputfile в $target:$!\n";

# помещаем его в репозиторий RCS $rcsobj->ci("-u","-m"."Converted by $user on ".scalar(localtime));

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

Взглянув на фрагмент записей из rlog hosts, можно понять, как дейст вует программа:

revision 1. date: 1998/05/19 23:34:16;

author: dnb;

state: Exp;

lines: +1 - Converted by David N. Blank-Edelman (dnb) on Tue May 19 19:34:16 revision 1. date: 1998/05/19 23:34:05;

author: eviltwin;

state: Exp;

lines: +1 - Converted by Divad Knalb-Namlede (eviltwin) on Tue May 19 19:34:05 revision 1. date: 1998/05/19 23:33:35;

author: dnb;

state: Exp;

lines: +20 - Converted by David N. Blank-Edelnan (dnb) on Tue May 19 19:33:16 Из предыдущего примера видно, что между версиями файла нет боль ших различий (обратите внимание на часть, включающую lines:), за то отслеживаются все изменения, происходящие при создании файла.

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

NlSf NIS+MWINS Разработчики из Sun Microsystems, осознав, что «редактирование по одному файлу на каждой машине» вряд ли можно назвать масштаби руемым подходом, придумали нечто под названием желтые страни цы (Yellow Pages или YP). YP были созданы для распространения ин формации из конфигурационных файлов сетевого масштаба, таких как /etc/hosts, /etc/passwd, /etc/services и т. д. В этой главе мы остано вимся на использовании «желтых страниц» в качестве информацион ной службы сети для предоставления сведений о связи между именем машины и ее IP-адресом.

178 Глава 5. Службы имен ТСР/|р YP были переименованы в Информационную службу сети (Network Information Service или NIS) в 1990 г., когда компания British Telecojji (совместно с юристами) заявила о правах на торговую марку «Yell ow Pages» в Великобритании. Призрак «желтых страниц» по-прежнему витает во многих Unix-системах, и сегодня для команд и библиотечных вызовов NIS употребляются имена ypcat, ypmatch, yppush и т. д. Все современные разновидности Unix поддерживают NIS. На машинах с NT можно использовать NIS для авторизации, если применить специ альные библиотеки авторизации1, но о существовании NIS-серверов для NT я не знаю. Мне также не известно о существовании NIS для MacOS.

В NIS администратор определяет одну или несколько машин как сер веры, от которых другие машины получают клиентский сервис. Один из серверов является главным (master), все остальные - подчиненные (slave). На главном сервере хранятся основные копии текстовых фай лов (например /etc/hosts или /etc/passwd), которые используют ьсе машины. Эти файлы изменяются на главном сервере и затем распрост раняются на подчиненные.

Теперь, если машине в сети необходимо получить информацию о связи IP-адресов и имен узлов, она обращается к серверу, вместо того чтобы хранить собственную локальную копию этой информации. Клиент мо жет запрашивать информацию как с главного, так и с любого из под чиненных серверов. Запросы клиентов просматриваются в NIS-кор тах. Карты - это другое название основных файлов, уже преобразо ванных в формат базы данных Unix DBM и распространенных на под чиненные серверы. С подробностями этого процесса преобразования (который включает в себя makedbm и некоторые другие изменения текста) можно ознакомиться в файле Makefile, в большинстве случаев расположенном в /var/yp. Группа NIS-серверов и клиентов, использу ющих одни и те же карты, называется NIS-доменом.

NIS значительно упрощает администрирование сетей. Так, если в сети oog.org появляются новые машины, то добавить их в существующую сеть совсем не сложно. Менеджер сети редактирует файл узлов на главном NIS-сервере и «проталкивает» новую версию на все подчинен ные. Теперь каждый клиент из NIS-домена будет «знать» о существо вании новых машин. NIS обеспечивает легкость администрирования, объединенную с избыточностью (если один сервер недоступен, клиент может обратиться к другому) и распределением нагрузки (не все кли енты в сети используют один и тот же сервер).

Теперь, когда мы знакомы с теорией, можно посмотреть, как Perl по могает в вопросах, связанных с NIS. Начнем мы с процесса размет^' Одна из таких библиотек - NISGINA, первоначально разработанная НайД' желом Вильямсом (Nigel Williams);

эту библиотеку можно найти на http:// www.dcs.qmw.ac.uk/~williams/. Но сначала изучите архивы списков рас сылки, чтобы выяснить, какая версия является самой новой.

IS, NIS+nWINS N ния данных в NIS. Вы, наверное, удивитесь, но это уже практически сделано. Файлы узлов, созданные в предыдущем разделе, можно им портировать в NIS, просто перенеся их в нужное место в каталоге ис ходных файлов на главном сервере и активировав обычные механиз мы принудительной рассылки (проталкивания, push mechanisms), как правило, для этого надо выполнить make в /var/yp. По умолчанию Makefile из каталога /var/yp использует в качестве исходников для NIS-карт содержимое конфигурационных файлов главного сервера.

Обычно имеет смысл создать отдельный каталог для ис ходных файлов NIS-карт и соответствующим образом из менить Makefile. Это позволит хранить различные данные для главного сервера и остальных членов NTS-домена.

Например, вы можете не захотеть, чтобы файл /etc/passwd с главного сервера применялся в качестве файла паролей для всего домена, или наоборот.

Более интересная задача - получить данные из NIS, запрашивая NIS сервер. Проще всего это сделать при помощи модуля Net : : NIS Рика Ха риса (Rik Harris). Данный модуль, начиная с 1995 года, находится в состоянии альфа-версии, но, тем не менее, он вполне рабочий. Вот пример, позволяющий получить и напечатать содержимое карты при помощи одной функции, применяя Net : : NIS. Это похоже на коман ду NIS у peat:

use Net: :NIS;

П NIS-домен по умолчанию Sdomain = Net: :NIS: :yp_get_default_domain();

8 считываем карту (Sstatus, $info) = Net: :NIS: :yp_all($domain, "hosts. byname");

foreach my $name (sort keys %{$info}){ print "$name => $info->{$name}\n";

Сначала необходимо обратиться к локальному узлу для получения имени домена. Используя эту информацию, можно вызвать функцию N e t : :NIS: :yp_all() и получить карту. Функция возвращает перемен ную состояния (фиктивную, как видно из сноски) и ссылку на хэш таблицу, содержащую данные из этой карты. Мы выводим эту инфор мацию, применяя обычный синтаксис разыменования.

Я знаю всего лишь об одной серьезной ошибке в версии а2. В документации рекомендуется сравнивать статус возврата вызовов модуля с предопреде ленными константами, например $Net: : NIS: : ERR_KEY и $Net: : NIS: : ERR_MAP. К сожалению, эти константы в модуле никогда не определяются. Самый простой способ выяснить, был ли запрос удачным, заключается в том, что бы проверить длину возвращенных данных.

180 Глава 5. Службы имен TCP/IP Если нужно узнать только IP-адрес одного узла, эффективнее было бы запросить у сервера именно это значение:

use Net::NIS;

$hostname = "olaf.oog.org";

$domain = Net::NIS::yp_get_default_domain();

($status,$info) = Net::NIS::yp_match($domain,"hosts.byname",Shostname);

print $info,"\n";

Функция Net: :NIS: : y p _ m a t c h ( ) возвращает еще одну фиктивную пере менную состояния и значение (скаляр), соответствующее запрашива емой информации.

Если не удается скомпилировать модуль Net: :NIS или он просто не ра ботает, всегда остается возможность вызвать внешнюю программу.

Например, так:

@hosts='/ypcat hosts' или так:

open(YPCAT, "<путь /<>/ypcat hosts|");

while (){...} Завершит данный раздел пример, в котором применяются оба способа.

Этот маленький, но полезный фрагмент программы получает список текущих NIS-серверов и опрашивает каждый из них при помощи программы yppoll. Если какой-либо из серверов не отвечает как пола гается, выводится соответствующее сообщение:

use Net::NIS;

Syppollex = "/usr/etc/yp/yppoll";

# полный путь к программе yppoll Sdomain = Net::NIS::yp_get_default_domain();

($status,$info) = Net::NIS::yp_all($domain,"ypservers");

foreach my $name (sort keys %{$info}) { Sanswer = '$yppollex -h $name hosts.byname';

if (Sanswer Г /has order number/) { warn "$name отвечает неверно!\п";

NIS+ В состав операционной системы Solaris входит NIS+ - следующая вер сия NIS. В NIS+ решены многие из наиболее серьезных проблем, кото рые были в NIS, в частности, проблема безопасности. К сожалению (а может быть и к счастью, т. к. NIS+ администрировать несколько |S, N15+и WINS N сложнее), NIS+ не стала столь популярной в мире Unix, как NIS. До недавнего времени она практически не поддерживалась на машинах, созданных не в Sun. NIS+ постепенно «приживается» в стандартных дистрибутивах Linux, благодаря работе Торстена Кукука (Thorsten Kukuk) (http://www.suse.de/~kukuk/nisplus/index.html), но она отнюдь не преобладает в мире Unix и ее просто не существует в NT и MacOS.

Принимая во внимание то, что NIS+ используется незначительно, го ворить о ней в книге мы больше не будем. Если вам необходимо рабо тать с NIS+ из Perl, можете применять еще один модуль Хариса Net::NISPlus.

Windows-служба имен Интернета (WINS) Когда в Microsoft стали использовать свой патентованный сетевой протокол NetBIOS поверх TCP/IP (NetBT), возникла необходимость решать проблему соответствия IP-адресов и имен узлов. Первым реше нием стало использование файла Imhosts, спроектированного по ана логии со стандартным файлом узлов. Но это было быстро дополнено NIS-подобным механизмом. В NT 3.5 появилась централизованная схема под названием Windows-служба имен Интернета (Windows In ternet Name Service, или WINS). WINS несколько отличается от NIS:

• WINS специализируется на распространении информации о соответ ствии имен узлов IP-адресам. В отличие от NIS, эта служба не при меняется для централизованного распространения другой информа ции (например, паролей, карты портов и групп пользователей).

• WINS-сервера получают большую часть из распространяемой ин формации от предварительно настроенных клиентов (такую инфор мацию можно предварительно загрузить). После получения IP-ад реса либо вручную, либо через протокол динамической конфигура ции узла (Dynamic Host Configuration Protocol, DHCP) WINS-кли енты ответственны за регистрацию и перерегистрацию своей информации. В этом состоит различие с NIS, там клиенты запраши вают информацию у сервера и, за исключением паролей, не обнов ляют на нем информацию.

WINS, как и NIS, позволяет иметь несколько серверов, повышающих надежность и разделяющих загрузку, по принципу «тяни-толкай».

В Windows 2000 WINS вышла из употребления (читай «от нее избави лись»), вместо нее теперь используется служба динамических домен ных имен (Dynamic Domain Name Service), являющаяся расширением DNS-системы, о которой мы очень скоро поговорим еще.

Учитывая, что WINS больше не существует, мы не будем приводить примеров для работы с ней. В настоящее время работа с WINS напря мую из Perl поддерживается очень слабо. Я не знаю о существовании модулей, созданных специально для работы с WINS. В этом случае лучше всего вызывать некоторые утилиты, работающие в командной 182 Глава 5. Службы имен ТСР/ip строке из Windows NT Server Resource Kit, например WINSCHK ц WINSCL.

Служба доменных имен (DNS) Несмотря на то, что NIS и WINS крайне полезны, им все же недостает некоторых свойств, что делает их непригодными для использования во «всем Интернете».

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

Управление До сих пор мы говорили только о технических аспектах, но это не единственная сторона администрирования. NIS, в особенности, тре бует единственного центра администрирования. Тот, кто управляет главным сервером, управляет и всем NIS-доменом, который этот сервер «возглавляет». Любые изменения в пространстве сетевых имен должны пройти через такого сторожа. Этот принцип не будет работать в пространстве имен размером во весь Интернет.

Для борьбы с недостатками, присущими сопровождению файлов узлов или NIS/NIS+/WINS-noflo6HbiM системам, была создана новая модель под названием служба доменных имен (DNS). В DNS пространство имен сети разделено на несколько «доменов верхнего уровня». Любой из них можно разделить на домены меньшего размера и т. д. В каждой точке деления следует назначить сторону, ответственную за контроль над этой частью пространства имен, что позволяет разобраться с воп росами администрирования.

Клиенты в сети обращаются к ближайшему по иерархии серверу имен.

Если информацию, которую ищет клиент, можно найти на данном ло кальном сервере, она возвращается клиенту. В большинстве сетей ос новная часть запросов, касающихся разыменования адресов, относит ся к машинам из той же сети, поэтому локальные серверы обрабатыва ют большую часть локального трафика. Это позволяет избавиться от проблемы масштабируемости. Можно настроить несколько DNS-cep' NIS+ предлагает механизмы поиска информации для клиентов за предела ми локального домена, но они не настолько гибкие, как в DNS.

Служба доменных имен(DNS) веров (также известных как вторичные или подчиненные), чтобы распределить загрузку и повысить надежность.

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

В такой схеме ни один сервер не должен знать о топологии всей сети, большинство запросов обрабатывается локально, за локальными ад министраторами сохраняется локальный контроль, и в результате все счастливы. У DNS есть преимущество перед другими службами — большинство других систем, подобных NIS и WINS, можно интегриро вать с DNS. Например, NIS-серверы в SunOS можно настроить так, чтобы они обращались к DNS-серверу, если клиент запрашивает у них имя узла, о котором сервер не знает. Результаты этого запроса возвра щаются как стандартные NIS-ответы, так что клиенты и не догадыва ются о каких-либо дополнительных действиях. DNS-серверы Micro soft обладают схожей функциональностью: если клиент запрашивает у DNS-сервера Microsoft адрес локальной машины, о которой ему не известно, то DNS-сервер можно настроить так, чтобы он пересылал этот запрос WINS-серверу от имени клиента.

Генерирование конфигурационных файлов DNS Процесс создания конфигурационных файлов DNS очень похож на тот, который мы использовали для создания файлов узлов и исходных файлов NIS:

• Данные хранятся в отдельной базе данных (одна и та же база может и, вероятно, должна быть источником для всех файлов, о которых идет речь).

• Данные преобразуются в формат вывода по нашему выбору, при этом проверяются ошибки.

• Используется RGS (или эквивалентная система контроля версий) для хранения предыдущих версий файлов.

В случае с DNS второй шаг необходимо расширить, поскольку здесь процесс преобразования оказывается более сложным. Сложности нуж но преодолевать, поэтому было бы неплохо иметь под рукой книгу По ла Альбица (Paul Albitz) и Крикета Лью (Cricket Liu) «DNS and BIND» («DNS и BIND», O'Reilly), содержащую, в том чисе, сведения о конфи гурационных файлах, создание которых рассматривается ниже.

ПолАльбиц, Крикет Лью «DNS и BIND» (перевод 4-го издания 2001г.), IV кв., издательство «Символ-Плюс», 2001 г. - Примеч.ред.

184 Глава 5. Службы имен ТСР/|р Создание административного заголовка Конфигурационные файлы DNS начинаются с административного за головка, в нем представлена информация о сервере и данных, которые он обслуживает. Самая важная часть этого заголовка - запись о ресур.

сах SOA (Start of Authority). Запись SOA содержит:

• Имя административного домена, обслуживаемого данным DNS-cep вером.

• Имя первичного DNS-сервера этого домена.

• Контактную информацию об администраторе (администраторах) DNS-сервера.

• Порядковый номер конфигурационного файла (подробнее об этом рассказывается чуть ниже).

• Значения тайм-аутов регенерации (refresh) и повторного обраще ния (retry) для вспомогательных серверов (т. е. информация о том, когда необходимо синхронизировать данные с первичным серве ром).

• Время жизни (TTL) для данных (т. е. в течение какого времени можно безопасно кэшировать информацию).

Вот как может выглядеть этот заголовок:

@ IN SOA dns.oog.org. hostmaster.oog.org. ( 1998052900 ;

serial 10800 ;

refresh 3600 ;

retry 604800 ;

expire 43200) ;

TTL @ IN NS dns.oog.org.

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

Современные вторичные DNS-серверы (подобные BIND v8+ или Micro soft DNS) могут быть сконфигурированы так, что будут сверяться с ос новным сервером в то время, когда на последнем меняются данные. В обоих случаях вторичный сервер запрашивает на первичном запись SOA. Если порядковый номер записи SOA первичного сервера больШ порядкового номера, хранимого на вторичном сервере, то произойдет перенос информации о зоне (вторичный сервер загрузит новые дай' ные). В итоге, важно увеличивать порядковый номер каждый раз пр создании нового конфигурационного файла. Многие из проблем с вызваны неполадками при обновлении порядкового номера.

доменных имен (DNS) Существует по крайней мере два способа сделать так, чтобы порядко вый номер всегда увеличивался:

1. Считывать предыдущий конфигурационный файл и увеличивать найденное там значение.

2. Вычислять новое значение, основываясь на внешних данных, кото рые «гарантированно» увеличиваются (это могут быть, например, системные часы или номера версий файла в RCS).

Ниже приведен пример программы, где применяется комбинация этих двух методов для создания допустимого заголовка файла зоны DNS. Порядковый номер будет представлен в виде, который рекомен дуют использовать Альбиц и Лью в своей книге (YYYYMMDDXX, где Y=rofl, М=месяц, В=день и ХХ=двузначный счетчик, позволяющий вносить более одного изменения за день):

и получаем текущую дату в формате YYYYMMDD @localtine = localtime;

Stoday = sprintf("%04d%02d%02d",$localtime[5]+1900, $localtime[4]+1, $localtime[3]);

# имя пользователя как в NT/2000, так и в Unix $user = ( ' eq "MSWin32")? $ENV{USERNAME} :

$ (getpwuid($<))[6]." (". (getpwuid($<))[0]. ")";

sub GenerateHeader{ my($header);

8 открываем старый файл, если это возможно, и считываем # порядковый номер, принимая во внимание формат старого файла if (open (OLDZONE,$target)){ while () { next unless (/(\d{8}).*serial/);

Soldserial = $1;

last;

} close (OLDZONE);

.

} else { Soldserial = "00000000";

«иначе начинаем с О # если предыдущий порядковый номер соответствует # сегодняшнему дню, то увеличиваем последние 2 цифры, в # противном случае используем новый номер для сегодняшнего дня Solddate = substr($oldserial,0,8);

Scount = ((Solddate == Stoday) ? substr($oldserial, 8, 2)+1 : 0);

Sserial = sprintf("%8d%02d", Stoday, $count);

186 Глава 5. Службы имен TCP/ip и начало заголовка $header.= ";

Файл зоны dns - СОЗДАН $0\п";

Sheader.= ";

НЕ РЕДАКТИРУЙТЕ ВРУЧНУЮ!\п;

\п";

$header.= ";

преобразован пользователем $user в ".scalar((localtime))."\n;

\n";

tf пересчитать число записей для каждого отдела и сообщить foreach my Sentry (keys %entries){ $depts{$entries{$entry}->{department}}++;

} foreach my $dept (keys %depts) { Sheader.= ";

число узлов в отделе $dept:

$depts{$dept}.\n";

} $header.= ";

всего узлов: ".scalar(keys %entries)."\nl\n\n";

Sheader.= «"EOH";

@ IN SOA dns.oog.org, hostmaster.oog.org. ( Sserial ;

serial 10800 ;

refresh 3600 ;

retry 604800 ;

expire 43200) ;

TTL @ IN NS dns.oog.org.

EOH return $header;

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

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

ба доменных имен (DNS) ж Рассмотрим в данной главе последний пример генерирования файлов, поэтому соберем воедино все, что обсуждали раньше. Приведенный сценарий использует для создания конфигурационных файлов зоны DNS простой файл базы данных.

Чтобы не усложнять сценарий, я сделал ряд предположений относи тельно данных, самые важные из которых касаются топологии сети и пространства имен. Я считаю, что сеть состоит из одной подсети клас са С с одной зоной DNS. В результате, необходимо создать один файл для прямого преобразования имен и один для обратного. Добавить код для работы с несколькими подсетями и зонами (т. е. создать отдельные файлы для каждой) будет несложно.

Вот, вкратце, что мы делаем:

1. Считываем файл базы данных в хэш хэшей, проверяя при этом дан ные.

2. Генерируем заголовок.

3. Записываем данные в файл для прямого преобразования (из имен в IP-адреса) и помещаем его под контроль RCS.

4. Записываем данные в файл для обратного преобразования (из IP-ад ресов в имена) и помещаем его под контроль RCS.

Вот как выглядит пример и получаемые в результате файлы:

use Res;

Sdatafile = "./database";

ft база данных узлов Soutputfile = "zone.$$";

ft временный файл для вывода Starget = "zone.db";

ff получаемый файл $revtarget = "rev.db";

ft получаемый файл для обратного преобразования Sdefzone = ".oog.org";

ft создаваемая по умолчанию зона $recordsep = "-=-\n";

ft получаем текущую дату в формате YYYYMMDD @localtime = localtime;

Stoday = sprintf("%04d%02d%02d",$localtime[5]+1900, $localtime[4]+1, $localtime[3]);

Я имя пользователя, как в NT/2000, так и Unix $user = ($-0 eq "MSWin32")? $ENV{USERNAME} :

(getpwuid($<))[6]." (".(getpwuid($<))[0].")";

$/ = Srecordsep;

ft считываем файл базы данных open(DATA,Sdatafile) or die "Ошибка! Невозможно открыть datafile:$!\n";

Имеется в виду простой текстовый файл с данными, а не файл базы данных в прямом смысле этого слова. - Примеч. науч. ред.

188 Глава 5. Службы имен TCP/ip while () { chomp;

n удаляем разделитель записей # разбиваем на key1,value @record = split /:\s*|\n/m;

$ record ={};

П создаем ссылку на пустой хэш %{$record} = ©record;

# заполняем его значениями из ©record # ищем ошибки в именах узлов if ($record->{name} =~ /["-.a-zA-ZO-9]/) { warn "!!!! ",$record->{name}.

" встретились недопустимые в именах узлов символы, пропускаем.. Дп" next;

# ищем ошибки в псевдонимах if ($record->{aliases} =" /[~-.a-zA-ZO-9\s]/) { warn "!!!! ". $record->{name}.

встретились недопустимые в псевдонимах символы, пропускаем.. Дп" next;

# ищем пропущенные адреса unless ($record->{address}) { warn "!!!! ". $record->{name}.

" нет IP-адреса, пропускаем.. Дп";

next;

# ищем повторяющиеся адреса if (defined $addrs{$record->{address}}) { warn "!!!! Повторение IP-адреса:". $record->{name}.

" & ". $addrs{$record->{address}}. ", пропускаем.. Дп" next;

} else { $addrs{$record->{address}} = $record->{name};

$entries{$record->{name}} = $record;

# добавляем это в хэш хэшей close(DATA);

'$header = &GenerateHeader;

№ создаем файл прямого преобразования open(OUTPUT,"> $outputfile") or die "Ошибка! Невозможно записать в $outputfile:$!\n";

print OUTPUT $header;

a ^ужба доменных имен (DNS) foreach my Sentry (sort byaddress keys %entries) { print OUTPUT ";

Владелец-- ",$entries{$_}->{owner}, " (", $entries{$entry}->{department}, ") : ", Sent ries{$entry}->{ building}, "/", Sent ries { Sent ry}->{ room}, "\n";

ft выводим запись А printf OUTPUT "%-20s\tIN A %s\n", Sent ries{ Sent ry}->{ name}, Sent ries{ Sent ry}->{address};

ft выводим записи CNAMES (псевдонимы) if (defined $entries{$entry}->{aliases}){ foreach my Salias (splitC ',$entries{$entry}->{aliases})) { printf OUTPUT "%-20s\tIN CNAME %s\n", $alias, Sent ries { Sent ry}->{ name};

print OUTPUT "\n";

close(OUTPUT);

Rcs->bindir( '/usr/local/bin' );

my Srcsobj = Rcs->new;

$rcsobj->file($target);

$rcsobj->co( '-!');

rename($outputfile, Starget) or die "Ошибка! Невозможно переименовать Soutputfile в $target:$!\n" $rcsob]->ci("-u", "-m". "Преобразовано пользователем Suser в ".scalar(localtime));

ft создаем файл обратного преобразования open(OUTPUT,"> Soutputfile") or die "Ошибка! Невозможно записать в $outputfile:$!\n";

print OUTPUT $header;

foreach my Sentry (sort byaddress keys %entries) !

print OUTPUT ";

Владелец -- ", $entries{$entry}->{owner}, " (", $entries{$entry}->{department}, ") : ", Sent ries{ Sent ry}->{building}, "/", $entries{$entry}->{room}, "\n";

printf OUTPUT "%-3d\tIN PTR %s$defzone. \n\rT, (split/\./,$entries{$entry}->{address})[3], Sent r ies { Sent ry}->{ name};

close(OUTPUT);

190 Глава 5. Службы имен ТСР/ip $rcsobj->file($revtarget);

$rcsobj->co('-!');

it предполагаем, что целевой файл по крайней # мере один раз извлекался из репозитория • rename($outputfile,$revtarget) or die "Ошибка! Невозможно переименовать Soutputfile в $revtarget:$!\n";

$rcsobj->ci("-u","-m"."Преобразовано пользователем $user в ".scalar(localtime));

sub GenerateHeader{ my($header);

if (open(OLDZONE,$target)){ while () { next unless (/(\d{8}).«serial/);

Soldserial = $1;

last;

} close(OLDZONE);

} else { Soldserial = "000000";

Solddate = substr($oldserial,0,6);

Scount = (Solddate == Stoday) ? substr($oldserial,6,2)+1 : 0;

Sserial = sprintf("%6d%02d",Stoday,Scount);

Sheader.= ";

файл зоны dns - СОЗДАН $0\п";

Sheader.= ";

HE РЕДАКТИРУЙТЕ ВРУЧНУЮ!\п;

\п";

Sheader.= ";

Преобразован пользователем Suser в ".scalar(localtime)."\n;

\n";

ff подсчитываем число узлов в каждом отделе foreach Sentry (keys %entries){ Sdepts{$entries{$entryJ->{department}}++;

foreach Sdept (keys %depts) { Sheader.= ";

в отделе Sdept $depts{$dept} машин.\n";

Sheader.= ";

общее число машин: ".scalar(keys %entries)."\n#\n\n";

Sheader.= «"EOH";

@ IN SOA dns.oog.org. hostmaster.oog.org. ( Sserial serial 10800 refresh retry 604800 expire TTL 43200) IN NS dns.oog.org.

Служба доменных имен (DNS) ЕОН return Sheader;

sub byaddress { @a = split(/\V,$entries{$a}->{address});

@b = split(/\./,$entries{$b}->{address});

($a[0]<=>$b[OJ) || ($a[2]<=>$b[2]) || ($a[3]<=>$b[3]);

Вот какой файл получается для прямого преобразования (гопеЛЪ):

файл зоны dns - СОЗДАН createdns НЕ РЕДАКТИРУЙТЕ ВРУЧНУЮ!

Blank-Edelman (dnb);

Преобразован пользователем David в Fri May 29 15:46:46 в отделе design 1 машин.

в отделе software 1 машин, в отделе IT 2 машин, общее число машин: IN SOA dns.oog.org. hostmaster.oog.org. ( 1998052900 serial refresh retry expire TTL 43200) @ IN NS dns.oog.org.

;

Владелец -- Cindy Coltrane (marketing): west/ bendir IN A 192.168.1. ben IN CNAME bendir bendoodles IN CNAME bendir ;

Владелец -- David Davis (software): main/ shimmer IN A 192.168.1. shim IN CNAME shimmer shimmy IN CNAME shimmer shimmydoodles IN CNAME shimmer ;

Владелец -- Ellen Monk (design): main/ Sulawesi IN A 192.168.1. Глава 5. Службы имен TCP/IP IN CNAME Sulawesi sula IN CNAME Sulawesi su-lee ;

Владелец -- Alex Rollins (IT): main/ sander IN A 192.168.1. sandy IN CNAME sander micky IN CNAME sander mickydoo IN CNAME sander А вот как выглядит файл для обратного преобразования (rev.db):

файл зоны dns - СОЗДАН createdns НЕ РЕДАКТИРУЙТЕ ВРУЧНУЮ!

Преобразован пользователем David N. Blank-Edelman (dnb);

в Fri May 29 15:46:46 в отделе design 1 машин, в отделе software 1 машин, в отделе IT 2 машин, общее число машин: IN SOA dns.oog.org. hostmaster.oog.org. ( 1998052900 serial refresh retry expire TTL 43200) @ IN NS dns.oog.org.

;

Владелец -- Cindy Coltrane (marketing): west/ 3 IN PTR bendir.oog.org.

;

Владелец -- David Davis (software): main/ 11 IN PTR shimmer.oog.org, ;

Владелец -- Ellen Monk (design): main/ 12 IN PTR sulawesi.oog.org.

;

Владелец -- Alex Rollins (IT): main/ 55 IN PTR sander.oog.org.

Этот метод создания файлов открывает перед нами много возможнос тей. До сих пор мы генерировали файлы, используя содержимое одно го текстового файла базы данных. Запись из базы данных считывалась и записывалась в файл, возможно, подвергаясь при этом форматирова' нию. Таким образом, в создаваемые файлы попадали только записи из базы данных.

Служба доменных имен (DNS) Иногда бывает полезно, чтобы сценарий добавлял в процессе преобра зования свои предопределенные данные. Например, в случае с конфи гурационными файлами DNS можно улучшить сценарий преобразова ния так, чтобы он добавлял записи MX (Mail exchange), указывающие на центральный почтовый сервер, для каждого узла из базы данных.

Простое изменение нескольких строк кода с таких:

П выводим запись А printf OUTPUT "%-20s\tIN A %s\n", Sentries{$entry}->{name},Sentries{$entry}->{address};

на следующие:

ft выводим запись А printf OUTPUT "%-20s\tIN A %s\n", Sentries{Sentry}->{name},Sentries{Sentry}->{address};

# выводим запись MX print OUTPUT " IN MX 10 $mailserver\n";

приведет к тому, что почта, посылаемая на любой из узлов домена, бу дет направляться на машину $mailserver. Если эта машина настроена так, что может обрабатывать почту для всего домена, то мы задейство вали очень важный компонент инфраструктуры (централизованную обработку почты), добавив всего лишь одну строчку кода на Perl.

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

Например, для системного/сетевого администратора очень многое за висит от ответа на вопрос «Все ли DNS-серверы работают?». В ситу ации, когда необходимо найти неисправности, практически настолько же важно знать, «Все ли серверы работают с одной и той же информа цией?», или, более точно, «Отвечают ли они одинаково на одинаковые запросы? Синхронизированы ли они?». Данный раздел посвящен по добным вопросам.

По главе 2 можно судить, как действует основной принцип Perl «Всег да существует несколько способов сделать это». Именно такое свойст во делает Perl отличным языком для «итеративной разработки». Ите ративная разработка - это один из способов описания эволюционного процесса, имеющего место при создании программ системного адми нистрирования (и не только), выполняющих определенную задачу. В случае с Perl можно быстро написать рабочую программу на скорую руку, а позднее вернуться к сценарию и переписать его более элегант 194 Глава 5. Службы имен ТСР/|р ным образом. Возможно, будет еще и третья итерация, на этот раз угке с использованием другого подхода к решению задачи.

Существует три различных подхода к одной и той же проблеме провер ки согласованности DNS. Они представлены в том порядке, которому действительно, мог бы последовать человек, пытаясь найти решение, а затем его совершенствуя. Этот порядок отражает взгляд на то, как ре шение проблемы может развиваться в Perl;

ибо ваше отношение к под ходу может меняться. Третий способ, использующий модуль N e t : : DNS, вероятно, самый простой и наиболее защищенный от ошибок. Но су ществуют ситуации, когда Net: : DNS применять нельзя, поэтому снача ла приведем несколько собственных решений. Обязательно обратите внимание на все за и против, перечисленные после каждого рассмот ренного подхода.

Вот наша задача: написать сценарий на Perl, принимающий имя узла и проверяющий список DNS-серверов, чтобы убедиться, что все они возвращают одну и ту же информацию об узле. Чтобы упростить зада чу, будем считать, что узел имеет единственный статический IP-адрес (т. е. у него один сетевой адаптер и один IP-адрес).

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

Shostname = $ARGV[0];

©servers = qw(nameserver1 nameserver2 naineserverS);

# серверы имен foreach Sserver (^servers) { &lookupaddress($hostname,$server);

ft заполняем %results > %inv = reverse %results;

ft инвертируем полученный хэш if (keys %inv > 1) { print "Между DNS-серверами есть разногласия:\п";

use Data:: Dumper;

print Data::Dumper->Dump([\%results],["results"]),"\n";

} Для каждого из DNS-серверов, перечисленных в списке ©servers, вы зывается подпрограмма &lookupaddress(), которая обращается к DNS серверу, чтобы получить IP-адрес заданного имени узла, и помещает результаты в хэш %results. Для каждого DNS-сервера в хэше %result есть запись, значением которой является IP-адрес, возвращаемый этим сервером (ключом является имя сервера).

Существует много способов определить, равны ли друг другу значения из хэша %results (т. е. убедиться, что все DNS-серверы возвращают ОДНУ и ту же информацию в ответ на запрос). Мы инвертируем хэш %results в другую хэш-таблицу, преобразовывая все ключи в значения и наобо рот. Если все значения из %results одинаковы, то в инвертированном хэше должен быть только один ключ. Если ключей несколько, значит, мы выловили прокол, и поэтому вызываем Data: :Dumper->Dump() ДЛЯ доменных имен(DNS) вывода содержимого %results, над которым будет ломать голову сис темный администратор.

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

Между DNS-серверами есть разногласия:

Sresults = { nameserverl => '192.168.1.2', nameserver2 => '192.168.1.5', nameserverS => '192.168.1.2', Теперь посмотрим на альтернативы подпрограмме &lookupaddress().

Использование nslookup Если у вас есть опыт работы в Unix или вы уже программировали на других языках сценариев помимо Perl, то первая попытка может сильно походить на сценарий командного интерпретатора. Внешняя программа, вызываемая из Perl сценария, выполняет всю сложную ра боту:

use Data::Dumper;

Shostname = $ARGV[0];

$nslookup = "/usr/local/bin/nslookup";

# путь к nslookup ©servers = qw(nameserver1 nameserver2 nameserverS);

# имена серверов имен foreach Sserver (©servers) { &lookupaddress($hostname,$server);

# заполняем %results %inv = reverse %results;

# инвертируем полученный хэш if (scalar(keys %inv) > 1) { print "Между DNS-серверами есть разногласия:\п";

print Data::Dumper->Dump([\%results],["results"]),"\n";

П обращаемся к серверу, чтобы получить IP-адрес и прочую П информацию для имени узла, переданного в программу в Я командной строке. Результаты записываем в хэш %results sub lookupaddress { my($hostname,Sserver) = @_;

open(NSLOOK,"$nslookup $hostname Sserver|") or die "Невозможно запустить nslookup:$!\n";

while () { it игнорировать, пока не дойдем до "Name:

next until (/"Name:/);

Я следующая строка - это ответ Address:

chonp($results{$server} = );

ti удаляем имя поля 196 Глава 5. Службы имен ТСР/|р die "Ошибка вывода nslookup \n" unless /Address/;

$results{$server} =" s/Address(es)?:\s+//;

# все, с nslookup мы закончили last;

} close(NSLOOK);

} Преимущества такого подхода:

• Это короткая программа, которую можно быстро написать (вероят но, ее даже можно построчно перевести из настоящего сценария ко мандного интерпретатора).

• Нет необходимости писать запутанный код для работы с сетью.

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

• Это может оказаться единственным выходом, если нельзя написать программу для взаимодействия клиента и сервера на Perl;

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

Недостатки такого подхода:

• Появляется зависимость от другой программы за пределами сцена рия. А если эта программа недоступна? Что делать, если изменится формат вывода данной программы?

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

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

• У вас меньше контроля. Во всех деталях реализации приходится полагаться на милость внешней программы. Например, в данном случае nslookup (если быть более точным, то библиотека разымено вания, которую использует nslookup) обрабатывает тайм-ауты сер вера, повторные попытки запросов и дописывает списки поисков доменов.

Работа напрямую с сетевыми сокетами Если вы «продвинутый системный администратор», вы можете ре" шить, что вызывать внешнюю программу не следует. Вы можете захо' теть реализовать запросы к DNS, не используя ничего, кроме Perl. Это означает, что нужно будет создавать вручную сетевые пакеты, переда' ужба доменных имен (DNS) вать их по сети и затем анализировать результаты, получаемые от сер вера.

Вероятно, это самый сложный пример из всех, приведенных в книге.

Написан он после обращения к дополнительным источникам инфор мации, в которых можно найти несколько примеров существующего кода (включая модуль Майкла Фура (Michael Fuhr), показанный в сле дующем разделе). Вот что происходит на самом деле. Запрос к DNS серверу состоит из создания специального сетевого пакета с опреде ленным заголовком и содержимым, отправки его на DNS-сервер, полу чения ответа от сервера и его анализа. Каждый DNS-пакет (из тех, которые нас интересуют) может иметь до пяти различных разделов:

Header(Заголовок) Содержит флаги и счетчики, относящиеся к запросу или ответу (присутствует всегда).

Question (Запрос) Содержит вопрос к серверу (присутствует в запросе и повторяется при ответе).

Answer (Ответ) Содержит все данные для ответа на DNS-запрос (присутствует в па кете DNS-ответа).

Authority (Полномочия) Содержит информацию о том, можно ли получать авторитетные от веты.

Pages:     | 1 | 2 || 4 | 5 |   ...   | 7 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.