Ресурсы по SELinux в Интернет

Начал собирать ссылки, посвященные SELinux в сети на страницах нашей Wiki.

Fedora Linux Security Guide

Руководство Security-Enhanced Linux User Guide, про которое я писал ранее, уже сменило статус с черновика на готовый документ, а вчера Eric Christensen опубликовал черновой вариант Fedora Linux Security Guide (Bugzilla Bug). В целом завершить работу планируется к выходу Fedora 11, а сейчас создатели документа с удовольствием выслушают отклики/исправления/замечания от сообщества пользователей и разработчиков Fedora. HTML-версия документа тут.

Книги по мониторингу и настройке производительности

На ресурсе IBM Redbooks нашел несколько интересных для себя книг в формате PDF по настройке производительности операционных систем.

Tuning IBM System x Servers for Performance. Рассмотрены вопросы настройки производительности Windows, Linux и ESX Server на System x. Естественно, часть информации не специфична именно для System x. Более тысячи страниц, датировано февралем 2007 года

Tuning Red Hat Enterprise Linux on IBM eServer xSeries Servers. Помимо настройки непосредственно операционной системы, затронуты вопросы производительности Apache, LDAP, серверов баз данных. Июль 2005, сто пятьдесят страниц.

Linux Performance and Tuning Guidelines. Краткое введение в предмет. Примеры приведены для Red Hat Enterprise Linux и Novell SUSE Linux. Июль 2007, сто семьдесят страниц.

SystemTap: Instrumenting the Linux Kernel for Analyzing Performance and Functional Problems. Публикация пока что находится в стадии "черновика". Окончательная версия по информации на сайте будет примерно через месяц. Еще одно описание Systemtap уже не от инженеров IBM, а от Red Hat - тут.

А вообще, IBM Redbooks - замечательный источник информации, на котором, я уверен, многие найдут для себя интересное.

Ресурсы Russian Fedora

Заработали Bugzilla и форум. Страница "Как присоединиться" с которой можно подписаться на списки рассылки. К следующему четвергу в wiki должны быть списки To Do по основным направлениям, и можно будет брать и раздавать задачи :)

I am RHCDS

Пришли результаты EX436, а вместе с ними сертификат Red Hat Certified Datacenter Specialist :) До RHCA остался всего один экзамен, но это уже на следующий год. :)

Создаём сервер сетевой установки Fedora/RHEL

С разрешения редакции размещена моя статья из 11/2008 номера журнала "Системный администратор":

Дистрибутив Fedora использует для установки весьма мощную и многофункциональную программу Anaconda, поддерживающую различные режимы работы и сценарии инсталляции. Вместе с рядом других технологий, в частности Spacewalk-сервером, вы можете значительно облегчить процесс развертывания и обслуживания вашей Linux-инфраструктуры.

Однако сегодня мы оставим Spacewalk-сервер в стороне и рассмотрим, как можно автоматизировать самую начальную стадию жизненного цикла серверов/рабочих станций – их развертывание. При этом в процессе установки мы постараемся обойтись без вмешательства оператора при помощи так называемого сервера сетевой установки. Для организации такого сервера мы используем следующие технологии:

• PXE (Pre-Boot Execution Environment). Минимальное вмешательство человека подразумевает загрузку первой стадии инсталлятора по сети. Большинство выпущенных за последние два-три года сетевых карт и BIOS материнских плат поддерживают эту функцию. Как правило, загрузка по сети начинается, если на жестком диске отсутствует загрузчик, при старте нажата клавиша или в BIOS выбран соответствующий пункт меню. Первый вариант – отсутствие загрузчика на жестком диске – нас вполне устраивает.

• DHCP-сервер. Предоставляет клиентам сетевые настройки и указывает место, где будут располагаться файлы, необходимые для загрузки с использованием Pre-Boot Execution Environment.

• TFTP-сервер. Там мы и расположим все необходимые для начала инсталляции файлы. Нужно заметить, что мы можем одновременно поддерживать несколько вариантов дистрибутива, например, Fedora 9 и Red Hat Enterprise Linux 5.

• Kickstart-файлы. Для каждого из дистрибутивов можно предусмотреть несколько вариантов установки, которые и будут задаваться при помощи kickstart-файлов. Kickstart-файл должен быть доступен по сети при помощи одного из протоколов: http/https, NFS, FTP. Необходимый kickstart-файл можно указывать и вручную, но, поскольку мы хотим максимально автоматизировать развертывание операционной системы, то нужно предусмотреть возможность автоматического выбора. Реализовать это можно следующими способами:
• При помощи DHCP-сервера в зависимости от MAC-адреса клиента.
• При помощи настроек PXE (конфигурационных файлов первой стадии загрузчика – pxelinux.0) в зависимости от MAC- или IP-адреса, полученного с DHCP-сервера. В последнем случае может понадобиться резервирование IP-адресов на DHCP-сервере.
• При помощи Spacewalk-сервера. Мы не будем рассматривать данный вариант, но заметьте, что в зависимости от того, в какой из диапазонов IP-адресов попадает клиент, Spacewalk-сервер может выдавать свой kickstart-файл. При этом его содержимое будет создаваться «на лету» из базы данных, а на DHCP-сервере или при помощи настроек pxelinux.0 можно будет всегда задавать одно и то же месторасположение этого «динамического» kickstart-файла.

• Сетевой репозиторий. Файлы дистрибутива, доступные по http, NFS, FTP или по всем трем протоколам. Быстрее всего установка будет производиться при выборе метода установки по NFS. Медленнее всего – по http.
  

Теперь попробуем собрать все компоненты вместе. Не буду подробно объяснять ключи командной строки или подробности работы протоколов – ответы на эти вопросы можно найти в обширной документации, включая официальную от Red Hat. Приведу рецепт решения конкретной задачи. Также обратите внимание на утилиту system-config-netboot, которая может упростить некоторые шаги. Однако в учебных целях не будем пользоваться GUI. Подробно использование system-config-netboot описано в руководстве системного администратора из комплекта официальной документации Red Hat Enterprise Linux.

Для начала установим и настроим автоматический запуск tftp-сервера:

# yum -y install tftp-server
# chkconfig tftp on
# service xinetd start

По умолчанию корневой директорией tftp-сервера в RHEL5 выступает /tftpboot, а в Fedora 9 – /var/lib/tftpboot. Если вы решите использовать директорию, отличную от установленной по умолчанию, не забудьте прописать соответствующие правила в своем модуле SELinux.

Скопируйте в избранный каталог необходимые файлы. Для начала нам необходима первая стадия загрузчика – файл pxelinux.0. Документация на загрузчик и сам файл привносятся в систему пакетом syslinux:

# yum -y install syslinux

Далее копируем загрузчик в корневую директорию tftp-сервера:

# cp $(rpm -ql syslinux | grep pxelinux.0) /var/lib/tftpboot/

Создадим сервер инсталляции для двух дистрибутивов. В качестве примера возьмем Fedora 9 и Red Hat Enterprise Linux 5.1, но пойдет и любой другой дистрибутив, использующий Anaconda. Скопируем в /tftpboot ядро и initrd-образы обоих дистрибутивов, которые расположены в директории /images/pxeboot/ установочного диска. Предположим, оба ISO-образа дистрибутивов смонтированы в /mnt/loop/:

# mkdir /var/lib/tftpboot/{fedora9,rhel51}
# cp /mnt/loop/RHEL_5.1/images/pxeboot/* /var/lib/tftpboot/rhel51/
# cp /mnt/loop/Fedora9/images/pxeboot/* /var/lib/tftpboot/fedora9/

Поскольку у нас два варианта дистрибутивов, предоставим оператору возможность выбора. Пусть в качестве информации наш загрузчик выводит на экран возможные варианты. Создадим текстовый файл /var/lib/tftpboot/boot.msg примерно следующего содержания:

--------------------------
MY SETUP MENU FOR PXE BOOT
--------------------------
f - install Fedora 9
r - install RHEL 5.1
q - boot normally

Кстати, в файле /usr/share/doc/syslinux-*/syslinux.doc (помимо опций, использующихся в конфигурационном файле загрузчика) описано, как сделать информационное сообщение более «веселым», добавив цвета, страницы, переключаемые при помощи функциональных клавиш, и различные управляющие символы. Теперь пришло время создать конфигурационный файл загрузчика, пользуясь все тем же руководством /usr/share/doc/syslinux-*/syslinux.doc:

# mkdir /var/lib/tftpboot/pxelinux.cfg
# vi /var/lib/tftpboot/pxelinux.cfg/default

Наш конфигурационный файл, используемый PXE по умолчанию, будет содержать следующие строки:

default q
display boot.msg
prompt 1
timeout 100

label q
localboot 0

