Журнал LinuxFormat - перейти на главную

LXF146:Sysadmin

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Новая страница: «==По рецептам доктора Брауна== : Эзотерическое системное администрирование из причудлив…»)
 

Текущая версия на 18:33, 14 июля 2014

Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

[править] По рецептам доктора Брауна

Эзотерическое системное администрирование из причудливых заворотов кишок серверной


[править] За исследования!

Splunk Тонете в файлах журнала? Ответом может стать «поисковая система оперативной разведки»...

Занятые серверы Linux генерируют бездну машинных данных, от журналов web-доступа Apache до предупреждений sshd об отказах в попытке доступа.

Для их исследования существуют несколько классических утилит. Скажем, Logwatch – прекрасная программа для создания сводок файлов журнала, и имеется куча программ, помогающих понять, хорошо ли функционирует ваш сайт (например, http://www.sawmill.co.uk).

Splunk (http://www.splunk.com) немного другой. Он предпринимает более интерактивный подход к добыче данных с вашей машины – возможно, чтобы глубже забуриться в поисках проблемы эксплуатации либо рассмотреть долгосрочные тенденции в работе машины.


Splunk работает как демон. Как и Beagle, он обшаривает машинные данные и индексирует их. Но Beagle ищет вашу персональную информацию, а Splunk – информацию о системе. Интерфейс его основан на web-браузере.

На настройку источников данных для Splunk требуется время. Он умеет индексировать вывод системного журнала, журналы событий окон, файлы настройки (и вообще любые указанные файлы), журналы Apache и WebSphere, и многое другое.

Приведенный ниже снимок экрана показывает простой поиск строки «failed» в системном журнале. Оказывается, имел место огромный всплеск около 8 утра 14 апреля. Копнув глубже, мы видим, что более 99,9 % этого исходит от программы под названием ntfs-3g. Фильтрация по времени генерации, по хосту, откуда это пришло, и по файлу журнала очень проста. Можно просматривать индивидуальные сообщения и даже перейти прямо на файл журнала, откуда идут ошибки.


[править] XML для администраторов

XML Вы испытывали чувство, что этот язык ставит вас в тупик? Добрый Доктор преподает простое введение, исцеляя ваш истерзанный разум.

Несколько лет назад, когда Novell перешел с NetWare на Linux, я проводил множество тренингов для их консультантов. Некоторые из них считали переход шагом в неверном направлении, хотя бы в техническом отношении, и не стеснялись твердить мне это.

Любимой мишенью их критики было изобилие форматов файлов системных настроек в Linux. «Не разумнее ли, – спрашивали они, – везде использовать XML?»

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

Лично мне XML не нравится. Он напоминает мне куски сырого сала, вывешиваемые зимой для синиц – хорошо для своих целей, но для людей несъедобно. Он засоряет страницу, тяжело читается и требует много лишнего места. И так уж вышло, что XML все-таки не используется в базовых файлах настройки Linux, типа /etc/passwd, /etc/fstab и /etc/hosts; и даже файл syslog-ng.conf устоял перед наваждением XML.

Но в других местах вы встретите множество XML под капотом. Например, документ OpenOffice.org – это на самом деле zip-архив XML-файлов с именами типа content.xml и style.xml. (Просто разархивируйте любой документ .odt, и сами убедитесь.)

Все файлы из каталога ~/.gconf, где хранятся настройки рабочего стола Gnome, имеют формат XML. На моей стандартной установке Fedora 14 в /etc их 212, что дает 191,000 строк XML – в основном в /etc/gconf. Библиотека виртуализации libvirt использует XML для определения характеристик виртуальной машины и виртуальной сети.

Поэтому в данном номере мы бегло рассмотрим формальный мир XML.


[править] Рабочий пример

Текст для сегодняшнего урока взят из примера определения машины в libvirt. Этот XML-файл описывает аппаратную конфигурацию виртуальной машины: 

<?xml version=”1.0” encoding=”utf-8” ?>
<domain type='kvm'>
<name>serverq</name>
<uuid>3cce3bbc-5d3c-ee98-e4d5-4cefb0f9bdf5</uuid>
<memory>262144</memory>
<currentMemory>262144</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='pc-0.12'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<source file='/home/chris/q-vm/tmp_Hy.qcow2'/>
<target dev='hda' bus='ide'/>
</disk>
<interface type='network'>
<mac address='52:54:00:2d:5d:4d'/>
<source network='default'/>
<model type='virtio'/>
</interface>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'/>
<video>
<model type='cirrus' vram='9216' heads='1'/>
</video>
</devices>
</domain>

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

Давайте добавим терминологии. В моем файле примера первая строка технически называется прологом. В ней указывается используемая версия XML и кодировка символов. Пролог в файле XML не обязателен, но у большинства он есть. Вторая строка – просто комментарий. После нее первый тэг (в нашем примере это <domain>) называется корневым элементом документа. Он должен быть единственным. У любого элемента элементы уровня ниже называются дочерними, более высокого уровня – родительскими, а элементы одного уровня (с общим родителем) являются родственными. Эти отношения показаны на следующей странице. Например, в нашем файле libvirt узлы <type> и <boot> являются родственными, а <os> – родительский для них.

Обратите внимание, что пробелы в файле (отступы и новые строки) облегчают человеку просмотр иерархической структуры, но не дают вклада в значения. Например, разархивировав документ OpenOffice.org и взглянув на содержимое XML-файлов, вы не увидите там ни одного пробела или перевода строки!


[править] Поиск в документах XML

Большинство языков программирования предоставляют расширения для перемещения по документу XML или для поиска узлов, отвечающих указанному критерию. В командной строке утилита Linux xpath отыщет узлы в XML-файле, отвечающие данному выражению. Выражения немного напоминают шаблоны для имен файлов, и немного – регулярные выражения. Ниже дана таблица с кратким введением в выражения Xpath.

Вот несколько примеров поиска Xpath, который можно провести в нашем файле-примере из libvirt: 

$ xpath -e //memory example.xml
Found 1 nodes in example.xml:
-- NODE --
<memory>262144</memory>
     
$ xpath -e “//disk/target[@dev='hda']” example.xml
Found 1 nodes in example.xml:
-- NODE --
<target dev=”hda” bus=”ide” />

На ранних стадиях развития HTML web-разработчики не особо заботились о синтаксисе. Они забывали про закрывающие тэги и сравнительно вольно обращались со вложением элементов. Web-браузерам приходилось учиться быть толерантными и извлекать из кода наибольший смысл, по возможности. Требования XML к синтаксису гораздо строже.

Про документ, который следует основным правилам синтаксиса, говорят, что он «правильно построен» [well-formed]. Это значит, что всем начальным тэгам соответствуют конечные тэги, тэги вложены правильно, значения атрибутов взяты в кавычки, специальные символы, типа < и >, не встречаются в других частях документа, и так далее. Вам, наверно, уже попадались и XHTML – это, в сущности, переформулировка HTML в более строгих синтаксических правилах XML.

Документы также бывают «действительными» [valid]. Это звание посерьезнее. Действительный документ – тот, что следует четкой спецификации. Спецификация может, например, установить, что элементы с именами <disk>, <interface> и <video> должны входить (именно в таком порядке) в элемент под названием <devices> и что элемент <video> должен задавать атрибуты type и vram.

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

Самым первым способом, применявшимся для спецификации структуры действительного XML-документа, включая список всех разрешенных элементов и их атрибутов, были определения типа документа [Document Type Definition, DTD]. Файлы DTD были, однако, тоже XML-документами. Они все еще используются, но почти везде заменяются на XML-схемы, которые обычно расположены в файлах XSD и являются документами XML.

В используемом нами примере из libvirt схемы пока нет (становится интересно, так ли сильна приверженность XML к libvirt; но я отвлекся). Чтобы обойти это, перейдем к новому, очень простому примеру. Во-первых, вот «целевой» файл (тот, который мы будем делать действительным): 

<?xml version=”1.0”?>
 
<message xmlns=”mynamespace”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”mynamespace message.xsd”>
<to> Graham </to>
<from> Chris </from>
<heading> Deadline </heading>
<body> I am running late this month! </body>
</message>

Можно заметить, что корневой элемент называется <message>, а элементы внутри него носят имена <to>, <from>, <heading> и <body>. Элемент <message> содержит некие атрибуты, определяющие пространство имен, которому должны принадлежать названия элементов. Пространство имен предотвращает (например) перепутывание моего элемента <heading> с любым из элементов <heading> других. Для простоты я назвал это пространство имен mynamespace, но на практике здесь обычно используют URL организации, для гарантии его уникальности. Элемент <message> также содержит атрибут, говорящий, где располагается схема (файл XSD). В нашем примере целевой файл и файл XSD расположены в одном каталоге.

Вот как выглядит схема: 

<?xml version=”1.0”?>
<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema”
targetNamespace=”mynamespace”
xmlns=”mynamespace”
elementFormDefault=”qualified”>
<xs:element name=”message”>
   
<xs:complexType>
<xs:sequence>
<xs:element name=”to” type=”xs:string”/>
<xs:element name=”from” type=”xs:string”/>
<xs:element name=”heading” type=”xs:string”/>
<xs:element name=”body” type=”xs:string”/>
</xs:sequence>
</xs:complexType>
  
</xs:element>
</xs:schema>

Главная часть расположена внутри тэга <xs:element>. Можно видеть, что в тэге <message> ожидаются элементы под названиями <to>, <from>, <heading>, <body>, в приведенном порядке. XML-редакторы автоматически определяют схему и делают файл действительным для нее. На снимке экрана с XML Copy Editor видно, что файл не прошел валидацию из-за использования элемента <recipient> вместо элемента <to>.

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


[править] Преобразование

Использованный мною пример был файлом libvirt config. Однако XML применяется в основном для определения содержимого документа (отчета, электронной таблицы или любого фрагмента документации) в виде, преобразуемом в другие форматы, такие как HTML для просмотра в браузере или PDF для распечатки. Для определения преобразования используются файлы XSLT.

XSLT означает «Extensible Stylesheet Language Transformations» [язык преобразования XML-документов], и они немного похожи на файлы CSS – тем, что в них указываются стили, применяемые для определенных элементов документа. Если вы хотите, улучив 10 минут, разобраться с XSLT, зайдите на www.w3schools.com, а затем по ссылке «Learn XSLT», и нажмите на кнопку «Try it yourself». Здесь можно поиграть с содержимым документа XML и связанным с ним XSLT и посмотреть на результат.

Снимок экрана на рисунке вверху дает хороший пример работы XSLT. Здесь Serna Free XML Editor от Syntext предоставляет WYSIWYG-редактирование документа XML. В правой панели показано содержимое текущего документа (после преобразования в HTML с помощью стилевой таблицы), а в панели слева – древовидная структура самого XML. Лично мне особенно нравится здесь то, что «сырое» содержимого XML не показывается!


Запросы Xpath без мистики
ЗАПРОС XPATH ЧЕМУ ОН СООТВЕТСТВУЕТ
/A Все элементы A в корне документа
//A Все элементы A по всему документу
//A/B Все элементы B, дочерние по отношению к элементам A, по всему документу
//A[B/FOO='BAR'] Все элементы A по всему документу, имеющие дочерний элемент B, у которого есть дочерний элемент FOO со значением BAR
//A/B[../FOO='BAR'] Все элементы B, дочерние к узлам A и у которых есть родственный элемент FOO со значением BAR
//A[@FOO='BAR'] Все элементы A, у которых есть атрибут FOO со значением BAR
Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF146:Sysadmin&oldid=15342»
Персональные инструменты
купить
подписаться
Яндекс.Метрика