Использование 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

SELinux User Guide для Fedora 10

Релиз Fedora 10 не за горами, и уже сейчас желающие могут протестировать бета-версию дистрибутива. Еще одна бета-версия, но уже руководства по SELinux для Fedora 10, также доступна для ознакомления уже сейчас. Security-Enhanced Linux User Guide особенно актуален с учетом относительного «информационного голода» в том, что касается данной реализации системы мандатного контроля доступа. Приятного чтения.