label f
kernel fedora9/vmlinuz
append initrd=fedora9/initrd.img ks=http://192.168.0.100/f9.cfg

label r
kernel rhel51/vmlinuz
append initrd=rhel51/initrd.img ks=http://192.168.0.100/rhel51.cfg

Вариант загрузки с меткой q описывает загрузку с локального диска. Данный вариант используется по умолчанию. Для загрузки ядра Fedora или RHEL необходимо выбрать f или r. Заметьте, мы воспользовались самым простым способом предоставления информации о kikstart-файле через параметры ядра, передаваемые опцией append. В случае использования Spacewalk-сервера можно было бы обойтись одним «динамическим» путем к kikstart-файлу. Без него, если необходимо, можно добавить еще несколько меток, указывающих на другие файлы, например:

label f2
kernel fedora9/vmlinuz
append initrd=fedora9/initrd.img ks=http://192.168.0.100/f9_2.cfg

Следующий компонент нашего сервера – служба DHCP. Устанавливаем его:

# yum -y install dhcp
# cp /usr/share/doc/dhcp-*/dhcpd.conf.sample /etc/dhcpd.conf

С учетом того, что имя kikstart-файла передается без помощи DHCP, а также упростив конфигурацию и не используя классы вендоров, отредактируем нашу область, добавив два параметра:

filename "pxelinux.0";
next-server 192.168.0.100;

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

Создание kickstart-файла также не должно представлять сложностей. Его формат подробно описан в документации Red Hat. Проще всего создать его при помощи GUI-утилиты system-config-kickstart или взяв за основу /root/anaconda-ks.cfg.

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

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

Как вы видите на рис. 3, до использования конфигурационного файла default загрузчик ищет конфигурационные файлы, соответствующие вашему MAC-адресу, IP-адресу и подсетям. Этим можно воспользоваться для создания конкретных комбинаций «дистрибутив/kickstart-файл» для определенных серверов или рабочих станций. Управлять привязкой IP-адресов к конкретным машинам можно в конфигурационном файле DHCP-сервера, используя резервирование IP-адресов и классы вендоров.

Приведенное решение является лишь «заготовкой», на основе которой вы можете самостоятельно собрать нужную вам конфигурациию сервера инсталляции. Следующим шагом я бы порекомендовал попробовать посмотреть в сторону Spacewalk-сервера, являющегося Open Source-решением для управления Linux-инфраструктурой и помимо прочих задач также служащего для развертывания серверов и рабочих станций.

Построение HA-кластера с использованием RHCS и GFS в RHEL 5

Цель поста - продемонстрировать создание тестовой конфигурации кластера высокой доступности с использованием Red Hat Cluster Suite и кластерной файловой системы Global File System.

При создании HA-кластера используем следующее ПО/технологии. Все они являются полностью открытыми и для них доступен исходный код:

- Red Hat Enterprise Linux Advanced Platform 5.1
-- Red Hat Cluster Suite (в том числе web-интерфейс Conga, qdiskd и clvmd);
-- Global File System;
-- udev.

Вместо RHEL можно использовать CentOS, Scientific Linux и другие подобные.

Для создания демо-стенда использовались два физических сервера с внешним дисковым массивом, подключенным через FC, и одна управляющая станция, на которой была установлена web-консоль luci (проект Conga). Данная конфигурация избыточна, и все эти шаги можно повторить с использованием одного физического сервера, предоставляющего доступ к разделу по iSCSI двум виртуальным машинам, которые работают на том же сервере. В этом случае luci также можно было бы запускать на хост-системе или, в зависимости от числа доступных ресурсов, на сервере "поднять" третью виртуальную машину. Использование физических серверов критично в случае, если вы в качестве серверного ресурса планируете запускать виртуальные машины - HA + "живая миграция" (т.е. примерно то, что обеспечивает VMWareHA, и чего ждем в Windows Server 2008 R2). В этом случае рекомендую помимо официальной документации Red Hat ознакомиться со статьей в Red Hat Magazine и workaround на тему живой миграции виртуальных машин, описанном в блоге Андрея Мартынова.

Важно. Хотя, по информации, приведенной в этом посте, можно повторить все шаги и по аналогии настроить свой кластер, но информации будет явно не достаточно для понимания всех деталей работы, команд и планирования развертывания кластера. Для дальнейшего изучения материала рекомендую обратиться к официальной документации Red Hat, свободно доступной на сайте Red Hat как в виде PDF, так и HTML. Пост в блоге не заменяет чтения сотен страниц документации. Также нужно заметить, что решение задействовать GFS и использование кластера именно из двух узлов не является необходимым/оптимальным решением для рассмотренной задачи (отказоустойчивый web-сервер). Решение продиктовано желанием продемонстрировать использование большего числа технологий (GFS и кворумный диск). Более того, использование web-сервера как кластерной службы выбрано исключительно для демонстрации и из-за простоты базовой настройки. Для достижения результата в каждом конкретном шаге также, как правило, возможно воспользоваться разными инструментами: system-config-cluster, Conga или командная строка.

Создаем кластер, используя web-интерфейс (проект Conga)

Наиболее простой способ создать кластер - использовать Conga. Также стоит использовать данный интерфейс, когда мы хотим управлять из одной точки несколькими кластерами. Для того чтобы избежать некоторых "шероховатостей" в дальнейшем, убедимся, что на всех кластерах в /etc/hosts имя узла не присутствует в одной строчке с localhost, как это прописывает по умолчанию Anaconda. Кроме того, для независимости кластера от работы службы DNS лучше всего также прописать в hosts все остальные узлы и машину, где будет установлена luci. Кроме того, предполагается, что всем машинам доступны группы Cluster и Cluster Storage через RHN, Satellite или локальный репозиторий.

На управляющей станции устанавливаем web-консоль:

[root@server1 ~]# yum -y install luci
[root@server1 ~]# luci_admin init

Задаем пароль администратора luci.

[root@server1 ~]# service luci restart
Shutting down luci: [ OK ]
Starting luci: [ OK ]

Point your web browser to https://server1.example.com:8084 to access luci

А на обоих узлах кластера агента, который работает в паре c luci:

[root@node1 ~]# yum -y install ricci
[root@node1 ~]# service ricci restart; chkconfig ricci on

Теперь можно как нам и предложили зайти в web-интерфейс server1.example.com:8084. Со вкладки Clucter выбираем создание нового кластера:

После нажатия кнопки Submit узлы кластера скачивают и устанавливают соответствующие пакеты. По окончании процесса мы должны увидеть такую картину:

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

Данный шаг необходим в ряде случаев, например, когда мы не можем гарантировать, что после перезагрузки каждый раздел будет иметь то же имя, что и перед прошлым циклом перезагрузки (iSCSI), или, например, в случае различного числа дисков на узлах кластера, когда один и тот же LUN будет выглядеть на узлах по-разному:

[root@node1 ~]# fdisk -l
...
Disk /dev/sdc: 72.8 GB, 72837857280 bytes
255 heads, 63 sectors/track, 8855 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 13 104391 83 Linux
...
[root@node2 ~]# fdisk -l
...
Disk /dev/sdd: 72.8 GB, 72837857280 bytes
255 heads, 63 sectors/track, 8855 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdd1 1 13 104391 83 Linux
...

В первом случае наш рабочий LUN на массиве - это sdc, а во втором - sdd. Данную проблему можно решить при помощи правила udev. В качестве альтернативы при использовании LVM и ext3 можно было бы воспользоваться UUID или метками ФС. Однако, правило udev более универсально.

Получим идентификатор нашего рабочего диска:

[root@node2 ~]# scsi_id -g -s /block/sdd
3600805f3001d3200a1e3ff9f259f0003

На каждом из узлов напишем правило udev (за подробностями - к документации):

[root@node1 ~]# cat /etc/udev/rules.d/75-custom.rules
KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -s %p",RESULT=="3600805f3001d3200a1e3ff9f259f0003", SYMLINK+="mydata%n"

В итоге на обоих узлах получаем картину:

[root@node1 ~]# ls -l /dev/my*
lrwxrwxrwx 1 root root 3 Dec 2 12:54 /dev/mydata -> sdc
lrwxrwxrwx 1 root root 4 Dec 2 12:54 /dev/mydata1 -> sdc1

[root@node2 ~]# ls -l /dev/my*
lrwxrwxrwx 1 root root 3 Aug 1 13:58 /dev/mydata -> sdd
lrwxrwxrwx 1 root root 4 Aug 1 13:58 /dev/mydata1 -> sdd1

Еще один вариант - это воспользоваться стандартно создаваемыми симлинками в /dev/disk/by-id/.

Fencing

В Red Hat Cluster Suite поддерживается большое число агентов, в том числе для ряда ИБП APC, что радует - HP iLO и IBM Blade Center, виртуальных машин Xen, коммутаторов McData, Brocade. Однако, например, Cisco MDS, насколько я знаю, "родными" средствами "гасить" нельзя. В luci настройка fencing производится на вкладке Cluster в свойствах кластера и пункте меню Shared Fence Devices. Снимки с экрана пропустим :)

Добавляем кворумный диск

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

[root@node1 ~]# clustat
Member Status: Quorate

Member Name ID Status
------ ---- ---- ------
node2.example.com 1 Online
node1.example.com 2 Online, Local

[root@node1 ~]# cman_tool status
Version: 6.0.1
Config Version: 1
Cluster Name: cluster0
Cluster Id: 26776
Cluster Member: Yes
Cluster Generation: 140
Membership state: Cluster-Member
Nodes: 2
Expected votes: 1
Total votes: 2
Quorum: 1
Active subsystems: 8
Flags: 2node
Ports Bound: 0 11 177
Node name: node1.example.com
Node ID: 2
Multicast addresses: 239.192.104.1
Node addresses: 192.168.50.140

В качестве кластерного диска используем первый раздел на общем диске:

[root@node1 ~]# mkqdisk -c /dev/mydata1 -l myqdisk
mkqdisk v0.5.1
Writing new quorum disk label 'myqdisk' to /dev/mydata1.
WARNING: About to destroy all data on /dev/mydata1; proceed [N/y] ? y
Initializing status block for node 1...
...
[root@node1 ~]# mkqdisk -L
mkqdisk v0.5.1
/dev/sdc1:
Magic: eb7a62c2
Label: myqdisk
Created: Tue Dec 2 13:12:29 2008
Host: node1.example.com

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

[root@node1 ~]# vi /etc/cluster/cluster.conf

cluster alias="cluster0" config_version="3" name="cluster0"
...
cman expected_votes="3" two_node="0"/

Даем команду узлам кластера обновить конфигурацию:

[root@node1 ~]# ccs_tool update /etc/cluster/cluster.conf
Config file updated from version 2 to 3

Update complete.

Стартуем сервис qdiskd, который уже привнесен нам на узлы пакетом cman:

[root@node2 ~]# chkconfig qdiskd on; service qdiskd start
Starting the Quorum Disk Daemon: [ OK ]

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

За объяснением параметров идем к документации. В итоге в clustat мы получаем следующую картину:

[root@node1 ~]# clustat
Member Status: Quorate

Member Name ID Status
------ ---- ---- ------
node2.example.com 1 Online
node1.example.com 2 Online, Local
/dev/mydata1 0 Online, Quorum Disk


Раздел GFS

Если в двух словах, то про сетевые файловые системы, в том числе и GFS, Андрей Меганов писал в блоге. А дальше, традиционно, читаем документацию.

К настоящему моменту Conga уже должна была установить все необходимые пакеты. Для гарантии того, что тип блокировок LVM2 сменен с stand-alone на cluster-wide, отдадим команду:

[root@node2 ~]# lvmconf --enable-cluster

После чего (пере)запустим clvmd. Далее создадим на общем диске раздел под GFS:

[root@node1 ~]# fdisk /dev/mydata

На обоих узлах перечитаем таблицу разделов:

[root@node1 ~]# partprobe
[root@node1 ~]# fdisk -l

Disk /dev/sdc: 72.8 GB, 72837857280 bytes
255 heads, 63 sectors/track, 8855 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 * 1 13 104391 83 Linux
/dev/sdc2 14 6093 48837600 8e Linux LVM

На новом разделе создадим логический том, который, благодаря clvmd, будет доступен на всех узлах кластера:

[root@node1 ~]# pvcreate /dev/mydata2
Physical volume "/dev/mydata2" successfully created
[root@node1 ~]# vgcreate vgcluster /dev/mydata2
Volume group "vgcluster" successfully created
[root@node1 ~]# vgdisplay | grep Free
Free PE / Size 11923 / 46.57 GB
Free PE / Size 0 / 0
[root@node1 ~]# lvcreate -l 11923 -n gfsvol vgcluster

В случае, если последняя команда отработает с ошибкой, workaround:

[root@node2 ~]# service clvmd stop
Stopping clvm: [ OK ]
[root@node2 ~]# rm /etc/lvm/cache/.cache
rm: remove regular file `/etc/lvm/cache/.cache'? y
[root@node2 ~]# pvscan
connect() failed on local socket: Connection refused
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
PV /dev/mydata2 VG vgcluster lvm2 [46.57 GB / 0 free]
PV /dev/sdb1 VG VolGroup00 lvm2 [149.03 GB / 0 free]
PV /dev/sda2 VG VolGroup00 lvm2 [74.41 GB / 0 free]
Total: 3 [270.01 GB] / in use: 3 [270.01 GB] / in no VG: 0 [0 ]
[root@node2 ~]# vgscan
connect() failed on local socket: Connection refused
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
Reading all physical volumes. This may take a while...
Skipping clustered volume group vgcluster
Found volume group "VolGroup00" using metadata type lvm2
[root@node2 ~]# lvscan
connect() failed on local socket: Connection refused
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
Skipping clustered volume group vgcluster
ACTIVE '/dev/VolGroup00/LogVol00' [221.50 GB] inherit
ACTIVE '/dev/VolGroup00/LogVol01' [1.94 GB] inherit

[root@node1 ~]# service clvmd start
Starting clvmd: [ OK ]
Activating VGs: 1 logical volume(s) in volume group "vgcluster" now active
2 logical volume(s) in volume group "VolGroup00" now active
[ OK ]

Создаем файловую систему (один лишний журнал "про запас"):

[root@node1 ~]# gfs_mkfs -p lock_dlm -t cluster0:share -j 3 /dev/vgcluster/gfsvol

Пробуем смонтировать:

[root@node1 ~]# mount /dev/vgcluster/gfsvol /var/www/html
[root@node1 ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/vgcluster-gfsvol on /var/www/html type gfs (rw,hostdata=jid=0:id=131074:first=1)

Информация о файловой системе:

[root@node1 ~]# gfs_tool df /var/www/html
/var/lib/xen/images:
SB lock proto = "lock_dlm"
SB lock table = "cluster0:share"
SB ondisk format = 1309
SB multihost format = 1401
Block size = 4096
Journals = 3
Resource Groups = 186
Mounted lock proto = "lock_dlm"
Mounted lock table = "cluster0:share"
Mounted host data = "jid=0:id=131074:first=1"
Journal number = 0
Lock module flags = 0
Local flocks = FALSE
Local caching = FALSE
Oopses OK = FALSE

Type Total Used Free use%
------------------------------------------------------------------------
inodes 5 5 0 100%
metadata 5 5 0 100%
data 12109426 0 12109426 0%

Добавляем строчку в /etc/fstab:

/dev/vgcluster/gfsvol /var/www/html gfs defaults 0 0

Создание кластерного ресурса

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

[root@node2 ~]# yum -y install httpd

На одном из узлов:

[root@node2 ~]# vi /var/www/html/index.html

Теперь в web-интерфейсе:

Проверяем:

[root@server1 ~]# elinks -dump http://192.168.50.146
My web Service!

И с любого из узлов:

[root@node1 ~]# clustat
Member Status: Quorate

Member Name ID Status
------ ---- ---- ------
node2.example.com 1 Online
node1.example.com 2 Online, Local
/dev/mydata1 0 Online, Quorum Disk

Service Name Owner (Last) State
------- ---- ----- ------ -----
service:webservice node2.example.com started

Теперь можно через web-интерфейс или из командной строки поперекидывать сервис с узла на узел, сымитировать падение узла, добавить скрипт, который будет каким-то образом менять данные, или добавить более интересный сервис в созданный HA-кластер.

Полная линейка курсов RHCA в России

Подписав соглашение с компанией Red Hat, Инвента стала первым учебным центром, авторизованным для проведения курсов RHCA на территории России и Казахстана.

Теперь и в России появилась возможность подготовить специалистов, чья квалификация позволит профессионально спроектировать и успешно развернуть в масштабах крупной корпоративной IT-инфраструктуры самые сложные архитектурные решения на базе Red Hat Enterprise Linux. Наличие в штате компании специалистов уровня RHCA гарантирует максимальную отдачу от внедрения таких продуктов, как RHN Satellite Server, Directory Server, Certificate System, Cluster Suite, Global File System.

Курсы RHCA представляют собой углубленные практические тренинги для ведущих системных администраторов Linux, уже имеющих сертификацию RHCE (Red Hat Certified Engineer) или эквивалентные знания и навыки.

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

• Кластерные решения для обеспечения отказоустойчивости и балансировки нагрузки
• Управление хранением данных уровня предприятия
• Массовое развертывание систем и управление настройками
• Оптимизация производительности и обеспечение безопасности систем и приложений
• Системы аутентификации пользователей корпоративного уровня

Подробнее тут.

Виртуализация: Red Hat vs Hyper-V vs VMWare

Краткое сравнение с точки зрения функций в таблицах.

Red Hat и Hyper-V:

К картинке можно добавить, что с точки зрения гостевых ОС, в Hyper-V поддерживаются только Windows и SLES 10 от Novell, а что касается Red Hat Enterprise Linux virtualization, то поддерживаются как Windows, так и Linux и UNIX-системы (включая NetBSD, FreeBSD и Solaris).

Red Hat и VMWare:

Выход Fedora 10

25 ноября 2008 года выходит десятая версия дистрибутива Fedora под кодовым названием "Cambridge".


Основные технологические улучшения:

NetworkManager — В NetworkManager появилась возможность создания общих соединений, что позволяет использовать систему с установленной Fedora в качестве общего хаба. При наличии единственного проводного или беспроводного подключения на втором беспроводном сетевом интерфейсе за несколько щелчков мыши пользователь может создать новую беспроводную ad-hoc сеть. Таким образом находящиеся вблизи устройства могут использовать данную сеть для доступа в Интернет.

PackageKit — PackageKit сделал очередной шаг в своем развитии и впервые расширил свои возможности функциями, направленными на улучшение открытого десктопа. Теперь PackageKit, используя информацию о зависимостях, расположенную в RPM пакетах, может искать кодеки для поддерживаемых форматов. Для этого PackageKit использует настроенные на хосте репозитории, и, после подтверждения пользователем, скачивает и устанавливает соответствующие пакеты. Примерно к моменту выхода Fedora 11 PackageKit должен получить дополнительные возможности по установке сходным образом шрифтов, а также приложений.

Plymouth/быстрая загрузка — Запуск устаревшей графической системы отображения процесса загрузки RHGB занимает продолжительное время, требует существенного объема памяти и дает значительную нагрузку на жесткий диск. Для RHGB требуется загрузка ряда графических компонент, которые всего лишь используются для вывода нескольких сообщений и отрисовки ползунка, демонстрирующего прогресс загрузки системы. Новый режим настройки ядра делает возможным ускорение и отображение процесса загрузки сопровождающегося графическими «спецэффектами». На момент выхода Fedora 10 по-настоящему насладиться графическими изысками Plymouth могут обладатели современных видеокарт от ATI. Однако, идет активная работа над тем, чтобы расширить базу поддерживаемых видеокарт.

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

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

Appliance tools - The Appliance OS (AOS) и Appliance Creation Tool (ACT) вместе с новым знаком "FEDORA REMIX" позволяют независимым разработчикам создавать как новые, так и уже существующие сборки, используя удобные и хорошо задокументированные утилиты Fedora. Пользователи могут объединять как сторонние приложения, так и приложения, входящие в огромную вселенную свободного обеспечения Fedora, для создания своих инновационных решений. Знак Fedora Remix позволяет создателям независимых сборок показать взаимосвязь с проектом Fedora. Дополнительная информация — на сайте http://thincrust.net/

sectool — активно развивающийся инструмент аудита настроек безопасности и локальная IDS(система обнаружения вторжений) . Включает в себя ряд тестов для различных аспектов настройки системы, служб и т.д. В настоящий момент их около тридцати. Тесты независимы от языка программирования (Perl, Python, Bash, ...), и их можно писать самостоятельно (на сайте проекта доступна документация). Имеется как графический, так и интерфейс командной строки, гибкая система настроек, сравнение результатов проверок, отправка отчетов по электронной почте и т.д.

Полный список нововедений с технической точки зрения - https://fedoraproject.org/wiki/Releases/10/FeatureList

Новейшие возможности

Тема оформления "Solar" — как и предыдущие темы создана командой Fedora Artwork с использованием свободного и открытого инструментария.

GNOME 2.24 — Для полного списка нововведений обратитесь к Замечаниям к релизу. Вот лишь пара из них:

• Новый апплет для планирования времени и более функциональная панель рабочего стола
• Полностью обновленное приложение для телефонии и видеконференций Ekiga 3.0
  

KDE 4.1.2 - Для полного списка нововведений обратитесь к Замечаниям к релизу KDE 4.1.2. Нововведения включают в себя:

• Восстановленный и интегрированный в систему KDE-PIM, приложение для управления личной информацией
• Новые функции в файловом менеджере Dolphin и веб-браузере Konqueror
• Улучшения композитного менеджера окон
• Приложение для работы с картами, интегрированное с OpenStreetMap
  

PulseAudio — звуковая подсистема, поддерживающая различные источники и различные средства вывода для трансляции звука, включая сеть. В Fedora 10 система PulseAudio стала работать с меньшими задержками и менее требовательно к ресурсам.

"День рождения" Russian Fedora в МИФИ (дополнение о respin)

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

"День рождения" Russian Fedora в МИФИ

Сегодня в МИФИ состоялись пресс-конференция и мероприятия, посвященные запуску проекта Russian Fedora. Десятая версия Fedora выходит через пять дней. К моменту ее выхода будет публично доступна инфраструктура (CMS, wiki, система контроля версий), относящаяся непосредственно к нашей локальной Russian Fedora. На сайте проекта и будет более подробно рассказано о конкретных шагах, которые уже сделаны и которые еще будут сделаны в ближайшее время. Это и локальный respin, и предстоящие мероприятия в ВУЗах, и Install Party, etc. Конечно, обо всем я постараюсь писать в этом блоге. Ну а сегодня есть силы только выложить фото :) После официальной части у нас было достаточно времени на живое общение за кружечкой Гиннеса с Максом Спеваком, который, нужно отметить, в России впервые :)

1) Пресс-конференция. Кстати, на слайде кратко - отличия Fedora от Ubuntu :)

2) Какой "день рождения" без торта

3) Основной спикер - Макс Спевак (Лидер Fedora Project с 2006 по 2008 год, в настоящее время отвечает в Red Hat за стратегию работы с коммьюнити)

4) Актовый зал МИФИ. Правда, часть из присутствующих студентов как раз перед фото сорвалась на лекции. Не успел сфотографировать зал до того :)

Настройка Device-Mapper Multipath в RHEL 5

В данном посте я хочу описать шаги для настройки Multipath при помощи dm-multipath. Device Mapper Multipathing (DM-Multipath) позволяет "собрать" несколько маршрутов ввода/вывода между сервером и дисковым массивом в единое целое, и рассматривать доступный по нескольким путям массив как одно мета-устройство. Например, если сервер с двумя двух-портовыми HBA подключен к одному и тому же массиву, то сервер, в самом простейшем случае, будет "видеть" четыре устройства /dev/sd{a,b,c,d}. При помощи dm-multipath можно собрать из них агрегирующее все четыре пути мета-устройство /dev/dm-N, обеспечив прозрачную для операционной системы и приложений конфигурацию, отказоустойчивую в случае выхода из строя HBA, кабеля или коммутатора (если каждый HBA подключен через свой коммутатор).

Хотя, по информации, приведенной в этом посте, можно повторить все шаги и настроить dm-multipath, но информация будет явно не достаточна для понимания всех деталей работы и команд. Для дальнейшего изучения материала рекомендую обратиться к официальной документации Red Hat - книге "Device-Mapper Multipath Configuration and Administration", доступной на сайте Red Hat как в виде PDF, так и HTML.

Далее рассмотрим настройку dm-multipath для конфигурации представленной на рисунке:Имеется iSCSI-target, доступная по двум интерфейсам в двух сетях: 192.168.0.0/24 и 192.168.1.0/24. Соответственно на сервере vm01 есть два сетевых интерфейса, каждый из которых подключен к одной из двух сетей. На сервере установлен iSCSI-инициатор, и сервер может обращаться к доступному ему целевому устройству по двум различным путям. Попробуем организовать конфигурацию, устойчивую к отказу одного из путей, при помощи dm-multipath.

Для начала убедимся, что на vm01 установлен пакет device-mapper-multipath, и загружены модули ядра dm_multipath и dm_round_robin:

[root@vm01 ~]# rpm -qa | grep multipath
device-mapper-multipath-0.4.7-12.el5
[root@vm01 ~]# lsmod | grep dm_
dm_round_robin 7617 0
dm_multipath 21577 1 dm_round_robin
dm_snapshot 20709 0
dm_zero 6209 0
dm_mirror 28869 0
dm_mod 58201 9 dm_multipath,dm_snapshot,dm_zero,dm_mirror

При необходимости установите пакет. Если модули не загружены, то воспользуйтесь командой modprobe. Далее запускаем процесс обзора для поиска iSCSI-целей. При необходимости можно обратиться к моему посту "Настройка iSCSI target и initiator в RHEL/Fedora" или к любой другой доступной документации.

[root@vm01 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.0.114:3260
192.168.0.114:3260,1 iqn.2003-12.net.markelov:disk1
[root@vm01 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.1.114:3260
192.168.1.114:3260,1 iqn.2003-12.net.markelov:disk1

Перезапускаем демон iscsi и проверяем вывод команды fdisk -l для того, чтобы убедиться, что сервер "видит" подключенную цель:

[root@vm01 ~]# service iscsi restart
[root@vm01 ~]# fdisk -l

Disk /dev/xvda: 17.1 GB, 17179869184 bytes
255 heads, 63 sectors/track, 2088 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

...

Disk /dev/sda: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Disk /dev/sda doesn't contain a valid partition table

Disk /dev/sdb: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Disk /dev/sdb doesn't contain a valid partition table

Как видно, помимо локального /dev/xvda, появились два новых устройства - /dev/sda и /dev/sdb - одинакового размера. Можно убедиться, что это одно и тоже устройство, сравнив идентификаторы:

[root@vm01 ~]# scsi_id -g -s /block/sda
16465616462656166313a3100000000000000000000000000
[root@vm01 ~]# scsi_id -g -s /block/sdb
16465616462656166313a3100000000000000000000000000

Теперь приступаем к правке конфигурационного файла демона multipathd - /etc/multipath.conf. Необходимо закомментировать секцию, определяющую, для каких устройств multipathing выключен:

#blacklist {
# devnode "*"
#}

По умолчанию он был выключен для всех устройств - devnode "*". Далее необходимо раскомментировать секцию с комментариями:
## This is a template multipath-tools configuration file
## Uncomment the lines relevent to your environment
В этом шаблоне есть практически все, что нам нужно. Единственное, что мы изменим, это в path_grouping_policy пропишем failover. В следующей секции описан blacklist, который определяет такие устройства, как floppy-дисководы и IDE-диски. Его также можно раскомментировать. При необходимости добавьте свои устройства. Теперь можно запустить демон multipathd:

[root@vm01 ~]# chkconfig multipathd on
[root@vm01 ~]# service multipathd start

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

[root@vm01 ~]# fdisk -l

...

Disk /dev/dm-2: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-2 doesn't contain a valid partition table

Цель iqn.2003-12.net.markelov:disk1, очевидно, не содержит таблицы разделов. Создадим ее. Однако, команду fdisk нельзя использовать для работы с разделами на устройствах /dev/dm-*. Вместо этого мы создадим разделы на /dev/sda или /dev/sdb:

[root@vm01 ~]# fdisk /dev/sda
... создаем, например, два раздела...
[root@vm01 ~]# partprobe
[root@vm01 ~]# fdisk -l

Disk /dev/xvda: 17.1 GB, 17179869184 bytes

...

Disk /dev/sda: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 509 2619283 83 Linux
/dev/sda2 510 1018 2619314 83 Linux

Disk /dev/sdb: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 509 2619283 83 Linux
/dev/sdb2 510 1018 2619314 83 Linux

Disk /dev/dm-2: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Device Boot Start End Blocks Id System
/dev/dm-2p1 1 509 2619283 83 Linux
/dev/dm-2p2 510 1018 2619314 83 Linux
[root@vm01 ~]#

Наконец осталось создать из наших разделов устройства /dev/dm-*, для того, чтобы с ними далее можно было работать:

[root@vm01 ~]# kpartx -a /dev/dm-2

После этого появятся два новых устройства - /dev/dm-3 и /dev/dm-4, - которые и являются нашими двумя ранее созданными разделами. Можно создать файловую систему и смонтировать ее:

[root@vm01 ~]# mkfs.ext3 /dev/dm-3
[root@vm01 ~]# mkdir /mnt/dm3
[root@vm01 ~]# mount /dev/dm-3 /mnt/dm3/

Далее можно работать с разделом /dev/dm-3 обычным образом. Просмотреть состояние multipathed-устройств можно командой:

[root@vm01 ~]# multipath -ll
mpath0 (16465616462656166313a3100000000000000000000000000) dm-2 IET,VIRTUAL-DISK
[size=5.0G][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
\_ 0:0:0:1 sda 8:0 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 1:0:0:1 sdb 8:16 [active][ready]

По выводу:

[root@vm01 ~]# dmsetup ls --target multipath
mpath0 (253, 2)

можно сопоставить устройство /dev/mapper/mpath0 и /dev/dm-2. Теперь промоделируем выход из строя одного из маршрутов:

[root@vm01 ~]# multipath -ll
sdb: checker msg is "readsector0 checker reports path is down"
mpath0 (16465616462656166313a3100000000000000000000000000) dm-2 IET,VIRTUAL-DISK
[size=5.0G][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
\_ 0:0:0:1 sda 8:0 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 1:0:0:1 sdb 8:16 [failed][faulty]

Тем не менее наше устройство доступно, что легко проверить, записав какую-нибудь информацию в /mnt/dm3. После этого можно "поднять" интерфейс eth1 и провести тот же эксперимент с eth0.

Выступление Макса Спевака (Fedora Project) в МИФИ 20 ноября

Я уже писал в блоге об анонсе проекта Russian Fedora. В течение этого месяца в ходе обсуждений инициатива обросла конкретными идеями, и были сделаны первые шаги в их воплощении. Инициатива Russian Fedora распадается на два направления - техническое и организационное. В качестве одного из шагов во втором направлении 20 ноября состоится пресс-конференция, а после нее - встреча с лидером Fedora Project (с 2006 по 2008) Максом Спеваком (Max Spevack). В настоящее время Макс отвечает за стратегию Red Hat по работе с комьюнити. Также на встрече будет проанонсирован ряд конкретных шагов (в том числе в техническом плане), осуществление которых планируется в рамках Russian Fedora, и направленных на то, чтобы сделать Fedora дистрибутивом, подходящим для российских пользователей «из коробки», а также инициативы в плане локализации. На встрече помимо Макса Спивака планируются выступления руководителей Европейского Red Hat и компании VDEL.
О подробностях регистрации на мероприятие читайте на opennet.ru.

Статья "Создание сервера сетевой установки Fedora/RHEL"

В ноябрьском номере журнала "Системный администратор" выходит моя статья "Создание сервера сетевой установки Fedora/RHEL".

"Дистрибутив Fedora использует для установки весьма мощную и многофункциональную программу Anaconda, поддерживающую различные режимы работы и сценарии инсталляции. Вместе с рядом других технологий, в частности Spacewalk-сервером, вы можете значительно облегчить процесс развертывания и обслуживания вашей Linux-инфраструктуры.
Однако сегодня мы оставим Spacewalk-сервер в стороне, и рассмотрим, как можно автоматизировать самую начальную стадию жизненного цикла серверов/рабочих станций – их развертывание. При этом в процессе установки мы постараемся обойтись без вмешательства оператора при помощи так называемого сервера сетевой установки.

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

• PXE (Pre-Boot Execution Environment)
• DHCP-сервер
• TFTP-сервер
• Kickstart-файлы
• Сетевой репозиторий"
  

Примерно через месяц с разрешения редакции статья будет выложена на сайте markelov.net.

Новые версии Red Hat Network Satellite 5.2 и Spacewalk 0.3

В начале этого месяца вышла новая версия open source решения для управления Linux-инфраструктурой - Spacewalk. Также обновился основанный на Spacewalk продукт Red Hat Network Satellite Server. К сожалению, планы по поводу возможности установки Spacewalk на Fedora перенесены на следующую версию - 0.4, которая должна появится в середине декабря. Пока что в качестве базовой ОС необходимо использовать Red Hat Enterprise Linux (или CentOS и т.п.). Из нововведений можно отметить новый API, возможность синхронизации серверов Spacewalk между собой, улучшенную систему поиска, исправление более четырех десятков различных ошибок.

Что касается новой версии Red Hat Network Satellite 5.2, основное - это возможность использовать в качестве базовой ОС Red Hat Enterprise Linux 5 вместо 4 (я в октябре экзамен сдавал еще на "четверке") и, раз перешли на RHEL 5, то в качестве СУБД - Oracle Database 10g Release 2 Standard Edition и Enterprise Edition, вместо девятой версии.

Настройка iSCSI target и initiator в RHEL/Fedora

Как известно, при использовании существующей сетевой инфраструктуры iSCSI представляет собой недорогую альтернативу FC, а для целей обучения и тестирования вообще не заменим, поскольку, в ряде случаев, можно обойтись без дорогостоящего оборудования. Безусловно, существует и множество "боевых" конфигураций, когда по тем или иным причинам стоит отдать предпочтение iSCSI. В этом посте я хочу кратко описать настройку iSCSI target и iSCSI initiator в Red Hat Enterprise Linux и Fedora. Нужно отметить, что до версии RHEL 5.2 поддержка iSCSI target присутствовала в статусе Technology Preview. Поддержка же iSCSI initiator присутствует в полном объеме еще с Red Hat Enterprise Linux 4.

Для тестов используем две машины: vm01, которая будет экспортировать раздел /dev/xvda5, и vm02, на которой настроим инициатор.

1) Настройка iSCSI target

Для начала устанавливаем пакет scsi-target-utils и запускаем демон tgtd:

[root@vm01 ~]# yum install scsi-target-utils
...
[root@vm01 ~]# service tgtd start
[root@vm01 ~]# chkconfig tgtd on

Теперь создаем наше целевое устройство. В качестве имени я выбрал iqn.2003-12.net.markelov:disk1

[root@vm01 ~]# tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2003-12.net.markelov:disk1

В моем случае я добавляю к целевому устройству свежесозданный раздел /dev/xvda5:

[root@vm01 ~]# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/xvda5

Теперь разрешим доступ хосту vm02 с IP-адресом 192.168.0.109:

[root@vm01 ~]# tgtadm --lld iscsi --op bind --mode target --tid 1 -I 192.168.0.109

Проверяем:

[root@vm01 ~]# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2003-12.net.markelov:disk1
System information:
Driver: iscsi
Status: running
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: deadbeaf1:0
SCSI SN: beaf10
Size: 0
Backing store: No backing store
LUN: 1
Type: disk
SCSI ID: deadbeaf1:1
SCSI SN: beaf11
Size: 964M
Backing store: /dev/xvda5
Account information:
ACL information:
192.168.0.109
[root@vm01 ~]#

Под конец не забудьте прорубить "дырку" в брандмауэре для порта 3260/tcp, который используется по умолчанию.

2) Настройка iSCSI initiator

Устанавливаем пакет iscsi-initiator-utils и запускаем демон iscsi:
[root@vm02 ~]# yum install iscsi-initiator-utils
...
[root@vm02 ~]# service iscsi start
iscsid is stopped
Turning off network shutdown. Starting iSCSI daemon: [ OK ]
[ OK ]
Setting up iSCSI targets: iscsiadm: No records found!
[ OK ]
[root@vm02 ~]# chkconfig iscsi on

При запуске мы получаем совершенно справедливое сообщение, что не сконфигурирована ни одна из целей. Запускаем процесс обзора для поиска целей на хосте vm01 c IP-адресом 192.168.0.100:

[root@vm02 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.0.100:3260
192.168.0.100:3260,1 iqn.2003-12.net.markelov:disk1

В итоге будут созданны две поддиректории с информацией о цели и хосте:

[root@vm02 ~]# ls /var/lib/iscsi/nodes/
iqn.2003-12.net.markelov:disk1
[root@vm02 ~]# ls /var/lib/iscsi/send_targets/
192.168.0.100,3260

Просмотреть информацию можно командой:

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260
node.name = iqn.2003-12.net.markelov:disk1
node.tpgt = 1
...

Теперь, используя содержимое /var/lib/iscsi/nodes/ и /var/lib/iscsi/send_targets/, демон iscsi при каждом перезапуске будет подключать наши ранее обнаруженные цели. Также процессом подключения/отключения можно управлять при помощи утилиты iscsiadm:

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260 -l
Login session [iface: default, target: iqn.2003-12.net.markelov:disk1, portal: 192.168.0.100,3260]
[root@vm02 ~]#

Теперь команда fdisk покажет наш раздел /dev/sda, экспортированный с vm01:

[root@vm02 ~]# fdisk -l

Disk /dev/xvda: 17.1 GB, 17179869184 bytes
255 heads, 63 sectors/track, 2088 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
...
Disk /dev/sda: 1011 MB, 1011677184 bytes
32 heads, 61 sectors/track, 1012 cylinders
Units = cylinders of 1952 * 512 = 999424 bytes

Disk /dev/sda doesn't contain a valid partition table

После команды

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260 -u
Logout session [sid: 2, target: iqn.2003-12.net.markelov:disk1, portal: 192.168.0.100,3260]

в выводе fdisk мы увидим только /dev/xvda. Однако, после рестарта демона iscsi, цель снова появиться в списке устройств. Для удаления всей информации о цели воспользуйтесь командой:

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260 -o delete
[root@vm02 ~]# ls /var/lib/iscsi/nodes/
[root@vm02 ~]#

Если у вас несколько целей, то вы не можете заранее знать, под каким именем после следующей перезагрузки/рестарта сервиса будет доступна конкретная цель. Для того, чтобы каждая цель всегда была доступна под одним и тем же именем устройства, вы можете написать соответствующее правило udev или воспользоваться монтированием по метке и UUID файловой системы ext3. При монтировании файловых систем не забывайте использовать опцию _netdev.

Для того, чтобы лучше понять лог выполненных команд, рекомендую ознакомиться со следующими источниками:

• /usr/share/doc/scsi-target-utils-*
• tgtadm(8)
• iscsiadm(8)

AMD и Red Hat: живая миграция виртуальных машин между ЦП AMD и Intel

Достаточно интересный пятиминутный ролик на youtube.com , показывающий процесс "живой миграции" виртуальной машины между серверами, работающими на платформах AMD и Intel. Насколько я знаю, у VMware такой возможности нет, а у Microsoft, собственно, нет и "живой миграции" :) Помимо прочего, можно посмотреть как выглядит интерфейс управления системы виртуализации с открытым исходным кодом oVirt. Как ожидается, к промышленному применению система виртуализации будет готова к концу года, а тестировать ее можно уже и сейчас.
Пресс релиз.

EX401 is done!

По сравнению с предыдущими лабами EX401 показался относительно простым. 3,5 часа - "внедрение", 1,5 часа - задачи виртуализации. 3/5 от RHCA - сделано :)

Использование LVM snapshots для упрощения работы с виртуальными машинами

Использование мгновенных снимков LVM (Snapshots, снапшоты) при работе с виртуальными машинами позволяет получить ряд полезных преимуществ:

• быстрое, за считанные минуты, развертывание стандартных конфигураций;
• создание/удаление машин, для которых требуется быстрый возврат к стандартной конфигурации (тестовые/учебные машины, машины без сохранения конфигурации);
• экономия места дискового хранилища.
  

Продемонстрируем работу на примере дистрибутива Fedora/RHEL с использованием гипервизора Xen. Задача разбивается на следующие шаги:

1. создание логического тома;
2. установка на логический том виртуальной машины;
3. удаление "машинозависимой" информации;
4. создание снапшота логического тома;
5. копирование и редактирование конфигурационного файла DomU;
6. создание домена;
7. для создания следующего домена переходим к пункту 4.
   

Если вы плохо знакомы с устройством и командами LVM2, то перед тем, как читать дальнейший текст, ознакомьтесь, например, с русскоязычной сатьей на IBM developerWorks Россия.

Сначала подготовим виртуальную машину-шаблон. Создадим новый раздел на жестком диске и установим его тип в 8e (Linux LVM):

[root@server1 ~]# fdisk -l

Диск /dev/sda: 160.0 ГБ, 160041885696 байт
255 heads, 63 sectors/track, 19457 cylinders
Единицы = цилиндры по 16065 * 512 = 8225280 байт

Устр-во Загр Начало Конец Блоки Id Система
/dev/sda1 * 1 19 152586 83 Linux
/dev/sda2 20 12767 102398310 83 Linux
/dev/sda3 12768 13022 2048287+ 82 Linux своп / Solaris
/dev/sda4 13023 19457 51689137+ 5 Расширенный
/dev/sda5 13023 19457 51689106 8e Linux LVM

Теперь инициализируем /dev/sda5 как физический том, создадим на нем группу томов volgroup и часть дискового пространства volgroup отдадим под логический том vmtemplate:

[root@server1 ~]# pvcreate /dev/sda5
Physical volume "/dev/sda5" successfully created
[root@server1 ~]# vgcreate volgroup /dev/sda5
Volume group "volgroup" successfully created
[root@server1 ~]# lvcreate -L 16G -n vmtemplate volgroup
Logical volume "vmtemplate" created
[root@server1 ~]# vgdisplay volgroup
--- Volume group ---
VG Name volgroup
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 49,29 GB
PE Size 4,00 MB
Total PE 12619
Alloc PE / Size 4096 / 16,00 GB
Free PE / Size 8523 / 33,29 GB
VG UUID t0E3c4-DYeW-Si8k-FBNF-sRnO-wVYG-cmpEX7

Итак, по выводу vgdisplay видно, что под снапшоты мы оставили 33G. Сколько выделить места под логический том vmtemplate и снапшоты, зависит от количества и целей, для которых будут использоваться виртуальные машины.

На этом мы закончили подготовительные действия, и теперь можно приступить к созданию эталонной виртуальной машины. В Fedora/RHEL проще всего ее создать при помощи утилиты virt-manager. Запустив мастер создания виртуальной машины, указываем ее имя, например, template1. В качестве типа виртуализации выбираем "паравиртуализация", задаем URL, по которому доступен дистрибутив, и месторасположение kickstart-файла, если вы заранее его подготовили. Теперь – важно: в качестве дискового хранилища указываем наш заранее созданный логический том /dev/volgroup/vmtemplate.

На оставшихся двух экранах укажем способ подключения к сети, число ЦП и объем ОЗУ. В итоге:

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

[root@template1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Xen Virtual Ethernet
DEVICE=eth0
BOOTPROTO=dhcp
DHCPCLASS=
HWADDR=00:16:3E:XX:XX:XX
ONBOOT=yes

После чего завершаем работу template1:

[root@server1 ~]# xm shutdown template1
Отключение домена template1

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

[root@server1 ~]# lvcreate -L 1G -s -n snap01 /dev/volgroup/vmtemplate
Logical volume "snap01" created
[root@server1 ~]# lvdisplay /dev/volgroup/snap01
--- Logical volume ---
LV Name /dev/volgroup/snap01
VG Name volgroup
LV UUID 1mMgmi-FdGJ-EDJK-QWXI-ePH3-EIRH-ZX2Ik3
LV Write Access read/write
LV snapshot status active destination for /dev/volgroup/vmtemplate
LV Status available
# open 0
LV Size 16,00 GB
Current LE 4096
COW-table size 1,00 GB
COW-table LE 256
Allocated to snapshot 0,00%
Snapshot chunk size 4,00 KB
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:1

После чего нам нужно создать конфигурационный файл для домена vm01. За основу можно взять конфигурационный файл "шаблона":

[root@server1 ~]# cp /etc/xen/template1 /etc/xen/vm01

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

[root@server1 ~]# cat /etc/xen/vm01
name = "vm01"
maxmem = 384
memory = 384
vcpus = 1
bootloader = "/usr/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [ "type=vnc,vncunused=1" ]
disk = [ "phy:/dev/volgroup/snap01,xvda,w" ]
vif = [ "bridge=virbr0" ]

Все готово. Создаем домен:

[root@server1 ~]# xm create /etc/xen/vm01
Using config file "/etc/xen/vm01".
Started domain vm01
[root@server1 ~]# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1510 2 r----- 7528.0
vm01 4 383 1 -b---- 15.4

При необходимости всегда можно проверить, сколько места занимает "разница" между шаблоном и снапшотом, при помощи команды:

[root@server1 ~]# lvdisplay /dev/volgroup/snap01

Сразу после создания домена vm01 и интерактивного входа пользователя (GNOME) - эта разница составляет порядка 20Мб. Теперь, пользуясь нашим "шаблонным" логическим томом vmtemplate, мы можем создавать/удалять столько виртуальных машин, сколько нам надо, экономя время и дисковое пространство хоста.

Linux Foundation: Примерная стоимость разработки Fedora 9 - $10.8 биллионов

На сайте Linux Foundation опубликована статья, в которой рассматривается методика и приводятся расчеты стоимости разработки Fedora, если бы этот дистрибутив разрабатывался как проприетарная операционная система. У авторов статьи получилась примерная цифра $10.8 биллионов в долларах США 2008 года. Отдельно оценивалась стоимость разработки только ядра Linux, которая составила $1.4 биллионов.

Установка пара-виртуализированных гостевых систем при помощи kickstart cо Spacewalk- или Satellite-сервера "в картинках"

1) Подготавливам хост-систему

Для начала убедимся, что хост-система зарегистрирована на Satellite- (или Spacewalk-) сервере. В случае, если это Sattelite-сервер, необходимо, чтобы система была подписана на каналы:

• Red Hat Network Tools for Red Hat Enterprise Linux Server
• RHEL Virtualization
  

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

[root@rhel5 ~]# yum install -y xen virtual-manager kernel-xen

и перезагружаемся с новым ядром. Убедиться, что система загружена с ядром xen, можно по выводу uname:

[root@rhel5 ~]# uname -r
2.6.18-53.1.14.el5xen

Далее необходимо доустановить два пакета, служащих клиентским ПО для обеспечения работы с виртуальными машинами c Satellite-сервера и osad-агента и для передачи из Dom0 команд виртуальным машинам (включить, выключить, перезагрузить и т.п.):

yum install -y rhn-virtualization-host osad

Далее запускаем службу osad:

[root@rhel5 ~]# service osad start

На этом подготовительные операции на хосте мы закончили.

2) Создаем kickstart-файл

Заходим в web-интерфейс satellite-сервера и создаем kickstart-файл (Kickstart Overview - Create a new Kickstart Profile), указав в качестве типа виртуализации Para-Virtualized Guest:

3) Назначаем установку виртуального гостя из kickstart-файл

Теперь заходим в свойства хост-системы в раздел Virtualization - Provisioning, где можно указать имя гостевой системы, число виртуальных процессоров, выбрать наш kickstart-файл и назначить время развертывания системы:

Далее можно следить за ходом установки гостя либо непосредственно в web-интерфейсе


либо на хосте:

[root@rhel5 ~]# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1382 2 r----- 3065.5
guest1 2 255 1 -b---- 28.7
guest2 3 255 1 r----- 114.0
[root@rhel5 ~]# xm console guest2

По окончании установки виртуальная система регистрируется на Satellite-сервере, и далее мы можем работать с ней как с физической. Посмотреть список в разрезе "виртуальные машины-физические машины" можно в разделе Systems ― Virtual systems:

Анонс проекта Russian Fedora на Российском СПО-Саммите

Сегодня на Russian Open Source Summit (http://www.ross-ru.ru/) был анонсирован новый проект и проведен круглый стол, посвященный старту программы Russian Fedora, направленной на поддержку СПО-сообщества. Организаторами инициативы стали Red Hat, VDEL и ВНИИНС им. Соломатина.

Полномасштабный запуск программы намечен на декабрь 2008 года. До этого времени будет сформировано ядро проекта, получен некий фидбэк от российского сообщества пользователей и разработчиков СПО. Это в большей степени организационный проект, который преследует следующие цели:

• объединить российских разработчиков и пользователей СПО, сформировать «центр притяжения» для новых пользователей
• сделать Fedora «коробочным» дистрибутивом, ориентированным на российских пользователей
• помочь российским разработчикам более активно влиять на апстрим
• укрепить имидж российского сообщества разработки СПО на глобальном мировом рынке
  

В рамках проекта Red Hat предоставит необходимую базу, технологии, и обеспечит взаимодействие со своими центрами разработки. На базе ВНИИНС им. Соломатина будет создан центр разработки, который станет технологическим ядром проекта. VDEL отвечает за организацию проекта.

Кстати, в ноябре в рамках запуска проекта в Москву приедет Макс Спевак — лидер Fedora Project. Конкретные шаги по развитию проекта будут объявлены позже. Следите за новостями...

Настраиваем TLS/SASL-шифрование и аутентификацию в MTA Sendmail

При помощи механизма STARTTLS и сертификатов мы попробуем настроить взаимную аутентификацию и шифрование пересылаемой почты между двумя почтовыми серверами с MTA Sendmail. Также при помощи TLS защитим отправляемую клиентами на сервер почту и настроим почтовый релей для пересылки корреспонденции только тех пользователей, которые предъявят сертификат, выданный нашим центром сертификации (CA).

STARTTLS (RFC 2487) является расширением протокола SMTP. STARTTLS в первую очередь предназначен для поддержки TLS-шифрования и аутентификации между двумя почтовыми серверами. Но как вы увидите далее, он с успехом может применяться и почтовыми клиентами.

MTA Sendmail в нашей тестовой конфигурации будет работать на двух серверах Red Hat Enterprise Linux 5.1. Выбор не является принципиальным – вы можете использовать ваш любимый или вовсе установить Sendmail в другой операционной системе, например Solaris. Единственное, с чем вы можете столкнуться, – отличие поставляемого по умолчанию в вашем дистрибутиве конфигурационного файла sendmail.mc от использующегося в Red Hat Enterprise Linux/Fedora.

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

В качестве «компенсации» засилья Open Source-инструментов в роли MUA используем штатную в Windows Vista программу Windows Mail.

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

Начнем с сертификата для MTA. Необходимо отметить, что STARTTLS в данном случае защищает только трафик между двумя соответствующим образом настроенными почтовыми серверами. Нет никакой гарантии при отправке письма «во вне», что все релеи, через которые пройдет письмо, используют STARTTLS. Никогда не надо забывать, что отправка письма через Интернет аналогична отправке почтовой карточки по обыкновенной почте. Текст вашего письма может быть прочитан во всех точках, через которые пересылается письмо. Для гарантированной защиты электронной почты между отправителем и получателем необходимо использовать шифрование при помощи S/MIME или GnuPG/PGP.

Генерируем для нашего сервера приватный ключ и создаем запрос в центр сертификации:

# openssl genrsa 1024 > sendmail.key
# openssl req -new -key sendmail.key -out sendmail.csr

После чего необходимо переслать запрос на выдачу сертификата в центр сертификации. Администратор центра сертификации выпускает на основе запроса сертификат:

# openssl ca -in sendmail.csr -out sendmail.crt

Копируем полученный сертификат на почтовый сервер и кладем рядом с ключом в директорию /etc/pki/tls/certs. Права на оба файла должны быть выставлены 600 или 400.

Далее начинаем править конфигурационный файл /etc/mail/sendmail.mc. Редактируем пути и убираем комментарии со строк:

# Директория с сертификатами
define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
# Сертификат CA, выдавшего сертификат нашему серверу.
# Не забудьте его также скопировать в указанную директорию
define(`confCACERT', `/etc/pki/CA/cacert.pem')dnl
# Сертификат нашего сервера, используемый во время
# приема почты
define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.crt')dnl
# Приватный ключ нашего сервера
define(`confSERVER_KEY', `/etc/pki/tls/certs/sendmail.key')dnl

и добавляем две новых строки:

# Сертификат и приватный ключ нашего сервера, используемый для отправления почты на другой сервер.
# Для простоты используем те же, файлы, что и в первом случае
define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.crt')dnl
define(`confSERVER_KEY', `/etc/pki/tls/certs/sendmail.key')dnl

Для проверки наших настроек зайдем на 25-й порт сервера при помощи команды telnet:

# openssl ca -in sendmail.csr -out sendmail.crt

Trying 192.168.0.17...

Connected to station17.example.com (192.168.0.17).

Escape character is '^]'.
220 station17.example.com ESMTP Sendmail 8.13.8/8.13.8; Thu, 31 Jul 2008 14:21:33 +0400
EHLO station18.example.com
250-station17.example.com Hello station18.example.com [192.168.0.18], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP
STARTTLS
220 2.0.0 Ready to start TLS
QUIT

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

Теперь если мы попробуем на одном из серверов локально запустить MUA, например mutt, и отправить сообщение пользователю второго сервера, то на первом сервере в /var/log/maillog увидим примерно такие сообщения:

Jul 31 01:07:21 station18 sendmail[9558]: STARTTLS=client, relay=station17.example.com.,
version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 31 01:07:21 station18 sendmail[9558]: m6UL7Lpc009556: to=,
ctladdr= (0/0), delay=00:00:00, xdelay=00:00:00, mailer=esmtp,
pri=120467, relay=station17.example.com. [192.168.0.17], dsn=2.0.0, stat=Sent (m6UL7LpK009193
Message accepted for delivery)

А на принимающем соответственно:

Jul 31 01:07:21 station17 sendmail[9193]: STARTTLS=server, relay=station18.example.com [192.168.0.18],
version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 31 01:07:21 station17 sendmail[9193]: m6UL7LpK009193: from=, size=748,
class=0, nrcpts=1, msgid=<20080730210721.ga9548@station18.example.com>, proto=ESMTP, daemon=MTA,
relay=station18.example.com [192.168.0.18]
Jul 31 01:07:21 station17 sendmail[9194]: m6UL7LpK009193: to=,
delay=00:00:00, xdelay=00:00:00, mailer=local, pri=31037, dsn=2.0.0, stat=Sent

Как видно из журнала, серверы аутентифицировали друг друга при помощи сертификатов, выданных одним и тем же CA, и при пересылке письма информация была зашифрована. Данный факт можно проверить, запустив на одном из тестовых серверов утилиту wireshark или tcpdump.

Настройка TLS для клиента

В текущем состоянии Sendmail готов работать с клиентом, принимая от него почту в зашифрованном виде, однако никакой проверки клиента при помощи механизма TLS не используется. Зато клиенту не нужны сертификаты, и всего лишь достаточно поставить соответствующую галку – «использовать защищенное соединение, TLS».

В журнале почтового сервера это выглядит примерно так:

Jul 30 23:29:09 station17 sendmail[8228]: STARTTLS=server, relay=station51.example.com [192.168.0.51],
version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 30 23:29:09 station17 sendmail[8228]: m6UJT8GH008228: from=, size=341,
class=0, nrcpts=1, msgid=<4890c39d.4020404@station17.example.com>, proto=ESMTP, daemon=MTA,
relay=station51.example.com [192.168.0.51]
Jul 30 23:29:09 station17 sendmail[8229]: m6UJT8GH008228: to=,
ctladdr= (507/508), delay=00:00:00, xdelay=00:00:00, mailer=local,
pri=30623, dsn=2.0.0, stat=Sent

Как видно, напротив verify мы видим значение «NO». Попробуем «закрутить гайки».

Сгенерируем сертификат для пользователя. Раз мы начали работать с OpenSSL, для упрощения задачи предположим, что наш пользователь также воспользуется этой утилитой. Естественно, какими средствами будет сгенерирован запрос в центр сертификации, нам не важно. В «боевой» среде скорее всего пользователь воспользуется каким-либо веб-интерфейсом.

Итак, от лица пользователя:

# openssl genrsa 1024 > andrey.key
# openssl req -new -key andrey.key -out andrey.csr

И от лица администратора CA:

# openssl ca -in andrey.csr -out andrey.crt

Далее необходимо «упаковать» ключ и сертификат в формат PKCS#12:

# cat andrey.key andrey.crt > andrey.pem
# openssl pkcs12 -export -in andrey.pem -out testusercert.p12 -name "Andrey's Personal cert"

«Скармливаем» персональный сертификат и сертификат CA выбранному MUA, в нашем случае программе Windows Mail.

А на сервере остается прописать, кому разрешена пересылка почты через наш сервер:

# cat /etc/mail/access
Connect:localhost.localdomain RELAY
Connect:localhost RELAY
Connect:127.0.0.1 RELAY
CERTISSUER:/C=GB/ST=Berkshire/L=Newbury/O=My+20Company+20Ltd/CN=Station+2018+20CA RELAY
CERTSUBJECT:/C=GB/ST=Berkshire/L=Newbury/O=My+20Company+20Ltd/CN=Station+2018+20CA RELAY

В данном случае мы разрешаем пересылку только обладателям сертификатов, выданных нашим CA.

Параметры CERTISSUER и CERTSUBJECT мы заполняем значениями, взятыми из полей Issuer и Subject сертификата CA:

# openssl x509 -in cacert.pem -noout -subject -issuer
subject= /C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd/CN=Station 18 CA
issuer= /C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd/CN=Station 18 CA

При этом ряд символов, в том числе «{», «<», «>», «(», «)», «"», «+», «}», и пробел заменяются на шестнадцатеричные ASCII-коды, предваряемые символом «плюс». Соответствующие коды можно посмотреть в странице руководства:

# man ascii

Успешная попытка обладателя сертификата использовать наш почтовый сервер в качестве релея в журнале /var/log/messages будет выглядеть примерно следующим образом:

Jul 31 02:10:31 station17 sendmail[9700]: STARTTLS=server, relay=station51.example.com [192.168.0.51],
version=TLSv1/SSLv3, verify=OK, cipher=AES128-SHA, bits=128/128
Jul 31 02:10:31 station17 sendmail[9700]: m6UMAVTH009700: from=, size=1128,
class=0, nrcpts=1, msgid=<57a621a4bfcb411f9acde6a1d9ce3e62@andreypc>, proto=ESMTP, daemon=MTA,
relay=station51.example.com [192.168.0.51]
Jul 31 02:10:31 station17 sendmail[9702]: STARTTLS=client, relay=station18.example.com.,
version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 31 02:10:31 station17 sendmail[9702]: m6UMAVTH009700: to=,
ctladdr= (507/508), delay=00:00:00, xdelay=00:00:00, mailer=esmtp,
pri=121128, relay=station18.example.com. [192.168.0.18], dsn=2.0.0, stat=Sent (m6UMAVR4009739 Message
accepted for delivery)

Если вы увидели подобные сообщения в журнале, значит наша цель достигнута. Убедиться в том, что соответствующий сеанс защищен, вы можете при помощи утилиты wireshark.
Таким образом, как видите, при всей относительной сложности настройки MTA Sendmail, механизм STARTTLS включается достаточно просто.

Андрей Маркелов

Впервые опубликовано в журнале "Системный администратор", август 2008