Linuxformat - Вклад участника [ru]

LXF104

2009-03-30T21:39:29Z

Kipruss: /* Учебники */

=== Учебники ===

* [[LXF104:Совет месяца|'''Совет месяца:''' ''Chroot'']]

* [[LXF104:Альтернативы Photoshop|'''Фотография.''' Альтернативы ''Photoshop'']]
Противники Linux утверждают, что наша ОС не подходит для работы с изображениями. '''Дейл Стрикланд-Кларк''' покажет, насколько они заблуждаются, предложив внушительный список доступных инструментов.

* [[LXF104:Hardcore Linux|'''Hardcore Linux.''' LDAP: Защитим вход в Dovecot.]]
Позволять кому попало использовать наш почтовый сервер без аутентификации пользователя – сущее безумие. '''Д-р Крис Браун''' наведет порядок с помощью LDAP…

* R: начала анализа

[[Категория:Математические пакеты]]

=== [[LXF104:Ответы|Ответы]] ===

Проблемы Linux решены: мониторинг серверов, автомонтирование с ''Udev'', преобразователи ''USB-to-serial'', сборка ПО, подстройка ''swap'' и запуск сканера в виртуальной машине.

LXF104:Hardcore Linux

2009-03-30T21:37:36Z

Kipruss: /* Станция «Рабочая» */

==LDAP: Защитим вход в Dovecot==

Позволять кому попало использовать наш почтовый сервер без аутентификации пользователя – сущее безумие. '''Д-р Крис Браун''' наведет порядок с помощью LDAP…

Сегодняшнее утреннее чтение начнем с Книги Тукса, главы пятой, с самого первого стиха.

# В начале был файл с паролями, и файл с паролями был Unix. Через него все пользователи могли получить доступ; и без него никто из входящих не мог пройти. И сисадмины сказали, что это хорошо.
# Но вот настала Великая Сеть, и возроптали сисадмины, говоря: «Файл с паролями свое отслужил, требует он дублирования данных и затрудняет масштабирование на большую сеть». Тогда Sun сказал: «Не бойтесь, ибо мы принесли вам Желтые Страницы, которые централизуют данные пользователей».
# Но затем явились четыре мудреца из Beetea и сказали: «Не смеете вы взять имя Желтые Страницы, оно наша собственность и наша торговая марка». И ответил им Sun: «Пускай то, что раньше звалось Желтыми Страницами, отныне зовется NIS». И сисадмины сказали, что это хорошо.
# Но прошло время, и снова разочаровались сисадмины, и возроптали они во второй раз: «Истинно, NIS имеет плоское пространство имен и не имеет контроля доступа».
# И снова сказал Sun: «Не бойтесь, ибо мы принесли вам NIS+, иерархическое пространство имен в нем и контроль доступа в избытке». Но сисадмины возроптали в третий раз, по своему неразумию.
# И создан был консорциум, и родил он спецификацию X500. И X500 родил DAP, DAP родил DIXIE, а DIXIE родил LDAP. И увидели сисадмины, что это хорошо. И это конец нашего утреннего чтения.

Истинно говорю вам, в этот день, на этом уроке мы создадим службу каталогов LDAP и используем ее для аутентификации в агенте доступа к почте POP/IMAP ''Dovecot''.

===Азбука LDAP===

LDAP (облегченный протокол доступа к каталогам) – это служба каталогов, которую в принципе можно использовать для хранения любых данных, хотя на практике она чаще используется для хранения информации о пользователях, в частности, аутентификационных данных. Благодаря наличию открытой реализации (OpenLDAP) LDAP стал популярен в мире Linux как замена служб типа NIS или NIS+; в мире Windows она тоже хорошо известна – как основа ''Microsoft Active Directory''.

Служба каталогов немного похожа на базу данных: обе могут хранить большие объемы информации и эффективно выполнять в ней поиск. Однако, служба каталогов оптимизирована для чтения (поиска); отношение времени записи к времени чтения обычно велико, и это не годится для ситуаций, когда требуется частое обновление данных. Для справочника естественно, что чтение выполняется в 10000 раз чаще, чем запись. Реляционные базы данных более симметричны по скорости чтения и записи. Кроме того, каталоги обычно не поддерживают транзакции, откаты и реляционные операции, типа join, которые имеют важное значение для реляционных баз данных.

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

Вы можете использовать LDAP в разных целях: например, для аутентификации постоянных пользователей Linux; или для реализации отображений ''Postfix'', таких как виртуальный почтовый ящик, рассмотренный на уроке прошлого месяца. На данном уроке мы используем LDAP для простой аутентификации пользователей в ''Dovecot''.

Отдать должное мощи и гибкости LDAP в ограниченном пространстве статьи – примерно то же, что пытаться открыть мир классической музыки инопланетянину, промычав ему первые четыре ноты Пятой симфонии Бетховена; но мы постараемся.

===Что в имени тебе моем?===

Каталоги LDAP состоят из набора записей, упорядоченных в виде древовидной структуры. Каждая позиция в дереве идентифицируется так называемым «различимым именем» (distinguished name, dn). Например, dn может быть вида cn=cbrown,ou=users,dc=example,dc=com. Сравним его с другими видами синтаксиса: как имя файла в Linux, оно бы записалось в виде '''/com/example/users/cbrown''', а «полное доменное имя» в DNS выглядело бы '''cbrown.users.example.com'''.

Каждая запись в справочнике содержит информацию в виде набора пар «атрибут:значение». Какие именно атрибуты присутствуют, определяется так называемым классом объекта записи. Например, наша запись cn=cbrown,ou=users,dc=example,dc=com является объектом класса posixAccount. Описание, какой атрибут ассоциируется с каким классом, называется схемой, и она задается в файлах схем. Например, здесь описание класса posixAccount берется из файла '''/etc/openldap/schema/nis.schema''':
<code>
objectclass ( 1.3.6.1.1.1.2.0 NAME ‘posixAccount’
DESC ‘Abstraction of an account with POSIX attributes’
SUP top AUXILIARY
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )
</code>

Здесь важно отметить имя класса, список требуемых атрибутов (условие MUST) и список необязательных атрибутов (условие MAY). Если вы знакомы с файлом паролей Linux, вы заметите сходство атрибутов в объекте posixAccount и полях в '''/etc/passwd'''. (Учтите, однако, что атрибут LDAP uid – это то, что мы назвали бы именем учетной записи, а атрибут uidNumber – как раз то, что мы называем UID!) В терминах объектно-ориентированного программирования вы можете представить запись в файле схемы как описание класса, а запись в каталоге – как экземпляр класса. Также возможно наследование класса от «вышестоящего» класса (в объектно-ориентированном программировании он называется родительским или базовым). Строка SUP top AUXILIARY в предыдущем примере говорит нам, что вышестоящий класс, находящийся на вершине иерархии классов – это сам posixAccount, который не наследуется ни от чего. Но зайти дальше в аналогиях с ООП не получится: записи LDAP содержат только данные. Никакого запускаемого кода (который ОО-программисты назвали бы методом) с объектом не ассоциируется.

{{Врезка
|Заголовок=LDAP как он есть
|Содержание=На стороне сервера услуги предоставляет демон ''slapd''. В качестве своей базы данных он использует ''BDB'' (встраиваемая библиотека базы данных, первоначально разработанная UC Berkeley), а прелестно названный ''slurpd'' распространяет изменения на все копии справочника LDAP. На стороне клиента OpenLDAP предоставляет различные инструменты командной строки для манипулирования записями каталога, включающие ''ldapadd'', добавляющий информацию в каталог, и ''ldapsearch'', используемый для (угадали!) поиска по каталогу.
|Ширина=200px}}

Для просмотра человеком записи каталога LDAP отображаются в текстовом формате, называемом LDIF (формат обмена данными LDAP). Это формально заданный синтаксис, в соответствии с которым записи каталога представляются «вне» LDAP. Например, LDIF используется для предварительного создания записи при вводе ее в каталог, переноса данных из одного справочника в другой или просмотра содержимого справочника. В развитие нашего примера, LDIF-представление пользователя cn=cbrown,ou=users,dc=example,dc=com будет выглядеть так:
<code>
dn: cn=cbrown,ou=users,dc=example,dc=com
objectclass: posixAccount
objectclass: Account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
</code>
Мы сфокусировали здесь внимание на типе объекта '''posixAccount''', потому что он необходим нам для поддержки аутентификации.

===Станция «Рабочая»===

Хватит теории! Давайте же установим и сконфигурируем LDAP. Я использую сервер CentOS, как на прошлом уроке (CentOS – это эквивалент RHEL5), но все, что будет показано далее, легко применимо для других дистрибутивов RedHat или Fedora.

Мы будем использовать LDAP, который создан в Мичиганском университете (см. '''<nowiki>www.openldap.org</nowiki>'''). Установка его в CentOS проста:
<code>
# yum install openldap-clients openldap-servers
</code>

[[Изображение:LXF104_73_1.png|thumb|300px|Рис. 1. Компоненты OpenLDAP.]]

Рисунок 1 показывает основные компоненты OpenLDAP. Остальные компоненты клиента – модуль PAM LDAP ('''/lib/security/pam_ldap.so''') и библиотека разрешения LDAP ('''/lib/libnss_ldap.so'''), поддерживающая хранение стандартных учетных записей Linux в LDAP; мы займемся ими в следующем месяце.

Для запуска службы LDAP необходимо кое-что изменить в файле конфигурации slapd ('''/etc/openldap/slapd.conf'''). Вот строки, которые я поменял:
<code>
suffix = “dc=example,dc=com”
rootdn = “cn=admin,dc=example,dc=com”
rootpw = {SSHA}JM2o2+Z07QJ9CZxqD6CIL3aEe/zSzMmW
</code>

Первая задает «именованный контекст» нашей службы LDAP, то есть dn ее верхней записи. Здесь можно использовать все что угодно, но я основывался на доменном имени DNS ('''<nowiki>example.com</nowiki>''') настраиваемой машины: это стандартное решение. Вторая строка задает dn для учетной записи администратора сервера LDAP (он имеет полный контроль над содержимым каталога – это аналог root для Linux), а третья строка задает хэшированный пароль для этой учетной записи. Хэшированный пароль я сгенерировал с помощью '''slappasswd''':
<code>
# slappasswd
New password:
Re-enter new password:
{SSHA}JM2o2+Z07QJ9CZxqD6CIL3aEe/zSzMmW
</code>
а затем вырезал и вставил результат в файл. После этого я запустил службу:
<code>
# service ldap start
</code>

[[Изображение:LXF104_74_1.png|thumb|300px|Рис. 2. Простая структура каталога LDAP для поддержки аутентификации.]]

Далее нам надо заселить наш каталог записями, которые пригодятся для аутентификации. Чтобы сообразить, куда мы движемся, посмотрите на рисунок 2, там показана структура, которую нам надо создать.

Сперва нужно построить и добавить в справочник узлы верхнего уровня. Я решил создать учетные записи пользователей в узле ou=users,dc=example,dc=com. Слово ‘users’ не является ключевым, просто я взял такое имя. Я начал с создания файла LDIF, названного '''root.ldif''':
<code>
# Build the root node
dn: dc=example,dc=com
dc: example
objectClass: dcObject
objectClass: organizationalUnit
ou: example dot com
# Build the users ou
dn: ou=users,dc=example,dc=com
ou: users
objectClass:
organizationalUnit
</code>

Затем я добавил этот узел в каталог с помощью команды:
<code>
# ldapadd -D “cn=admin,dc=example,dc=com” -x -W -f root.ldif
</code>

Теперь добавим учетную запись пользователя. Выполняется это сходным образом: создается файл LDIF, а затем используется ''ldapadd'' для его добавления. Вот файл ('''newuser.ldif'''), который я создал:
<code>
dn: cn=cbrown,ou=users,dc=
example,dc=com
objectclass: posixAccount
objectclass: Account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
</code>

Затем я добавил этот узел в каталог:
<code>
# ldapadd -D “cn=admin,dc=example,dc=com” -x -W -f newuser.ldif
</code>

Так как записи LDAP нам понадобятся для аутентификации входа на сервер ''Dovecot'', я должен задать еще и пароль для пользователя, как показано здесь:
<code>
# ldappasswd -x -D “cn=admin,dc=example,dc=com” -W -S “cn=cbrown,ou=users,dc=example,dc=com”
New password:
Re-enter new password:
Enter LDAP Password:
Result: Success (0)
</code>

Теперь не мешает проверить, что пользователь был добавлен в каталог; давайте выполним поиск записи. Для этого можно употребить ''ldapsearch'':
<code>
# ldapsearch -x -b “ou=users,dc=example,dc=com” ‘(cn=cbrown)’
# cbrown, users, example.com
dn: cn=cbrown,ou=users,dc=example,dc=com
objectClass: posixAccount
objectClass: account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
userPassword:: e1NTSEF9cCt2Sml1enpCSTdOZjJUSU1ZcEp0c
U5LTnQzVHhjZzg=
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
</code>

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

Справочники создаются именно для поиска в них, поэтому стоит разобрать поиск LDAP более подробно. Команда ldapsearch немного похожа на SQL-запрос к реляционной базе данных. Попробуем обойтись без формального описания синтаксиса. Я придумал хороший пример: разбил команду на несколько строк и для удобства ссылок пронумеровал их. Первые шесть строк из представленных ниже – на самом деле одна команда (обратные слэши у них на конце указывают, что команда продолжается на следующей строке). Для запуска этой команды в терминале просто удалите номера и, естественно, слэши, набрав весь код в одну строку.
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
# ldapsearch -h mail.example.com \
-x -LLL -b “dc=example,dc=com” \
-D cn=admin,dc=example,dc=com -W
-s sub \
‘(|(uid=*brown)(gidNumber<=100))’ \
uid
Enter LDAP Password:
dn: cn=cbrown,ou=users,dc=example,dc=com
uid: cbrown
</source>

[[Изображение:LXF104_75_1.png|thumb|304px|Рис. 3. Просмотр справочника LDAP с помощью LAT. Снимок экрана показывает запись, добавленную нами для пользователя cbrown.]]
[[Изображение:LXF104_75_2.png|thumb|304px|Рис. 4. Выполнение поиска в LDAP при помощи LAT.]]

Теперь давайте вникать:
# Флаг -h используется для указания хоста, где запущен сервер LDAP. По умолчанию считается, что это localhost.
# Аргумент -x велит команде использовать простой метод аутентификации (не SASL), -LLL снижает число комментариев и прочих лишних слов в выводе, а флаг -b определяет, где мы хотим начать поиск в дереве справочника. В нашем случае мы начинаем с вершины дерева.
# Флаг -D задает dn пользователя, под которым мы хотим зайти (это пользователь, определенный параметром rootdn в '''slapd.conf'''), а -W велит команде запрашивать пароль.
# Здесь говорится, что поиск должен захватывать все ветви указанной базы, так что в данном случае мы запускаем поиск по всему справочнику.
# Пример фильтра поиска. Он говорит «покажите мне записи, где имя пользователя заканчивается на ‘brown’ или ID группы меньше или равно 100». Фильтры поиска – самая трудная часть синтаксиса для правильного написания, но (в определенном смысле) и самая важная.
# Эта строка содержит список имен атрибутов, которые мы хотим отобразить (в нашем случае просто имя пользователя). Если список пуст, ''ldapsearch'' покажет все атрибуты.
# Далее мы запрашиваем пароль для входа LDAP.

Наконец, строки 8 и 9 показывают вывод поиска.

Осилим еще один пример?
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
# ldapsearch -x \
-b “ou=users,dc=example,dc=com” \
-D cn=admin,dc=example,dc=com -W \
-s base ‘(objectClass=*)’
</source>

Рассмотрим строки 2 и 4. В строке 2 задан конкретный узел дерева справочника, откуда начнется поиск, а в строке 4 мы говорим LDAP не распространять поиск за пределы этого узла, а изучать только записи, заданные в строке 2. Фильтр поиска здесь фактически и не фильтр: он гласит «любая запись с атрибутом '''objectClass''', независимо от значения», а это вообще все записи. Итак, этот поиск выводит на дисплей содержимое определенного узла дерева.

Если вы предпочли бы использовать графические инструменты для поиска в вашем справочнике LDAP или добавления учетной записи пользователя, обратите внимание на Lat (''LDAP Administration Tool''). Это одно из новоиспеченных приложений, написанное на C# с использованием Mono и ''GTK#'', поэтому вам понадобятся установленные библиотеки Mono для его использования, но на моем клиенте с Ubuntu он установился и работал без каких-либо проблем. Рисунок 3 показывает этот инструмент в работе при обозревании иерархии LDAP, а на рисунке 4 показан пример поиска по UID 555.

===Аутентификация Dovecot===

Давайте закруглимся, применив каталог LDAP к полезному делу. Читатели предыдущего номера могут помнить, что мы оставили нашего героя (почтовый сервер ''Dovecot'') нуждающимся в аутентификации учетных записей POP3 базы данных пользователей, независимых от учетных записей пользователей в Linux.

Оказывается, ''Dovecot'' может использовать LDAP для аутентификации двумя способами: он может войти в LDAP с именем пользователя ‘rootdn’ и паролем ‘rootpw’, затем посмотреть имя пользователя и хэшированный пароль пользователя, который пытается аутентифицироваться, а может просто попробовать подключиться к серверу LDAP с именем и паролем того пользователя, кто пытается войти, и посмотреть, успешна ли попытка. Вход в LDAP известен как ‘связывание’, и эта техника называется аутентификационной связью. Этот метод мы и будем использовать.

Настройка ''Dovecot'' на использование LDAP для аутентификационной связи требует изменений в файле '''/etc/Dovecot.conf'''. Вот строки, которые я менял:
<code>
auth_verbose = yes
auth_debug = yes
passdb ldap {
args = /etc/dovecot-ldap.conf
}
userdb ldap {
args = /etc/dovecot-ldap.conf
}
</code>

Первые две строки включают вывод отладочных сообщений. На рабочем сервере они вам не понадобятся, но мне файл журнала ('''/var/log/maillog''') очень помог при отладке конфигурации ''Dovecot''. Две остальные строфы файла указывают, что мы будем использовать LDAP и как базу данных паролей, и как базу данных пользователей, и задают место размещения файла конфигурации LDAP для ''Dovecot''.

Дико извиняюсь, но есть еще один файл конфигурации! Для его создания я начал с копирования примера конфигурации LDAP из дистрибутива ''Dovecot'' на место:
<code>
# cp /usr/share/doc/dovecot-1.0/examples/dovecot-ldap.conf /etc
</code>

Затем я сделал следующие изменения в '''/etc/Dovecot-ldap.conf''' (номера строк опять-таки нужны только для ссылок на них в тексте):
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
hosts = localhost
dn = cn=admin,dc=example,dc=com
dnpass = adminpw
auth_bind = yes
auth_bind_userdn = cn=%u,ou=users,dc=example,dc=com
base = ou=users,dc=example,dc=com
</source>

Строка 1 задает имя сервера, на котором запущен LDAP. Строка 2 определяет dn учетной записи, которое ''Dovecot'' будет использовать для входа в LDAP, а строка 3 задает пароль для этой учетной записи. (Вообще-то было бы лучше не использовать для этого учетную запись с полными правами rootdn, а создать особую учетную запись для ''Dovecot''). Строка 4 говорит, что будет использоваться аутентификационная связь, а строка 5 задает dn пользователя, которого мы пробуем аутентифицировать как такового (над этим мне пришлось поломать голову!). В файле конфигурации ''Dovecot'', %u ссылается на имя пользователя, которое использует MUA (почтовый агент) пользователя, чтобы войти. Строка 6 определяет узел в дереве справочника LDAP, под которым находятся учетные записи пользователей.

Угнездив на месте эти строки, я смог подсоединиться к службе POP3 ''Dovecot'' с учетной записью cbrown и забрать почту.

Если у вас что-то не заработало, загляните в файл журнала, обычно '''/var/log/maillog'''. Сообщения, оставляемые ''Dovecot'', очень подробны и говорят сами за себя. '''LXF'''

----

===Что еще почитать? (врезка)===

# По LDAP существует множество книг. Самыми полезными мне показались две: ''LDAP System Administration by Gerald Carter'' (O’Reilly, 1-56592-491-6), и ''Understanding and Deploying LDAP Directory Services by Howes, Smith and Good'' (Addison Wesley, 0672323168). Последняя более академическая (и тяжелая!)
# Официальная документация ''Dovecot'' доступна по адресу http://wiki.dovecot.org. В частности, статья http://wiki.dovecot.org/AuthDatabase/LDAP показывает, как сделать аутентификацию LDAP в ''Dovecot''. Кроме того, '''slapd.conf''', '''ldap.conf''' и все инструменты командной строки имеют прекрасные man-страницы.
# Основную информацию по сборке почтового сервера можно найти по адресам http://freshrpms.net/docs/mail-server и http://wanderingbarque.com/howtos/mailserver/mailserver.html. (Это очень подробное пошаговое руководство, написанное Питером Лэйси [Peter Lacey]; оно охватывает интеграцию ''Postfix'', ''Dovecot'', OpenLDAP, Jamm, ''Cyrus-SASL'' и ''SquirrelMail'', и основано на RHEL 3).

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

LXF104:Hardcore Linux

2009-03-30T21:32:41Z

Kipruss:

==LDAP: Защитим вход в Dovecot==

Позволять кому попало использовать наш почтовый сервер без аутентификации пользователя – сущее безумие. '''Д-р Крис Браун''' наведет порядок с помощью LDAP…

Сегодняшнее утреннее чтение начнем с Книги Тукса, главы пятой, с самого первого стиха.

# В начале был файл с паролями, и файл с паролями был Unix. Через него все пользователи могли получить доступ; и без него никто из входящих не мог пройти. И сисадмины сказали, что это хорошо.
# Но вот настала Великая Сеть, и возроптали сисадмины, говоря: «Файл с паролями свое отслужил, требует он дублирования данных и затрудняет масштабирование на большую сеть». Тогда Sun сказал: «Не бойтесь, ибо мы принесли вам Желтые Страницы, которые централизуют данные пользователей».
# Но затем явились четыре мудреца из Beetea и сказали: «Не смеете вы взять имя Желтые Страницы, оно наша собственность и наша торговая марка». И ответил им Sun: «Пускай то, что раньше звалось Желтыми Страницами, отныне зовется NIS». И сисадмины сказали, что это хорошо.
# Но прошло время, и снова разочаровались сисадмины, и возроптали они во второй раз: «Истинно, NIS имеет плоское пространство имен и не имеет контроля доступа».
# И снова сказал Sun: «Не бойтесь, ибо мы принесли вам NIS+, иерархическое пространство имен в нем и контроль доступа в избытке». Но сисадмины возроптали в третий раз, по своему неразумию.
# И создан был консорциум, и родил он спецификацию X500. И X500 родил DAP, DAP родил DIXIE, а DIXIE родил LDAP. И увидели сисадмины, что это хорошо. И это конец нашего утреннего чтения.

Истинно говорю вам, в этот день, на этом уроке мы создадим службу каталогов LDAP и используем ее для аутентификации в агенте доступа к почте POP/IMAP ''Dovecot''.

===Азбука LDAP===

LDAP (облегченный протокол доступа к каталогам) – это служба каталогов, которую в принципе можно использовать для хранения любых данных, хотя на практике она чаще используется для хранения информации о пользователях, в частности, аутентификационных данных. Благодаря наличию открытой реализации (OpenLDAP) LDAP стал популярен в мире Linux как замена служб типа NIS или NIS+; в мире Windows она тоже хорошо известна – как основа ''Microsoft Active Directory''.

Служба каталогов немного похожа на базу данных: обе могут хранить большие объемы информации и эффективно выполнять в ней поиск. Однако, служба каталогов оптимизирована для чтения (поиска); отношение времени записи к времени чтения обычно велико, и это не годится для ситуаций, когда требуется частое обновление данных. Для справочника естественно, что чтение выполняется в 10000 раз чаще, чем запись. Реляционные базы данных более симметричны по скорости чтения и записи. Кроме того, каталоги обычно не поддерживают транзакции, откаты и реляционные операции, типа join, которые имеют важное значение для реляционных баз данных.

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

Вы можете использовать LDAP в разных целях: например, для аутентификации постоянных пользователей Linux; или для реализации отображений ''Postfix'', таких как виртуальный почтовый ящик, рассмотренный на уроке прошлого месяца. На данном уроке мы используем LDAP для простой аутентификации пользователей в ''Dovecot''.

Отдать должное мощи и гибкости LDAP в ограниченном пространстве статьи – примерно то же, что пытаться открыть мир классической музыки инопланетянину, промычав ему первые четыре ноты Пятой симфонии Бетховена; но мы постараемся.

===Что в имени тебе моем?===

Каталоги LDAP состоят из набора записей, упорядоченных в виде древовидной структуры. Каждая позиция в дереве идентифицируется так называемым «различимым именем» (distinguished name, dn). Например, dn может быть вида cn=cbrown,ou=users,dc=example,dc=com. Сравним его с другими видами синтаксиса: как имя файла в Linux, оно бы записалось в виде '''/com/example/users/cbrown''', а «полное доменное имя» в DNS выглядело бы '''cbrown.users.example.com'''.

Каждая запись в справочнике содержит информацию в виде набора пар «атрибут:значение». Какие именно атрибуты присутствуют, определяется так называемым классом объекта записи. Например, наша запись cn=cbrown,ou=users,dc=example,dc=com является объектом класса posixAccount. Описание, какой атрибут ассоциируется с каким классом, называется схемой, и она задается в файлах схем. Например, здесь описание класса posixAccount берется из файла '''/etc/openldap/schema/nis.schema''':
<code>
objectclass ( 1.3.6.1.1.1.2.0 NAME ‘posixAccount’
DESC ‘Abstraction of an account with POSIX attributes’
SUP top AUXILIARY
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )
</code>

Здесь важно отметить имя класса, список требуемых атрибутов (условие MUST) и список необязательных атрибутов (условие MAY). Если вы знакомы с файлом паролей Linux, вы заметите сходство атрибутов в объекте posixAccount и полях в '''/etc/passwd'''. (Учтите, однако, что атрибут LDAP uid – это то, что мы назвали бы именем учетной записи, а атрибут uidNumber – как раз то, что мы называем UID!) В терминах объектно-ориентированного программирования вы можете представить запись в файле схемы как описание класса, а запись в каталоге – как экземпляр класса. Также возможно наследование класса от «вышестоящего» класса (в объектно-ориентированном программировании он называется родительским или базовым). Строка SUP top AUXILIARY в предыдущем примере говорит нам, что вышестоящий класс, находящийся на вершине иерархии классов – это сам posixAccount, который не наследуется ни от чего. Но зайти дальше в аналогиях с ООП не получится: записи LDAP содержат только данные. Никакого запускаемого кода (который ОО-программисты назвали бы методом) с объектом не ассоциируется.

{{Врезка
|Заголовок=LDAP как он есть
|Содержание=На стороне сервера услуги предоставляет демон ''slapd''. В качестве своей базы данных он использует ''BDB'' (встраиваемая библиотека базы данных, первоначально разработанная UC Berkeley), а прелестно названный ''slurpd'' распространяет изменения на все копии справочника LDAP. На стороне клиента OpenLDAP предоставляет различные инструменты командной строки для манипулирования записями каталога, включающие ''ldapadd'', добавляющий информацию в каталог, и ''ldapsearch'', используемый для (угадали!) поиска по каталогу.
|Ширина=200px}}

Для просмотра человеком записи каталога LDAP отображаются в текстовом формате, называемом LDIF (формат обмена данными LDAP). Это формально заданный синтаксис, в соответствии с которым записи каталога представляются «вне» LDAP. Например, LDIF используется для предварительного создания записи при вводе ее в каталог, переноса данных из одного справочника в другой или просмотра содержимого справочника. В развитие нашего примера, LDIF-представление пользователя cn=cbrown,ou=users,dc=example,dc=com будет выглядеть так:
<code>
dn: cn=cbrown,ou=users,dc=example,dc=com
objectclass: posixAccount
objectclass: Account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
</code>
Мы сфокусировали здесь внимание на типе объекта '''posixAccount''', потому что он необходим нам для поддержки аутентификации.

===Станция «Рабочая»===

Хватит теории! Давайте же установим и сконфигурируем LDAP. Я использую сервер CentOS, как на прошлом уроке (CentOS – это эквивалент RHEL5), но все, что будет показано далее, легко применимо для других дистрибутивов RedHat или Fedora.

Мы будем использовать LDAP, который создан в Мичиганском университете (см. '''<nowiki>www.openldap.org</nowiki>'''). Установка его в CentOS проста:
<code>
# yum install openldap-clients openldap-servers
</code>

[[Изображение:LXF104_73_1.png|thumb|300px|Рис. 1. Компоненты OpenLDAP.]]

Рисунок 1 показывает основные компоненты OpenLDAP. Остальные компоненты клиента – модуль PAM LDAP ('''/lib/security/pam_ldap.so''') и библиотека разрешения LDAP ('''/lib/libnss_ldap.so'''), поддерживающая хранение стандартных учетных записей Linux в LDAP; мы займемся ими в следующем месяце.

Для запуска службы LDAP необходимо кое-что изменить в файле конфигурации slapd ('''/etc/openldap/slapd.conf'''). Вот строки, которые я поменял:
<code>
suffix = “dc=example,dc=com”
rootdn = “cn=admin,dc=example,dc=com”
rootpw = {SSHA}JM2o2+Z07QJ9CZxqD6CIL3aEe/zSzMmW
</code>

Первая задает «именованный контекст» нашей службы LDAP, то есть dn ее верхней записи. Здесь можно использовать все что угодно, но я основывался на доменном имени DNS ('''<nowiki>example.com</nowiki>''') настраиваемой машины: это стандартное решение. Вторая строка задает dn для учетной записи администратора сервера LDAP (он имеет полный контроль над содержимым каталога – это аналог root для Linux), а третья строка задает хэшированный пароль для этой учетной записи. Хэшированный пароль я сгенерировал с помощью '''slappasswd''':
<code>
# slappasswd
New password:
Re-enter new password:
{SSHA}JM2o2+Z07QJ9CZxqD6CIL3aEe/zSzMmW
</code>
а затем вырезал и вставил результат в файл. После этого я запустил службу:
<code>
# service ldap start
</code>

[[Изображение:LXF104_74_1.png|thumb|300px|Рис. 2. Простая структура каталога LDAP для поддержки аутентификации.]]

Далее нам надо заселить наш каталог записями, которые пригодятся для аутентификации. Чтобы сообразить, куда мы движемся, посмотрите на рисунок 2, там показана структура, которую нам надо создать.

Сперва нужно построить и добавить в справочник узлы верхнего уровня. Я решил создать учетные записи пользователей в узле ou=users,dc=example,dc=com. Слово ‘users’ не является ключевым, просто я взял такое имя. Я начал с создания файла LDIF, названного '''root.ldif''':
<code>
# Build the root node
dn: dc=example,dc=com
dc: example
objectClass: dcObject
objectClass: organizationalUnit
ou: example dot com
# Build the users ou
dn: ou=users,dc=example,dc=com
ou: users
objectClass:
organizationalUnit
</code>

Затем я добавил этот узел в каталог с помощью команды:
<code>
# ldapadd -D “cn=admin,dc=example,dc=com” -x -W -f root.ldif
</code>

Теперь добавим учетную запись пользователя. Выполняется это сходным образом: создается файл LDIF, а затем используется ''ldapadd'' для его добавления. Вот файл ('''newuser.ldif'''), который я создал:
<code>
dn: cn=cbrown,ou=users,dc=
example,dc=com
objectclass: posixAccount
objectclass: Account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
</code>

Затем я добавил этот узел в каталог:
<code>
# ldapadd -D “cn=admin,dc=example,dc=com” -x -W -f newuser.ldif
</code>

Так как записи LDAP нам понадобятся для аутентификации входа на сервер ''Dovecot'', я должен задать еще и пароль для пользователя, как показано здесь:
<code>
# ldappasswd -x -D “cn=admin,dc=example,dc=com” -W -S “cn=cbrown,ou=users,dc=example,dc=com”
New password:
Re-enter new password:
Enter LDAP Password:
Result: Success (0)
</code>

Теперь не мешает проверить, что пользователь был добавлен в каталог; давайте выполним поиск записи. Для этого можно употребить ''ldapsearch'':
<code>
# ldapsearch -x -b “ou=users,dc=example,dc=com” ‘(cn=cbrown)’
# cbrown, users, example.com
dn: cn=cbrown,ou=users,dc=example,dc=com
objectClass: posixAccount
objectClass: account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
userPassword:: e1NTSEF9cCt2Sml1enpCSTdOZjJUSU1ZcEp0c
U5LTnQzVHhjZzg=
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
</code>

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

Справочники создаются именно для поиска в них, поэтому стоит разобрать поиск LDAP более подробно. Команда ldapsearch немного похожа на SQL-запрос к реляционной базе данных. Попробуем обойтись без формального описания синтаксиса. Я придумал хороший пример: разбил команду на несколько строк и для удобства ссылок пронумеровал их. Первые шесть строк из представленных ниже – на самом деле одна команда (обратные слэши у них на конце указывают, что команда продолжается на следующей строке). Для запуска этой команды в терминале просто удалите номера и, естественно, слэши, набрав весь код в одну строку.
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
# ldapsearch -h mail.example.com \
-x -LLL -b “dc=example,dc=com” \
-D cn=admin,dc=example,dc=com -W
-s sub \
‘(|(uid=*brown)(gidNumber<=100))’ \
uid
Enter LDAP Password:
dn: cn=cbrown,ou=users,dc=example,dc=com
uid: cbrown
</source>

Теперь давайте вникать:
# Флаг -h используется для указания хоста, где запущен сервер LDAP. По умолчанию считается, что это localhost.
# Аргумент -x велит команде использовать простой метод аутентификации (не SASL), -LLL снижает число комментариев и прочих лишних слов в выводе, а флаг -b определяет, где мы хотим начать поиск в дереве справочника. В нашем случае мы начинаем с вершины дерева.
# Флаг -D задает dn пользователя, под которым мы хотим зайти (это пользователь, определенный параметром rootdn в '''slapd.conf'''), а -W велит команде запрашивать пароль.
# Здесь говорится, что поиск должен захватывать все ветви указанной базы, так что в данном случае мы запускаем поиск по всему справочнику.
# Пример фильтра поиска. Он говорит «покажите мне записи, где имя пользователя заканчивается на ‘brown’ или ID группы меньше или равно 100». Фильтры поиска – самая трудная часть синтаксиса для правильного написания, но (в определенном смысле) и самая важная.
# Эта строка содержит список имен атрибутов, которые мы хотим отобразить (в нашем случае просто имя пользователя). Если список пуст, ''ldapsearch'' покажет все атрибуты.
# Далее мы запрашиваем пароль для входа LDAP.

Наконец, строки 8 и 9 показывают вывод поиска.

Осилим еще один пример?
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
# ldapsearch -x \
-b “ou=users,dc=example,dc=com” \
-D cn=admin,dc=example,dc=com -W \
-s base ‘(objectClass=*)’
</source>

Рассмотрим строки 2 и 4. В строке 2 задан конкретный узел дерева справочника, откуда начнется поиск, а в строке 4 мы говорим LDAP не распространять поиск за пределы этого узла, а изучать только записи, заданные в строке 2. Фильтр поиска здесь фактически и не фильтр: он гласит «любая запись с атрибутом '''objectClass''', независимо от значения», а это вообще все записи. Итак, этот поиск выводит на дисплей содержимое определенного узла дерева.

[[Изображение:LXF104_75_1.png|thumb|Рис. 3. Просмотр справочника LDAP с помощью LAT. Снимок экрана показывает запись, добавленную нами для пользователя cbrown.]]
[[Изображение:LXF104_75_2.png|thumb|Рис. 4. Выполнение поиска в LDAP при помощи LAT.]]

Если вы предпочли бы использовать графические инструменты для поиска в вашем справочнике LDAP или добавления учетной записи пользователя, обратите внимание на Lat (''LDAP Administration Tool''). Это одно из новоиспеченных приложений, написанное на C# с использованием Mono и ''GTK#'', поэтому вам понадобятся установленные библиотеки Mono для его использования, но на моем клиенте с Ubuntu он установился и работал без каких-либо проблем. Рисунок 3 показывает этот инструмент в работе при обозревании иерархии LDAP, а на рисунке 4 показан пример поиска по UID 555.

===Аутентификация Dovecot===

Давайте закруглимся, применив каталог LDAP к полезному делу. Читатели предыдущего номера могут помнить, что мы оставили нашего героя (почтовый сервер ''Dovecot'') нуждающимся в аутентификации учетных записей POP3 базы данных пользователей, независимых от учетных записей пользователей в Linux.

Оказывается, ''Dovecot'' может использовать LDAP для аутентификации двумя способами: он может войти в LDAP с именем пользователя ‘rootdn’ и паролем ‘rootpw’, затем посмотреть имя пользователя и хэшированный пароль пользователя, который пытается аутентифицироваться, а может просто попробовать подключиться к серверу LDAP с именем и паролем того пользователя, кто пытается войти, и посмотреть, успешна ли попытка. Вход в LDAP известен как ‘связывание’, и эта техника называется аутентификационной связью. Этот метод мы и будем использовать.

Настройка ''Dovecot'' на использование LDAP для аутентификационной связи требует изменений в файле '''/etc/Dovecot.conf'''. Вот строки, которые я менял:
<code>
auth_verbose = yes
auth_debug = yes
passdb ldap {
args = /etc/dovecot-ldap.conf
}
userdb ldap {
args = /etc/dovecot-ldap.conf
}
</code>

Первые две строки включают вывод отладочных сообщений. На рабочем сервере они вам не понадобятся, но мне файл журнала ('''/var/log/maillog''') очень помог при отладке конфигурации ''Dovecot''. Две остальные строфы файла указывают, что мы будем использовать LDAP и как базу данных паролей, и как базу данных пользователей, и задают место размещения файла конфигурации LDAP для ''Dovecot''.

Дико извиняюсь, но есть еще один файл конфигурации! Для его создания я начал с копирования примера конфигурации LDAP из дистрибутива ''Dovecot'' на место:
<code>
# cp /usr/share/doc/dovecot-1.0/examples/dovecot-ldap.conf /etc
</code>

Затем я сделал следующие изменения в '''/etc/Dovecot-ldap.conf''' (номера строк опять-таки нужны только для ссылок на них в тексте):
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
hosts = localhost
dn = cn=admin,dc=example,dc=com
dnpass = adminpw
auth_bind = yes
auth_bind_userdn = cn=%u,ou=users,dc=example,dc=com
base = ou=users,dc=example,dc=com
</source>

Строка 1 задает имя сервера, на котором запущен LDAP. Строка 2 определяет dn учетной записи, которое ''Dovecot'' будет использовать для входа в LDAP, а строка 3 задает пароль для этой учетной записи. (Вообще-то было бы лучше не использовать для этого учетную запись с полными правами rootdn, а создать особую учетную запись для ''Dovecot''). Строка 4 говорит, что будет использоваться аутентификационная связь, а строка 5 задает dn пользователя, которого мы пробуем аутентифицировать как такового (над этим мне пришлось поломать голову!). В файле конфигурации ''Dovecot'', %u ссылается на имя пользователя, которое использует MUA (почтовый агент) пользователя, чтобы войти. Строка 6 определяет узел в дереве справочника LDAP, под которым находятся учетные записи пользователей.

Угнездив на месте эти строки, я смог подсоединиться к службе POP3 ''Dovecot'' с учетной записью cbrown и забрать почту.

Если у вас что-то не заработало, загляните в файл журнала, обычно '''/var/log/maillog'''. Сообщения, оставляемые ''Dovecot'', очень подробны и говорят сами за себя. '''LXF'''

----

===Что еще почитать? (врезка)===

# По LDAP существует множество книг. Самыми полезными мне показались две: ''LDAP System Administration by Gerald Carter'' (O’Reilly, 1-56592-491-6), и ''Understanding and Deploying LDAP Directory Services by Howes, Smith and Good'' (Addison Wesley, 0672323168). Последняя более академическая (и тяжелая!)
# Официальная документация ''Dovecot'' доступна по адресу http://wiki.dovecot.org. В частности, статья http://wiki.dovecot.org/AuthDatabase/LDAP показывает, как сделать аутентификацию LDAP в ''Dovecot''. Кроме того, '''slapd.conf''', '''ldap.conf''' и все инструменты командной строки имеют прекрасные man-страницы.
# Основную информацию по сборке почтового сервера можно найти по адресам http://freshrpms.net/docs/mail-server и http://wanderingbarque.com/howtos/mailserver/mailserver.html. (Это очень подробное пошаговое руководство, написанное Питером Лэйси [Peter Lacey]; оно охватывает интеграцию ''Postfix'', ''Dovecot'', OpenLDAP, Jamm, ''Cyrus-SASL'' и ''SquirrelMail'', и основано на RHEL 3).

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

LXF104:Hardcore Linux

2009-03-30T21:31:59Z

Kipruss:

==LDAP: Защитим вход в Dovecot==

Позволять кому попало использовать наш почтовый сервер без аутентификации пользователя – сущее безумие. '''Д-р Крис Браун''' наведет порядок с помощью LDAP…

Сегодняшнее утреннее чтение начнем с Книги Тукса, главы пятой, с самого первого стиха.

# В начале был файл с паролями, и файл с паролями был Unix. Через него все пользователи могли получить доступ; и без него никто из входящих не мог пройти. И сисадмины сказали, что это хорошо.
# Но вот настала Великая Сеть, и возроптали сисадмины, говоря: «Файл с паролями свое отслужил, требует он дублирования данных и затрудняет масштабирование на большую сеть». Тогда Sun сказал: «Не бойтесь, ибо мы принесли вам Желтые Страницы, которые централизуют данные пользователей».
# Но затем явились четыре мудреца из Beetea и сказали: «Не смеете вы взять имя Желтые Страницы, оно наша собственность и наша торговая марка». И ответил им Sun: «Пускай то, что раньше звалось Желтыми Страницами, отныне зовется NIS». И сисадмины сказали, что это хорошо.
# Но прошло время, и снова разочаровались сисадмины, и возроптали они во второй раз: «Истинно, NIS имеет плоское пространство имен и не имеет контроля доступа».
# И снова сказал Sun: «Не бойтесь, ибо мы принесли вам NIS+, иерархическое пространство имен в нем и контроль доступа в избытке». Но сисадмины возроптали в третий раз, по своему неразумию.
# И создан был консорциум, и родил он спецификацию X500. И X500 родил DAP, DAP родил DIXIE, а DIXIE родил LDAP. И увидели сисадмины, что это хорошо. И это конец нашего утреннего чтения.

Истинно говорю вам, в этот день, на этом уроке мы создадим службу каталогов LDAP и используем ее для аутентификации в агенте доступа к почте POP/IMAP ''Dovecot''.

===Азбука LDAP===

LDAP (облегченный протокол доступа к каталогам) – это служба каталогов, которую в принципе можно использовать для хранения любых данных, хотя на практике она чаще используется для хранения информации о пользователях, в частности, аутентификационных данных. Благодаря наличию открытой реализации (OpenLDAP) LDAP стал популярен в мире Linux как замена служб типа NIS или NIS+; в мире Windows она тоже хорошо известна – как основа ''Microsoft Active Directory''.

Служба каталогов немного похожа на базу данных: обе могут хранить большие объемы информации и эффективно выполнять в ней поиск. Однако, служба каталогов оптимизирована для чтения (поиска); отношение времени записи к времени чтения обычно велико, и это не годится для ситуаций, когда требуется частое обновление данных. Для справочника естественно, что чтение выполняется в 10000 раз чаще, чем запись. Реляционные базы данных более симметричны по скорости чтения и записи. Кроме того, каталоги обычно не поддерживают транзакции, откаты и реляционные операции, типа join, которые имеют важное значение для реляционных баз данных.

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

Вы можете использовать LDAP в разных целях: например, для аутентификации постоянных пользователей Linux; или для реализации отображений ''Postfix'', таких как виртуальный почтовый ящик, рассмотренный на уроке прошлого месяца. На данном уроке мы используем LDAP для простой аутентификации пользователей в ''Dovecot''.

Отдать должное мощи и гибкости LDAP в ограниченном пространстве статьи – примерно то же, что пытаться открыть мир классической музыки инопланетянину, промычав ему первые четыре ноты Пятой симфонии Бетховена; но мы постараемся.

===Что в имени тебе моем?===

Каталоги LDAP состоят из набора записей, упорядоченных в виде древовидной структуры. Каждая позиция в дереве идентифицируется так называемым «различимым именем» (distinguished name, dn). Например, dn может быть вида cn=cbrown,ou=users,dc=example,dc=com. Сравним его с другими видами синтаксиса: как имя файла в Linux, оно бы записалось в виде '''/com/example/users/cbrown''', а «полное доменное имя» в DNS выглядело бы '''cbrown.users.example.com'''.

Каждая запись в справочнике содержит информацию в виде набора пар «атрибут:значение». Какие именно атрибуты присутствуют, определяется так называемым классом объекта записи. Например, наша запись cn=cbrown,ou=users,dc=example,dc=com является объектом класса posixAccount. Описание, какой атрибут ассоциируется с каким классом, называется схемой, и она задается в файлах схем. Например, здесь описание класса posixAccount берется из файла '''/etc/openldap/schema/nis.schema''':
<code>
objectclass ( 1.3.6.1.1.1.2.0 NAME ‘posixAccount’
DESC ‘Abstraction of an account with POSIX attributes’
SUP top AUXILIARY
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )
</code>

Здесь важно отметить имя класса, список требуемых атрибутов (условие MUST) и список необязательных атрибутов (условие MAY). Если вы знакомы с файлом паролей Linux, вы заметите сходство атрибутов в объекте posixAccount и полях в '''/etc/passwd'''. (Учтите, однако, что атрибут LDAP uid – это то, что мы назвали бы именем учетной записи, а атрибут uidNumber – как раз то, что мы называем UID!) В терминах объектно-ориентированного программирования вы можете представить запись в файле схемы как описание класса, а запись в каталоге – как экземпляр класса. Также возможно наследование класса от «вышестоящего» класса (в объектно-ориентированном программировании он называется родительским или базовым). Строка SUP top AUXILIARY в предыдущем примере говорит нам, что вышестоящий класс, находящийся на вершине иерархии классов – это сам posixAccount, который не наследуется ни от чего. Но зайти дальше в аналогиях с ООП не получится: записи LDAP содержат только данные. Никакого запускаемого кода (который ОО-программисты назвали бы методом) с объектом не ассоциируется.

{{Врезка
|Заголовок=LDAP как он есть
|Содержание=На стороне сервера услуги предоставляет демон ''slapd''. В качестве своей базы данных он использует ''BDB'' (встраиваемая библиотека базы данных, первоначально разработанная UC Berkeley), а прелестно названный ''slurpd'' распространяет изменения на все копии справочника LDAP. На стороне клиента OpenLDAP предоставляет различные инструменты командной строки для манипулирования записями каталога, включающие ''ldapadd'', добавляющий информацию в каталог, и ''ldapsearch'', используемый для (угадали!) поиска по каталогу.
|Ширина=200px}}

Для просмотра человеком записи каталога LDAP отображаются в текстовом формате, называемом LDIF (формат обмена данными LDAP). Это формально заданный синтаксис, в соответствии с которым записи каталога представляются «вне» LDAP. Например, LDIF используется для предварительного создания записи при вводе ее в каталог, переноса данных из одного справочника в другой или просмотра содержимого справочника. В развитие нашего примера, LDIF-представление пользователя cn=cbrown,ou=users,dc=example,dc=com будет выглядеть так:
<code>
dn: cn=cbrown,ou=users,dc=example,dc=com
objectclass: posixAccount
objectclass: Account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
</code>
Мы сфокусировали здесь внимание на типе объекта '''posixAccount''', потому что он необходим нам для поддержки аутентификации.

===Станция «Рабочая»===

Хватит теории! Давайте же установим и сконфигурируем LDAP. Я использую сервер CentOS, как на прошлом уроке (CentOS – это эквивалент RHEL5), но все, что будет показано далее, легко применимо для других дистрибутивов RedHat или Fedora.

Мы будем использовать LDAP, который создан в Мичиганском университете (см. '''<nowiki>www.openldap.org</nowiki>'''). Установка его в CentOS проста:
<code>
# yum install openldap-clients openldap-servers
</code>

[[Изображение:LXF104_73_1.png|thumb|300px|Рис. 1. Компоненты OpenLDAP.]]

Рисунок 1 показывает основные компоненты OpenLDAP. Остальные компоненты клиента – модуль PAM LDAP ('''/lib/security/pam_ldap.so''') и библиотека разрешения LDAP ('''/lib/libnss_ldap.so'''), поддерживающая хранение стандартных учетных записей Linux в LDAP; мы займемся ими в следующем месяце.

Для запуска службы LDAP необходимо кое-что изменить в файле конфигурации slapd ('''/etc/openldap/slapd.conf'''). Вот строки, которые я поменял:
<code>
suffix = “dc=example,dc=com”
rootdn = “cn=admin,dc=example,dc=com”
rootpw = {SSHA}JM2o2+Z07QJ9CZxqD6CIL3aEe/zSzMmW
</code>

Первая задает «именованный контекст» нашей службы LDAP, то есть dn ее верхней записи. Здесь можно использовать все что угодно, но я основывался на доменном имени DNS ('''<nowiki>example.com</nowiki>''') настраиваемой машины: это стандартное решение. Вторая строка задает dn для учетной записи администратора сервера LDAP (он имеет полный контроль над содержимым каталога – это аналог root для Linux), а третья строка задает хэшированный пароль для этой учетной записи. Хэшированный пароль я сгенерировал с помощью '''slappasswd''':
<code>
# slappasswd
New password:
Re-enter new password:
{SSHA}JM2o2+Z07QJ9CZxqD6CIL3aEe/zSzMmW
</code>
а затем вырезал и вставил результат в файл. После этого я запустил службу:
<code>
# service ldap start
</code>

[[Изображение:LXF104_74_1.png|thumb|300px|Рис. 2. Простая структура каталога LDAP для поддержки аутентификации.]]

Далее нам надо заселить наш каталог записями, которые пригодятся для аутентификации. Чтобы сообразить, куда мы движемся, посмотрите на рисунок 2, там показана структура, которую нам надо создать.

Сперва нужно построить и добавить в справочник узлы верхнего уровня. Я решил создать учетные записи пользователей в узле ou=users,dc=example,dc=com. Слово ‘users’ не является ключевым, просто я взял такое имя. Я начал с создания файла LDIF, названного '''root.ldif''':
<code>
# Build the root node
dn: dc=example,dc=com
dc: example
objectClass: dcObject
objectClass: organizationalUnit
ou: example dot com
# Build the users ou
dn: ou=users,dc=example,dc=com
ou: users
objectClass:
organizationalUnit
</code>

Затем я добавил этот узел в каталог с помощью команды:
<code>
# ldapadd -D “cn=admin,dc=example,dc=com” -x -W -f root.ldif
</code>

Теперь добавим учетную запись пользователя. Выполняется это сходным образом: создается файл LDIF, а затем используется ''ldapadd'' для его добавления. Вот файл ('''newuser.ldif'''), который я создал:
<code>
dn: cn=cbrown,ou=users,dc=
example,dc=com
objectclass: posixAccount
objectclass: Account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
</code>

Затем я добавил этот узел в каталог:
<code>
# ldapadd -D “cn=admin,dc=example,dc=com” -x -W -f newuser.ldif
</code>

Так как записи LDAP нам понадобятся для аутентификации входа на сервер ''Dovecot'', я должен задать еще и пароль для пользователя, как показано здесь:
<code>
# ldappasswd -x -D “cn=admin,dc=example,dc=com” -W -S “cn=cbrown,ou=users,dc=example,dc=com”
New password:
Re-enter new password:
Enter LDAP Password:
Result: Success (0)
</code>

Теперь не мешает проверить, что пользователь был добавлен в каталог; давайте выполним поиск записи. Для этого можно употребить ''ldapsearch'':
<code>
# ldapsearch -x -b “ou=users,dc=example,dc=com” ‘(cn=cbrown)’
# cbrown, users, example.com
dn: cn=cbrown,ou=users,dc=example,dc=com
objectClass: posixAccount
objectClass: account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
userPassword:: e1NTSEF9cCt2Sml1enpCSTdOZjJUSU1ZcEp0c
U5LTnQzVHhjZzg=
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
</code>

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

Справочники создаются именно для поиска в них, поэтому стоит разобрать поиск LDAP более подробно. Команда ldapsearch немного похожа на SQL-запрос к реляционной базе данных. Попробуем обойтись без формального описания синтаксиса. Я придумал хороший пример: разбил команду на несколько строк и для удобства ссылок пронумеровал их. Первые шесть строк из представленных ниже – на самом деле одна команда (обратные слэши у них на конце указывают, что команда продолжается на следующей строке). Для запуска этой команды в терминале просто удалите номера и, естественно, слэши, набрав весь код в одну строку.
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
# ldapsearch -h mail.example.com \
-x -LLL -b “dc=example,dc=com” \
-D cn=admin,dc=example,dc=com -W
-s sub \
‘(|(uid=*brown)(gidNumber<=100))’ \
uid
Enter LDAP Password:
dn: cn=cbrown,ou=users,dc=example,dc=com
uid: cbrown
</source>

Теперь давайте вникать:
# Флаг -h используется для указания хоста, где запущен сервер LDAP. По умолчанию считается, что это localhost.
# Аргумент -x велит команде использовать простой метод аутентификации (не SASL), -LLL снижает число комментариев и прочих лишних слов в выводе, а флаг -b определяет, где мы хотим начать поиск в дереве справочника. В нашем случае мы начинаем с вершины дерева.
# Флаг -D задает dn пользователя, под которым мы хотим зайти (это пользователь, определенный параметром rootdn в '''slapd.conf'''), а -W велит команде запрашивать пароль.
# Здесь говорится, что поиск должен захватывать все ветви указанной базы, так что в данном случае мы запускаем поиск по всему справочнику.
# Пример фильтра поиска. Он говорит «покажите мне записи, где имя пользователя заканчивается на ‘brown’ или ID группы меньше или равно 100». Фильтры поиска – самая трудная часть синтаксиса для правильного написания, но (в определенном смысле) и самая важная.
# Эта строка содержит список имен атрибутов, которые мы хотим отобразить (в нашем случае просто имя пользователя). Если список пуст, ''ldapsearch'' покажет все атрибуты.
# Далее мы запрашиваем пароль для входа LDAP.

Наконец, строки 8 и 9 показывают вывод поиска.

Осилим еще один пример?
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
# ldapsearch -x \
-b “ou=users,dc=example,dc=com” \
-D cn=admin,dc=example,dc=com -W \
-s base ‘(objectClass=*)’
</source>

Рассмотрим строки 2 и 4. В строке 2 задан конкретный узел дерева справочника, откуда начнется поиск, а в строке 4 мы говорим LDAP не распространять поиск за пределы этого узла, а изучать только записи, заданные в строке 2. Фильтр поиска здесь фактически и не фильтр: он гласит «любая запись с атрибутом '''objectClass''', независимо от значения», а это вообще все записи. Итак, этот поиск выводит на дисплей содержимое определенного узла дерева.

[[Изображение:LXF104_75_1.png|Thumb|Рис. 3. Просмотр справочника LDAP с помощью LAT. Снимок экрана показывает запись, добавленную нами для пользователя cbrown.]]
[[Изображение:LXF104_75_2.png|Thumb|Рис. 4. Выполнение поиска в LDAP при помощи LAT.]]

Если вы предпочли бы использовать графические инструменты для поиска в вашем справочнике LDAP или добавления учетной записи пользователя, обратите внимание на Lat (''LDAP Administration Tool''). Это одно из новоиспеченных приложений, написанное на C# с использованием Mono и ''GTK#'', поэтому вам понадобятся установленные библиотеки Mono для его использования, но на моем клиенте с Ubuntu он установился и работал без каких-либо проблем. Рисунок 3 показывает этот инструмент в работе при обозревании иерархии LDAP, а на рисунке 4 показан пример поиска по UID 555.

===Аутентификация Dovecot===

Давайте закруглимся, применив каталог LDAP к полезному делу. Читатели предыдущего номера могут помнить, что мы оставили нашего героя (почтовый сервер ''Dovecot'') нуждающимся в аутентификации учетных записей POP3 базы данных пользователей, независимых от учетных записей пользователей в Linux.

Оказывается, ''Dovecot'' может использовать LDAP для аутентификации двумя способами: он может войти в LDAP с именем пользователя ‘rootdn’ и паролем ‘rootpw’, затем посмотреть имя пользователя и хэшированный пароль пользователя, который пытается аутентифицироваться, а может просто попробовать подключиться к серверу LDAP с именем и паролем того пользователя, кто пытается войти, и посмотреть, успешна ли попытка. Вход в LDAP известен как ‘связывание’, и эта техника называется аутентификационной связью. Этот метод мы и будем использовать.

Настройка ''Dovecot'' на использование LDAP для аутентификационной связи требует изменений в файле '''/etc/Dovecot.conf'''. Вот строки, которые я менял:
<code>
auth_verbose = yes
auth_debug = yes
passdb ldap {
args = /etc/dovecot-ldap.conf
}
userdb ldap {
args = /etc/dovecot-ldap.conf
}
</code>

Первые две строки включают вывод отладочных сообщений. На рабочем сервере они вам не понадобятся, но мне файл журнала ('''/var/log/maillog''') очень помог при отладке конфигурации ''Dovecot''. Две остальные строфы файла указывают, что мы будем использовать LDAP и как базу данных паролей, и как базу данных пользователей, и задают место размещения файла конфигурации LDAP для ''Dovecot''.

Дико извиняюсь, но есть еще один файл конфигурации! Для его создания я начал с копирования примера конфигурации LDAP из дистрибутива ''Dovecot'' на место:
<code>
# cp /usr/share/doc/dovecot-1.0/examples/dovecot-ldap.conf /etc
</code>

Затем я сделал следующие изменения в '''/etc/Dovecot-ldap.conf''' (номера строк опять-таки нужны только для ссылок на них в тексте):
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
hosts = localhost
dn = cn=admin,dc=example,dc=com
dnpass = adminpw
auth_bind = yes
auth_bind_userdn = cn=%u,ou=users,dc=example,dc=com
base = ou=users,dc=example,dc=com
</source>

Строка 1 задает имя сервера, на котором запущен LDAP. Строка 2 определяет dn учетной записи, которое ''Dovecot'' будет использовать для входа в LDAP, а строка 3 задает пароль для этой учетной записи. (Вообще-то было бы лучше не использовать для этого учетную запись с полными правами rootdn, а создать особую учетную запись для ''Dovecot''). Строка 4 говорит, что будет использоваться аутентификационная связь, а строка 5 задает dn пользователя, которого мы пробуем аутентифицировать как такового (над этим мне пришлось поломать голову!). В файле конфигурации ''Dovecot'', %u ссылается на имя пользователя, которое использует MUA (почтовый агент) пользователя, чтобы войти. Строка 6 определяет узел в дереве справочника LDAP, под которым находятся учетные записи пользователей.

Угнездив на месте эти строки, я смог подсоединиться к службе POP3 ''Dovecot'' с учетной записью cbrown и забрать почту.

Если у вас что-то не заработало, загляните в файл журнала, обычно '''/var/log/maillog'''. Сообщения, оставляемые ''Dovecot'', очень подробны и говорят сами за себя. '''LXF'''

----

===Что еще почитать? (врезка)===

# По LDAP существует множество книг. Самыми полезными мне показались две: ''LDAP System Administration by Gerald Carter'' (O’Reilly, 1-56592-491-6), и ''Understanding and Deploying LDAP Directory Services by Howes, Smith and Good'' (Addison Wesley, 0672323168). Последняя более академическая (и тяжелая!)
# Официальная документация ''Dovecot'' доступна по адресу http://wiki.dovecot.org. В частности, статья http://wiki.dovecot.org/AuthDatabase/LDAP показывает, как сделать аутентификацию LDAP в ''Dovecot''. Кроме того, '''slapd.conf''', '''ldap.conf''' и все инструменты командной строки имеют прекрасные man-страницы.
# Основную информацию по сборке почтового сервера можно найти по адресам http://freshrpms.net/docs/mail-server и http://wanderingbarque.com/howtos/mailserver/mailserver.html. (Это очень подробное пошаговое руководство, написанное Питером Лэйси [Peter Lacey]; оно охватывает интеграцию ''Postfix'', ''Dovecot'', OpenLDAP, Jamm, ''Cyrus-SASL'' и ''SquirrelMail'', и основано на RHEL 3).

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

LXF104:Hardcore Linux

2009-03-30T21:28:40Z

Kipruss: викификация

==LDAP: Защитим вход в Dovecot==

Позволять кому попало использовать наш почтовый сервер без аутентификации пользователя – сущее безумие. '''Д-р Крис Браун''' наведет порядок с помощью LDAP…

Сегодняшнее утреннее чтение начнем с Книги Тукса, главы пятой, с самого первого стиха.

# В начале был файл с паролями, и файл с паролями был Unix. Через него все пользователи могли получить доступ; и без него никто из входящих не мог пройти. И сисадмины сказали, что это хорошо.
# Но вот настала Великая Сеть, и возроптали сисадмины, говоря: «Файл с паролями свое отслужил, требует он дублирования данных и затрудняет масштабирование на большую сеть». Тогда Sun сказал: «Не бойтесь, ибо мы принесли вам Желтые Страницы, которые централизуют данные пользователей».
# Но затем явились четыре мудреца из Beetea и сказали: «Не смеете вы взять имя Желтые Страницы, оно наша собственность и наша торговая марка». И ответил им Sun: «Пускай то, что раньше звалось Желтыми Страницами, отныне зовется NIS». И сисадмины сказали, что это хорошо.
# Но прошло время, и снова разочаровались сисадмины, и возроптали они во второй раз: «Истинно, NIS имеет плоское пространство имен и не имеет контроля доступа».
# И снова сказал Sun: «Не бойтесь, ибо мы принесли вам NIS+, иерархическое пространство имен в нем и контроль доступа в избытке». Но сисадмины возроптали в третий раз, по своему неразумию.
# И создан был консорциум, и родил он спецификацию X500. И X500 родил DAP, DAP родил DIXIE, а DIXIE родил LDAP. И увидели сисадмины, что это хорошо. И это конец нашего утреннего чтения.

Истинно говорю вам, в этот день, на этом уроке мы создадим службу каталогов LDAP и используем ее для аутентификации в агенте доступа к почте POP/IMAP ''Dovecot''.

===Азбука LDAP===

LDAP (облегченный протокол доступа к каталогам) – это служба каталогов, которую в принципе можно использовать для хранения любых данных, хотя на практике она чаще используется для хранения информации о пользователях, в частности, аутентификационных данных. Благодаря наличию открытой реализации (OpenLDAP) LDAP стал популярен в мире Linux как замена служб типа NIS или NIS+; в мире Windows она тоже хорошо известна – как основа ''Microsoft Active Directory''.

Служба каталогов немного похожа на базу данных: обе могут хранить большие объемы информации и эффективно выполнять в ней поиск. Однако, служба каталогов оптимизирована для чтения (поиска); отношение времени записи к времени чтения обычно велико, и это не годится для ситуаций, когда требуется частое обновление данных. Для справочника естественно, что чтение выполняется в 10000 раз чаще, чем запись. Реляционные базы данных более симметричны по скорости чтения и записи. Кроме того, каталоги обычно не поддерживают транзакции, откаты и реляционные операции, типа join, которые имеют важное значение для реляционных баз данных.

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

Вы можете использовать LDAP в разных целях: например, для аутентификации постоянных пользователей Linux; или для реализации отображений ''Postfix'', таких как виртуальный почтовый ящик, рассмотренный на уроке прошлого месяца. На данном уроке мы используем LDAP для простой аутентификации пользователей в ''Dovecot''.

Отдать должное мощи и гибкости LDAP в ограниченном пространстве статьи – примерно то же, что пытаться открыть мир классической музыки инопланетянину, промычав ему первые четыре ноты Пятой симфонии Бетховена; но мы постараемся.

===Что в имени тебе моем?===

Каталоги LDAP состоят из набора записей, упорядоченных в виде древовидной структуры. Каждая позиция в дереве идентифицируется так называемым «различимым именем» (distinguished name, dn). Например, dn может быть вида cn=cbrown,ou=users,dc=example,dc=com. Сравним его с другими видами синтаксиса: как имя файла в Linux, оно бы записалось в виде '''/com/example/users/cbrown''', а «полное доменное имя» в DNS выглядело бы '''cbrown.users.example.com'''.

Каждая запись в справочнике содержит информацию в виде набора пар «атрибут:значение». Какие именно атрибуты присутствуют, определяется так называемым классом объекта записи. Например, наша запись cn=cbrown,ou=users,dc=example,dc=com является объектом класса posixAccount. Описание, какой атрибут ассоциируется с каким классом, называется схемой, и она задается в файлах схем. Например, здесь описание класса posixAccount берется из файла '''/etc/openldap/schema/nis.schema''':
<code>
objectclass ( 1.3.6.1.1.1.2.0 NAME ‘posixAccount’
DESC ‘Abstraction of an account with POSIX attributes’
SUP top AUXILIARY
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )
</code>

Здесь важно отметить имя класса, список требуемых атрибутов (условие MUST) и список необязательных атрибутов (условие MAY). Если вы знакомы с файлом паролей Linux, вы заметите сходство атрибутов в объекте posixAccount и полях в '''/etc/passwd'''. (Учтите, однако, что атрибут LDAP uid – это то, что мы назвали бы именем учетной записи, а атрибут uidNumber – как раз то, что мы называем UID!) В терминах объектно-ориентированного программирования вы можете представить запись в файле схемы как описание класса, а запись в каталоге – как экземпляр класса. Также возможно наследование класса от «вышестоящего» класса (в объектно-ориентированном программировании он называется родительским или базовым). Строка SUP top AUXILIARY в предыдущем примере говорит нам, что вышестоящий класс, находящийся на вершине иерархии классов – это сам posixAccount, который не наследуется ни от чего. Но зайти дальше в аналогиях с ООП не получится: записи LDAP содержат только данные. Никакого запускаемого кода (который ОО-программисты назвали бы методом) с объектом не ассоциируется.

{{Врезка
|Заголовок=LDAP как он есть
|Содержание=На стороне сервера услуги предоставляет демон ''slapd''. В качестве своей базы данных он использует ''BDB'' (встраиваемая библиотека базы данных, первоначально разработанная UC Berkeley), а прелестно названный ''slurpd'' распространяет изменения на все копии справочника LDAP. На стороне клиента OpenLDAP предоставляет различные инструменты командной строки для манипулирования записями каталога, включающие ''ldapadd'', добавляющий информацию в каталог, и ''ldapsearch'', используемый для (угадали!) поиска по каталогу.
|Ширина=200px}}

Для просмотра человеком записи каталога LDAP отображаются в текстовом формате, называемом LDIF (формат обмена данными LDAP). Это формально заданный синтаксис, в соответствии с которым записи каталога представляются «вне» LDAP. Например, LDIF используется для предварительного создания записи при вводе ее в каталог, переноса данных из одного справочника в другой или просмотра содержимого справочника. В развитие нашего примера, LDIF-представление пользователя cn=cbrown,ou=users,dc=example,dc=com будет выглядеть так:
<code>
dn: cn=cbrown,ou=users,dc=example,dc=com
objectclass: posixAccount
objectclass: Account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
</code>
Мы сфокусировали здесь внимание на типе объекта '''posixAccount''', потому что он необходим нам для поддержки аутентификации.

===Станция «Рабочая»===

Хватит теории! Давайте же установим и сконфигурируем LDAP. Я использую сервер CentOS, как на прошлом уроке (CentOS – это эквивалент RHEL5), но все, что будет показано далее, легко применимо для других дистрибутивов RedHat или Fedora.

Мы будем использовать LDAP, который создан в Мичиганском университете (см. '''<nowiki>www.openldap.org</nowiki>'''). Установка его в CentOS проста:
<code>
# yum install openldap-clients openldap-servers
</code>

[[Изображение:LXF104_73_1.png|thumb|300px|Рис. 1. Компоненты OpenLDAP.]]

Рисунок 1 показывает основные компоненты OpenLDAP. Остальные компоненты клиента – модуль PAM LDAP ('''/lib/security/pam_ldap.so''') и библиотека разрешения LDAP ('''/lib/libnss_ldap.so'''), поддерживающая хранение стандартных учетных записей Linux в LDAP; мы займемся ими в следующем месяце.

Для запуска службы LDAP необходимо кое-что изменить в файле конфигурации slapd ('''/etc/openldap/slapd.conf'''). Вот строки, которые я поменял:
<code>
suffix = “dc=example,dc=com”
rootdn = “cn=admin,dc=example,dc=com”
rootpw = {SSHA}JM2o2+Z07QJ9CZxqD6CIL3aEe/zSzMmW
</code>

Первая задает «именованный контекст» нашей службы LDAP, то есть dn ее верхней записи. Здесь можно использовать все что угодно, но я основывался на доменном имени DNS ('''<nowiki>example.com</nowiki>''') настраиваемой машины: это стандартное решение. Вторая строка задает dn для учетной записи администратора сервера LDAP (он имеет полный контроль над содержимым каталога – это аналог root для Linux), а третья строка задает хэшированный пароль для этой учетной записи. Хэшированный пароль я сгенерировал с помощью '''slappasswd''':
<code>
# slappasswd
New password:
Re-enter new password:
{SSHA}JM2o2+Z07QJ9CZxqD6CIL3aEe/zSzMmW
</code>
а затем вырезал и вставил результат в файл. После этого я запустил службу:
<code>
# service ldap start
</code>

[[Изображение:LXF104_74_1.png|thumb|300px|Рис. 2. Простая структура каталога LDAP для поддержки аутентификации.]]

Далее нам надо заселить наш каталог записями, которые пригодятся для аутентификации. Чтобы сообразить, куда мы движемся, посмотрите на рисунок 2, там показана структура, которую нам надо создать.

Сперва нужно построить и добавить в справочник узлы верхнего уровня. Я решил создать учетные записи пользователей в узле ou=users,dc=example,dc=com. Слово ‘users’ не является ключевым, просто я взял такое имя. Я начал с создания файла LDIF, названного '''root.ldif''':
<code>
# Build the root node
dn: dc=example,dc=com
dc: example
objectClass: dcObject
objectClass: organizationalUnit
ou: example dot com
# Build the users ou
dn: ou=users,dc=example,dc=com
ou: users
objectClass:
organizationalUnit
</code>

Затем я добавил этот узел в каталог с помощью команды:
<code>
# ldapadd -D “cn=admin,dc=example,dc=com” -x -W -f root.ldif
</code>

Теперь добавим учетную запись пользователя. Выполняется это сходным образом: создается файл LDIF, а затем используется ''ldapadd'' для его добавления. Вот файл ('''newuser.ldif'''), который я создал:
<code>
dn: cn=cbrown,ou=users,dc=
example,dc=com
objectclass: posixAccount
objectclass: Account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
</code>

Затем я добавил этот узел в каталог:
<code>
# ldapadd -D “cn=admin,dc=example,dc=com” -x -W -f newuser.ldif
</code>

Так как записи LDAP нам понадобятся для аутентификации входа на сервер ''Dovecot'', я должен задать еще и пароль для пользователя, как показано здесь:
<code>
# ldappasswd -x -D “cn=admin,dc=example,dc=com” -W -S “cn=cbrown,ou=users,dc=example,dc=com”
New password:
Re-enter new password:
Enter LDAP Password:
Result: Success (0)
</code>

Теперь не мешает проверить, что пользователь был добавлен в каталог; давайте выполним поиск записи. Для этого можно употребить ''ldapsearch'':
<code>
# ldapsearch -x -b “ou=users,dc=example,dc=com” ‘(cn=cbrown)’
# cbrown, users, example.com
dn: cn=cbrown,ou=users,dc=example,dc=com
objectClass: posixAccount
objectClass: account
cn: cbrown
uid: cbrown
uidNumber: 555
gidNumber: 555
homeDirectory: /home/cbrown
userPassword:: e1NTSEF9cCt2Sml1enpCSTdOZjJUSU1ZcEp0c
U5LTnQzVHhjZzg=
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
</code>

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

Справочники создаются именно для поиска в них, поэтому стоит разобрать поиск LDAP более подробно. Команда ldapsearch немного похожа на SQL-запрос к реляционной базе данных. Попробуем обойтись без формального описания синтаксиса. Я придумал хороший пример: разбил команду на несколько строк и для удобства ссылок пронумеровал их. Первые шесть строк из представленных ниже – на самом деле одна команда (обратные слэши у них на конце указывают, что команда продолжается на следующей строке). Для запуска этой команды в терминале просто удалите номера и, естественно, слэши, набрав весь код в одну строку.
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
# ldapsearch -h mail.example.com \
-x -LLL -b “dc=example,dc=com” \
-D cn=admin,dc=example,dc=com -W
-s sub \
‘(|(uid=*brown)(gidNumber<=100))’ \
uid
Enter LDAP Password:
dn: cn=cbrown,ou=users,dc=example,dc=com
uid: cbrown
</source>

Теперь давайте вникать:
# Флаг -h используется для указания хоста, где запущен сервер LDAP. По умолчанию считается, что это localhost.
# Аргумент -x велит команде использовать простой метод аутентификации (не SASL), -LLL снижает число комментариев и прочих лишних слов в выводе, а флаг -b определяет, где мы хотим начать поиск в дереве справочника. В нашем случае мы начинаем с вершины дерева.
# Флаг -D задает dn пользователя, под которым мы хотим зайти (это пользователь, определенный параметром rootdn в '''slapd.conf'''), а -W велит команде запрашивать пароль.
# Здесь говорится, что поиск должен захватывать все ветви указанной базы, так что в данном случае мы запускаем поиск по всему справочнику.
# Пример фильтра поиска. Он говорит «покажите мне записи, где имя пользователя заканчивается на ‘brown’ или ID группы меньше или равно 100». Фильтры поиска – самая трудная часть синтаксиса для правильного написания, но (в определенном смысле) и самая важная.
# Эта строка содержит список имен атрибутов, которые мы хотим отобразить (в нашем случае просто имя пользователя). Если список пуст, ''ldapsearch'' покажет все атрибуты.
# Далее мы запрашиваем пароль для входа LDAP.

Наконец, строки 8 и 9 показывают вывод поиска.

Осилим еще один пример?
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
# ldapsearch -x \
-b “ou=users,dc=example,dc=com” \
-D cn=admin,dc=example,dc=com -W \
-s base ‘(objectClass=*)’
</source>

Рассмотрим строки 2 и 4. В строке 2 задан конкретный узел дерева справочника, откуда начнется поиск, а в строке 4 мы говорим LDAP не распространять поиск за пределы этого узла, а изучать только записи, заданные в строке 2. Фильтр поиска здесь фактически и не фильтр: он гласит «любая запись с атрибутом '''objectClass''', независимо от значения», а это вообще все записи. Итак, этот поиск выводит на дисплей содержимое определенного узла дерева.

[[Изображение:LXF104_75_1.png|Рис. 3. Просмотр справочника LDAP с помощью LAT. Снимок экрана показывает запись, добавленную нами для пользователя cbrown.]]
[[Изображение:LXF104_75_2.png|Рис. 4. Выполнение поиска в LDAP при помощи LAT.]]

Если вы предпочли бы использовать графические инструменты для поиска в вашем справочнике LDAP или добавления учетной записи пользователя, обратите внимание на Lat (''LDAP Administration Tool''). Это одно из новоиспеченных приложений, написанное на C# с использованием Mono и ''GTK#'', поэтому вам понадобятся установленные библиотеки Mono для его использования, но на моем клиенте с Ubuntu он установился и работал без каких-либо проблем. Рисунок 3 показывает этот инструмент в работе при обозревании иерархии LDAP, а на рисунке 4 показан пример поиска по UID 555.

===Аутентификация Dovecot===

Давайте закруглимся, применив каталог LDAP к полезному делу. Читатели предыдущего номера могут помнить, что мы оставили нашего героя (почтовый сервер ''Dovecot'') нуждающимся в аутентификации учетных записей POP3 базы данных пользователей, независимых от учетных записей пользователей в Linux.

Оказывается, ''Dovecot'' может использовать LDAP для аутентификации двумя способами: он может войти в LDAP с именем пользователя ‘rootdn’ и паролем ‘rootpw’, затем посмотреть имя пользователя и хэшированный пароль пользователя, который пытается аутентифицироваться, а может просто попробовать подключиться к серверу LDAP с именем и паролем того пользователя, кто пытается войти, и посмотреть, успешна ли попытка. Вход в LDAP известен как ‘связывание’, и эта техника называется аутентификационной связью. Этот метод мы и будем использовать.

Настройка ''Dovecot'' на использование LDAP для аутентификационной связи требует изменений в файле '''/etc/Dovecot.conf'''. Вот строки, которые я менял:
<code>
auth_verbose = yes
auth_debug = yes
passdb ldap {
args = /etc/dovecot-ldap.conf
}
userdb ldap {
args = /etc/dovecot-ldap.conf
}
</code>

Первые две строки включают вывод отладочных сообщений. На рабочем сервере они вам не понадобятся, но мне файл журнала ('''/var/log/maillog''') очень помог при отладке конфигурации ''Dovecot''. Две остальные строфы файла указывают, что мы будем использовать LDAP и как базу данных паролей, и как базу данных пользователей, и задают место размещения файла конфигурации LDAP для ''Dovecot''.

Дико извиняюсь, но есть еще один файл конфигурации! Для его создания я начал с копирования примера конфигурации LDAP из дистрибутива ''Dovecot'' на место:
<code>
# cp /usr/share/doc/dovecot-1.0/examples/dovecot-ldap.conf /etc
</code>

Затем я сделал следующие изменения в '''/etc/Dovecot-ldap.conf''' (номера строк опять-таки нужны только для ссылок на них в тексте):
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
hosts = localhost
dn = cn=admin,dc=example,dc=com
dnpass = adminpw
auth_bind = yes
auth_bind_userdn = cn=%u,ou=users,dc=example,dc=com
base = ou=users,dc=example,dc=com
</source>

Строка 1 задает имя сервера, на котором запущен LDAP. Строка 2 определяет dn учетной записи, которое ''Dovecot'' будет использовать для входа в LDAP, а строка 3 задает пароль для этой учетной записи. (Вообще-то было бы лучше не использовать для этого учетную запись с полными правами rootdn, а создать особую учетную запись для ''Dovecot''). Строка 4 говорит, что будет использоваться аутентификационная связь, а строка 5 задает dn пользователя, которого мы пробуем аутентифицировать как такового (над этим мне пришлось поломать голову!). В файле конфигурации ''Dovecot'', %u ссылается на имя пользователя, которое использует MUA (почтовый агент) пользователя, чтобы войти. Строка 6 определяет узел в дереве справочника LDAP, под которым находятся учетные записи пользователей.

Угнездив на месте эти строки, я смог подсоединиться к службе POP3 ''Dovecot'' с учетной записью cbrown и забрать почту.

Если у вас что-то не заработало, загляните в файл журнала, обычно '''/var/log/maillog'''. Сообщения, оставляемые ''Dovecot'', очень подробны и говорят сами за себя. '''LXF'''

----

===Что еще почитать? (врезка)===

# По LDAP существует множество книг. Самыми полезными мне показались две: ''LDAP System Administration by Gerald Carter'' (O’Reilly, 1-56592-491-6), и ''Understanding and Deploying LDAP Directory Services by Howes, Smith and Good'' (Addison Wesley, 0672323168). Последняя более академическая (и тяжелая!)
# Официальная документация ''Dovecot'' доступна по адресу http://wiki.dovecot.org. В частности, статья http://wiki.dovecot.org/AuthDatabase/LDAP показывает, как сделать аутентификацию LDAP в ''Dovecot''. Кроме того, '''slapd.conf''', '''ldap.conf''' и все инструменты командной строки имеют прекрасные man-страницы.
# Основную информацию по сборке почтового сервера можно найти по адресам http://freshrpms.net/docs/mail-server и http://wanderingbarque.com/howtos/mailserver/mailserver.html. (Это очень подробное пошаговое руководство, написанное Питером Лэйси [Peter Lacey]; оно охватывает интеграцию ''Postfix'', ''Dovecot'', OpenLDAP, Jamm, ''Cyrus-SASL'' и ''SquirrelMail'', и основано на RHEL 3).

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

Файл:LXF104 75 2.png

2009-03-30T21:28:27Z

Kipruss: Рис. 4. Выполнение поиска в LDAP при помощи LAT.

Рис. 4. Выполнение поиска в LDAP при помощи LAT.

Файл:LXF104 75 1.png

2009-03-30T21:28:08Z

Kipruss: Рис. 3. Просмотр справочника LDAP с помощью LAT. Снимок экрана показывает запись, добавленную нами для пользователя cbrown.

Рис. 3. Просмотр справочника LDAP с помощью LAT. Снимок экрана показывает запись, добавленную нами для пользователя cbrown.

Файл:LXF104 74 1.png

2009-03-30T21:27:46Z

Kipruss: Рис. 2. Простая структура каталога LDAP для поддержки аутентификации.

Рис. 2. Простая структура каталога LDAP для поддержки аутентификации.

Файл:LXF104 73 1.png

2009-03-30T21:27:25Z

Kipruss: Рис. 1. Компоненты OpenLDAP.

Рис. 1. Компоненты OpenLDAP.

LXF103:Hardcore Linux

2009-03-28T22:41:36Z

Kipruss: /* Продолжение следует */

==Почта: собери свой сервер==

Большинство людей пользуется электронной почтой, понятия не имея, как она работает. Светоч знаний '''д-ра Криса Брауна''' рассеет тьму невежества.

Чтобы вы могли представить, с чем вообще едят почтовый сервер, взгляните на '''Рис. 1''': там показана схема доставки почты в Интернете.

[[Изображение:LXF103_67_1.png|thumb|300px|Рис. 1: Один день из жизни почтового сообщения.]]

Проследим продвижение почтового сообщения на его пути через Интернет от отправителя к получателю и разберемся, как все компоненты работают совместно. Пусть Маша сидит за своим компьютером и составляет электронное послание, используя почтовый клиент (Mail User Agent – MUA). В мире Linux клиент Маши будет чем-то вроде ''Evolution'' или ''KMail''. Она пишет своей маме Ане, электронный адрес которой '''<nowiki>anna@example.com</nowiki>'''. Когда Маша нажимает кнопку Послать, ее MUA соединяется с Mail Transport Agent (MTA – почтовым транспортным агентом), на который Маша настроила свой MUA для отправки почты. Обычно MTA предоставляется Маше ее интернет-провайдером (ISP). MUA и MTA говорят друг с другом на языке протокола SMTP (Simple Mail Transfer Protocol – простой протокол передачи почты), организовывая доставку сообщений. В ходе этого диалога MUA определяет получателя сообщения и передает текст письма.

MTA отвечает за «дальнюю перевозку» сообщения. Он сделает запрос к DNS (Domain Name System, системе доменных имен) на поиск записи MX (Mail Exchanger), которая скажет ему, какая машина действует как почтовый сервер для домена '''<nowiki>example.com</nowiki>''', где расположен Анин почтовый ящик. Из этого запроса он может узнать, что почтовый сервер, допустим, '''<nowiki>mail.example.com</nowiki>'''. MTA Маши теперь соединяется с MTA на '''<nowiki>mail.example.com</nowiki>''', снова использует SMTP для указания получателя письма и передает тело сообщения. Принимающий MTA проверяет, что он и вправду почтовый сервер для домена получателя, а потом уж дает согласие на прием. Если все проходит нормально, принимающий MTA передает сообщение MDA (Mail Delivery Agent – почтовому агенту доставки), который сохраняет сообщение в хранилище сообщений (оно находится в файловой системе почтового сервера). Для этого сообщения работа MTA выполнена.

Аня проводит выходные с дядей Васей, помогая ему разбирать чердак, и не может в эти дни читать почту. Но когда она доберется до компьютера, ее почтовый клиент соединится с Mail Access Agent (MAA – агентом доступа к почте) на ее почтовом сервере '''<nowiki>example.com</nowiki>''' для проверки почты, которую MTA ее домена сохранил в ее хранилище. Ее MUA может использовать для этого один или два протокола. Чаще всего это Post Office Protocol (POP3 – почтовый протокол) версии 3. POP – это протокол, который скачивает почту с почтового сервера, затем (как правило) удаляет ее с сервера и оставляет ее на клиенте (компьютере в Аниной квартире), обеспечивая долговременное хранение сообщения. Но если Аня работает в корпорации Example.Com, данное учреждение может иметь почтовый сервер, работающий по протоколу IMAP4. IMAP расшифровывается как Internet Message Access Protocol [интернетпротокол доступа к сообщениям]; он позволяет Аниному MUA получать доступ к ее почтовому архиву, но долговременное хранение писем происходит на сервере (хотя некоторые MUA поддерживают локальные копии). Благодаря IMAP можно подключаться к серверу с любого компьютера с IMAP-клиентом и видеть весь почтовый архив – а вот если бы вы читали почту, используя POP на разных машинах, то в итоге ваши письма были бы раскиданы по этим машинам, что я знаю по своему горькому опыту.

Наш почтовый сервер изображен на Рисунке 1 как большой серый квадрат в правом верхнем углу. В реальности необходимы два компьютера – один для почтового сервера, другой для клиента. Возьмем ''Postfix'' как SMTP-сервер и ''Dovecot'' как почтовый POP3-сервер. На почтовом сервере моя основная ОС – CentOS 5 (CentOS – это клон Red Hat Enterprise Linux), но конфигурация и операции с ''Postfix'' и ''Dovecot'' не зависят от используемого дистрибутива Linux. Клиентская машина может быть любой. В моем случае на ней Ubuntu 7.04 с ''Evolution'' в качестве MUA.

===Начнем: Mail Transfer Agent===

Сперва мы установим ''Postfix''. Но предварительно проверим: вдруг ''Sendmail'' уже установлен и запущен. На системах типа Red Hat это могут сделать следующие команды:
<code>
# rpm -q sendmail
# service sendmail status
</code>

Если ''Sendmail'' запущен, надо его остановить и позаботиться, чтобы он не запустился после перезагрузки:
<code>
# service sendmail stop
# chkconfig sendmail --del
</code>

При наличии на вашей машине включенного брандмауэра, вы должны открыть порт для SMTP (tcp/25).

Моя собственная установка ''Postfix'' споткнулась, обнаружив отсутствие административной группы под названием postdrop. То есть до установки пакетов нужно было создать эту группу:
<code>
# groupadd -r postdrop
# yum install postfix
</code>

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

Для обеспечения запуска сервиса ''Postfix'' при загрузке, запустите команду
<code>
# chkconfig --add postfix
</code>

Файл настройки ''Postfix'' – '''/etc/postfix/main.cf'''. Фактически, ''Postfix'' должен заработать «из коробки» как простой почтовый сервер с минимальной доработкой готовой конфигурации, но есть несколько параметров, требующих внимания. Так, строку в '''main.cf'''
<code>
inet_interfaces = localhost
</code>
нужно заменить на
<code>
inet_interfaces = all
</code>

Это мы велим ''Postfix'' слушать SMTP соединения на всех сетевых интерфейсах машины, а не только на локальном (localhost).

Далее проверим установки параметра myhostname. Он определяет FQDN этой почтовой системы. Если он не определен, то по умолчанию берется имя хоста машины, на которой запущен сервер, возвращаемое командой hostname. Так, если ваш хост – '''<nowiki>mail.example.com</nowiki>''', это имя и будет принято по умолчанию.

Наконец, параметр mydestination задает список доменов, которые эта машина считает для себя пунктом назначения (то есть домены, для которых машина сохраняет сообщения). Минимальное значение этого параметра должно походить на следующее:
<code>
mydestination = example.com
</code>

Установив все эти параметры, можно запускать ''Postfix''. На RedHat-совместимых системах это делается командой
<code>
# service postfix start
</code>

Далее, я создал учетную запись для пользователя anna и установил пароль:
<code>
# useradd anna
# passwd anna
</code>

Без них не обойтись, потому что «локальный» агент доставки почты в ''Postfix'' требует, чтобы получатель имел учетную запись в Linux-системе: по ней происходит аутентификация в ''Dovecot'' (который мы рассмотрим чуть позже).

Теперь у нас все готово для теста доставки почты в хранилище сообщений. На моей настольной системе с Ubuntu я создал запись в файле '''/etc/hosts''', возвращающую IP-адрес машины '''<nowiki>mail.example.com</nowiki>'''. В моем случае строка выглядела так:
<code>
192.168.0.41 mail.example.com
</code>

В реальности, почтовый сервер должен иметь DNS-запись, и вам не нужно задавать ее в '''/etc/hosts'''. Затем я сконфигурировал «учетную запись» в моем MUA (''Evolution'') на использование SMTP-сервера '''<nowiki>mail.example.com</nowiki>''' для исходящих сообщений. Я включил эту учетную запись Evolution и отключил остальные. Затем я попытался послать несколько писем на '''<nowiki>anna@example.com</nowiki>'''.

Сработало? Ну, тот факт, что письма исчезли из моих Исходящих [Outbox] в ''Evolution'', уже обнадеживал, но лучший способ проверки – найти сообщения сохраненными на почтовом сервере. Что выводит нас на ...

===Хранилище сообщений===

Традиционный способ хранения сообщений на почтовом сервере известен как формат Mbox: для каждого пользователя хранится отдельный текстовый файл. Имя этого файла совпадает с именем учетной записи пользователя, чью почту он хранит, а каталог определяется параметром mail_spool_directory настройки ''Postfix'' (обычно '''/var/spool/mail''' или '''/var/mail'''). Например, Анины сообщения могут заноситься в '''/var/spool/mail/anna'''. Внутри этого файла каждое сообщение начинается строкой с первым словом “From” и заканчивается пустой строкой. (Вас может сбить с толку наличие в этом файле других строк, тоже начинающихся на “From:” – заметили двоеточие? Это часть заголовков сообщения.) Надеюсь, ''Postfix'' вписал мое тестовое сообщение в этот файл.

Альтернативная схема хранения сообщений (также называемая форматом Maildir) использует отдельную директорию для каждого пользователя (обычно это поддиректория с названием '''maildir''' внутри домашнего каталога пользователя) и, внутри нее, отдельный файл для каждого сообщения. При этом меньше шансов заблокировать или угробить все сообщения разом, чем в формате Mbox.

Если посланное вами сообщение появилось в хранилище, пора перейти к нашему POP3-серверу. Если его нет, прочитайте советы во врезке ''Решение проблем'', внизу .

===Установка и настройка Dovecot===

На моей CentOS для установки ''Dovecot'' надо всего лишь скомандовать:
<code>
# yum install dovecot
</code>

Теперь нужно найти файл конфигурации ''Dovecot''. Обычно это '''/etc/dovecot.conf'''. Как типичный современный файл конфигурации, он довольно длинен (более 1000 строк), но почти целиком состоит из комментариев. Как оказалось, мне нужно было изменить две строчки; одна задает протокол(ы), которые должен обслуживать ''Dovecot'', а вторая говорит, где находятся файлы почтового ящика. Эти два параметра я изменил так:
<code>
protocols = pop3
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%n
</code>

Первая строка говорит, что мы будем использовать только протокол POP3. Во второй строке, установка INBOX использует специальный параметр %n для замены именем пользователя, под которым мы зашли проверить почту (в нашем примере – “anna”). Заметим, что значение параметра INBOX должно совпадать с расположением хранилища почты, указанном в ''Postfix''.

Если у вас на почтовом сервере запущен брандмауэр, нужно также открыть порт POP3 (110/tcp).

Теперь мы готовы к запуску сервиса:
<code>
# service dovecot start
</code>

Пора тестировать. На клиенте, в настройках MUA мне необходимо установить для приема почты использование протокола POP и сервера '''<nowiki>mail.example.com</nowiki>''', затем задать имя '''anna''' и отключить опции шифрования, предлагаемые MUA. Теперь я готов принять мои сообщения. В этом пункте мой MUA должен (надеюсь) запросить пароль '''anna''', а мне необходимо предоставить пароль, который я задал, создавая ее учетную запись Linux на сервере. Если все пройдет гладко, вы должны увидеть ранее посланные письма появившимися во Входящих MUA. И если вы вернетесь на сервер, то обнаружите, что сообщения исчезли из хранилища anna. Если опять ничего не выйдет, обратитесь ко врезке ''Решение проблем''.

===Ура, оно работает!===

Если вы дошли досюда, поздравляем! У вас появился работающий почтовый сервер. Как обычно, я создавал максимально простую конфигурацию, чтобы все поскорее заработало. Однако эта реализация подразумевает несколько допущений: во-первых, почтовый сервер обслуживает только один домен ('''<nowiki>example.com</nowiki>'''), а во-вторых, все пользователи, желающие получать почту, имеют учетные записи Linux на почтовом сервере. Это последнее ограничение задается как со стороны локального агента доставки в ''Postfix'', так и ''Dovecot'', который, в своей конфигурации по умолчанию, требует действующей учетной записи Linux для аутентификации пользователей, для входа через POP и получения электронной почты. Отметим также, что в нашей конфигурации MTA (''Postfix'') не требуется аутентификации пользователя, в отличие от MAA (''Dovecot'').

===Поддерживаем несколько доменов===

В реальных условиях одной машине приходится быть почтовым сервером для множества доменов. Самый простой путь это обеспечить – добавить домены в параметр mydestination в '''/etc/Postfix/main.cf'''. Например, установка:
<code>
mydestination = example.com example.org example.net
</code>
велит Postfix принимать почту для трех указанных доменов. Конечно, если вы что-то поменяли в '''main.cf''', нужно заставить postfix перечитать его:
<code>
# service postfix reload
</code>

Конечно, надо также обеспечить, чтобы MX-записи в DNS для всех трех доменов ссылались на сервер '''<nowiki>mail.example.com</nowiki>'''. Однако эта методика имеет ограниченное применение, поскольку у всех доменов – общее пространство имен: так, почта на '''<nowiki>anna@example.com</nowiki>''', '''<nowiki>anna@example.org</nowiki>''' и '''<nowiki>anna@example.net</nowiki>''' будет в конце концов сохранена в одном и том же месте. И, конечно, Ане (и всем другим получателям почты) нужна учетная запись Linux на сервере.

Более гибкое решение – использовать так называемые «виртуальные» почтовые домены. При таком способе каждый домен имеет отдельное пространство имен, и письма для '''<nowiki>anna@example.com</nowiki>''' и '''<nowiki>anna@example.net</nowiki>''' окажутся в разных хранилищах почты. Получателю также не требуется иметь системную учетную запись Linux. Но зато требуется чуть больше работы по настройке...

Требуемые для этого строки в '''main.cf''' показаны в Листинге А ниже. Учтите, что номера строк проставлены только для удобства ссылки: в файле их нет.

{{Врезка
|Заголовок=Альтернативы
|Содержание=Как всегда в Linux, существует несколько программных решений для построения почтового сервера. Для MTA вы можете использовать ''Postfix'', ''Exim'' или почтенный ''Sendmail''. ''Postfix'' – самый юный; он написан Вьетсе Венема <nowiki>[Wietse Venema]</nowiki> в 1999 году, имеет прекрасную репутацию по безопасности и служит MTA по умолчанию во многих текущих дистрибутивах Linux. Exim был разработан в 1995 году в Кембриджском университете Филипом Хейзелом <nowiki>[Philip Hazel]</nowiki>. ''Sendmail'' написан Эриком Оллманом <nowiki>[Eric Allman]</nowiki> в 1983 году; много лет он тянул на себе большинство интернет-почты, и стало почти обязательным ссылаться на него, как на «почтенный», хотя у него самый непонятный файл конфигурации по эту сторону Бетельгейзе. Для MAA тоже есть выбор. Это может быть IMAP-сервер ''Cyrus'', ''Courier'', ''qpopper'', инструментарий IMAP University of Washington, Dovecot и другие. Более подробный список и сравнение почтовых серверов вы можете найти на http://en.wikipedia.org/wiki/Comparison_of_mail_servers.
|Ширина=200px}}

===ЛИСТИНГ A===
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
virtual_mailbox_domains = example.com example.org example.net
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/etc/Postfix/virtual_mailbox_map
virtual_uid_maps = static:550
virtual_gid_maps = static:101
</source>

Строка 1 в ''Листинге А'' содержит список доменов, которые будут поддерживаться. Их надо удалить из параметра mydestination, так как они теперь будут обрабатываться с использованием «виртуального» агента доставки ''Postfix'', и «локальный» агент им больше не нужен.

Если список доменов по-настоящему большой, вы можете предпочесть поместить его в отдельный файл, например, '''/etc/postfix/virtual_domains''', по образцу:
<code>
# list of virtual domains for postfix
example.com
example.net
example.org
# ... and lots more ...
</code>
и ссылаться на этот файл через параметр virtual_mailbox_domains в '''main.cf''':
<code>
virtual_mailbox_domains = /etc/postfix/virtual_domains
</code>

Аналогично, многие параметры в '''main.cf''' могут иметь список требуемых значений, помещенный в отдельный файл.

Строка 2 в ''Листинге А'' задает директорию верхнего уровня, где должны сохраняться сообщения. Очевидно, надо выбрать схему, совместимую с нашими POP- и IMAP-серверами. Здесь выбрано одно из множества возможных решений.

Создадим то, что ''Postfix'' называет «картой» – для отметки, где получатели почтовых адресов будут сохранять сообщения относительно заданного virtual_mailbox_base. Я создал простую карту в файле, который назвал '''/etc/postfix/virtual_mailbox_map''':
<code>
anna@example.com anna
anna@example.net anna_smith
chris@example.org cbrown
</code>

Теперь, например, письмо, посланное на '''<nowiki>anna@example.net</nowiki>''', будет сохранено в '''/var/spool/vmail/anna_smith'''; письмо, посланное на адрес '''<nowiki>chris@example.org</nowiki>''', «упадет» в '''/var/spool/vmail/cbrown''', и так далее. Заметьте, что здесь не требуется совпадения видимых снаружи имен пользователей (в нашем примере, '''anna''' и '''chris''') со внутренними именами (anna_smith и cbrown).

Конвертируем этот файл в «карту», используя команду postmap:
<code>
# postmap /etc/postfix/virtual_mailbox_map
</code>

В результате появится файл '''virtual_mailbox_map.db'''. Карта, в данном случае, просто вид индексированной структуры данных, ключи которой могут быть эффективно просмотрены ''Postfix''. ''Postfix'' поддерживает несколько типов «карт»; по умолчанию это обычно «хэш».

Далее, в строке 3 ''Листинга А'', вы сообщаете ''Postfix'', где находится карта.

''Postfix'' нуждается в отождествлении пользователя, используемом для доставки сообщения в хранилище. Возможно задание нескольких карт (uid_map и gid_map), определяющих отдельные отождествления для всех и каждого получателя, но мы сделаем проще и используем одну и ту же личность для всех получателей. Я создал пользователя с именем '''postmanpat''' для этой цели.
<code>
# useradd -d /var/spool/vmail -g postdrop -u 550 -m postmanpat
</code>

Отметим, что домашняя директория '''postmanpat''' находится в моей выбранной директории '''virtual_ mailbox_base'''. Далее я смягчил права доступа в '''/var/spool/vmail''', чтобы Dovecot мог ей воспользоваться.
<code>
# chmod 755 /var/spool/vmail
</code>

Нет необходимости предварительно создавать файл сохраненных сообщений для индивидуальных получателей – ''Postfix'' сделает это по требованию. Наконец, строки 4 и 5 Листинга А задают тождество пользователя и группы, которые ''Postfix'' будет использовать для помещения сообщений в хранилище. Они соответствуют ID пользователя postmanpat и группы postdrop.

После внесения данных изменений та часть, за которую отвечает ''Postfix'', должна работать. Возвратитесь к клиентской машине и пошлите тестовое сообщение на '''<nowiki>chris@example.org</nowiki>'''. На сервере проверьте, что это сообщение появилось в '''/var/spool/vmail/cbrown'''. Если да, то доставка ''Postfix'' на виртуальные почтовые домены работает!

На стороне ''Dovecot'' я просто изменил определение параметра mail_location на следующее:
<code>
mail_location = mbox:~/mail:INBOX=/var/spool/vmail/%n
</code>

===Продолжение следует===

Пока мы не касались аутентификации POP3 при входе в ''Dovecot''. В текущем состоянии, чтобы Dovecot заработал, вам необходимо создать очередные учетные записи Linux пользователям anna, anna_smith и cbrown, для новой аутентификации ''Dovecot''. Чтобы виртуальные домены применялись правильно, необходимо рассмотреть вопрос об аутентификации учетных записей POP3 через базу данных пользователей, не зависящую от учетных записей Linux. На данном уроке уже подпущено достаточно ежей под череп, но в следующем номере ''Linux Format'' я попытаюсь решить вопрос об аутентификации внутри почтовых систем и в ''Postfix'' и в ''Dovecot''. Пишите на [[mailto://answers@linuxformat.ru]], если у вас возникнут проблемы с вашим почтовым сервером. '''LXF'''

----

===Решение проблем (врезка)===

[[Изображение:LXF103_68_1.png|thumb|300px|Пример использования команды telnet.]]

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

1. На клиенте проверьте, что почтовый сервер пингуется по его IP-адресу и имени, используя команды:
<code>
# ping 192.168.0.41
# ping mail.example.com
</code>
(Естественно, подставьте сюда IP-адреc вашего сервера.)

2. На сервере проверьте, что серверы SMTP и POP слушают соединения, используя команду
<code>
# netstat -at
</code>

Вы должны увидеть LISTEN в конце информации о портах SMTP и POP3.

3. На клиенте, попробуйте использовать telnet для соединения с портом 25 на почтовом сервере, используя команду:
<code>
# telnet mail.example.com 25
</code>

Вы должны получить отклик с сервера типа такого:
<code>
220 mail.example.com ESMTP Postfix
</code>

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

4. На сервере проверьте, что брандмауэр не блокирует доступ к портам 25 (SMTP) и 110 (POP3), используя команду:
<code>
# iptables -L
</code>

Если вы не уверены, отключите брандмауэр командой:
<code>
# itables -F
</code>
и попробуйте снова. Не забудьте потом восстановить работоспособность брандмауэра.

5. На сервере поищите разгадку в системных журналах почты (обычно /var/log/maillog).

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

LXF103

2009-03-28T22:25:44Z

Kipruss: /* Учебники */

=== Учебники ===

* [[LXF103:Совет месяца|'''Совет месяца:''' Счастье луковое]]
* [[LXF103:Навести порядок в снимках|'''Фотография.''' Навести порядок в снимках]]
В Linux нет недостатка в инструментах управления фотографиями. '''Дэйл Стрикланд-Кларк''' рассмотрит все варианты и найдет для вас лучший, будь то ''DigiKam, Picasa'' или ''F-Spot''.

* [[LXF103:Hardcore Linux|'''Hardcore Linux.''' Почта: собери свой сервер.]]
Большинство людей пользуется электронной почтой, понятия не имея, как она работает. Светоч знаний '''д-ра Криса Брауна''' рассеет тьму невежества.

* R: типы данных

* [[LXF103:Ни строчки кода!|Ни строчки кода!]]
* [[LXF103:Стрелялка|Стрелялка за выходные]]

[[Категория:Математические пакеты]]

=== [[LXF103:Ответы|Ответы]]===

Устраняем проблемы Linux: память, смена IP-адреса, проблемы с загрузкой, ''apt-get'' без сети, шрифты, компиляция ПО, брандмауэры и поиски Луны с ''KMoon''.

LXF103

2009-03-28T22:24:56Z

Kipruss:

=== Учебники ===

* [[LXF103:Совет месяца|'''Совет месяца:''' Счастье луковое]]
* [[LXF103:Навести порядок в снимках|'''Фотография.''' Навести порядок в снимках]]
В Linux нет недостатка в инструментах управления фотографиями. '''Дэйл Стрикланд-Кларк''' рассмотрит все варианты и найдет для вас лучший, будь то ''DigiKam, Picasa'' или ''F-Spot''.

* [[LXF103:Hardcore Linux|'''Hardcore Linux.''' Почта: собери свой сервер.]]
Большинство людей пользуется электронной почтой, понятия не имея, как она работает. Светоч знаний д-ра Криса Брауна рассеет тьму невежества.

* R: типы данных

* [[LXF103:Ни строчки кода!|Ни строчки кода!]]
* [[LXF103:Стрелялка|Стрелялка за выходные]]

[[Категория:Математические пакеты]]

=== [[LXF103:Ответы|Ответы]]===

Устраняем проблемы Linux: память, смена IP-адреса, проблемы с загрузкой, ''apt-get'' без сети, шрифты, компиляция ПО, брандмауэры и поиски Луны с ''KMoon''.

LXF103:Hardcore Linux

2009-03-28T22:23:00Z

Kipruss: /* Продолжение следует */

==Почта: собери свой сервер==

Большинство людей пользуется электронной почтой, понятия не имея, как она работает. Светоч знаний '''д-ра Криса Брауна''' рассеет тьму невежества.

Чтобы вы могли представить, с чем вообще едят почтовый сервер, взгляните на '''Рис. 1''': там показана схема доставки почты в Интернете.

[[Изображение:LXF103_67_1.png|thumb|300px|Рис. 1: Один день из жизни почтового сообщения.]]

Проследим продвижение почтового сообщения на его пути через Интернет от отправителя к получателю и разберемся, как все компоненты работают совместно. Пусть Маша сидит за своим компьютером и составляет электронное послание, используя почтовый клиент (Mail User Agent – MUA). В мире Linux клиент Маши будет чем-то вроде ''Evolution'' или ''KMail''. Она пишет своей маме Ане, электронный адрес которой '''<nowiki>anna@example.com</nowiki>'''. Когда Маша нажимает кнопку Послать, ее MUA соединяется с Mail Transport Agent (MTA – почтовым транспортным агентом), на который Маша настроила свой MUA для отправки почты. Обычно MTA предоставляется Маше ее интернет-провайдером (ISP). MUA и MTA говорят друг с другом на языке протокола SMTP (Simple Mail Transfer Protocol – простой протокол передачи почты), организовывая доставку сообщений. В ходе этого диалога MUA определяет получателя сообщения и передает текст письма.

MTA отвечает за «дальнюю перевозку» сообщения. Он сделает запрос к DNS (Domain Name System, системе доменных имен) на поиск записи MX (Mail Exchanger), которая скажет ему, какая машина действует как почтовый сервер для домена '''<nowiki>example.com</nowiki>''', где расположен Анин почтовый ящик. Из этого запроса он может узнать, что почтовый сервер, допустим, '''<nowiki>mail.example.com</nowiki>'''. MTA Маши теперь соединяется с MTA на '''<nowiki>mail.example.com</nowiki>''', снова использует SMTP для указания получателя письма и передает тело сообщения. Принимающий MTA проверяет, что он и вправду почтовый сервер для домена получателя, а потом уж дает согласие на прием. Если все проходит нормально, принимающий MTA передает сообщение MDA (Mail Delivery Agent – почтовому агенту доставки), который сохраняет сообщение в хранилище сообщений (оно находится в файловой системе почтового сервера). Для этого сообщения работа MTA выполнена.

Аня проводит выходные с дядей Васей, помогая ему разбирать чердак, и не может в эти дни читать почту. Но когда она доберется до компьютера, ее почтовый клиент соединится с Mail Access Agent (MAA – агентом доступа к почте) на ее почтовом сервере '''<nowiki>example.com</nowiki>''' для проверки почты, которую MTA ее домена сохранил в ее хранилище. Ее MUA может использовать для этого один или два протокола. Чаще всего это Post Office Protocol (POP3 – почтовый протокол) версии 3. POP – это протокол, который скачивает почту с почтового сервера, затем (как правило) удаляет ее с сервера и оставляет ее на клиенте (компьютере в Аниной квартире), обеспечивая долговременное хранение сообщения. Но если Аня работает в корпорации Example.Com, данное учреждение может иметь почтовый сервер, работающий по протоколу IMAP4. IMAP расшифровывается как Internet Message Access Protocol [интернетпротокол доступа к сообщениям]; он позволяет Аниному MUA получать доступ к ее почтовому архиву, но долговременное хранение писем происходит на сервере (хотя некоторые MUA поддерживают локальные копии). Благодаря IMAP можно подключаться к серверу с любого компьютера с IMAP-клиентом и видеть весь почтовый архив – а вот если бы вы читали почту, используя POP на разных машинах, то в итоге ваши письма были бы раскиданы по этим машинам, что я знаю по своему горькому опыту.

Наш почтовый сервер изображен на Рисунке 1 как большой серый квадрат в правом верхнем углу. В реальности необходимы два компьютера – один для почтового сервера, другой для клиента. Возьмем ''Postfix'' как SMTP-сервер и ''Dovecot'' как почтовый POP3-сервер. На почтовом сервере моя основная ОС – CentOS 5 (CentOS – это клон Red Hat Enterprise Linux), но конфигурация и операции с ''Postfix'' и ''Dovecot'' не зависят от используемого дистрибутива Linux. Клиентская машина может быть любой. В моем случае на ней Ubuntu 7.04 с ''Evolution'' в качестве MUA.

===Начнем: Mail Transfer Agent===

Сперва мы установим ''Postfix''. Но предварительно проверим: вдруг ''Sendmail'' уже установлен и запущен. На системах типа Red Hat это могут сделать следующие команды:
<code>
# rpm -q sendmail
# service sendmail status
</code>

Если ''Sendmail'' запущен, надо его остановить и позаботиться, чтобы он не запустился после перезагрузки:
<code>
# service sendmail stop
# chkconfig sendmail --del
</code>

При наличии на вашей машине включенного брандмауэра, вы должны открыть порт для SMTP (tcp/25).

Моя собственная установка ''Postfix'' споткнулась, обнаружив отсутствие административной группы под названием postdrop. То есть до установки пакетов нужно было создать эту группу:
<code>
# groupadd -r postdrop
# yum install postfix
</code>

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

Для обеспечения запуска сервиса ''Postfix'' при загрузке, запустите команду
<code>
# chkconfig --add postfix
</code>

Файл настройки ''Postfix'' – '''/etc/postfix/main.cf'''. Фактически, ''Postfix'' должен заработать «из коробки» как простой почтовый сервер с минимальной доработкой готовой конфигурации, но есть несколько параметров, требующих внимания. Так, строку в '''main.cf'''
<code>
inet_interfaces = localhost
</code>
нужно заменить на
<code>
inet_interfaces = all
</code>

Это мы велим ''Postfix'' слушать SMTP соединения на всех сетевых интерфейсах машины, а не только на локальном (localhost).

Далее проверим установки параметра myhostname. Он определяет FQDN этой почтовой системы. Если он не определен, то по умолчанию берется имя хоста машины, на которой запущен сервер, возвращаемое командой hostname. Так, если ваш хост – '''<nowiki>mail.example.com</nowiki>''', это имя и будет принято по умолчанию.

Наконец, параметр mydestination задает список доменов, которые эта машина считает для себя пунктом назначения (то есть домены, для которых машина сохраняет сообщения). Минимальное значение этого параметра должно походить на следующее:
<code>
mydestination = example.com
</code>

Установив все эти параметры, можно запускать ''Postfix''. На RedHat-совместимых системах это делается командой
<code>
# service postfix start
</code>

Далее, я создал учетную запись для пользователя anna и установил пароль:
<code>
# useradd anna
# passwd anna
</code>

Без них не обойтись, потому что «локальный» агент доставки почты в ''Postfix'' требует, чтобы получатель имел учетную запись в Linux-системе: по ней происходит аутентификация в ''Dovecot'' (который мы рассмотрим чуть позже).

Теперь у нас все готово для теста доставки почты в хранилище сообщений. На моей настольной системе с Ubuntu я создал запись в файле '''/etc/hosts''', возвращающую IP-адрес машины '''<nowiki>mail.example.com</nowiki>'''. В моем случае строка выглядела так:
<code>
192.168.0.41 mail.example.com
</code>

В реальности, почтовый сервер должен иметь DNS-запись, и вам не нужно задавать ее в '''/etc/hosts'''. Затем я сконфигурировал «учетную запись» в моем MUA (''Evolution'') на использование SMTP-сервера '''<nowiki>mail.example.com</nowiki>''' для исходящих сообщений. Я включил эту учетную запись Evolution и отключил остальные. Затем я попытался послать несколько писем на '''<nowiki>anna@example.com</nowiki>'''.

Сработало? Ну, тот факт, что письма исчезли из моих Исходящих [Outbox] в ''Evolution'', уже обнадеживал, но лучший способ проверки – найти сообщения сохраненными на почтовом сервере. Что выводит нас на ...

===Хранилище сообщений===

Традиционный способ хранения сообщений на почтовом сервере известен как формат Mbox: для каждого пользователя хранится отдельный текстовый файл. Имя этого файла совпадает с именем учетной записи пользователя, чью почту он хранит, а каталог определяется параметром mail_spool_directory настройки ''Postfix'' (обычно '''/var/spool/mail''' или '''/var/mail'''). Например, Анины сообщения могут заноситься в '''/var/spool/mail/anna'''. Внутри этого файла каждое сообщение начинается строкой с первым словом “From” и заканчивается пустой строкой. (Вас может сбить с толку наличие в этом файле других строк, тоже начинающихся на “From:” – заметили двоеточие? Это часть заголовков сообщения.) Надеюсь, ''Postfix'' вписал мое тестовое сообщение в этот файл.

Альтернативная схема хранения сообщений (также называемая форматом Maildir) использует отдельную директорию для каждого пользователя (обычно это поддиректория с названием '''maildir''' внутри домашнего каталога пользователя) и, внутри нее, отдельный файл для каждого сообщения. При этом меньше шансов заблокировать или угробить все сообщения разом, чем в формате Mbox.

Если посланное вами сообщение появилось в хранилище, пора перейти к нашему POP3-серверу. Если его нет, прочитайте советы во врезке ''Решение проблем'', внизу .

===Установка и настройка Dovecot===

На моей CentOS для установки ''Dovecot'' надо всего лишь скомандовать:
<code>
# yum install dovecot
</code>

Теперь нужно найти файл конфигурации ''Dovecot''. Обычно это '''/etc/dovecot.conf'''. Как типичный современный файл конфигурации, он довольно длинен (более 1000 строк), но почти целиком состоит из комментариев. Как оказалось, мне нужно было изменить две строчки; одна задает протокол(ы), которые должен обслуживать ''Dovecot'', а вторая говорит, где находятся файлы почтового ящика. Эти два параметра я изменил так:
<code>
protocols = pop3
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%n
</code>

Первая строка говорит, что мы будем использовать только протокол POP3. Во второй строке, установка INBOX использует специальный параметр %n для замены именем пользователя, под которым мы зашли проверить почту (в нашем примере – “anna”). Заметим, что значение параметра INBOX должно совпадать с расположением хранилища почты, указанном в ''Postfix''.

Если у вас на почтовом сервере запущен брандмауэр, нужно также открыть порт POP3 (110/tcp).

Теперь мы готовы к запуску сервиса:
<code>
# service dovecot start
</code>

Пора тестировать. На клиенте, в настройках MUA мне необходимо установить для приема почты использование протокола POP и сервера '''<nowiki>mail.example.com</nowiki>''', затем задать имя '''anna''' и отключить опции шифрования, предлагаемые MUA. Теперь я готов принять мои сообщения. В этом пункте мой MUA должен (надеюсь) запросить пароль '''anna''', а мне необходимо предоставить пароль, который я задал, создавая ее учетную запись Linux на сервере. Если все пройдет гладко, вы должны увидеть ранее посланные письма появившимися во Входящих MUA. И если вы вернетесь на сервер, то обнаружите, что сообщения исчезли из хранилища anna. Если опять ничего не выйдет, обратитесь ко врезке ''Решение проблем''.

===Ура, оно работает!===

Если вы дошли досюда, поздравляем! У вас появился работающий почтовый сервер. Как обычно, я создавал максимально простую конфигурацию, чтобы все поскорее заработало. Однако эта реализация подразумевает несколько допущений: во-первых, почтовый сервер обслуживает только один домен ('''<nowiki>example.com</nowiki>'''), а во-вторых, все пользователи, желающие получать почту, имеют учетные записи Linux на почтовом сервере. Это последнее ограничение задается как со стороны локального агента доставки в ''Postfix'', так и ''Dovecot'', который, в своей конфигурации по умолчанию, требует действующей учетной записи Linux для аутентификации пользователей, для входа через POP и получения электронной почты. Отметим также, что в нашей конфигурации MTA (''Postfix'') не требуется аутентификации пользователя, в отличие от MAA (''Dovecot'').

===Поддерживаем несколько доменов===

В реальных условиях одной машине приходится быть почтовым сервером для множества доменов. Самый простой путь это обеспечить – добавить домены в параметр mydestination в '''/etc/Postfix/main.cf'''. Например, установка:
<code>
mydestination = example.com example.org example.net
</code>
велит Postfix принимать почту для трех указанных доменов. Конечно, если вы что-то поменяли в '''main.cf''', нужно заставить postfix перечитать его:
<code>
# service postfix reload
</code>

Конечно, надо также обеспечить, чтобы MX-записи в DNS для всех трех доменов ссылались на сервер '''<nowiki>mail.example.com</nowiki>'''. Однако эта методика имеет ограниченное применение, поскольку у всех доменов – общее пространство имен: так, почта на '''<nowiki>anna@example.com</nowiki>''', '''<nowiki>anna@example.org</nowiki>''' и '''<nowiki>anna@example.net</nowiki>''' будет в конце концов сохранена в одном и том же месте. И, конечно, Ане (и всем другим получателям почты) нужна учетная запись Linux на сервере.

Более гибкое решение – использовать так называемые «виртуальные» почтовые домены. При таком способе каждый домен имеет отдельное пространство имен, и письма для '''<nowiki>anna@example.com</nowiki>''' и '''<nowiki>anna@example.net</nowiki>''' окажутся в разных хранилищах почты. Получателю также не требуется иметь системную учетную запись Linux. Но зато требуется чуть больше работы по настройке...

Требуемые для этого строки в '''main.cf''' показаны в Листинге А ниже. Учтите, что номера строк проставлены только для удобства ссылки: в файле их нет.

{{Врезка
|Заголовок=Альтернативы
|Содержание=Как всегда в Linux, существует несколько программных решений для построения почтового сервера. Для MTA вы можете использовать ''Postfix'', ''Exim'' или почтенный ''Sendmail''. ''Postfix'' – самый юный; он написан Вьетсе Венема <nowiki>[Wietse Venema]</nowiki> в 1999 году, имеет прекрасную репутацию по безопасности и служит MTA по умолчанию во многих текущих дистрибутивах Linux. Exim был разработан в 1995 году в Кембриджском университете Филипом Хейзелом <nowiki>[Philip Hazel]</nowiki>. ''Sendmail'' написан Эриком Оллманом <nowiki>[Eric Allman]</nowiki> в 1983 году; много лет он тянул на себе большинство интернет-почты, и стало почти обязательным ссылаться на него, как на «почтенный», хотя у него самый непонятный файл конфигурации по эту сторону Бетельгейзе. Для MAA тоже есть выбор. Это может быть IMAP-сервер ''Cyrus'', ''Courier'', ''qpopper'', инструментарий IMAP University of Washington, Dovecot и другие. Более подробный список и сравнение почтовых серверов вы можете найти на http://en.wikipedia.org/wiki/Comparison_of_mail_servers.
|Ширина=200px}}

===ЛИСТИНГ A===
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
virtual_mailbox_domains = example.com example.org example.net
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/etc/Postfix/virtual_mailbox_map
virtual_uid_maps = static:550
virtual_gid_maps = static:101
</source>

Строка 1 в ''Листинге А'' содержит список доменов, которые будут поддерживаться. Их надо удалить из параметра mydestination, так как они теперь будут обрабатываться с использованием «виртуального» агента доставки ''Postfix'', и «локальный» агент им больше не нужен.

Если список доменов по-настоящему большой, вы можете предпочесть поместить его в отдельный файл, например, '''/etc/postfix/virtual_domains''', по образцу:
<code>
# list of virtual domains for postfix
example.com
example.net
example.org
# ... and lots more ...
</code>
и ссылаться на этот файл через параметр virtual_mailbox_domains в '''main.cf''':
<code>
virtual_mailbox_domains = /etc/postfix/virtual_domains
</code>

Аналогично, многие параметры в '''main.cf''' могут иметь список требуемых значений, помещенный в отдельный файл.

Строка 2 в ''Листинге А'' задает директорию верхнего уровня, где должны сохраняться сообщения. Очевидно, надо выбрать схему, совместимую с нашими POP- и IMAP-серверами. Здесь выбрано одно из множества возможных решений.

Создадим то, что ''Postfix'' называет «картой» – для отметки, где получатели почтовых адресов будут сохранять сообщения относительно заданного virtual_mailbox_base. Я создал простую карту в файле, который назвал '''/etc/postfix/virtual_mailbox_map''':
<code>
anna@example.com anna
anna@example.net anna_smith
chris@example.org cbrown
</code>

Теперь, например, письмо, посланное на '''<nowiki>anna@example.net</nowiki>''', будет сохранено в '''/var/spool/vmail/anna_smith'''; письмо, посланное на адрес '''<nowiki>chris@example.org</nowiki>''', «упадет» в '''/var/spool/vmail/cbrown''', и так далее. Заметьте, что здесь не требуется совпадения видимых снаружи имен пользователей (в нашем примере, '''anna''' и '''chris''') со внутренними именами (anna_smith и cbrown).

Конвертируем этот файл в «карту», используя команду postmap:
<code>
# postmap /etc/postfix/virtual_mailbox_map
</code>

В результате появится файл '''virtual_mailbox_map.db'''. Карта, в данном случае, просто вид индексированной структуры данных, ключи которой могут быть эффективно просмотрены ''Postfix''. ''Postfix'' поддерживает несколько типов «карт»; по умолчанию это обычно «хэш».

Далее, в строке 3 ''Листинга А'', вы сообщаете ''Postfix'', где находится карта.

''Postfix'' нуждается в отождествлении пользователя, используемом для доставки сообщения в хранилище. Возможно задание нескольких карт (uid_map и gid_map), определяющих отдельные отождествления для всех и каждого получателя, но мы сделаем проще и используем одну и ту же личность для всех получателей. Я создал пользователя с именем '''postmanpat''' для этой цели.
<code>
# useradd -d /var/spool/vmail -g postdrop -u 550 -m postmanpat
</code>

Отметим, что домашняя директория '''postmanpat''' находится в моей выбранной директории '''virtual_ mailbox_base'''. Далее я смягчил права доступа в '''/var/spool/vmail''', чтобы Dovecot мог ей воспользоваться.
<code>
# chmod 755 /var/spool/vmail
</code>

Нет необходимости предварительно создавать файл сохраненных сообщений для индивидуальных получателей – ''Postfix'' сделает это по требованию. Наконец, строки 4 и 5 Листинга А задают тождество пользователя и группы, которые ''Postfix'' будет использовать для помещения сообщений в хранилище. Они соответствуют ID пользователя postmanpat и группы postdrop.

После внесения данных изменений та часть, за которую отвечает ''Postfix'', должна работать. Возвратитесь к клиентской машине и пошлите тестовое сообщение на '''<nowiki>chris@example.org</nowiki>'''. На сервере проверьте, что это сообщение появилось в '''/var/spool/vmail/cbrown'''. Если да, то доставка ''Postfix'' на виртуальные почтовые домены работает!

На стороне ''Dovecot'' я просто изменил определение параметра mail_location на следующее:
<code>
mail_location = mbox:~/mail:INBOX=/var/spool/vmail/%n
</code>

===Продолжение следует===

Пока мы не касались аутентификации POP3 при входе в ''Dovecot''. В текущем состоянии, чтобы Dovecot заработал, вам необходимо создать очередные учетные записи Linux пользователям anna, anna_smith и cbrown, для новой аутентификации ''Dovecot''. Чтобы виртуальные домены применялись правильно, необходимо рассмотреть вопрос об аутентификации учетных записей POP3 через базу данных пользователей, не зависящую от учетных записей Linux. На данном уроке уже подпущено достаточно ежей под череп, но в следующем номере ''Linux Format'' я попытаюсь решить вопрос об аутентификации внутри почтовых систем и в ''Postfix'' и в ''Dovecot''. Пишите на [[mailto://answers@linuxformat.ru|answers@linuxformat.ru]], если у вас возникнут проблемы с вашим почтовым сервером. '''LXF'''

----

===Решение проблем (врезка)===

[[Изображение:LXF103_68_1.png|thumb|300px|Пример использования команды telnet.]]

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

1. На клиенте проверьте, что почтовый сервер пингуется по его IP-адресу и имени, используя команды:
<code>
# ping 192.168.0.41
# ping mail.example.com
</code>
(Естественно, подставьте сюда IP-адреc вашего сервера.)

2. На сервере проверьте, что серверы SMTP и POP слушают соединения, используя команду
<code>
# netstat -at
</code>

Вы должны увидеть LISTEN в конце информации о портах SMTP и POP3.

3. На клиенте, попробуйте использовать telnet для соединения с портом 25 на почтовом сервере, используя команду:
<code>
# telnet mail.example.com 25
</code>

Вы должны получить отклик с сервера типа такого:
<code>
220 mail.example.com ESMTP Postfix
</code>

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

4. На сервере проверьте, что брандмауэр не блокирует доступ к портам 25 (SMTP) и 110 (POP3), используя команду:
<code>
# iptables -L
</code>

Если вы не уверены, отключите брандмауэр командой:
<code>
# itables -F
</code>
и попробуйте снова. Не забудьте потом восстановить работоспособность брандмауэра.

5. На сервере поищите разгадку в системных журналах почты (обычно /var/log/maillog).

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

LXF103:Hardcore Linux

2009-03-28T22:22:12Z

Kipruss: /* Продолжение следует */

==Почта: собери свой сервер==

Большинство людей пользуется электронной почтой, понятия не имея, как она работает. Светоч знаний '''д-ра Криса Брауна''' рассеет тьму невежества.

Чтобы вы могли представить, с чем вообще едят почтовый сервер, взгляните на '''Рис. 1''': там показана схема доставки почты в Интернете.

[[Изображение:LXF103_67_1.png|thumb|300px|Рис. 1: Один день из жизни почтового сообщения.]]

Проследим продвижение почтового сообщения на его пути через Интернет от отправителя к получателю и разберемся, как все компоненты работают совместно. Пусть Маша сидит за своим компьютером и составляет электронное послание, используя почтовый клиент (Mail User Agent – MUA). В мире Linux клиент Маши будет чем-то вроде ''Evolution'' или ''KMail''. Она пишет своей маме Ане, электронный адрес которой '''<nowiki>anna@example.com</nowiki>'''. Когда Маша нажимает кнопку Послать, ее MUA соединяется с Mail Transport Agent (MTA – почтовым транспортным агентом), на который Маша настроила свой MUA для отправки почты. Обычно MTA предоставляется Маше ее интернет-провайдером (ISP). MUA и MTA говорят друг с другом на языке протокола SMTP (Simple Mail Transfer Protocol – простой протокол передачи почты), организовывая доставку сообщений. В ходе этого диалога MUA определяет получателя сообщения и передает текст письма.

MTA отвечает за «дальнюю перевозку» сообщения. Он сделает запрос к DNS (Domain Name System, системе доменных имен) на поиск записи MX (Mail Exchanger), которая скажет ему, какая машина действует как почтовый сервер для домена '''<nowiki>example.com</nowiki>''', где расположен Анин почтовый ящик. Из этого запроса он может узнать, что почтовый сервер, допустим, '''<nowiki>mail.example.com</nowiki>'''. MTA Маши теперь соединяется с MTA на '''<nowiki>mail.example.com</nowiki>''', снова использует SMTP для указания получателя письма и передает тело сообщения. Принимающий MTA проверяет, что он и вправду почтовый сервер для домена получателя, а потом уж дает согласие на прием. Если все проходит нормально, принимающий MTA передает сообщение MDA (Mail Delivery Agent – почтовому агенту доставки), который сохраняет сообщение в хранилище сообщений (оно находится в файловой системе почтового сервера). Для этого сообщения работа MTA выполнена.

Аня проводит выходные с дядей Васей, помогая ему разбирать чердак, и не может в эти дни читать почту. Но когда она доберется до компьютера, ее почтовый клиент соединится с Mail Access Agent (MAA – агентом доступа к почте) на ее почтовом сервере '''<nowiki>example.com</nowiki>''' для проверки почты, которую MTA ее домена сохранил в ее хранилище. Ее MUA может использовать для этого один или два протокола. Чаще всего это Post Office Protocol (POP3 – почтовый протокол) версии 3. POP – это протокол, который скачивает почту с почтового сервера, затем (как правило) удаляет ее с сервера и оставляет ее на клиенте (компьютере в Аниной квартире), обеспечивая долговременное хранение сообщения. Но если Аня работает в корпорации Example.Com, данное учреждение может иметь почтовый сервер, работающий по протоколу IMAP4. IMAP расшифровывается как Internet Message Access Protocol [интернетпротокол доступа к сообщениям]; он позволяет Аниному MUA получать доступ к ее почтовому архиву, но долговременное хранение писем происходит на сервере (хотя некоторые MUA поддерживают локальные копии). Благодаря IMAP можно подключаться к серверу с любого компьютера с IMAP-клиентом и видеть весь почтовый архив – а вот если бы вы читали почту, используя POP на разных машинах, то в итоге ваши письма были бы раскиданы по этим машинам, что я знаю по своему горькому опыту.

Наш почтовый сервер изображен на Рисунке 1 как большой серый квадрат в правом верхнем углу. В реальности необходимы два компьютера – один для почтового сервера, другой для клиента. Возьмем ''Postfix'' как SMTP-сервер и ''Dovecot'' как почтовый POP3-сервер. На почтовом сервере моя основная ОС – CentOS 5 (CentOS – это клон Red Hat Enterprise Linux), но конфигурация и операции с ''Postfix'' и ''Dovecot'' не зависят от используемого дистрибутива Linux. Клиентская машина может быть любой. В моем случае на ней Ubuntu 7.04 с ''Evolution'' в качестве MUA.

===Начнем: Mail Transfer Agent===

Сперва мы установим ''Postfix''. Но предварительно проверим: вдруг ''Sendmail'' уже установлен и запущен. На системах типа Red Hat это могут сделать следующие команды:
<code>
# rpm -q sendmail
# service sendmail status
</code>

Если ''Sendmail'' запущен, надо его остановить и позаботиться, чтобы он не запустился после перезагрузки:
<code>
# service sendmail stop
# chkconfig sendmail --del
</code>

При наличии на вашей машине включенного брандмауэра, вы должны открыть порт для SMTP (tcp/25).

Моя собственная установка ''Postfix'' споткнулась, обнаружив отсутствие административной группы под названием postdrop. То есть до установки пакетов нужно было создать эту группу:
<code>
# groupadd -r postdrop
# yum install postfix
</code>

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

Для обеспечения запуска сервиса ''Postfix'' при загрузке, запустите команду
<code>
# chkconfig --add postfix
</code>

Файл настройки ''Postfix'' – '''/etc/postfix/main.cf'''. Фактически, ''Postfix'' должен заработать «из коробки» как простой почтовый сервер с минимальной доработкой готовой конфигурации, но есть несколько параметров, требующих внимания. Так, строку в '''main.cf'''
<code>
inet_interfaces = localhost
</code>
нужно заменить на
<code>
inet_interfaces = all
</code>

Это мы велим ''Postfix'' слушать SMTP соединения на всех сетевых интерфейсах машины, а не только на локальном (localhost).

Далее проверим установки параметра myhostname. Он определяет FQDN этой почтовой системы. Если он не определен, то по умолчанию берется имя хоста машины, на которой запущен сервер, возвращаемое командой hostname. Так, если ваш хост – '''<nowiki>mail.example.com</nowiki>''', это имя и будет принято по умолчанию.

Наконец, параметр mydestination задает список доменов, которые эта машина считает для себя пунктом назначения (то есть домены, для которых машина сохраняет сообщения). Минимальное значение этого параметра должно походить на следующее:
<code>
mydestination = example.com
</code>

Установив все эти параметры, можно запускать ''Postfix''. На RedHat-совместимых системах это делается командой
<code>
# service postfix start
</code>

Далее, я создал учетную запись для пользователя anna и установил пароль:
<code>
# useradd anna
# passwd anna
</code>

Без них не обойтись, потому что «локальный» агент доставки почты в ''Postfix'' требует, чтобы получатель имел учетную запись в Linux-системе: по ней происходит аутентификация в ''Dovecot'' (который мы рассмотрим чуть позже).

Теперь у нас все готово для теста доставки почты в хранилище сообщений. На моей настольной системе с Ubuntu я создал запись в файле '''/etc/hosts''', возвращающую IP-адрес машины '''<nowiki>mail.example.com</nowiki>'''. В моем случае строка выглядела так:
<code>
192.168.0.41 mail.example.com
</code>

В реальности, почтовый сервер должен иметь DNS-запись, и вам не нужно задавать ее в '''/etc/hosts'''. Затем я сконфигурировал «учетную запись» в моем MUA (''Evolution'') на использование SMTP-сервера '''<nowiki>mail.example.com</nowiki>''' для исходящих сообщений. Я включил эту учетную запись Evolution и отключил остальные. Затем я попытался послать несколько писем на '''<nowiki>anna@example.com</nowiki>'''.

Сработало? Ну, тот факт, что письма исчезли из моих Исходящих [Outbox] в ''Evolution'', уже обнадеживал, но лучший способ проверки – найти сообщения сохраненными на почтовом сервере. Что выводит нас на ...

===Хранилище сообщений===

Традиционный способ хранения сообщений на почтовом сервере известен как формат Mbox: для каждого пользователя хранится отдельный текстовый файл. Имя этого файла совпадает с именем учетной записи пользователя, чью почту он хранит, а каталог определяется параметром mail_spool_directory настройки ''Postfix'' (обычно '''/var/spool/mail''' или '''/var/mail'''). Например, Анины сообщения могут заноситься в '''/var/spool/mail/anna'''. Внутри этого файла каждое сообщение начинается строкой с первым словом “From” и заканчивается пустой строкой. (Вас может сбить с толку наличие в этом файле других строк, тоже начинающихся на “From:” – заметили двоеточие? Это часть заголовков сообщения.) Надеюсь, ''Postfix'' вписал мое тестовое сообщение в этот файл.

Альтернативная схема хранения сообщений (также называемая форматом Maildir) использует отдельную директорию для каждого пользователя (обычно это поддиректория с названием '''maildir''' внутри домашнего каталога пользователя) и, внутри нее, отдельный файл для каждого сообщения. При этом меньше шансов заблокировать или угробить все сообщения разом, чем в формате Mbox.

Если посланное вами сообщение появилось в хранилище, пора перейти к нашему POP3-серверу. Если его нет, прочитайте советы во врезке ''Решение проблем'', внизу .

===Установка и настройка Dovecot===

На моей CentOS для установки ''Dovecot'' надо всего лишь скомандовать:
<code>
# yum install dovecot
</code>

Теперь нужно найти файл конфигурации ''Dovecot''. Обычно это '''/etc/dovecot.conf'''. Как типичный современный файл конфигурации, он довольно длинен (более 1000 строк), но почти целиком состоит из комментариев. Как оказалось, мне нужно было изменить две строчки; одна задает протокол(ы), которые должен обслуживать ''Dovecot'', а вторая говорит, где находятся файлы почтового ящика. Эти два параметра я изменил так:
<code>
protocols = pop3
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%n
</code>

Первая строка говорит, что мы будем использовать только протокол POP3. Во второй строке, установка INBOX использует специальный параметр %n для замены именем пользователя, под которым мы зашли проверить почту (в нашем примере – “anna”). Заметим, что значение параметра INBOX должно совпадать с расположением хранилища почты, указанном в ''Postfix''.

Если у вас на почтовом сервере запущен брандмауэр, нужно также открыть порт POP3 (110/tcp).

Теперь мы готовы к запуску сервиса:
<code>
# service dovecot start
</code>

Пора тестировать. На клиенте, в настройках MUA мне необходимо установить для приема почты использование протокола POP и сервера '''<nowiki>mail.example.com</nowiki>''', затем задать имя '''anna''' и отключить опции шифрования, предлагаемые MUA. Теперь я готов принять мои сообщения. В этом пункте мой MUA должен (надеюсь) запросить пароль '''anna''', а мне необходимо предоставить пароль, который я задал, создавая ее учетную запись Linux на сервере. Если все пройдет гладко, вы должны увидеть ранее посланные письма появившимися во Входящих MUA. И если вы вернетесь на сервер, то обнаружите, что сообщения исчезли из хранилища anna. Если опять ничего не выйдет, обратитесь ко врезке ''Решение проблем''.

===Ура, оно работает!===

Если вы дошли досюда, поздравляем! У вас появился работающий почтовый сервер. Как обычно, я создавал максимально простую конфигурацию, чтобы все поскорее заработало. Однако эта реализация подразумевает несколько допущений: во-первых, почтовый сервер обслуживает только один домен ('''<nowiki>example.com</nowiki>'''), а во-вторых, все пользователи, желающие получать почту, имеют учетные записи Linux на почтовом сервере. Это последнее ограничение задается как со стороны локального агента доставки в ''Postfix'', так и ''Dovecot'', который, в своей конфигурации по умолчанию, требует действующей учетной записи Linux для аутентификации пользователей, для входа через POP и получения электронной почты. Отметим также, что в нашей конфигурации MTA (''Postfix'') не требуется аутентификации пользователя, в отличие от MAA (''Dovecot'').

===Поддерживаем несколько доменов===

В реальных условиях одной машине приходится быть почтовым сервером для множества доменов. Самый простой путь это обеспечить – добавить домены в параметр mydestination в '''/etc/Postfix/main.cf'''. Например, установка:
<code>
mydestination = example.com example.org example.net
</code>
велит Postfix принимать почту для трех указанных доменов. Конечно, если вы что-то поменяли в '''main.cf''', нужно заставить postfix перечитать его:
<code>
# service postfix reload
</code>

Конечно, надо также обеспечить, чтобы MX-записи в DNS для всех трех доменов ссылались на сервер '''<nowiki>mail.example.com</nowiki>'''. Однако эта методика имеет ограниченное применение, поскольку у всех доменов – общее пространство имен: так, почта на '''<nowiki>anna@example.com</nowiki>''', '''<nowiki>anna@example.org</nowiki>''' и '''<nowiki>anna@example.net</nowiki>''' будет в конце концов сохранена в одном и том же месте. И, конечно, Ане (и всем другим получателям почты) нужна учетная запись Linux на сервере.

Более гибкое решение – использовать так называемые «виртуальные» почтовые домены. При таком способе каждый домен имеет отдельное пространство имен, и письма для '''<nowiki>anna@example.com</nowiki>''' и '''<nowiki>anna@example.net</nowiki>''' окажутся в разных хранилищах почты. Получателю также не требуется иметь системную учетную запись Linux. Но зато требуется чуть больше работы по настройке...

Требуемые для этого строки в '''main.cf''' показаны в Листинге А ниже. Учтите, что номера строк проставлены только для удобства ссылки: в файле их нет.

{{Врезка
|Заголовок=Альтернативы
|Содержание=Как всегда в Linux, существует несколько программных решений для построения почтового сервера. Для MTA вы можете использовать ''Postfix'', ''Exim'' или почтенный ''Sendmail''. ''Postfix'' – самый юный; он написан Вьетсе Венема <nowiki>[Wietse Venema]</nowiki> в 1999 году, имеет прекрасную репутацию по безопасности и служит MTA по умолчанию во многих текущих дистрибутивах Linux. Exim был разработан в 1995 году в Кембриджском университете Филипом Хейзелом <nowiki>[Philip Hazel]</nowiki>. ''Sendmail'' написан Эриком Оллманом <nowiki>[Eric Allman]</nowiki> в 1983 году; много лет он тянул на себе большинство интернет-почты, и стало почти обязательным ссылаться на него, как на «почтенный», хотя у него самый непонятный файл конфигурации по эту сторону Бетельгейзе. Для MAA тоже есть выбор. Это может быть IMAP-сервер ''Cyrus'', ''Courier'', ''qpopper'', инструментарий IMAP University of Washington, Dovecot и другие. Более подробный список и сравнение почтовых серверов вы можете найти на http://en.wikipedia.org/wiki/Comparison_of_mail_servers.
|Ширина=200px}}

===ЛИСТИНГ A===
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
virtual_mailbox_domains = example.com example.org example.net
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/etc/Postfix/virtual_mailbox_map
virtual_uid_maps = static:550
virtual_gid_maps = static:101
</source>

Строка 1 в ''Листинге А'' содержит список доменов, которые будут поддерживаться. Их надо удалить из параметра mydestination, так как они теперь будут обрабатываться с использованием «виртуального» агента доставки ''Postfix'', и «локальный» агент им больше не нужен.

Если список доменов по-настоящему большой, вы можете предпочесть поместить его в отдельный файл, например, '''/etc/postfix/virtual_domains''', по образцу:
<code>
# list of virtual domains for postfix
example.com
example.net
example.org
# ... and lots more ...
</code>
и ссылаться на этот файл через параметр virtual_mailbox_domains в '''main.cf''':
<code>
virtual_mailbox_domains = /etc/postfix/virtual_domains
</code>

Аналогично, многие параметры в '''main.cf''' могут иметь список требуемых значений, помещенный в отдельный файл.

Строка 2 в ''Листинге А'' задает директорию верхнего уровня, где должны сохраняться сообщения. Очевидно, надо выбрать схему, совместимую с нашими POP- и IMAP-серверами. Здесь выбрано одно из множества возможных решений.

Создадим то, что ''Postfix'' называет «картой» – для отметки, где получатели почтовых адресов будут сохранять сообщения относительно заданного virtual_mailbox_base. Я создал простую карту в файле, который назвал '''/etc/postfix/virtual_mailbox_map''':
<code>
anna@example.com anna
anna@example.net anna_smith
chris@example.org cbrown
</code>

Теперь, например, письмо, посланное на '''<nowiki>anna@example.net</nowiki>''', будет сохранено в '''/var/spool/vmail/anna_smith'''; письмо, посланное на адрес '''<nowiki>chris@example.org</nowiki>''', «упадет» в '''/var/spool/vmail/cbrown''', и так далее. Заметьте, что здесь не требуется совпадения видимых снаружи имен пользователей (в нашем примере, '''anna''' и '''chris''') со внутренними именами (anna_smith и cbrown).

Конвертируем этот файл в «карту», используя команду postmap:
<code>
# postmap /etc/postfix/virtual_mailbox_map
</code>

В результате появится файл '''virtual_mailbox_map.db'''. Карта, в данном случае, просто вид индексированной структуры данных, ключи которой могут быть эффективно просмотрены ''Postfix''. ''Postfix'' поддерживает несколько типов «карт»; по умолчанию это обычно «хэш».

Далее, в строке 3 ''Листинга А'', вы сообщаете ''Postfix'', где находится карта.

''Postfix'' нуждается в отождествлении пользователя, используемом для доставки сообщения в хранилище. Возможно задание нескольких карт (uid_map и gid_map), определяющих отдельные отождествления для всех и каждого получателя, но мы сделаем проще и используем одну и ту же личность для всех получателей. Я создал пользователя с именем '''postmanpat''' для этой цели.
<code>
# useradd -d /var/spool/vmail -g postdrop -u 550 -m postmanpat
</code>

Отметим, что домашняя директория '''postmanpat''' находится в моей выбранной директории '''virtual_ mailbox_base'''. Далее я смягчил права доступа в '''/var/spool/vmail''', чтобы Dovecot мог ей воспользоваться.
<code>
# chmod 755 /var/spool/vmail
</code>

Нет необходимости предварительно создавать файл сохраненных сообщений для индивидуальных получателей – ''Postfix'' сделает это по требованию. Наконец, строки 4 и 5 Листинга А задают тождество пользователя и группы, которые ''Postfix'' будет использовать для помещения сообщений в хранилище. Они соответствуют ID пользователя postmanpat и группы postdrop.

После внесения данных изменений та часть, за которую отвечает ''Postfix'', должна работать. Возвратитесь к клиентской машине и пошлите тестовое сообщение на '''<nowiki>chris@example.org</nowiki>'''. На сервере проверьте, что это сообщение появилось в '''/var/spool/vmail/cbrown'''. Если да, то доставка ''Postfix'' на виртуальные почтовые домены работает!

На стороне ''Dovecot'' я просто изменил определение параметра mail_location на следующее:
<code>
mail_location = mbox:~/mail:INBOX=/var/spool/vmail/%n
</code>

===Продолжение следует===

Пока мы не касались аутентификации POP3 при входе в ''Dovecot''. В текущем состоянии, чтобы Dovecot заработал, вам необходимо создать очередные учетные записи Linux пользователям anna, anna_smith и cbrown, для новой аутентификации ''Dovecot''. Чтобы виртуальные домены применялись правильно, необходимо рассмотреть вопрос об аутентификации учетных записей POP3 через базу данных пользователей, не зависящую от учетных записей Linux. На данном уроке уже подпущено достаточно ежей под череп, но в следующем номере ''Linux Format'' я попытаюсь решить вопрос об аутентификации внутри почтовых систем и в ''Postfix'' и в ''Dovecot''. Пишите на mailto://answers@linuxformat.ru, если у вас возникнут проблемы с вашим почтовым сервером. '''LXF'''

----

===Решение проблем (врезка)===

[[Изображение:LXF103_68_1.png|thumb|300px|Пример использования команды telnet.]]

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

1. На клиенте проверьте, что почтовый сервер пингуется по его IP-адресу и имени, используя команды:
<code>
# ping 192.168.0.41
# ping mail.example.com
</code>
(Естественно, подставьте сюда IP-адреc вашего сервера.)

2. На сервере проверьте, что серверы SMTP и POP слушают соединения, используя команду
<code>
# netstat -at
</code>

Вы должны увидеть LISTEN в конце информации о портах SMTP и POP3.

3. На клиенте, попробуйте использовать telnet для соединения с портом 25 на почтовом сервере, используя команду:
<code>
# telnet mail.example.com 25
</code>

Вы должны получить отклик с сервера типа такого:
<code>
220 mail.example.com ESMTP Postfix
</code>

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

4. На сервере проверьте, что брандмауэр не блокирует доступ к портам 25 (SMTP) и 110 (POP3), используя команду:
<code>
# iptables -L
</code>

Если вы не уверены, отключите брандмауэр командой:
<code>
# itables -F
</code>
и попробуйте снова. Не забудьте потом восстановить работоспособность брандмауэра.

5. На сервере поищите разгадку в системных журналах почты (обычно /var/log/maillog).

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

LXF103:Hardcore Linux

2009-03-28T22:19:45Z

Kipruss: викификация

==Почта: собери свой сервер==

Большинство людей пользуется электронной почтой, понятия не имея, как она работает. Светоч знаний '''д-ра Криса Брауна''' рассеет тьму невежества.

Чтобы вы могли представить, с чем вообще едят почтовый сервер, взгляните на '''Рис. 1''': там показана схема доставки почты в Интернете.

[[Изображение:LXF103_67_1.png|thumb|300px|Рис. 1: Один день из жизни почтового сообщения.]]

Проследим продвижение почтового сообщения на его пути через Интернет от отправителя к получателю и разберемся, как все компоненты работают совместно. Пусть Маша сидит за своим компьютером и составляет электронное послание, используя почтовый клиент (Mail User Agent – MUA). В мире Linux клиент Маши будет чем-то вроде ''Evolution'' или ''KMail''. Она пишет своей маме Ане, электронный адрес которой '''<nowiki>anna@example.com</nowiki>'''. Когда Маша нажимает кнопку Послать, ее MUA соединяется с Mail Transport Agent (MTA – почтовым транспортным агентом), на который Маша настроила свой MUA для отправки почты. Обычно MTA предоставляется Маше ее интернет-провайдером (ISP). MUA и MTA говорят друг с другом на языке протокола SMTP (Simple Mail Transfer Protocol – простой протокол передачи почты), организовывая доставку сообщений. В ходе этого диалога MUA определяет получателя сообщения и передает текст письма.

MTA отвечает за «дальнюю перевозку» сообщения. Он сделает запрос к DNS (Domain Name System, системе доменных имен) на поиск записи MX (Mail Exchanger), которая скажет ему, какая машина действует как почтовый сервер для домена '''<nowiki>example.com</nowiki>''', где расположен Анин почтовый ящик. Из этого запроса он может узнать, что почтовый сервер, допустим, '''<nowiki>mail.example.com</nowiki>'''. MTA Маши теперь соединяется с MTA на '''<nowiki>mail.example.com</nowiki>''', снова использует SMTP для указания получателя письма и передает тело сообщения. Принимающий MTA проверяет, что он и вправду почтовый сервер для домена получателя, а потом уж дает согласие на прием. Если все проходит нормально, принимающий MTA передает сообщение MDA (Mail Delivery Agent – почтовому агенту доставки), который сохраняет сообщение в хранилище сообщений (оно находится в файловой системе почтового сервера). Для этого сообщения работа MTA выполнена.

Аня проводит выходные с дядей Васей, помогая ему разбирать чердак, и не может в эти дни читать почту. Но когда она доберется до компьютера, ее почтовый клиент соединится с Mail Access Agent (MAA – агентом доступа к почте) на ее почтовом сервере '''<nowiki>example.com</nowiki>''' для проверки почты, которую MTA ее домена сохранил в ее хранилище. Ее MUA может использовать для этого один или два протокола. Чаще всего это Post Office Protocol (POP3 – почтовый протокол) версии 3. POP – это протокол, который скачивает почту с почтового сервера, затем (как правило) удаляет ее с сервера и оставляет ее на клиенте (компьютере в Аниной квартире), обеспечивая долговременное хранение сообщения. Но если Аня работает в корпорации Example.Com, данное учреждение может иметь почтовый сервер, работающий по протоколу IMAP4. IMAP расшифровывается как Internet Message Access Protocol [интернетпротокол доступа к сообщениям]; он позволяет Аниному MUA получать доступ к ее почтовому архиву, но долговременное хранение писем происходит на сервере (хотя некоторые MUA поддерживают локальные копии). Благодаря IMAP можно подключаться к серверу с любого компьютера с IMAP-клиентом и видеть весь почтовый архив – а вот если бы вы читали почту, используя POP на разных машинах, то в итоге ваши письма были бы раскиданы по этим машинам, что я знаю по своему горькому опыту.

Наш почтовый сервер изображен на Рисунке 1 как большой серый квадрат в правом верхнем углу. В реальности необходимы два компьютера – один для почтового сервера, другой для клиента. Возьмем ''Postfix'' как SMTP-сервер и ''Dovecot'' как почтовый POP3-сервер. На почтовом сервере моя основная ОС – CentOS 5 (CentOS – это клон Red Hat Enterprise Linux), но конфигурация и операции с ''Postfix'' и ''Dovecot'' не зависят от используемого дистрибутива Linux. Клиентская машина может быть любой. В моем случае на ней Ubuntu 7.04 с ''Evolution'' в качестве MUA.

===Начнем: Mail Transfer Agent===

Сперва мы установим ''Postfix''. Но предварительно проверим: вдруг ''Sendmail'' уже установлен и запущен. На системах типа Red Hat это могут сделать следующие команды:
<code>
# rpm -q sendmail
# service sendmail status
</code>

Если ''Sendmail'' запущен, надо его остановить и позаботиться, чтобы он не запустился после перезагрузки:
<code>
# service sendmail stop
# chkconfig sendmail --del
</code>

При наличии на вашей машине включенного брандмауэра, вы должны открыть порт для SMTP (tcp/25).

Моя собственная установка ''Postfix'' споткнулась, обнаружив отсутствие административной группы под названием postdrop. То есть до установки пакетов нужно было создать эту группу:
<code>
# groupadd -r postdrop
# yum install postfix
</code>

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

Для обеспечения запуска сервиса ''Postfix'' при загрузке, запустите команду
<code>
# chkconfig --add postfix
</code>

Файл настройки ''Postfix'' – '''/etc/postfix/main.cf'''. Фактически, ''Postfix'' должен заработать «из коробки» как простой почтовый сервер с минимальной доработкой готовой конфигурации, но есть несколько параметров, требующих внимания. Так, строку в '''main.cf'''
<code>
inet_interfaces = localhost
</code>
нужно заменить на
<code>
inet_interfaces = all
</code>

Это мы велим ''Postfix'' слушать SMTP соединения на всех сетевых интерфейсах машины, а не только на локальном (localhost).

Далее проверим установки параметра myhostname. Он определяет FQDN этой почтовой системы. Если он не определен, то по умолчанию берется имя хоста машины, на которой запущен сервер, возвращаемое командой hostname. Так, если ваш хост – '''<nowiki>mail.example.com</nowiki>''', это имя и будет принято по умолчанию.

Наконец, параметр mydestination задает список доменов, которые эта машина считает для себя пунктом назначения (то есть домены, для которых машина сохраняет сообщения). Минимальное значение этого параметра должно походить на следующее:
<code>
mydestination = example.com
</code>

Установив все эти параметры, можно запускать ''Postfix''. На RedHat-совместимых системах это делается командой
<code>
# service postfix start
</code>

Далее, я создал учетную запись для пользователя anna и установил пароль:
<code>
# useradd anna
# passwd anna
</code>

Без них не обойтись, потому что «локальный» агент доставки почты в ''Postfix'' требует, чтобы получатель имел учетную запись в Linux-системе: по ней происходит аутентификация в ''Dovecot'' (который мы рассмотрим чуть позже).

Теперь у нас все готово для теста доставки почты в хранилище сообщений. На моей настольной системе с Ubuntu я создал запись в файле '''/etc/hosts''', возвращающую IP-адрес машины '''<nowiki>mail.example.com</nowiki>'''. В моем случае строка выглядела так:
<code>
192.168.0.41 mail.example.com
</code>

В реальности, почтовый сервер должен иметь DNS-запись, и вам не нужно задавать ее в '''/etc/hosts'''. Затем я сконфигурировал «учетную запись» в моем MUA (''Evolution'') на использование SMTP-сервера '''<nowiki>mail.example.com</nowiki>''' для исходящих сообщений. Я включил эту учетную запись Evolution и отключил остальные. Затем я попытался послать несколько писем на '''<nowiki>anna@example.com</nowiki>'''.

Сработало? Ну, тот факт, что письма исчезли из моих Исходящих [Outbox] в ''Evolution'', уже обнадеживал, но лучший способ проверки – найти сообщения сохраненными на почтовом сервере. Что выводит нас на ...

===Хранилище сообщений===

Традиционный способ хранения сообщений на почтовом сервере известен как формат Mbox: для каждого пользователя хранится отдельный текстовый файл. Имя этого файла совпадает с именем учетной записи пользователя, чью почту он хранит, а каталог определяется параметром mail_spool_directory настройки ''Postfix'' (обычно '''/var/spool/mail''' или '''/var/mail'''). Например, Анины сообщения могут заноситься в '''/var/spool/mail/anna'''. Внутри этого файла каждое сообщение начинается строкой с первым словом “From” и заканчивается пустой строкой. (Вас может сбить с толку наличие в этом файле других строк, тоже начинающихся на “From:” – заметили двоеточие? Это часть заголовков сообщения.) Надеюсь, ''Postfix'' вписал мое тестовое сообщение в этот файл.

Альтернативная схема хранения сообщений (также называемая форматом Maildir) использует отдельную директорию для каждого пользователя (обычно это поддиректория с названием '''maildir''' внутри домашнего каталога пользователя) и, внутри нее, отдельный файл для каждого сообщения. При этом меньше шансов заблокировать или угробить все сообщения разом, чем в формате Mbox.

Если посланное вами сообщение появилось в хранилище, пора перейти к нашему POP3-серверу. Если его нет, прочитайте советы во врезке ''Решение проблем'', внизу .

===Установка и настройка Dovecot===

На моей CentOS для установки ''Dovecot'' надо всего лишь скомандовать:
<code>
# yum install dovecot
</code>

Теперь нужно найти файл конфигурации ''Dovecot''. Обычно это '''/etc/dovecot.conf'''. Как типичный современный файл конфигурации, он довольно длинен (более 1000 строк), но почти целиком состоит из комментариев. Как оказалось, мне нужно было изменить две строчки; одна задает протокол(ы), которые должен обслуживать ''Dovecot'', а вторая говорит, где находятся файлы почтового ящика. Эти два параметра я изменил так:
<code>
protocols = pop3
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%n
</code>

Первая строка говорит, что мы будем использовать только протокол POP3. Во второй строке, установка INBOX использует специальный параметр %n для замены именем пользователя, под которым мы зашли проверить почту (в нашем примере – “anna”). Заметим, что значение параметра INBOX должно совпадать с расположением хранилища почты, указанном в ''Postfix''.

Если у вас на почтовом сервере запущен брандмауэр, нужно также открыть порт POP3 (110/tcp).

Теперь мы готовы к запуску сервиса:
<code>
# service dovecot start
</code>

Пора тестировать. На клиенте, в настройках MUA мне необходимо установить для приема почты использование протокола POP и сервера '''<nowiki>mail.example.com</nowiki>''', затем задать имя '''anna''' и отключить опции шифрования, предлагаемые MUA. Теперь я готов принять мои сообщения. В этом пункте мой MUA должен (надеюсь) запросить пароль '''anna''', а мне необходимо предоставить пароль, который я задал, создавая ее учетную запись Linux на сервере. Если все пройдет гладко, вы должны увидеть ранее посланные письма появившимися во Входящих MUA. И если вы вернетесь на сервер, то обнаружите, что сообщения исчезли из хранилища anna. Если опять ничего не выйдет, обратитесь ко врезке ''Решение проблем''.

===Ура, оно работает!===

Если вы дошли досюда, поздравляем! У вас появился работающий почтовый сервер. Как обычно, я создавал максимально простую конфигурацию, чтобы все поскорее заработало. Однако эта реализация подразумевает несколько допущений: во-первых, почтовый сервер обслуживает только один домен ('''<nowiki>example.com</nowiki>'''), а во-вторых, все пользователи, желающие получать почту, имеют учетные записи Linux на почтовом сервере. Это последнее ограничение задается как со стороны локального агента доставки в ''Postfix'', так и ''Dovecot'', который, в своей конфигурации по умолчанию, требует действующей учетной записи Linux для аутентификации пользователей, для входа через POP и получения электронной почты. Отметим также, что в нашей конфигурации MTA (''Postfix'') не требуется аутентификации пользователя, в отличие от MAA (''Dovecot'').

===Поддерживаем несколько доменов===

В реальных условиях одной машине приходится быть почтовым сервером для множества доменов. Самый простой путь это обеспечить – добавить домены в параметр mydestination в '''/etc/Postfix/main.cf'''. Например, установка:
<code>
mydestination = example.com example.org example.net
</code>
велит Postfix принимать почту для трех указанных доменов. Конечно, если вы что-то поменяли в '''main.cf''', нужно заставить postfix перечитать его:
<code>
# service postfix reload
</code>

Конечно, надо также обеспечить, чтобы MX-записи в DNS для всех трех доменов ссылались на сервер '''<nowiki>mail.example.com</nowiki>'''. Однако эта методика имеет ограниченное применение, поскольку у всех доменов – общее пространство имен: так, почта на '''<nowiki>anna@example.com</nowiki>''', '''<nowiki>anna@example.org</nowiki>''' и '''<nowiki>anna@example.net</nowiki>''' будет в конце концов сохранена в одном и том же месте. И, конечно, Ане (и всем другим получателям почты) нужна учетная запись Linux на сервере.

Более гибкое решение – использовать так называемые «виртуальные» почтовые домены. При таком способе каждый домен имеет отдельное пространство имен, и письма для '''<nowiki>anna@example.com</nowiki>''' и '''<nowiki>anna@example.net</nowiki>''' окажутся в разных хранилищах почты. Получателю также не требуется иметь системную учетную запись Linux. Но зато требуется чуть больше работы по настройке...

Требуемые для этого строки в '''main.cf''' показаны в Листинге А ниже. Учтите, что номера строк проставлены только для удобства ссылки: в файле их нет.

{{Врезка
|Заголовок=Альтернативы
|Содержание=Как всегда в Linux, существует несколько программных решений для построения почтового сервера. Для MTA вы можете использовать ''Postfix'', ''Exim'' или почтенный ''Sendmail''. ''Postfix'' – самый юный; он написан Вьетсе Венема <nowiki>[Wietse Venema]</nowiki> в 1999 году, имеет прекрасную репутацию по безопасности и служит MTA по умолчанию во многих текущих дистрибутивах Linux. Exim был разработан в 1995 году в Кембриджском университете Филипом Хейзелом <nowiki>[Philip Hazel]</nowiki>. ''Sendmail'' написан Эриком Оллманом <nowiki>[Eric Allman]</nowiki> в 1983 году; много лет он тянул на себе большинство интернет-почты, и стало почти обязательным ссылаться на него, как на «почтенный», хотя у него самый непонятный файл конфигурации по эту сторону Бетельгейзе. Для MAA тоже есть выбор. Это может быть IMAP-сервер ''Cyrus'', ''Courier'', ''qpopper'', инструментарий IMAP University of Washington, Dovecot и другие. Более подробный список и сравнение почтовых серверов вы можете найти на http://en.wikipedia.org/wiki/Comparison_of_mail_servers.
|Ширина=200px}}

===ЛИСТИНГ A===
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
virtual_mailbox_domains = example.com example.org example.net
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/etc/Postfix/virtual_mailbox_map
virtual_uid_maps = static:550
virtual_gid_maps = static:101
</source>

Строка 1 в ''Листинге А'' содержит список доменов, которые будут поддерживаться. Их надо удалить из параметра mydestination, так как они теперь будут обрабатываться с использованием «виртуального» агента доставки ''Postfix'', и «локальный» агент им больше не нужен.

Если список доменов по-настоящему большой, вы можете предпочесть поместить его в отдельный файл, например, '''/etc/postfix/virtual_domains''', по образцу:
<code>
# list of virtual domains for postfix
example.com
example.net
example.org
# ... and lots more ...
</code>
и ссылаться на этот файл через параметр virtual_mailbox_domains в '''main.cf''':
<code>
virtual_mailbox_domains = /etc/postfix/virtual_domains
</code>

Аналогично, многие параметры в '''main.cf''' могут иметь список требуемых значений, помещенный в отдельный файл.

Строка 2 в ''Листинге А'' задает директорию верхнего уровня, где должны сохраняться сообщения. Очевидно, надо выбрать схему, совместимую с нашими POP- и IMAP-серверами. Здесь выбрано одно из множества возможных решений.

Создадим то, что ''Postfix'' называет «картой» – для отметки, где получатели почтовых адресов будут сохранять сообщения относительно заданного virtual_mailbox_base. Я создал простую карту в файле, который назвал '''/etc/postfix/virtual_mailbox_map''':
<code>
anna@example.com anna
anna@example.net anna_smith
chris@example.org cbrown
</code>

Теперь, например, письмо, посланное на '''<nowiki>anna@example.net</nowiki>''', будет сохранено в '''/var/spool/vmail/anna_smith'''; письмо, посланное на адрес '''<nowiki>chris@example.org</nowiki>''', «упадет» в '''/var/spool/vmail/cbrown''', и так далее. Заметьте, что здесь не требуется совпадения видимых снаружи имен пользователей (в нашем примере, '''anna''' и '''chris''') со внутренними именами (anna_smith и cbrown).

Конвертируем этот файл в «карту», используя команду postmap:
<code>
# postmap /etc/postfix/virtual_mailbox_map
</code>

В результате появится файл '''virtual_mailbox_map.db'''. Карта, в данном случае, просто вид индексированной структуры данных, ключи которой могут быть эффективно просмотрены ''Postfix''. ''Postfix'' поддерживает несколько типов «карт»; по умолчанию это обычно «хэш».

Далее, в строке 3 ''Листинга А'', вы сообщаете ''Postfix'', где находится карта.

''Postfix'' нуждается в отождествлении пользователя, используемом для доставки сообщения в хранилище. Возможно задание нескольких карт (uid_map и gid_map), определяющих отдельные отождествления для всех и каждого получателя, но мы сделаем проще и используем одну и ту же личность для всех получателей. Я создал пользователя с именем '''postmanpat''' для этой цели.
<code>
# useradd -d /var/spool/vmail -g postdrop -u 550 -m postmanpat
</code>

Отметим, что домашняя директория '''postmanpat''' находится в моей выбранной директории '''virtual_ mailbox_base'''. Далее я смягчил права доступа в '''/var/spool/vmail''', чтобы Dovecot мог ей воспользоваться.
<code>
# chmod 755 /var/spool/vmail
</code>

Нет необходимости предварительно создавать файл сохраненных сообщений для индивидуальных получателей – ''Postfix'' сделает это по требованию. Наконец, строки 4 и 5 Листинга А задают тождество пользователя и группы, которые ''Postfix'' будет использовать для помещения сообщений в хранилище. Они соответствуют ID пользователя postmanpat и группы postdrop.

После внесения данных изменений та часть, за которую отвечает ''Postfix'', должна работать. Возвратитесь к клиентской машине и пошлите тестовое сообщение на '''<nowiki>chris@example.org</nowiki>'''. На сервере проверьте, что это сообщение появилось в '''/var/spool/vmail/cbrown'''. Если да, то доставка ''Postfix'' на виртуальные почтовые домены работает!

На стороне ''Dovecot'' я просто изменил определение параметра mail_location на следующее:
<code>
mail_location = mbox:~/mail:INBOX=/var/spool/vmail/%n
</code>

===Продолжение следует===

Пока мы не касались аутентификации POP3 при входе в ''Dovecot''. В текущем состоянии, чтобы Dovecot заработал, вам необходимо создать очередные учетные записи Linux пользователям anna, anna_smith и cbrown, для новой аутентификации ''Dovecot''. Чтобы виртуальные домены применялись правильно, необходимо рассмотреть вопрос об аутентификации учетных записей POP3 через базу данных пользователей, не зависящую от учетных записей Linux. На данном уроке уже подпущено достаточно ежей под череп, но в следующем номере ''Linux Format'' я попытаюсь решить вопрос об аутентификации внутри почтовых систем и в ''Postfix'' и в ''Dovecot''. Пишите на answers@linuxformat.ru, если у вас возникнут проблемы с вашим почтовым сервером. '''LXF'''

----

===Решение проблем (врезка)===

[[Изображение:LXF103_68_1.png|thumb|300px|Пример использования команды telnet.]]

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

1. На клиенте проверьте, что почтовый сервер пингуется по его IP-адресу и имени, используя команды:
<code>
# ping 192.168.0.41
# ping mail.example.com
</code>
(Естественно, подставьте сюда IP-адреc вашего сервера.)

2. На сервере проверьте, что серверы SMTP и POP слушают соединения, используя команду
<code>
# netstat -at
</code>

Вы должны увидеть LISTEN в конце информации о портах SMTP и POP3.

3. На клиенте, попробуйте использовать telnet для соединения с портом 25 на почтовом сервере, используя команду:
<code>
# telnet mail.example.com 25
</code>

Вы должны получить отклик с сервера типа такого:
<code>
220 mail.example.com ESMTP Postfix
</code>

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

4. На сервере проверьте, что брандмауэр не блокирует доступ к портам 25 (SMTP) и 110 (POP3), используя команду:
<code>
# iptables -L
</code>

Если вы не уверены, отключите брандмауэр командой:
<code>
# itables -F
</code>
и попробуйте снова. Не забудьте потом восстановить работоспособность брандмауэра.

5. На сервере поищите разгадку в системных журналах почты (обычно /var/log/maillog).

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

Файл:LXF103 68 1.png

2009-03-28T21:26:08Z

Kipruss: Пример использования команды telnet

Пример использования команды telnet

Файл:LXF103 67 1.png

2009-03-28T20:58:51Z

Kipruss: Рис. 1: Один день из жизни почтового сообщения.

Рис. 1: Один день из жизни почтового сообщения.

LXF102

2009-03-07T21:54:54Z

Kipruss: дополнение

=== Учебники ===

* [[LXF102:Hardcore Linux|'''Hardcore Linux.''' Виртуальный сервер Linux.]]
Строить сбалансированный по нагрузке кластер с LVS – отличный способ согреться в зимний день: не хуже, чем колоть дрова, уверяет д-р Крис Браун.
* R: данные и графики
[[Категория:Математические пакеты]]

* [[LXF102:Кодирование DVD|DVD: уложиться в формат]]
Что делать, если отснятый вами материал чуть-чуть не умещается на DVD-диск.

LXF102:Hardcore Linux

2009-03-07T21:50:29Z

Kipruss: викификация

==Виртуальный сервер Linux==

Строить сбалансированный по нагрузке кластер с LVS – отличный способ согреться
в зимний день: не хуже, чем колоть дрова, уверяет '''д-р Крис Браун'''.

Данный урок покажет вам, как создать сбалансированный по нагрузке кластер web-серверов, с масштабируемой производительностью, значительно превышающей возможности индивидуального сервера. Мы будем использовать программное обеспечение для кластеров от Red Hat, но основная функциональность, описанная в данном учебнике, основана на модуле виртуального сервера ядра Linux и не привязана к Red Hat.

Если вы захотите последовать уроку «в натуре», вам потребуется как минимум четыре компьютера, как показано на рис. 1 (на следующей странице). Я понимаю, что для некоторых читателей такой проект будет практически недосягаемым, но, надеюсь, он пригодится как мысленный эксперимент, вроде того, что Шредингер проделывал со своим котом.

Машина 1 – просто клиент, используемый для тестирования: ею может быть все, что имеет web-браузер. Я экспроприировал машину моей жены, на ней стоит Vista. Машина 2 – стенд для эксперимента. Она должна работать под Linux и, предпочтительно, иметь два сетевых интерфейса, как показано на рисунке. (Можно собрать кластер, используя всего одну сеть, но этот механизм не годится для промышленного применения и требует немного колдовства на уровне IP, чтобы заставить его работать.)

Эта машина выполняет обязанности балансировщика нагрузки и маршрутизатора в кластере, и в документации LVS ее называют “director” [активный маршрутизатор, – прим. пер.]. В моем случае на машине 2 запущен CentOS5 (по сути, эквивалент RHEL5). Машины 3 и 4 – дополнительные серверы [в документации их называют «реальными»]; в принципе, вы можете использовать что-то вроде webсерверов. Я использовал пару ноутбуков, один с SUSE 10.3, второй с Ubuntu 7.04. На деле вам потребуется больше дополнительных серверов, но двух достаточно для получения результата.

Вы, верно, недоумеваете, почему на всех четырех компьютеров я запустил разные ОС. Хороший вопрос – я сам часто его себе задаю! Увы, это просто факт из жизни тех из нас, кто зарабатывает на хлеб с Linux.

===Как работает сбалансированный по нагрузке кластер===

Машины клиентов посылают запрос (например, запрос на web-страницу HTTP GET) на публичный IP-адрес активного маршрутизатора (на рисунке, '''192.168.0.41'''; для клиентов это адрес, по которому предоставляется услуга).

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

Выбранный реальный сервер обрабатывает запрос и отсылает HTTP-ответ, который теоретически содержит запрошенную страницу. Этот ответ адресован клиентской машине ('''192.168.0.2'''), но вначале он возвращается к активному маршрутизатору ('''10.0.0.1'''), потому что тот сконфигурирован как шлюз по умолчанию для реальных серверов. Активный маршрутизатор меняет IP-адрес источника в пакете на свой публичный IP-адрес и посылает пакет обратно клиенту.

Все эти трюки на уровне IP выполняются с помощью LVS-модуля ядра Linux. Активный маршрутизатор работает не просто в качестве обратного web-прокси, и команды типа netstat -ant не покажут каких либо процессов уровня пользователя, прослушивающих 80 порт. Перезапись адреса – это разновидность NAT (Network Address Translation), позволяющая активному маршрутизатору маскироваться под реальный сервер, скрыв наличие внутренней сети, выполняющей реальную работу.

===Балансируя нагрузку===

Балансировка нагрузки – ключевая особенность LVS: благодаря ей, можно быть уверенным, что каждый реальный сервер получает примерно одинаковый объем работы. LVS имеет для этого несколько алгоритмов; мы упомянем четыре из них.

* '''Циклическое распределение [round-robin scheduling]''' – самый простой алгоритм. Активный маршрутизатор просто работает по кругу, переходя снова на первый реальный сервер, когда исчерпает список. Этот метод хорошо подходит для тестирования, потому что позволяет легко проверить на работоспособность все реальные сервера, но он не самый лучший при промышленном применении.
* '''Циклическое распределение с весовыми коэффициентами [weighted round-robin]''' – аналогично, но позволяет назначать для каждого реального сервера «вес», соответствующий его относительной скорости. Сервер с весовым коэффициентом «два» считается в два раза мощнее сервера с весовым коэффициентом «один», и может обработать в два раза больше запросов.
* '''Минимум соединений [least-connection]''' – наименее нагруженный сервер отслеживается по количеству активных соединений, и запрос отправляется на сервер с наименьшей загрузкой.
* '''Минимум соединений с весовыми коэффициентами [weighted least connection]''' также выполняет подсчет относительной производительности (весов) серверов. Этот метод хорош для производственных кластеров, потому что он прекрасно работает, когда запросы сильно различаются по времени их обработки и/или когда реальные сервера в кластере имеют различную мощность.

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

[[Изображение:LXF102_73_1.png|thumb|300px|Рис. 1. Простой кластер со сбалансированной нагрузкой.]]

===Инструменты для работы===

Чтобы все это заработало, ядро поддерживает таблицу виртуального сервера, которая содержит, кроме прочего, IP-адреса реальных серверов. Для поддержания и просмотра этой таблицы используется инструмент командной строки ''ipvsadm''.

Если ваше ядро (как большинство других современных ядер) собрано с поддержкой LVS, то ''ipvsadm'' – единственная программа, которую вы обязаны иметь, чтоб заставить LVS работать; однако есть другие инструменты, облегчающие жизнь. (Ситуация похожа на механизм пакетной фильтрации в ядре. В теории для управления им и создания межсетевого экрана нужна только утилита командной строки ''iptables'', на практике же большинство из нас использует для построения собственных правил фильтрации инструменты высокого уровня, часто графические). На данном уроке мы воспользуемся инструментами для кластеров от Red Hat, включая web-ориентированный инструмент настройки ''Piranha''.

Основной недостаток конфигурации, показанной на '''рис. 1''' – активный маршрутизатор является единой точкой отказа в пределах кластера. Чтобы этого избежать, можно использовать в качестве активного маршрутизатора пару серверов (основной и резервный); используя обмен сообщениями heartbeat, резервный сервер может определить сбой основного сервера и взять на себя его работу.

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

===Настраиваем реальные сервера===

Если вы хотите по-настоящему построить кластер, описанный на этом уроке, начните с реальных серверов. Это могут быть любые машины, имеющие web-сервер HTTP на 80-м порту; в моем случае на них был запущен Linux и ''Apache''.

Нужно создать какие-нибудь данные в директории '''DocumentRoot''' на каждом сервере, и для тестирования было бы неплохо, чтобы на каждой машине эти данные были свои: тогда легко различить, какой сервер обрабатывает запрос в данный момент. Например, на реальном сервере 1 я создал файл '''proverb.html''', содержащий строку «Дорога ложка к обеду». На сервере 2 строка была уже «Не зная броду, не суйся в воду». Конечно, в реальных условиях нужно, наоборот, «синхронизировать» все реальные сервера, чтобы они хранили одно и то же содержимое – к этой проблеме мы вернемся позднее.

Назначьте машинам реальные IP-адреса, предназначенные для внутренних сетей; в моем случае это '''10.0.0.2''' и '''10.0.0.3'''. Установите маршрутизацию по умолчанию на этих машинах на приватный IP-адрес активного маршрутизатора ('''10.0.0.1''').

[[Изображение:LXF102_74_1.jpg|thumb|200px|Рис. 2. Конфигурирование виртуального сервера с Piranha.]]

===Установка активного маршрутизатора===

На активном маршрутизаторе начните с закачки и установки инструментов кластеризации Red Hat. В моем случае (вспомните, что я запустил на этой машине CentOS5) я просто использовал графический инструмент установки (''pirut'') для добавления пакетов ''ipvsadm'' и ''Piranha'' из репозитория CentOS5. Моим следующим шагом был запуск команды piranha-passwd для установки пароля на инструмент конфигурации ''piranha'':
<code>
# /etc/init.d/piranha-gui start
</code>

[[Изображение:LXF102_74_2.jpg|thumb|200px|Рис. 3. Определяем реальные сервера.]]

Этот сервис слушает порт 3636 и предоставляет web-интерфейс для конфигурирования инструментов кластеризации, так что после его запуска мне осталось набрать в браузере '''<nowiki>http://localhost:3636</nowiki>''' для доступа к нему. Далее мне нужно было зайти, используя имя пользователя piranha и пароль, который я установил. После этого стали доступны четыре основных окна: Control/Monitoring, Global Settings, Redundancy и Virtual Servers (вы можете увидеть ссылку на них на '''рис. 3'''). Для начала зайдите в окно Virtual Servers и добавьте новый сервис. На '''рис. 2''' показана форма, которую вы должны заполнить. Среди прочего, вы должны задать имя сервиса, указать номер порта и интерфейс, через который он будет принимать пакеты, и выбрать алгоритм работы (для начального тестирования я выбрал ‘Round Robin’ [Циклическое распределение]). Кликнув на ссылку Real Server вверху этой страницы, вы попадете на страницу, показанную на '''рис. 3'''. Здесь вы должны указать имя, IP-адрес и веса ваших реальных серверов.

За кадром, большинство настроек, захваченных ''Piranha'', хранятся в файле конфигурации '''/etc/sysconfig/ha/lvs.cf'''. Другие инструменты кластеризации читают его; это обычный текстовый файл, и ник-

то не запрещает вам редактировать его напрямую. Выполнив данную настройку, можно начинать. Запустите сервис кластеризации из командной строки:
<code>
# /etc/init.d/pulse start
</code>

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

[[Изображение:LXF102_75_1.jpg|thumb|200px|Рис. 4. Экран управления и мониторинга Piranha.]]

Теперь идите на экран управления/мониторинга ''Piranha'', как показано на '''рис. 4'''. Внимательно посмотрите на таблицу маршрутизации LVS. Вы должны увидеть записи о вашем виртуальном сервере (это строки, начинающиеся с TCP...), а пониже – строки для каждого реального сервера. Ту же информацию можно добыть из командной строки, набрав
<code>
# ipvsadm -L
</code>

===Периодическая проверка здоровья===

Также на экране управления/мониторинга есть таблица процессов LVS. Здесь вы можете увидеть множество «процессов-нянек». Они отвечают за проверку присутствия и работоспособности реальных серверов – по няньке на сервер. Их работа – периодически посылать простой запрос HTTP GET и проверять ответ. Внимательно рассмотрев опции -s и -x для няньки, вы распознаете посылаемые и ожидаемые строки, используемые для теста. (Вы можете задать эти строки, как вам нравится, используя страницу Virtual Servers > Monitoring Scripts Piranha.)

{{Врезка
|Заголовок=Боитесь за узкие места?
|Содержание=Так как весь входящий и исходящий трафик идет через активный маршрутизатор, вы, возможно, опасаетесь, что его производительность создаст узкое место. Но это маловероятно. Вспомните, что активный маршрутизатор выполняет только простые манипуляции над заголовками пакетов внутри ядра; даже скромная машина способна разобраться со 100-мегабитной сетью. Более вероятно, что узким местом будет ширина канала при доступе к сайту. Для более подробной информации об использовании старых ПК для задач типа сетевых, см. [[LXF102:Вторая_жизнь_старого_ПК|спецрепортаж этого месяца]]
|Ширина=200px}}

Просмотрев журнал доступа ''Apache'' на реальном сервере, вы увидите, что эти запросы выполняются каждые шесть секунд. Если нянька обнаружит, что ее сервер замолк, она вызовет ''ipvsadm'' для удаления записи о машине из таблицы маршрутизации LVS, и активный маршрутизатор не сможет пересылать запросы на эту машину. Нянька будет продолжать опрашивать сервер, и если он восстановится, она снова запустит ''ipvsadm'' для восстановления записи маршрутизации.

Вы можете наблюдать такое поведение, отключив сетевой кабель от реального сервера (или просто остановив демон ''httpd'') и изучив таблицу маршрутизации LVS: окажется, что запись о вашем покойном сервере исчезла. Подключите сетевой кабель или перезапустите сервер, и запись возникнет снова. Будьте терпеливы: прежде чем эти изменения проявятся, может пройти 20 секунд, а то и больше.

===Развязка===

Если все в порядке, пора заняться клиентской машиной (под номером 1 на первом рисунке) и попробовать получить доступ к странице из браузера. В нашем примере, вы должны обратиться к '''<nowiki>http://192.168.0.41/proverbs.html</nowiki>''' и увидеть страницу с пословицей, хранящуюся на одном из ваших реальных серверов. Обновившись, вы увидите страницу с другой пословицей со следующего сервера в циклическом порядке. Можете также проверить поведение циклического распределения, изучив журнал доступа Apache на каждом реальном сервере. (Вглядевшись в записи журнала, вы увидите, что доступ был с '''192.168.0.2''', а няня запрашивала состояние с '''10.0.0.1'''.) Если все заработало, поздравляю! Вы только что построили свой первый сбалансированный по нагрузке Linux-кластер.

===Постскриптум===

Давайте сделаем паузу и выясним, что мы изучили на двух наших уроках. Мы увидели, как построить отказоустойчивое кластерное решение, добавляющее лишнюю девятку к коэффициенту доступности вашего сервиса (например, с доступности 99.9% до 99.99%); и увидели, как построить сбалансированный по нагрузке кластер, превышающий по производительности индивидуальный web-сервер. В обоих случаях мы использовали свободное, открытое ПО, запускаемое на свободной открытой ОС. Иногда я представляю, что именно об этом думает Стив Балмер на сон грядущий; и всякий раз мне чертовски приятно. '''LXF'''

----

===Если он не работает... (врезка)===

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

Это, конечно, не конструктивная мера, хотя бы вы и почувствовали себя лучше. И Microsoft обвинять не за что, потому что мы не пользуемся никаким ее программным обеспечением. Второй вариант – сделать несколько глубоких вдохов, успокоиться и провести серию диагностических тестов.

Первым делом неплохо проверить соединение с LVS-машиной, используя старый добрый ''ping''. Сперва убедитесь, что пингуется ваша тестовая машина ('''192.168.0.2'''). Затем проверьте доступность обоих реальных серверов ('''10.0.0.2''' и '''10.0.0.3'''). Если это не работает, запустите ifconfig -a и убедитесь, что '''eth0''' имеет IP-адрес '''192.168.0.41''', а '''eth1''' – '''10.0.0.1'''.

Также запустите route -n для проверки таблицы маршрутизации – убедитесь, что вы имеете маршруты к сетям '''192.168.0.0''' и '''10.0.0.0''' через соответствующие интерфейсы.

Если ваши реальные серверы пингуются, запустите web-браузер на LVS-машине (исходя из того, что браузер установлен – вообще-то он там ни к чему). Убедитесь, что вы можете открыть URL '''<nowiki>http://10.0.0.2</nowiki>''' и '''<nowiki>http://10.0.0.3</nowiki>''' и видите содержимое web-страниц, хранящихся на этих серверах. (Если машины пингуются, но web-сервера недоступны, убедитесь, что они запущены на реальных серверах и эти сервера не имеют правил брандмауэра, запрещающих к ним доступ.)

Нужно также внимательно проверить таблицу маршрутизации LVS, отображаемую на странице Control/Monitoring в ''Piranha'', и убедиться, что ваши реальные сервера там показаны. Если у вас опять ничего не вышло, проверьте, включена ли на LVS-машине маршрутизация IP-пакетов (IP-forwarding) – например, командой
<code>
# cat /proc/sys/net/ipv4/ip_forward
</code>

Если она вернет '''1''', то все прекрасно, а если '''0''', включайте функцию командой:
<code>
# echo 1 > /proc/sys/net/ipv4/ip_forward
</code>

Вы можете также проверить, настроено ли ваше ядро для работы с LVS. Если ваш дистрибутив содержит копию файла конфигурации, использованного при сборке ядра (с именем '''/boot/config-так-или-сяк'''), примените ''grep'' для поиска строки CONFIG_IP_VS и убедитесь, что вы видите CONFIG_IP_VS=m среди прочих. Вы также можете попробовать
<code>
# lsmod | grep vs
</code>
для проверки, что модуль ''ip_vs'' загружен. Если вы не можете найти доказательства поддержки виртуального сервера в ядре, придется перенастроить и пересобрать ядро; порядок действий при этом выходит за рамки данного урока.

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

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

Файл:LXF102 75 1.jpg

2009-03-07T21:03:50Z

Kipruss:

Рис. 4. Экран управления и мониторинга Piranha.

Файл:LXF102 75 1.jpg

2009-03-07T21:03:38Z

Kipruss: Рис. 5. Экран управления и мониторинга Piranha.

Рис. 5. Экран управления и мониторинга Piranha.

Файл:LXF102 74 2.jpg

2009-03-07T20:55:59Z

Kipruss: Рис. 3. Определяем реальные сервера.

Рис. 3. Определяем реальные сервера.

Файл:LXF102 74 1.jpg

2009-03-07T20:55:31Z

Kipruss: Рис. 2. Конфигурирование виртуального сервера с Piranha.

Рис. 2. Конфигурирование виртуального сервера с Piranha.

Файл:LXF102 73 1.png

2009-03-07T20:38:37Z

Kipruss: Рис. 1. Простой кластер со сбалансированной нагрузкой.

Рис. 1. Простой кластер со сбалансированной нагрузкой.

LXF98:Hardcore Linux

2009-03-07T20:23:02Z

Kipruss: /* Установка VirtualBox */

==VirtualBox: Windows в Ubuntu==

''Запускайте приложения Microsoft под Linux в Ubuntu Feisty при помощи VirtualBox от Innotek и Windows XP – '''Джек Найт''' здесь на коне….''

Требовалось ли вам когда-нибудь на вашей машине одно или несколько Windows-приложений для решения некоторой задачи? А может, у вас есть клиент, использующий Windows, и вам надо работать с документами ''MS Project'' или запускать непосредственно ''Outlook'' для совместного использования их календарей ''MS Exchange''? Один из выходов – двойная загрузка, другой – запуск Windows XP в качестве гостевой ОС на виртуальной машине (ВМ); но
есть действительно классное решение – угадайте, какое? Бесплатное, по крайней мере для большинства из нас! ''VirtualBox'' от ''Innotek'' – удивительный продукт, и хотя я на самом деле не проверял его производительность, навскидку кажется, что он значительно превосходит и ''VMWare Workstation'', и ''Server''. Он располагает набором приятных функций и возможностью организовать сетевой мост через беспроводной адаптер ноутбука (нечто прежде немыслимое в ''VMWare'') – чем не продукт-конфетка?

Innotek применяет дуальную схему лицензирования – существуют открытая и закрытая двоичная версии ''VirtualBox'' (последняя бесплатна для ознакомления или персонального использования). Более того, у Innonek весьма разумная политика лицензирования для малого бизнеса – по запросу о покупке коммерческих лицензий на две машины я был любезно извещен, что это относится к категории «бесплатно»! Уже в восторге? Ну, это только начало – а вот и убойный довод: при помощи этой штуки можно запускать отдельные приложения Windows на рабочем столе Linux, и они появятся как обычные окна Gnome, KDE (или другие) на вашем X-столе. Прибавьте сюда ''Beryl/Compiz'', и получите весьма впечатляющий инструмент. Качайте с [http://www.virtualbox.org www.virtualbox.org].

Но как заставить все это работать? Что ж, понадобится кое-какая подгонка и на стороне Linux, и на стороне Windows – но результат стоящий, по крайней мере, по моему скромному мнению. В этой статье я проведу вас через настройку моста через беспроводной адаптер на ноутбуке, а продолжу настройкой двух типичных приложений, зависящих от Windows – ''MS Project'' и ''Outlook'', чтобы под Ubuntu Feisty они выглядели как родные.

===План действий===

Вот что мы проделаем на следующих страницах:

*Кое-что подправим для устранения неприятностей с USB и DVD.
*Создадим TAP-устройство на сетевом интерфейсе базовой машины (идеально для WLAN-интерфейса ноутбука).
*Установим персональную/пробную версию ''VirtualBox'' от Innotek.
*Создадим ВМ для Windows XP и настроим ее на использование сетевого TAP-устройства.
*Установим Windows XP (самые общие моменты).
*Настроим Windows XP со всеми тонкостями, для безупречной работы.
*Настроим ''VirtualBox'' на работу без ручного вмешательства и автоматический старт.
*Введем пункты меню для наших приложений-примеров.

В детали установки гостевой ОС я вдаваться не буду: если кто не знает, как это сделать, описание найти легко. Зато приведу простой метод установки самого ''VirtualBox''.

Лично я использую на этом уроке Ubuntu 7.04 (Feisty), но эти инструкции должны отлично работать для dapper или edgy, при мелких изменениях (например, замене всех вхождений слова «feisty» по смыслу). Они должны работать и в Kubuntu; правда, я еще не проделывал мои операции в KDE, чтобы разобраться с отличиями. Машину, где запущен VirtualBox, я буду называть HOST [хост], а запущенные в нем системы – GUEST [гость]. Предполагается, что вы можете запускать командную оболочку и использовать редактор для изменения текстовых файлов. Прежде чем продолжить, познакомьтесь со врезкой
Избавляемся от неприятностей.

===Настраиваем TAP-устройство===

Нам нужно установить пакеты, а именно ''User Mode Linux Utilities'' и ''Proxy Arp Routing Daemon''. Для начала убедитесь, что подключен репозиторий '''universe''': в строке-меню Gnome выберите Система > Администрирование > Источники приложений, затем установите галочку Свободное ПО, поддерживаемое сообществом (universe). Теперь откройте терминал и введите:
<source lang="bash">
sudo apt-get install uml-utilities parprouted
sudo chgrp vboxusers /dev/net/tun
</source>

Теперь надо встроить TAP в сетевой адаптер хост-системы. Это особенно полезно для ноутбуков с беспроводными интерфейсами, поскольку WLAN-адаптер обычно получает IP-адрес через DHCP, но гостевая машина не может делать этого – как правило, несколько IP-адресов нельзя получить для того, что в сущности является клонированным интерфейсом. К тому же если беспроводной интерфейс использует защиту WPA, то появление интерфейса-клона, вероятно, заставит WAP
(Wireless Access Point – точка беспроводного доступа) заподозрить, что компьютер под атакой. Итак, сделаем вот что: выявим неиспользованные подсети, выберем пару уникальных IP-адресов и присвоим один TAP-устройству, а другой гостевой машине. Неважно, что они фиксированы: адрес хост-машины будет динамическим, и они будут проходить через маскардинг. В итоге гостевая машина будет «просто работать», где бы вы ни получили WLAN-соединение для хоста.

Проще всего создать скрипт для инициализации TAP-устройства и поддержки конфигурации сети. Вот мой вариант:
<source lang="bash">
#!/bin/bash
# Имя: tapctrl
# Использование: tapctrl start|stop
# Обеспечивает: tap для virtualbox во внешней сети, включая беспроводные
# Аннотация:
# устанавливает tap-устройство для совместного использования интерфейса wifi с vbox
# Описание: создает виртуальный tap-интерфейс, присваивает IP- адрес, настраивает iptables
# для маскарадинга через устройство по умолчанию
# и настраивает прокси arp с демоном parprouted для корректной маршрутизации
# Автор: Jack Knight
# - Open Source Migrations Ltd, UK (http://www.osml.co.uk)
# Настраиваем переменные здесь:
DESC="Virtualbox IP tap"
PATH=/sbin:/bin:/usr/sbin:/usr/bin
TUNDEVICE=tap1 # Произвольно, но должно соответствовать устройству, указанному в сетевых настройках VirtualBox.
LANDEVICE=eth1 # Исправьте, чтобы соответствовало вашему сетевому устройству – может быть eth0, eth1 ath0, wlan1 и т. д.
IPADDR=172.16.254.254 # Произвольно, но убедитесь, что вы взяли нечто из неиспользуемой подсети
case "$1" in start|restart|force-reload)
echo -n "Starting $DESC: "
tunctl -t $TUNDEVICE -u $USER
ip link set $TUNDEVICE up
ip addr add $IPADDR dev $TUNDEVICE
arp -Ds $IPADDR $TUNDEVICE pub
iptables -t nat -A POSTROUTING -o $LANDEVICE -j MASQUERADE
iptables -t nat -P POSTROUTING ACCEPT # Разрешаем работу других интерфейсов
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/$TUNDEVICE/proxy_arp
parprouted $LANDEVICE $TUNDEVICE
;;
stop)
echo -n "Stopping $DESC: "
iptables --table nat -F
killall parprouted
ip link set $TUNDEVICE down
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N start|stop" >&2
exit 1
;;
esac
exit 0
</source>

Этот код есть на DVD; если кому-то нужно, у меня также есть более проработанный скрипт, работающий со многими пользователями, виртуальными машинами и устройствами и не опубликованный здесь ради простоты. Не стесняйтесь обращаться за ним ко мне по электронной почте через мой web-сайт.

===Установка VirtualBox===

К сожалению, поскольку на момент написания ''VirtualBox'' еще не попал в основные репозитории Ubuntu, перед установкой пакета придется добавить новый сторонний репозиторий от ''VirtualBox'':
<source lang="bash">
sudo sh -c 'echo "# VirtualBox репозиторий для Ubuntu Feisty Fawn
deb http://www.virtualbox.org/debian feisty non-free" \
> /etc/apt/sources.list.d/feisty-virtualbox.list'
wget http://www.virtualbox.org/debian/innotek.asc -O- | sudo apt-key add -
sudo apt-get update
sudo apt-get -y install virtualbox
</source>

===Настройка виртуальной машины===

На хост-ситеме Ubuntu нам понадобится механизм совместного использования файлов мирами Linux и Windows. К счастью, ''VirtualBox'' имеет для этого встроенный механизм , так что Samba на хост-машине или NFS на обеих сторонах можно не устанавливать. Учтите: совместного использования вашего жесткого диска НЕ получится, пока вы не установите ''Vbox GuestAdditions'' в гостевой системе! При создании общих папок гостевая система должна быть выключена.

Общие папки работают только в версии 1.3.8; в версию 1.4.0 вкралась ошибка! Если у вас та самая версия, и вы не хотите возиться с Samba ради совместного доступа, скачайте iso с [http://www.virtualbox.de/download/1.3.8/VBoxGuestAdditions_1.3.8.iso www.virtualbox.de/download/1.3.8/VBoxGuestAdditions_1.3.8.iso].

Выключите ВМ, смените виртуальный '''cdrom''' на этот '''iso''' и перезапустите гостевую систему. Установите ''VirtualBoxGuest Additions'', и все должно заработать. Пока что я не слыхал о неприятностях, связанных с «не той» версией гостевых дополнений. Это должно вас временно выручить, до следующей версии, где Innotek, скорее всего, исправит эту ошибку.

Для настройки на стороне хоста, с выключенной гостевой ОС, просто выберите вашу ВМ в окне ''VirtualBox Manager'' и нажмите Свойства, а затем Общие папки у нижнего края, как показано на экранном снимке справа, заполните два поля подходящими значениями и нажмите OK. Теперь запустите гостевую ОС и, открыв окно DOS, введите:

net use E: \\vboxsvr\Shared_Folder

и добавьте /Persistent:Yes к этой команде, если хотите сохранить это при перезапуске. Внимание: не ошибитесь в написании vboxsvr – это важно!

Альтернативный метод – открыть окно ''Проводника'' Windows и выбрать Сервис > Подключить сетевой диск; вы увидите диалоговое окно, похожее на то, что справа. Тем же манером вставьте подходящие значения и нажмите Готово. Если все в порядке, то появится новое окно ''Проводника'' с содержимым каталога хост-машины.

Далее включим RDP-протокол, чтобы разрешить удаленные сессии. Просто щелкните на флажке Enable VRDP Server, как показано в этой колонке ниже.

===Настройка Windows XP===

Следующие настройки в принципе могут работать и для других версий Windows, не XP, но я не берусь этого утверждать, поскольку не успел протестировать. Нам нужны такие настройки, чтобы наша установленная Windows выводила на экран только панель задач, но не рабочий стол. Для этого поковыряемся в реестре; но учтите, что в Windows XP SP2 доступ к рассматриваемым настройкам ограничен, и обычный пользователь не вправе изменять эту часть – поэтому сперва мы временно присвоим права администратора пользователю, который будет использовать сессию Windows.

Войдите как «Администратор» (или любой другой пользователь с достаточными правами), затем перейдите в нужное место посредством Пуск > Настройки > Панель управления > Пользователи и щелкните на записи, которую хотите использовать для запуска Windows-программ. Щелкните на Изменить тип учетной записи и установите переключатель в Администратор компьютера, затем обратитесь к кнопке Изменить тип учетной записи. Теперь выйдите из-под администратора и войдите как ваш пользователь, запустите ''regedit32'' и найдите следующий ключ:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Нам необходимо создать новое значение DWORD с именем NoDesktop и присвоить ему значение 1, чтобы Windows отображала только приложение, которое мы хотим запустить, а не весь рабочий стол. Для этого выберите Правка в главном меню, далее Создать и Параметр DWORD и введите имя NoDesktop, затем нажмите Enter. Ключ теперь должен быть выделен, поэтому нажмите вновь Enter, чтобы отредактировать его и установить его значение в 1. По завершении все
должно выглядеть как на экранном снимке в конце этой колонки.

Другой вариант – загрузка файла [http://www.osml.eu/files/nodesktop.reg www.osml.eu/files/nodesktop.reg] с сервера Open Source Migrations Limited (используйте его на собственный страх и риск). Сохраните его на своем рабочем столе, затем просто дважды щелкните на нем, подтвердите действие, и реестр соответствующим образом изменится.

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

====Настройка Windows на автоматический вход.====

*Нажмите кнопку Пуск, выберите Выполнить, введите в окне
control userpasswords2
и нажмите OK.

*Снимите галочку около Требовать ввод имени и пароля пользователя и нажмите Применить.

*Появится окно с запросом: под каким пользователем и паролем вы хотите осуществить автоматический вход. Просто введите ранее определенные имя и пароль пользователя.

====Установка Гостевых Дополнений VirtualBox.====

*Выберите в главном меню окна вашей ВМ пункт Devices [Устройства], затем щелкните на Install Guest Additions.
*Отвечайте на вопросы установщика для завершения установки.

====Настройка фиксированного IP-адреса, используемого Windows.====

*Перейдите к Пуск > Настройка > Панель управления > Сетевые подключения.
*Выполните правый щелчок на Подключение к локальной сети и выберите Свойства.
*Введите IP-адрес, соответствующую маску подсети, адрес шлюза по умолчанию и по крайней мере один DNS-сервер. Вы можете найти
ваш(и) DNS сервер(а), набрав в терминале хост-машины:
cat /etc/resolv.conf
После слов nameserver указаны IP-адреса DNS-серверов. Шлюз по умолчанию должен соответствовать определенному для вашего TAP-интерфейса в '''/etc/tap.conf'''. Учтите: IP-адрес должен отличаться от IP ''Virtual Box'', прописанного в файле '''/etc/tap.conf'''. Я предлагаю устанавливать IP-адреса, отсчитывая от конца диапазона назад в '''tap.conf''' – т. е. от 254 и меньше для каждого TAP-устройства – и от начала диапазона для ваших гостевых машин, например, 172.16.254.1 и больше. Настройте ваш маршрутизатор на выдачу Windows другого IP. У большинства из вас, вероятно, только одно TAP-устройство, так что это не должно быть проблемой.

====Включение RDP-соединений в Windows и установка пароля.====

*Нажмите Пуск > Настройка > Панель управления > Система и перейдите на вкладку Удаленные сеансы.
*Поставьте галочку напротив пункта Разрешить удаленные подключения к этому компьютеру и нажмите OK.
*В Панели управления щелкните на Пользователи. Выберите пользователя, под которым хотите входить, и нажмите Создать пароль.
*Введите ваш пароль в появившейся строке и нажмите кнопку Создать пароль. Учтите: этот пароль надо установить обязательно, иначе нормальной работы не будет.
*Далее, загрузите файл: [http://www.cendio.se/files/thinlinc/seamlessrdp/seamlessrdp.zip www.cendio.se/files/thinlinc/seamlessrdp/seamlessrdp.zip] и распакуйте его в '''C:\seamlessrdp'''.
*Теперь подготовим Windows XP Pro для разрешения удаленного доступа с глубиной цвета 256 бит.
*Нажмите Пуск, Выполнить, введите в поле ''regedit'' и нажмите OK.
*В редакторе реестра перейдите к ключу: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
*В панели справа выделите ключ ColorDepth и щелкните на нем правой кнопкой мыши. Выберите Изменить и измените поле Значение на 4.
*Или, для удобства, просто загрузите файл: [http://www.osml.eu/files/rdpcolourdepth.reg www.osml.eu/files/rdpcolourdepth.reg] с сервера Open Source Migrations Limited (используйте на свой страх и риск). Сохраните его на рабочем столе, затем дважды щелкните на нем, подтвердите действие – и реестр будет изменен. На этом завершается настройка на стороне Windows.

===Настройка: VirtualBox===

Теперь можно настроить ''VirtualBox'' на автозапуск при загрузке. Вопервых, мы собираемся запустить вашу машину из командной строки,
поэтому в терминале введите:

VBoxManage startvm "WinXPPro" -type vrdp

Замените здесь WinXPPro на имя вашей ВМ. Чтобы Windows всякий раз запускалась без проблем, выполните Система > Параметры > Сеансы и выберите вкладку Запускаемые при старте программы. Щелкните на кнопке Создать, затем скопируйте и вставьте указанную выше команду в текстовое поле и нажмите OK.

Перед запуском новой ВМ необходимо убедиться, что наша нижняя панель сворачивается, иначе в Windows будут не видны кнопка Пуск и системный лоток, и нам это необходимо по крайней мере один раз (а может, и больше): если мы далее в Windows наткнемся на проблемы или для установки новых приложений. Просто щелкните правой кнопкой мыши в пустом месте нижней панели и выберите Свойства, установите флажок Показывать/скрывать кнопки и нажмите OK. Теперь слева и справа на вашей панели есть кнопки с изображением стрелки, позволяющие при нажатии ее спрятать.

Теперь впервые запустим нашу ВМ Windows. В терминале наберите:

rdesktop -rsound -A -s "c:\seamlessrdp\seamlessrdpshell.exe C:\Windows\explorer.exe" <IP-адрес Windows XP>:3389 -u "<Имя пользователя Windows>" -p <Ваш пароль Windows>

Вам нужно будет соответственно изменить переменные. Практически все, но будет виден полный рабочий стол, поскольку Windows необходимо перезагрузить, чтобы все новые возможности заработали. Это немного путано, но сделать так придется, потому что XP не будет воспринимать удаленные подключения, пока вы хоть раз не войдете. Короче, нажмите комбинацию клавиш Ctrl+Esc и выберите Завершить сеанс.

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

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

Теперь мы можем войти в верхнее меню Ubuntu, Система > Параметры > Главное меню и определить важные приложения, без которых вам не жить. Например, для установки ''Outlook'' (подразумевается, из ''Office 2003'') вам следует поместить в строку следующую команду:

/usr/bin/rdesktop -rsound -A -s "c:\seamlessrdp\seamlessrdpshell.exe C:\
Program Files\Microsoft Office\OFFICE11\OUTLOOK.EXE" <IP-адрес
Windows XP>:3389 -u "<Имя пользователя Windows >" -p <Ваш пароль
Windows >

Наконец, выключить ВМ можно так:

VBoxManage controlvm "Windows-XP-Pro" savestate

или так:

VBoxManage controlvm "Windows-XP-Pro" acpipowerbutton

для сохранения текущего состояния машины; или имитировать отключение питания. Пора звать к своему монитору друзей – пусть подивятся на ваши подвиги!

[[Категория:Hardcore Linux]]
[[Категория:Ubuntu]]
[[Категория:VirtualBox]]
[[Категория:Джек Найт]]

LXF98:Hardcore Linux

2009-03-07T20:22:23Z

Kipruss: /* Настраиваем TAP-устройство */

==VirtualBox: Windows в Ubuntu==

''Запускайте приложения Microsoft под Linux в Ubuntu Feisty при помощи VirtualBox от Innotek и Windows XP – '''Джек Найт''' здесь на коне….''

Требовалось ли вам когда-нибудь на вашей машине одно или несколько Windows-приложений для решения некоторой задачи? А может, у вас есть клиент, использующий Windows, и вам надо работать с документами ''MS Project'' или запускать непосредственно ''Outlook'' для совместного использования их календарей ''MS Exchange''? Один из выходов – двойная загрузка, другой – запуск Windows XP в качестве гостевой ОС на виртуальной машине (ВМ); но
есть действительно классное решение – угадайте, какое? Бесплатное, по крайней мере для большинства из нас! ''VirtualBox'' от ''Innotek'' – удивительный продукт, и хотя я на самом деле не проверял его производительность, навскидку кажется, что он значительно превосходит и ''VMWare Workstation'', и ''Server''. Он располагает набором приятных функций и возможностью организовать сетевой мост через беспроводной адаптер ноутбука (нечто прежде немыслимое в ''VMWare'') – чем не продукт-конфетка?

Innotek применяет дуальную схему лицензирования – существуют открытая и закрытая двоичная версии ''VirtualBox'' (последняя бесплатна для ознакомления или персонального использования). Более того, у Innonek весьма разумная политика лицензирования для малого бизнеса – по запросу о покупке коммерческих лицензий на две машины я был любезно извещен, что это относится к категории «бесплатно»! Уже в восторге? Ну, это только начало – а вот и убойный довод: при помощи этой штуки можно запускать отдельные приложения Windows на рабочем столе Linux, и они появятся как обычные окна Gnome, KDE (или другие) на вашем X-столе. Прибавьте сюда ''Beryl/Compiz'', и получите весьма впечатляющий инструмент. Качайте с [http://www.virtualbox.org www.virtualbox.org].

Но как заставить все это работать? Что ж, понадобится кое-какая подгонка и на стороне Linux, и на стороне Windows – но результат стоящий, по крайней мере, по моему скромному мнению. В этой статье я проведу вас через настройку моста через беспроводной адаптер на ноутбуке, а продолжу настройкой двух типичных приложений, зависящих от Windows – ''MS Project'' и ''Outlook'', чтобы под Ubuntu Feisty они выглядели как родные.

===План действий===

Вот что мы проделаем на следующих страницах:

*Кое-что подправим для устранения неприятностей с USB и DVD.
*Создадим TAP-устройство на сетевом интерфейсе базовой машины (идеально для WLAN-интерфейса ноутбука).
*Установим персональную/пробную версию ''VirtualBox'' от Innotek.
*Создадим ВМ для Windows XP и настроим ее на использование сетевого TAP-устройства.
*Установим Windows XP (самые общие моменты).
*Настроим Windows XP со всеми тонкостями, для безупречной работы.
*Настроим ''VirtualBox'' на работу без ручного вмешательства и автоматический старт.
*Введем пункты меню для наших приложений-примеров.

В детали установки гостевой ОС я вдаваться не буду: если кто не знает, как это сделать, описание найти легко. Зато приведу простой метод установки самого ''VirtualBox''.

Лично я использую на этом уроке Ubuntu 7.04 (Feisty), но эти инструкции должны отлично работать для dapper или edgy, при мелких изменениях (например, замене всех вхождений слова «feisty» по смыслу). Они должны работать и в Kubuntu; правда, я еще не проделывал мои операции в KDE, чтобы разобраться с отличиями. Машину, где запущен VirtualBox, я буду называть HOST [хост], а запущенные в нем системы – GUEST [гость]. Предполагается, что вы можете запускать командную оболочку и использовать редактор для изменения текстовых файлов. Прежде чем продолжить, познакомьтесь со врезкой
Избавляемся от неприятностей.

===Настраиваем TAP-устройство===

Нам нужно установить пакеты, а именно ''User Mode Linux Utilities'' и ''Proxy Arp Routing Daemon''. Для начала убедитесь, что подключен репозиторий '''universe''': в строке-меню Gnome выберите Система > Администрирование > Источники приложений, затем установите галочку Свободное ПО, поддерживаемое сообществом (universe). Теперь откройте терминал и введите:
<source lang="bash">
sudo apt-get install uml-utilities parprouted
sudo chgrp vboxusers /dev/net/tun
</source>

Теперь надо встроить TAP в сетевой адаптер хост-системы. Это особенно полезно для ноутбуков с беспроводными интерфейсами, поскольку WLAN-адаптер обычно получает IP-адрес через DHCP, но гостевая машина не может делать этого – как правило, несколько IP-адресов нельзя получить для того, что в сущности является клонированным интерфейсом. К тому же если беспроводной интерфейс использует защиту WPA, то появление интерфейса-клона, вероятно, заставит WAP
(Wireless Access Point – точка беспроводного доступа) заподозрить, что компьютер под атакой. Итак, сделаем вот что: выявим неиспользованные подсети, выберем пару уникальных IP-адресов и присвоим один TAP-устройству, а другой гостевой машине. Неважно, что они фиксированы: адрес хост-машины будет динамическим, и они будут проходить через маскардинг. В итоге гостевая машина будет «просто работать», где бы вы ни получили WLAN-соединение для хоста.

Проще всего создать скрипт для инициализации TAP-устройства и поддержки конфигурации сети. Вот мой вариант:
<source lang="bash">
#!/bin/bash
# Имя: tapctrl
# Использование: tapctrl start|stop
# Обеспечивает: tap для virtualbox во внешней сети, включая беспроводные
# Аннотация:
# устанавливает tap-устройство для совместного использования интерфейса wifi с vbox
# Описание: создает виртуальный tap-интерфейс, присваивает IP- адрес, настраивает iptables
# для маскарадинга через устройство по умолчанию
# и настраивает прокси arp с демоном parprouted для корректной маршрутизации
# Автор: Jack Knight
# - Open Source Migrations Ltd, UK (http://www.osml.co.uk)
# Настраиваем переменные здесь:
DESC="Virtualbox IP tap"
PATH=/sbin:/bin:/usr/sbin:/usr/bin
TUNDEVICE=tap1 # Произвольно, но должно соответствовать устройству, указанному в сетевых настройках VirtualBox.
LANDEVICE=eth1 # Исправьте, чтобы соответствовало вашему сетевому устройству – может быть eth0, eth1 ath0, wlan1 и т. д.
IPADDR=172.16.254.254 # Произвольно, но убедитесь, что вы взяли нечто из неиспользуемой подсети
case "$1" in start|restart|force-reload)
echo -n "Starting $DESC: "
tunctl -t $TUNDEVICE -u $USER
ip link set $TUNDEVICE up
ip addr add $IPADDR dev $TUNDEVICE
arp -Ds $IPADDR $TUNDEVICE pub
iptables -t nat -A POSTROUTING -o $LANDEVICE -j MASQUERADE
iptables -t nat -P POSTROUTING ACCEPT # Разрешаем работу других интерфейсов
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/$TUNDEVICE/proxy_arp
parprouted $LANDEVICE $TUNDEVICE
;;
stop)
echo -n "Stopping $DESC: "
iptables --table nat -F
killall parprouted
ip link set $TUNDEVICE down
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N start|stop" >&2
exit 1
;;
esac
exit 0
</source>

Этот код есть на DVD; если кому-то нужно, у меня также есть более проработанный скрипт, работающий со многими пользователями, виртуальными машинами и устройствами и не опубликованный здесь ради простоты. Не стесняйтесь обращаться за ним ко мне по электронной почте через мой web-сайт.

===Установка VirtualBox===

К сожалению, поскольку на момент написания ''VirtualBox'' еще не попал в основные репозитории Ubuntu, перед установкой пакета придется добавить новый сторонний репозиторий от ''VirtualBox'':

sudo sh -c 'echo "# VirtualBox репозиторий для Ubuntu Feisty Fawn
deb http://www.virtualbox.org/debian feisty non-free" \
> /etc/apt/sources.list.d/feisty-virtualbox.list'
wget http://www.virtualbox.org/debian/innotek.asc -O- | sudo apt-key add -
sudo apt-get update
sudo apt-get -y install virtualbox

===Настройка виртуальной машины===

На хост-ситеме Ubuntu нам понадобится механизм совместного использования файлов мирами Linux и Windows. К счастью, ''VirtualBox'' имеет для этого встроенный механизм , так что Samba на хост-машине или NFS на обеих сторонах можно не устанавливать. Учтите: совместного использования вашего жесткого диска НЕ получится, пока вы не установите ''Vbox GuestAdditions'' в гостевой системе! При создании общих папок гостевая система должна быть выключена.

Общие папки работают только в версии 1.3.8; в версию 1.4.0 вкралась ошибка! Если у вас та самая версия, и вы не хотите возиться с Samba ради совместного доступа, скачайте iso с [http://www.virtualbox.de/download/1.3.8/VBoxGuestAdditions_1.3.8.iso www.virtualbox.de/download/1.3.8/VBoxGuestAdditions_1.3.8.iso].

Выключите ВМ, смените виртуальный '''cdrom''' на этот '''iso''' и перезапустите гостевую систему. Установите ''VirtualBoxGuest Additions'', и все должно заработать. Пока что я не слыхал о неприятностях, связанных с «не той» версией гостевых дополнений. Это должно вас временно выручить, до следующей версии, где Innotek, скорее всего, исправит эту ошибку.

Для настройки на стороне хоста, с выключенной гостевой ОС, просто выберите вашу ВМ в окне ''VirtualBox Manager'' и нажмите Свойства, а затем Общие папки у нижнего края, как показано на экранном снимке справа, заполните два поля подходящими значениями и нажмите OK. Теперь запустите гостевую ОС и, открыв окно DOS, введите:

net use E: \\vboxsvr\Shared_Folder

и добавьте /Persistent:Yes к этой команде, если хотите сохранить это при перезапуске. Внимание: не ошибитесь в написании vboxsvr – это важно!

Альтернативный метод – открыть окно ''Проводника'' Windows и выбрать Сервис > Подключить сетевой диск; вы увидите диалоговое окно, похожее на то, что справа. Тем же манером вставьте подходящие значения и нажмите Готово. Если все в порядке, то появится новое окно ''Проводника'' с содержимым каталога хост-машины.

Далее включим RDP-протокол, чтобы разрешить удаленные сессии. Просто щелкните на флажке Enable VRDP Server, как показано в этой колонке ниже.

===Настройка Windows XP===

Следующие настройки в принципе могут работать и для других версий Windows, не XP, но я не берусь этого утверждать, поскольку не успел протестировать. Нам нужны такие настройки, чтобы наша установленная Windows выводила на экран только панель задач, но не рабочий стол. Для этого поковыряемся в реестре; но учтите, что в Windows XP SP2 доступ к рассматриваемым настройкам ограничен, и обычный пользователь не вправе изменять эту часть – поэтому сперва мы временно присвоим права администратора пользователю, который будет использовать сессию Windows.

Войдите как «Администратор» (или любой другой пользователь с достаточными правами), затем перейдите в нужное место посредством Пуск > Настройки > Панель управления > Пользователи и щелкните на записи, которую хотите использовать для запуска Windows-программ. Щелкните на Изменить тип учетной записи и установите переключатель в Администратор компьютера, затем обратитесь к кнопке Изменить тип учетной записи. Теперь выйдите из-под администратора и войдите как ваш пользователь, запустите ''regedit32'' и найдите следующий ключ:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Нам необходимо создать новое значение DWORD с именем NoDesktop и присвоить ему значение 1, чтобы Windows отображала только приложение, которое мы хотим запустить, а не весь рабочий стол. Для этого выберите Правка в главном меню, далее Создать и Параметр DWORD и введите имя NoDesktop, затем нажмите Enter. Ключ теперь должен быть выделен, поэтому нажмите вновь Enter, чтобы отредактировать его и установить его значение в 1. По завершении все
должно выглядеть как на экранном снимке в конце этой колонки.

Другой вариант – загрузка файла [http://www.osml.eu/files/nodesktop.reg www.osml.eu/files/nodesktop.reg] с сервера Open Source Migrations Limited (используйте его на собственный страх и риск). Сохраните его на своем рабочем столе, затем просто дважды щелкните на нем, подтвердите действие, и реестр соответствующим образом изменится.

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

====Настройка Windows на автоматический вход.====

*Нажмите кнопку Пуск, выберите Выполнить, введите в окне
control userpasswords2
и нажмите OK.

*Снимите галочку около Требовать ввод имени и пароля пользователя и нажмите Применить.

*Появится окно с запросом: под каким пользователем и паролем вы хотите осуществить автоматический вход. Просто введите ранее определенные имя и пароль пользователя.

====Установка Гостевых Дополнений VirtualBox.====

*Выберите в главном меню окна вашей ВМ пункт Devices [Устройства], затем щелкните на Install Guest Additions.
*Отвечайте на вопросы установщика для завершения установки.

====Настройка фиксированного IP-адреса, используемого Windows.====

*Перейдите к Пуск > Настройка > Панель управления > Сетевые подключения.
*Выполните правый щелчок на Подключение к локальной сети и выберите Свойства.
*Введите IP-адрес, соответствующую маску подсети, адрес шлюза по умолчанию и по крайней мере один DNS-сервер. Вы можете найти
ваш(и) DNS сервер(а), набрав в терминале хост-машины:
cat /etc/resolv.conf
После слов nameserver указаны IP-адреса DNS-серверов. Шлюз по умолчанию должен соответствовать определенному для вашего TAP-интерфейса в '''/etc/tap.conf'''. Учтите: IP-адрес должен отличаться от IP ''Virtual Box'', прописанного в файле '''/etc/tap.conf'''. Я предлагаю устанавливать IP-адреса, отсчитывая от конца диапазона назад в '''tap.conf''' – т. е. от 254 и меньше для каждого TAP-устройства – и от начала диапазона для ваших гостевых машин, например, 172.16.254.1 и больше. Настройте ваш маршрутизатор на выдачу Windows другого IP. У большинства из вас, вероятно, только одно TAP-устройство, так что это не должно быть проблемой.

====Включение RDP-соединений в Windows и установка пароля.====

*Нажмите Пуск > Настройка > Панель управления > Система и перейдите на вкладку Удаленные сеансы.
*Поставьте галочку напротив пункта Разрешить удаленные подключения к этому компьютеру и нажмите OK.
*В Панели управления щелкните на Пользователи. Выберите пользователя, под которым хотите входить, и нажмите Создать пароль.
*Введите ваш пароль в появившейся строке и нажмите кнопку Создать пароль. Учтите: этот пароль надо установить обязательно, иначе нормальной работы не будет.
*Далее, загрузите файл: [http://www.cendio.se/files/thinlinc/seamlessrdp/seamlessrdp.zip www.cendio.se/files/thinlinc/seamlessrdp/seamlessrdp.zip] и распакуйте его в '''C:\seamlessrdp'''.
*Теперь подготовим Windows XP Pro для разрешения удаленного доступа с глубиной цвета 256 бит.
*Нажмите Пуск, Выполнить, введите в поле ''regedit'' и нажмите OK.
*В редакторе реестра перейдите к ключу: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
*В панели справа выделите ключ ColorDepth и щелкните на нем правой кнопкой мыши. Выберите Изменить и измените поле Значение на 4.
*Или, для удобства, просто загрузите файл: [http://www.osml.eu/files/rdpcolourdepth.reg www.osml.eu/files/rdpcolourdepth.reg] с сервера Open Source Migrations Limited (используйте на свой страх и риск). Сохраните его на рабочем столе, затем дважды щелкните на нем, подтвердите действие – и реестр будет изменен. На этом завершается настройка на стороне Windows.

===Настройка: VirtualBox===

Теперь можно настроить ''VirtualBox'' на автозапуск при загрузке. Вопервых, мы собираемся запустить вашу машину из командной строки,
поэтому в терминале введите:

VBoxManage startvm "WinXPPro" -type vrdp

Замените здесь WinXPPro на имя вашей ВМ. Чтобы Windows всякий раз запускалась без проблем, выполните Система > Параметры > Сеансы и выберите вкладку Запускаемые при старте программы. Щелкните на кнопке Создать, затем скопируйте и вставьте указанную выше команду в текстовое поле и нажмите OK.

Перед запуском новой ВМ необходимо убедиться, что наша нижняя панель сворачивается, иначе в Windows будут не видны кнопка Пуск и системный лоток, и нам это необходимо по крайней мере один раз (а может, и больше): если мы далее в Windows наткнемся на проблемы или для установки новых приложений. Просто щелкните правой кнопкой мыши в пустом месте нижней панели и выберите Свойства, установите флажок Показывать/скрывать кнопки и нажмите OK. Теперь слева и справа на вашей панели есть кнопки с изображением стрелки, позволяющие при нажатии ее спрятать.

Теперь впервые запустим нашу ВМ Windows. В терминале наберите:

rdesktop -rsound -A -s "c:\seamlessrdp\seamlessrdpshell.exe C:\Windows\explorer.exe" <IP-адрес Windows XP>:3389 -u "<Имя пользователя Windows>" -p <Ваш пароль Windows>

Вам нужно будет соответственно изменить переменные. Практически все, но будет виден полный рабочий стол, поскольку Windows необходимо перезагрузить, чтобы все новые возможности заработали. Это немного путано, но сделать так придется, потому что XP не будет воспринимать удаленные подключения, пока вы хоть раз не войдете. Короче, нажмите комбинацию клавиш Ctrl+Esc и выберите Завершить сеанс.

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

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

Теперь мы можем войти в верхнее меню Ubuntu, Система > Параметры > Главное меню и определить важные приложения, без которых вам не жить. Например, для установки ''Outlook'' (подразумевается, из ''Office 2003'') вам следует поместить в строку следующую команду:

/usr/bin/rdesktop -rsound -A -s "c:\seamlessrdp\seamlessrdpshell.exe C:\
Program Files\Microsoft Office\OFFICE11\OUTLOOK.EXE" <IP-адрес
Windows XP>:3389 -u "<Имя пользователя Windows >" -p <Ваш пароль
Windows >

Наконец, выключить ВМ можно так:

VBoxManage controlvm "Windows-XP-Pro" savestate

или так:

VBoxManage controlvm "Windows-XP-Pro" acpipowerbutton

для сохранения текущего состояния машины; или имитировать отключение питания. Пора звать к своему монитору друзей – пусть подивятся на ваши подвиги!

[[Категория:Hardcore Linux]]
[[Категория:Ubuntu]]
[[Категория:VirtualBox]]
[[Категория:Джек Найт]]

Обсуждение участника:Yaleks

2009-03-07T20:14:57Z

Kipruss: /* LXF100 ... */

Установил расширения Cite, ParserFunctions и SyntaxHighlight - проверяйте --17:21, 11 марта 2008 (MSK)

Вы вчера перенесли статью LXF97:TEX в LXF97:Препринт, но при этом некорректно изменили оглавление номера, оставив в нем ссылку на LXF97:TEX, но удалив при этом ссылку на следующую статью Андрея Боровского. Я ее найти в списке статей не могу. Верните ее пожалуйста на место. --[[Участник:Crazy Rebel|Crazy Rebel]] 08:07, 3 октября 2008 (MSD)
: Я просто очистил содержимое, сама статья была создана давно. Оглавление сейчас пофиксил. --[[Участник:Yaleks|Yaleks]] 15:07, 4 октября 2008 (MSD)

== Викификация LXF70-77 ==
До сих пор я занимался викификацией LXF c конца, а Вы с начала. Но теперь, когда остались не завершенными только самые начальные номера, причем в каждом из них уже сделана какая то часть работы, Валентин Синицин посоетовал обратиться непосредственно к Вам, чтобы разделить оставшиеся для викификации статьи. В принципе я могу пойти и другим путем - начиная викификацию 2008 года. Так что давайте решим как будет удобнее. --[[Участник:Crazy Rebel|Crazy Rebel]]

* Вот что осталось (если существующие оглавления полные):
<nowiki># <s>[[LXF74-75:Inkscape]] (13 ссылок)</s>
# <s>[[LXF71:GIMP]]</s> (7 ссылок)
# <s>[[LXF72:GIMP]]</s> (7 ссылок)
# <s>[[LXF73:GIMP]]</s> (7 ссылок)
# <s>[[LXF73:Сравнение: Электронные фотоальбомы]] (2 ссылки)</s>
# <s>[[LXF74-75:Технологии Linux-2006]] (2 ссылки)</s>
# <s>[[LXF71:VariCAD 2005]]</s>
# <s>[[LXF71:KOffice 1.4]]</s>
# <s>[[LXF71:SmoothWall Firewall 4]]</s>
# <s>[[LXF71:Amarok 1.3]]</s>
# <s>[[LXF71:Спецрепортаж]]</s>
# <s>[[LXF71:Настольный Linux]]</s>
# <s>[[LXF71:Гонка за лидером]]</s>
# <s>[[LXF71:Дневники Linux]]</s>
# <s>[[LXF71:Subversion]]</s>
# <s>[[LXF77:Realsoft 3D]]</s>
# <s>[[LXF72:Советы по ускорению]]</s>
# <s>[[LXF76:Азбука записи]]</s>
# <s>[[LXF73:Автомонтирование USB]]</s>
# <s>[[LXF73:Русификация Debian 3.1]]</s>
# <s>[[LXF72:Frequently Asked Questions]]</s>
# <s>[[LXF72:Краткая справка]]</s>
# <s>[[LXF71:Ответы]]</s>
# <s>[[LXF72:Ответы]]</s>
# <s>[[LXF73:Ответы]]</s>
# <s>[[LXF74-75:Ответы]]</s>
# <s>[[LXF77:Ответы]]</s>
# <s>[[LXF71:Первые шаги]]</s>
# <s>[[LXF72:Первые шаги Печать]]</s>
# <s>[[LXF74-75:Первые шаги]]</s>
# <s>[[LXF77:Сравнение]]</s>
# <s>[[LXF71:Сравнение]]</s>
# <s>[[LXF76:Сравнение]]</s>
# <s>[[LXF76:Что такое]] GPL V3</s>
# <s>[[LXF76:Интервью]] Джереми Элиссон</s>
# <s>[[LXF76:Трюки с железом]]</s>
# <s>[[LXF76:Интервью2]] Йон фон Течнер</s>
# <s>[[LXF76:Dynebolic]]</s>
# <s>[[LXF76:MythTV]]</s></nowiki>

Большое число из этого уже устарело и представляет лишь исторический интерес. Можно тут <s>отмечать</s> (<nowiki><s>...</s></nowiki>) перед викификаций, чтобы не было коллизий. --[[Участник:Yaleks|Yaleks]] 22:45, 3 февраля 2009 (MSK)

* Поздравляю! Позиции в списке закончились.
** Это да, но мне ещё спецрепортаж доделывать. --[[Участник:Yaleks|Yaleks]] 20:24, 5 марта 2009 (MSK)
*** Я так сильно подозреваю, что это не единственная проблема, хотя я старался и выверял все номера, но могли гдето и недоделки остаться и статьи спрятаться. Но в общем следует считать, что эта часть завершена. Тем более что спецрепортаж это большая но всего одна статья.--[[Участник:Crazy Rebel|Crazy Rebel]] 10:08, 6 марта 2009 (MSK)

== LXF72 Советы по ускорению ==

А зачем там было делать "LXF72..." загловком? Я тоже так вначале сделал, но мне крайне не понравилось, что советы нумеруются 1.1 ... 1.32 тогда как в моем варианта было 1, 2 .... Ну и еще почему заголовок статьи Вы выделяетя двумя знаками <nowiki>==</nowiki> ведь можно и одним, тогда каждый вопрос отделяется друг от друго горизонтальной линией.
:* <nowiki>==</nowiki> это заголовок 1-ого уровня вики-синтаксиса (= использовать некорректно). И где вы редактируете статьи, что там вставляется какой-то 2-х байтовый пробел? Через OCR что-ли пропускаете? --[[Участник:Yaleks|Yaleks]] 22:15, 26 февраля 2009 (MSK)
:::* Статьи я копирую из kpdf собственно сразу в окно Firefox, откуда там стали браться неразрывные пробелы я понятия не имею. Возможно такие pdf-ки потому что LXF99 я делал таким же способом но никаких неразрывных пробелов там нет. Или это так работает новый kpdf.
:::* Проблему решил так - сначала копирую текст в kate там удаляю всю гадость (заменой по тексту) и уже потом вставляю в окно Firefox.

== LXF100 ... ==

В общем то викификация LXF70-99 подходит к концу и Синицын уже спрашивал меня о продолжении работы. Я согласен и как я понимаю Вы тоже. Но у Вас несколько другой подход - викифицировать не номерами, а темами. В приципе я вижу и преимущества и недостатки такого подхода. Ну из перимуществ это то, что пользователь получает информацию которая должна быть для него наиболее интересна, а из недостатков- отдельный номер может быть так до конца и не закончен. Будет осутствовать общий стиль оформлния. В общем я готов на любой подход к викификации. Если мы будем пользоваться Вашим методом то предлагаю делать так чтобы не пересекаться - Заранее оглавления не делаем, кто создает статью, тот ее и викифицирует.
: Если вы посмотрите на статистику хотя-бы нескольких ресурсов, то поймёте, что удержать и заставить посмотреть хотя-бы 3 страницы очень сложно. Потому иметь законченные и связанные кластеры статей лучше, чем несвязанную подборку из одного номера. Очень мало людей приходят введя адрес первой страницы и читают по-порядку, в основном по ссылкам с других сайтов или поисковых систем. --[[Участник:Yaleks|Yaleks]] 15:24, 1 марта 2009 (MSK)
:: И всеже я предлагаю сначала закончить LXF71 и только после этого приступать к 100 и далее, а то Синицын мне как то писал что руководство недовольно, что викификация этих номеров не закончена. А в остальном полностью согласен. Предлагаю значит сделать как раз так - кто начал викификацию тот ее и заканчивает. Чтобы нам тут оглавление не составлять.

Надо не забывать делать редиректы на статьи в номере 100-101 с несуществующих номеров 100 и 101. --[[Участник:Kipruss|Kipruss]]
* Зачем эти редиректы? И наверно не надо делать вики-ссылок на изображения, просто размещайте в зоне видимости, где на них ссылаются. Я ещё пару мелочей поправил. --[[Участник:Yaleks|Yaleks]] 09:33, 7 марта 2009 (MSK)
:: Редиректы - мне показалось, что лишними не будут. Я и сам сперва создал страницу с LXF100 в составе, вот и задумался о редиректах. И - да, насчет source вместо code - это полезная штука. Буду пользоваться.--[[Участник:Kipruss|Kipruss]] 23:14, 7 марта 2009 (MSK)

== Присоединение к проекту ==

Обращаюсь к Yaleks'у, как к координатору: я готов в меру сил помочь в викификации того, что наиболее нужно в настоящее время. Номера 100-106 имеются, скачал по ссылке, которую дал Валентин. Мой почтовый адрес: kipruss_A_mail.ru. После прочтения, думаю, этот раздел можно удалить. :)

* Ну так выбирайте статью, вроде как решили с учебников начать, а то и цикл, вписывайте на соответствующей странице(цах) его название и вперед. Валентин сказал что за оформлением оглавления журанлов он сам проследит, но всетаки постарайтесь как в журнале делать название статьи и аннотацию.--[[Участник:Crazy Rebel|Crazy Rebel]] 10:10, 6 марта 2009 (MSK)
** Раз с учебников, то беру цикл "Hardcore Linux". Потом - Django, но этот цикл начинается с мая, по-моему - наверное лучше сделать те, которые продолжаются с прошлого года.--[[Участник:Kipruss|Kipruss]] 23:36, 6 марта 2009 (MSK)
* Смотрите на оформление существующих статей и делайте по аналогии (также см. [[Информация для авторов]]). Crazy Rebel, осталось расхождение с наименование картинок, я всё-таки предлагаю, чтобы в названии был номер журнала и страницы (возможно выбранный в начале Img не очень логично и лучше перейти к LXF10X_YY_Z.{jpg/png}). --[[Участник:Yaleks|Yaleks]] 11:57, 6 марта 2009 (MSK)
** Поздно я обратил внимание на это замечание. Ну, ничего страшного, надеюсь. Проба пера: [[LXF100:Hardcore_Linux]]
** Хорошо. Со следующей статьи начну именовать так. Не думаю что надо что либо переделывать в уже викифицицированных журналах если только качество старых картинок не нравится.--[[Участник:Crazy Rebel|Crazy Rebel]] 16:35, 6 марта 2009 (MSK)

LXF100-101:Hardcore Linux

2009-03-07T20:12:05Z

Kipruss: оформление

==Кластеры: Повышаем отказоустойчивость.==

Отказоустойчивость – то свойство, которое помогает кластеру пережить сбой электропитания и другие бедствия. '''Д-р Крис Браун''' покажет, как удержаться на плаву.

Журналы доступа к моей web-странице – не самое захватывающее чтиво. Если исключить случайные вторжения роботов поисковых систем, посетители заходят на сайт не чаще раза в неделю. Честно говоря, если сайт упадет, это заметят разве что через несколько месяцев. Даже грустно. Другая крайность – коммерческие web-сайты, приносящие владельцам ежедневный доход: несколько минут простоя такого сайта выливаются в ощутимые убытки для компании. На данном уроке я расскажу, как создать в Linux отказоустойчивый кластер. В случае краха основного сервера система автоматически переключается на запасной, а снаружи кластер выглядит как один очень надежный сервер. Нам поможет открытая программа ''Heartbeat'', найти которую можно на сайте http://www.linuxha.org. Кластер мы построим из двух компьютеров (основной и запасной сервер). ''Heartbeat'' будет отвечать за обнаружение отказа основного сервера и управлять запуском нужного нам сервиса на запасном. Мы воспользуемся сервисом ''Apache (httpd)'', но эта технология подойдет и для любого другого сервиса: FTP, DNS или почтового. В общем, все будет работать примерно так:

# В обычном режиме необходимые сервисы (типа ''httpd'') предоставляются основным сервером.
# Основной и запасной серверы постоянно обмениваются друг с другом сообщениями ''Heartbeat'' [англ. пульс], которые говорят запасному серверу, что с основным все в порядке.
# Если запасной сервер не получает сообщения, он перенимает ресурсы основного сервера (например, запускает собственную копию сервера ''httpd'').
# Запасной сервер перенимает IP-адрес, по которому предоставлялся сервис на основном сервере.

===Начинаем: компоненты системы===
[[Изображение:Img_100_87_1.png|thumb|400px|Рис. 1: Общая схема проекта; обратите внимание на IP-адреса.]]
Если вы намерены двинуться дальше и попробовать все на практике, то вам понадобятся три компьютера – основной сервер, запасной сервер и клиент, с помощью которого мы сможем проверить, как все работает.

На основном и запасном серверах должен быть установлен Linux, на клиенте – необязательно (хотя под Linux в вашем распоряжении окажутся лучшие средства диагностики). Компьютеры должны быть подключены к сети Ethernet. Для обмена сигналами ''Heartbeat'' на основном и запасном серверах должна быть вторая сетевая карта. Эти карты нужно соединить друг с другом либо перекрестным (crossover) кабелем, либо через мини-хаб. Если на обоих компьютерах есть последовательный порт, то вместо второго Ethernet-подключения можно соединить их последовательные порты перекрестным кабелем, по которому будет производиться обмен сигналами. Общая схема показана на Рис. 1.

===Установка heartbeat-соединения===

Если обмен сигналами ''Heartbeat'' будет осуществляться через Ethernet, соединить сетевые карты друг с другом можно двумя способами: либо через перекрестный кабель RJ45, либо парой обычных кабелей через мини-хаб. Первый вариант лучше, потому что здесь нечему выходить из строя. Каждой из карт нужно назначить статический IP-адрес, причем выбранный из частного диапазона, ни один адрес из которого не используется во внутренней сети. Например, первой карте можно назначить адрес 10.0.0.1, второй – 10.0.0.2. Убедитесь, что компьютеры могут достучаться друг до друга [ping].

Также можно использовать и соединение через последовательный порт. Тогда нам потребуется последовательный перекрестный кабель. На обоих концах этого кабеля, который еще называют нуль-модемным, имеется 9-контактный разъем типа «мама». Кабелем нужно соединить последовательные порты компьютеров. (Последовательные порты и кабели сейчас используются редко, и если на ваших компьютерах их нет, проще пойти и купить вторую сетевую карту для соединения по Ethernet.)

Чтобы проверить соединение через последовательные порты, выполните на основном сервере команду:
<source lang="bash">
cat /dev/ttyS0
</source>
а на запасном – команду:
<source lang="bash">
cat /etc/fstab > /dev/ttyS0
</source>

На основном сервере должно отображаться содержимое файла. Повторите эксперимент в обратном направлении.

''Heartbeat'' будет прекрасно работать с соединением любого типа. Преимущество Ethernet-соединения – трафик ''Heartbeat'' в этом случае можно отслеживать с помощью одной из утилит для отслеживания пакетов (например, wireshark). Можно даже использовать одновременно оба соединения, что позволит обойтись без ненужных откатов, если только одно из них выйдет из строя.

===Настройка сетевых интерфейсов===

Оба сетевых интерфейса, которые участвуют в ''Heartbeat''-соединении, должны быть настроены на статические IP-адреса, так как DHCP-сервера в этой «сети» точно нет. Статические адреса должны быть и на основных интерфейсах, которые используются для подключения к основному и запасному серверам. Обратите внимание, что это НЕ те адреса, на которых предоставляется сервис. ''Heartbeat'' назначит сетевой карте исправного компьютера второй IP-адрес, и именно он будет использоваться клиентами для доступа к ресурсу.

===Три файла конфигурации===

Сразу после установки Heartbeat нужно создать в каталоге '''/etc/ha.d''' три (да, три!) файла конфигурации, а именно:

* '''ha.cf''' Файл содержит настройки самого ''Heartbeat''; в нем определяются используемые программой пути и устанавливаются некоторые временные параметры.
* '''haresources''' Этот файл определяет ресурсы (сервисы), которыми будет управлять Heartbeat, и основной сервер для каждого из этих ресурсов.
* '''authkey''' В этом файле задается пароль и метод шифрования, используемый для аутентификации Heartbeat-сообщений.

Начнем с '''ha.cf'''. Пример этого файла можно найти в документации на ''Heartbeat'' ('''/usr/share/doc/heartbeat/ha.cf'''). Это один из файлов типа «визгу много, проку мало», которые целиком состоят из документации и закомментированных примеров. Можно скопировать его в '''/etc/ha.d''' и использовать как отправную точку, или создать свой файл с нуля.

{{Врезка
|Заголовок=Ошибка!
|Содержание=В этой статье мы не говорим о том, как предотвратить неисправности других типов, например, те, что возникают в инфраструктуре самого интернета. В частности, мы не говорим о создании дополнительных информационных каналов для связи с сайтом. Впрочем, это не так уж и важно, потому что врожденная гибкость архитектуры интернета позволяет поглощать частные сбои. Часто даже говорят, что сеть ARPANET (предшественник интернета) разрабатывалась с таким расчетом, чтобы выдержать взрыв атомной бомбы. ARPANET и правда должна была справляться с утратой части сети, но главная причина была в том, что коммутация узлов сети и связей внутри нее была не особенно надежной, даже и без атомной бомбы.
|Ширина=200px}}

Вот минимальный вариант этого файла. Номера строк даны только для удобства ссылок, в самом файле их нет:
<source lang="ini" line="GESHI_NORMAL_LINE_NUMBERS">
udpport 694
bcast eth1
serial /dev/ttyS0
baud 9600
keepalive 2
deadtime 20
initdead 60
node primary.example.com
node backup.example.com
</source>

Строки 1 и 2 задают номер порта и сетевой интерфейс, используемые для Heartbeat-соединения. Для соединения через последовательные порты в строках 3 и 3 задается порт и скорость соединения. Можно (и рекомендуется) использовать оба типа, но у меня было только соединение через последовательные порты, и я закомментировал строки 1 и 2. В строке 5 задается тайм-аут между сообщениями, а строка 6 определяет время, по истечении которого, не дождавшись очередного сообщения от основного сервера, запасной сочтет его покойником. В строке 7 указывается время, необходимое для активации сетевого интерфейса после включения компьютера, после чего ''Heartbeat'' начинает функционировать. В строках 8 и 9 задаются имена хостов для основного и запасного серверов (те, что возвращает команда uname -n).

Для начала попробуем управлять полностью фиктивным сервисом '''tester'''. Мы напишем скрипт, '''/etc/ha.d/resources.d/tester''', вызываемый ''Heartbeat''. Он будет всего лишь вызывать команду logger, которая сообщит нам (через ''syslogd''), что скрипт был запущен. Вот как он выглядит:
<source lang="bash">
#!/bin/bash
logger $0 called with argument $1
</source>

Скрипт нужно сделать исполняемым, например, так:
<source lang="bash">
chmod 755 tester
</source>

В следующем файле, ''haresources'', содержится список ресурсов, которыми управляет ''Heartbeat''. Когда компьютер выходит из строя, эти ресурсы перемещаются с одного узла сети на другой. (попробуйте произносить это как “ha-resources”, а не “hare-sauces” [англ. hare – заяц, source – источник, sauce – соус, – прим. ред.]. По правде говоря, я сроду не ел зайчатины, но первым делом подумал о кролике и решил, что подойдет клюквенный соус.) Опять же, пример этого файла можно найти в документации ('''/usr/share/doc/Heartbeat''') – можете просто скопировать его в '''/etc/ha.d''' или создать свой собственный файл с нуля. Для нашего первого теста в этом файле должна быть всего одна строка:
<code>
primary.example.com tester
</code>

Также нужно создать файл '''/etc/ha.d/authkeys''', содержащий ключи, используемые для аутентификации ''Heartbeat''-сообщений, например:
<code>
auth1
1 sha1 foobar
</code>

Нужно позаботиться, чтобы читать этот файл мог только администратор:
<source lang="bash">
chmod 600 authkeys
</source>

Если права доступа к этому файлу есть у кого-то еще, ''Heartbeat'' не запустится.

Скопируйте эти четыре файла с основного сервера на запасной в соответствующие каталоги. Файл '''ha.cf''', возможно, придется подправить в зависимости от аппаратного обеспечения компьютера, а остальные файлы должны быть одинаковыми на обоих компьютерах.

Теперь можно запустить ''Heartbeat''. Для отслеживания сообщений ''Heartbeat'' на обоих компьютерах запустите tail -f для файла журнала ('''/var/log/messages'''). Запустите программу с помощью команды:
<source lang="bash">
/etc/init.d/heartbeat start
</source>

{{Врезка
|Заголовок=Украденная личность
|Содержание=Перенос IP-адреса на другой компьютер – компьютерный эквивалент «воровства личности»: вы притворяетесь кем-то другим, а потом убеждаете весь мир, что вы настоящий. В процессе переноса системы на запасной сервер обязано произойти следующее. Во-первых, основной сервер должен отдать IP-адрес. Если он загорелся или нашел другую кончину, это произойдет по умолчанию, но если heartbeat останавливается на другом (исправном) сервере, адрес, очевидно, нужно забрать назад. Другая проблема – обновление записей в ARP-кэше. Доставка сетевого пакета на конкретный компьютер в конечном счете основана на его MAC-адресе – уникальном 48-битном номере, зашитом в каждую сетевую карту. Чтобы определить MAC-адрес компьютера по его IP-адресу, используется протокол ARP (Address Resolution Protocol – протокол разрешения адресов). Записи о соответствии IP-адресов и MAC-адресов обычно хранятся в кэше ARP 10–15 минут. Чтобы принудительно обновить ARP-кэш на других компьютерах, heartbeat рассылает в сеть так называемые «незаконные» [gratuitous] ARP-пакеты с компьютера, перенявшего IP-адрес.
|Ширина=200px}}

На обоих компьютерах действия ''Heartbeat'' будут писаться в журнал. На основном сервере среди прочего должно появиться сообщение типа:
<code>
logger: /etc/ha.d/resource.d/tester called with argument start
</code>

Оно означает, что основной сервер, как и ожидалось, запустил сервис '''tester'''.

{{Врезка
|Заголовок=Загружаем heartbeat
|Содержание=''Heartbeat'' нужно установить и на основном, и на запасном сервере. У меня на обоих компьютерах была установлена CentOS 5 (фактически, RHEL5). Я просто установил ''heartbeat'' вместе с зависимостями (которые включали ''heartbeat-pils'' и ''heartbeat-stonith'') из репозиториев CentOS с помощью ''yum''. Похожие пакеты есть и в репозиториях других дистрибутивов, таких как Ubuntu; в виде пакета RPMs для SUSE/Novell Linux их можно найти на сайте http://www.linux-ha.org/ или загрузить архив с исходными кодами с этого же сайта и скомпилировать программу из них.
|Ширина=200px}}

''Heartbeat'' запущен, и мы можем проверить поведение системы в случае отказа. Я просто выдернул шнур электропитания из основного сервера и наблюдал за сообщениями в файле журнала запасного. По истечении заданного времени запасной сервер сообщил об отказе основного и запустил сервис '''tester'''. Вот соответствующие строки журнала:
<code>
heartbeat: [9615]: WARN: node primary.example.com: is dead
heartbeat: [9615]: WARN: No STONITH device configured.
heartbeat: [9615]: WARN: Shared disks are not protected.
heartbeat: [9615]: info: Resources being acquired from primary.example.com.
heartbeat: [9615]: info: Link primary.example.com:/dev/ttyS0 dead.
heartbeat: [10305]: info: No local resources [/usr/share/heartbeat/ResourceManager listkeys backup.example.com] to acquire.
harc[10304]: [10323]: info: Running /etc/ha.d/rc.d/status status
mach_down[10329]: [10350]: info: Taking over resource group tester
ResourceManager[10351]: [10362]: info: Acquiring resource group:primary.example.com tester
logger: /etc/ha.d/resource.d/tester called with argument status
ResourceManager[10351]: [10379]: info: Running /etc/ha.d/resource.d/tester start
logger: /etc/ha.d/resource.d/tester called with argument start
mach_down[10329]: [10384]: info: mach_down takeover complete for node primary.example.com.
</code>

Первая проверка завершилась успешно, и пора поручить ''Heartbeat'' управление полноценным сервисом. Для этого проекта я выбрал httpd. Таким образом, сейчас нам нужно убедиться, что ''Apache'' установлен на обоих компьютерах, и положить в корневой каталог web-сервера какие-нибудь легко распознаваемые файлы. Я просто создал два файла '''/var/www/html/index.html''', по одному для основного и запасного серверов; в файле для основного сервера была строка “This is the website from the primary server”, для запасного – “This is the website from the backup server” («Это сайт с основного/запасного сервера»). На обоих компьютерах запустите ''httpd'':
<source lang="bash">
/etc/init.d/httpd start
</source>
и проверьте, что, открыв в браузере адрес <nowiki>http://localhost</nowiki>, вы видите эти файлы. Теперь остановите ''Apache'' и убедитесь, что он не запустится автоматически при загрузке системы. Воспользуйтесь командами:
<source lang="bash">
/etc/init.d/httpd stop
chkconfig httpd --del
</source>

Это важно, потому что ''Apache'' должен запуститься не во время загрузки, а только если ''Heartbeat'' запустил его.

Теперь нужно изменить файл ''haresources'' так:
<code>
primary.example.com httpd
primary.example.com 192.168.0.50
</code>

В первой строке указывается сервис, которым будет управлять ''Heartbeat'', а во второй – IP-адрес, используемый клиентом для доступа к сервису. При запуске ''Heartbeat'' этот адрес назначается на основной сервер как второй IP-адрес. Если основной сервер откажет, копия ''Heartbeat'', запущенная на запасном сервере, перенесет этот IP-адрес на свой сетевой интерфейс.

Предполагается, что ''Heartbeat'' будет управлять сервисами путем запуска скрипта, указанного в '''haresources''', с аргументами start, stop или status. Конечно, это те самые аргументы скриптов каталога '''/etc/init.d''', что используются для запуска сервисов во время загрузки системы, и, по правде говоря, ''Heartbeat'' будет автоматически искать скрипт '''httpd''' в каталоге '''/etc/init.d'''.

После внесения этих изменений в конфигурацию основного и запасного серверов можно снова запустить ''Heartbeat'' на каждом из них:
<source lang="bash">
/etc/init.d/heartbeat start
</source>

Когда ''Heartbeat'' войдет в нормальный режим работы, нужно кое-что проверить. На основном сервере запустите:
<code>
ip addr show
</code>
и проверьте, что ''Heartbeat'' назначил второй IP-адрес (в нашем примере 192.168.0.50) на наш сетевой интерфейс. Также запустите команду
<source lang="bash">
ps -ef | grep httpd
</source>
которая проверит, что сервис ''httpd'' запущен. На запасной сервер второй IP-адрес не назначается, а сервис ''httpd'' на нем не выполняется.

Теперь пора загрузить третий компьютер, чтобы использовать в качестве клиента. Убедитесь, что он может разрешить имя компьютера, на котором запущен сервис, по его IP-адресу. Для этого я просто добавил строку
<code>
192.168.0.50 www.example.com
</code>
в файл '''/etc/hosts'''. Проверьте, пингуется ли адрес <nowiki>www.example.com</nowiki> с компьютера клиента. Откройте в браузере на клиентском компьютере страницу <nowiki>http://www.example.com</nowiki>. Вы должны увидеть файл '''index.html''' основного сервера. На клиенте также можно проверить кэш '''arp''', запустив команду
<source lang="bash">
arp -a
</source>
и обратить внимание на MAC-адрес, связанный с IP-адресом 192.168.0.50. В моем случае результат работы команды был таким:
<code>
www.example.com (192.168.0.50) at 00:0C:F1:96:A3:F7 [ether] on eth0
</code>

===Ладно, и как это работает?===

Мы подошли к драматической развязке: демонстрации переноса сервиса на запасной сервер в случае отказа основного. Можно было просто отключить питание основного сервера, как и в предыдущем эксперименте, но на сей раз я избрал более кроткий способ – просто остановил ''Heartbeat'' на основном сервере командой:
<source lang="bash">
/etc/init.d/heartbeat stop
</source>

Остановившись, ''Heartbeat'' остановит ''httpd'' на основном сервере и проинформирует запасной сервер об отключении основного (через ''Heartbeat''-соединение). Запасной сервер сразу возьмет управление на себя, и в файле его журнала ('''/var/log/messages''') появятся новые сообщения. Два из них наиболее важны (время и другую информацию в начале строки я удалил):
<code>
Running /etc/init.d/httpd start
Registering new address record for 192.168.0.50 on eth0
</code>

В этом случае все заняло пару секунд. Если бы я просто выдернул из сети шнур питания основного сервера, то на восстановление системы потребовалось бы больше времени: в этом случае перед тем, как сделать вывод об отказе основного сервера и взять управление на себя, запасной сервер ожидал бы ответа 20 секунд (параметр deadtime в файле '''ha.cf''').

На клиентском компьютере следует провести пару важных тестов. Во-первых, попробуйте обновить страницу <nowiki>www.example.com</nowiki> в браузере. Должна появиться страница запасного сервера. Во-вторых, еще раз просмотрите содержимое ARP-кэша. На моем компьютере команда arp –a вернула следующий результат:
<code>
www.example.com (192.168.0.50) at 00:10:60:60:3E:8E [ether] on eth0
</code>

Это означает, что пакеты, предназначенные для адреса 192.168.0.50, теперь будут направляться на запасной сервер.

{{Врезка
|Заголовок=Дополнительная информация
|Содержание=Побольше узнать о ''heartbeat'' можно в документации '''/usr/share/doc/heartbeat''' (каталог зависит от конкретного дистрибутива), в частности, в файле '''GettingStarted'''. На сайте Linux HA также есть руководства и документация. Рекомендую вам прекрасную книжку “Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software” (No Starch Press, ISBN 1-59327-036-4).
|Ширина=200px}}

А что же дальше? Ну, наверное, со временем кто-то доберется до основного сервера, починит его и перезапустит. Когда ''Heartbeat'' перезапускается, он сообщает об этом запасному серверу через ''Heartbeat''-соединение. В журнале запасного сервера появятся такие строки:
<code>
Heartbeat restart on node primary.example.com
Releasing resource group: primary.example.com httpd
Running /etc/init.d/httpd stop
Withdrawing address record for 192.168.0.50 on eth0
</code>

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

Если у вас хватило духу дочитать до конца, поздравляю! Вы создали отказоустойчивый кластер в Linux и можете начать делать на этом деньги в реальном мире! Однако прежде чем пойти на собеседование в Google, NASA или даже Krazy Ken’s 24x7 Liquorice Emporium, быть может, вы захотите узнать о некоторых вопросах подробнее.

Один из них – это концепция «ограждения» (fencing). Когда запасной сервер перенимает ресурсы основного, нужно как-то гарантировать, чтобы основной сервер не попытался снова предоставить эти сервисы. ''Heartbeat'' может использовать для этого механизм STONITH (“shoot the other node in the head” – «контрольный выстрел в голову»), если вы купите устройство, программно отключающее питание компьютера. Второй вопрос – как синхронизировать содержимое двух web-серверов. В нашем примере мы умышленно сделали его разным, но на практике может потребоваться какое-то средство синхронизации их содержимого (''rsync'' или ''unison''). '''LXF'''

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

LXF100-101:Hardcore Linux

2009-03-06T23:36:58Z

Kipruss:

==Кластеры: Повышаем отказоустойчивость.==

Отказоустойчивость – то свойство, которое помогает кластеру пережить сбой электропитания и другие бедствия. '''Д-р Крис Браун''' покажет, как удержаться на плаву.

Журналы доступа к моей web-странице – не самое захватывающее чтиво. Если исключить случайные вторжения роботов поисковых систем, посетители заходят на сайт не чаще раза в неделю. Честно говоря, если сайт упадет, это заметят разве что через несколько месяцев. Даже грустно. Другая крайность – коммерческие web-сайты, приносящие владельцам ежедневный доход: несколько минут простоя такого сайта выливаются в ощутимые убытки для компании. На данном уроке я расскажу, как создать в Linux отказоустойчивый кластер. В случае краха основного сервера система автоматически переключается на запасной, а снаружи кластер выглядит как один очень надежный сервер. Нам поможет открытая программа ''Heartbeat'', найти которую можно на сайте www.linuxha.org. Кластер мы построим из двух компьютеров (основной и запасной сервер). ''Heartbeat'' будет отвечать за обнаружение отказа основного сервера и управлять запуском нужного нам сервиса на запасном. Мы воспользуемся сервисом ''Apache (httpd)'', но эта технология подойдет и для любого другого сервиса: FTP, DNS или почтового. В общем, все будет работать примерно так:

# В обычном режиме необходимые сервисы (типа ''httpd'') предоставляются основным сервером.
# Основной и запасной серверы постоянно обмениваются друг с другом сообщениями ''Heartbeat'' [англ. пульс], которые говорят запасному серверу, что с основным все в порядке.
# Если запасной сервер не получает сообщения, он перенимает ресурсы основного сервера (например, запускает собственную копию сервера ''httpd'').
# Запасной сервер перенимает IP-адрес, по которому предоставлялся сервис на основном сервере.

===Начинаем: компоненты системы===

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

На основном и запасном серверах должен быть установлен Linux, на клиенте – необязательно (хотя под Linux в вашем распоряжении окажутся лучшие средства диагностики). Компьютеры должны быть подключены к сети Ethernet. Для обмена сигналами ''Heartbeat'' на основном и запасном серверах должна быть вторая сетевая карта. Эти карты нужно соединить друг с другом либо перекрестным (crossover) кабелем, либо через мини-хаб. Если на обоих компьютерах есть последовательный порт, то вместо второго Ethernet-подключения можно соединить их последовательные порты перекрестным кабелем, по которому будет производиться обмен сигналами. Общая схема показана на [[:Изображение:Img_100_87_1.png|Рис. 1]].

===Установка heartbeat-соединения===

Если обмен сигналами ''Heartbeat'' будет осуществляться через Ethernet, соединить сетевые карты друг с другом можно двумя способами: либо через перекрестный кабель RJ45, либо парой обычных кабелей через мини-хаб. Первый вариант лучше, потому что здесь нечему выходить из строя. Каждой из карт нужно назначить статический IP-адрес, причем выбранный из частного диапазона, ни один адрес из которого не используется во внутренней сети. Например, первой карте можно назначить адрес 10.0.0.1, второй – 10.0.0.2. Убедитесь, что компьютеры могут достучаться друг до друга [ping].

Также можно использовать и соединение через последовательный порт. Тогда нам потребуется последовательный перекрестный кабель. На обоих концах этого кабеля, который еще называют нуль-модемным, имеется 9-контактный разъем типа «мама». Кабелем нужно соединить последовательные порты компьютеров. (Последовательные порты и кабели сейчас используются редко, и если на ваших компьютерах их нет, проще пойти и купить вторую сетевую карту для соединения по Ethernet.)

Чтобы проверить соединение через последовательные порты, выполните на основном сервере команду:
<code>
cat /dev/ttyS0
</code>
а на запасном – команду:
<code>
cat /etc/fstab > /dev/ttyS0
</code>

На основном сервере должно отображаться содержимое файла. Повторите эксперимент в обратном направлении.

''Heartbeat'' будет прекрасно работать с соединением любого типа. Преимущество Ethernet-соединения – трафик ''Heartbeat'' в этом случае можно отслеживать с помощью одной из утилит для отслеживания пакетов (например, wireshark). Можно даже использовать одновременно оба соединения, что позволит обойтись без ненужных откатов, если только одно из них выйдет из строя.

[[Изображение:Img_100_87_1.png|thumb|Рис. 1: Общая схема проекта; обратите внимание на IP-адреса.]]

===Настройка сетевых интерфейсов===

Оба сетевых интерфейса, которые участвуют в ''Heartbeat''-соединении, должны быть настроены на статические IP-адреса, так как DHCP-сервера в этой «сети» точно нет. Статические адреса должны быть и на основных интерфейсах, которые используются для подключения к основному и запасному серверам. Обратите внимание, что это НЕ те адреса, на которых предоставляется сервис. ''Heartbeat'' назначит сетевой карте исправного компьютера второй IP-адрес, и именно он будет использоваться клиентами для доступа к ресурсу.

===Три файла конфигурации===

Сразу после установки Heartbeat нужно создать в каталоге '''/etc/ha.d''' три (да, три!) файла конфигурации, а именно:

* '''ha.cf''' Файл содержит настройки самого ''Heartbeat''; в нем определяются используемые программой пути и устанавливаются некоторые временные параметры.
* '''haresources''' Этот файл определяет ресурсы (сервисы), которыми будет управлять Heartbeat, и основной сервер для каждого из этих ресурсов.
* '''authkey''' В этом файле задается пароль и метод шифрования, используемый для аутентификации Heartbeat-сообщений.

Начнем с '''ha.cf'''. Пример этого файла можно найти в документации на ''Heartbeat'' ('''/usr/share/doc/heartbeat/ha.cf'''). Это один из файлов типа «визгу много, проку мало», которые целиком состоят из документации и закомментированных примеров. Можно скопировать его в '''/etc/ha.d''' и использовать как отправную точку, или создать свой файл с нуля.

{{Врезка
|Заголовок=Ошибка!
|Содержание=В этой статье мы не говорим о том, как предотвратить неисправности других типов, например, те, что возникают в инфраструктуре самого интернета. В частности, мы не говорим о создании дополнительных информационных каналов для связи с сайтом. Впрочем, это не так уж и важно, потому что врожденная гибкость архитектуры интернета позволяет поглощать частные сбои. Часто даже говорят, что сеть ARPANET (предшественник интернета) разрабатывалась с таким расчетом, чтобы выдержать взрыв атомной бомбы. ARPANET и правда должна была справляться с утратой части сети, но главная причина была в том, что коммутация узлов сети и связей внутри нее была не особенно надежной, даже и без атомной бомбы.
|Ширина=200px}}

Вот минимальный вариант этого файла. Номера строк даны только для удобства ссылок, в самом файле их нет:
<code>
1. udpport 694
2. bcast eth1
3. serial /dev/ttyS0
4. baud 9600
5. keepalive 2
6. deadtime 20
7. initdead 60
8. node primary.example.com
9. node backup.example.com
</code>

Строки 1 и 2 задают номер порта и сетевой интерфейс, используемые для Heartbeat-соединения. Для соединения через последовательные порты в строках 3 и 3 задается порт и скорость соединения. Можно (и рекомендуется) использовать оба типа, но у меня было только соединение через последовательные порты, и я закомментировал строки 1 и 2. В строке 5 задается тайм-аут между сообщениями, а строка 6 определяет время, по истечении которого, не дождавшись очередного сообщения от основного сервера, запасной сочтет его покойником. В строке 7 указывается время, необходимое для активации сетевого интерфейса после включения компьютера, после чего ''Heartbeat'' начинает функционировать. В строках 8 и 9 задаются имена хостов для основного и запасного серверов (те, что возвращает команда uname -n).

Для начала попробуем управлять полностью фиктивным сервисом '''tester'''. Мы напишем скрипт, '''/etc/ha.d/resources.d/tester''', вызываемый ''Heartbeat''. Он будет всего лишь вызывать команду logger, которая сообщит нам (через ''syslogd''), что скрипт был запущен. Вот как он выглядит:
<code>
#!/bin/bash
logger $0 called with argument $1
</code>

Скрипт нужно сделать исполняемым, например, так:
<code>
chmod 755 tester
</code>

В следующем файле, ''haresources'', содержится список ресурсов, которыми управляет ''Heartbeat''. Когда компьютер выходит из строя, эти ресурсы перемещаются с одного узла сети на другой. (попробуйте произносить это как “ha-resources”, а не “hare-sauces” [англ. hare – заяц, source – источник, sauce – соус, – прим. ред.]. По правде говоря, я сроду не ел зайчатины, но первым делом подумал о кролике и решил, что подойдет клюквенный соус.) Опять же, пример этого файла можно найти в документации ('''/usr/share/doc/Heartbeat''') – можете просто скопировать его в '''/etc/ha.d''' или создать свой собственный файл с нуля. Для нашего первого теста в этом файле должна быть всего одна строка:
<code>
primary.example.com tester
</code>

Также нужно создать файл '''/etc/ha.d/authkeys''', содержащий ключи, используемые для аутентификации ''Heartbeat''-сообщений, например:
<code>
auth1
1 sha1 foobar
</code>

Нужно позаботиться, чтобы читать этот файл мог только администратор:
<code>
chmod 600 authkeys
</code>

Если права доступа к этому файлу есть у кого-то еще, ''Heartbeat'' не запустится.

Скопируйте эти четыре файла с основного сервера на запасной в соответствующие каталоги. Файл '''ha.cf''', возможно, придется подправить в зависимости от аппаратного обеспечения компьютера, а остальные файлы должны быть одинаковыми на обоих компьютерах.

Теперь можно запустить ''Heartbeat''. Для отслеживания сообщений ''Heartbeat'' на обоих компьютерах запустите tail -f для файла журнала ('''/var/log/messages'''). Запустите программу с помощью команды:
<code>
/etc/init.d/heartbeat start
</code>

{{Врезка
|Заголовок=Украденная личность
|Содержание=Перенос IP-адреса на другой компьютер – компьютерный эквивалент «воровства личности»: вы притворяетесь кем-то другим, а потом убеждаете весь мир, что вы настоящий. В процессе переноса системы на запасной сервер обязано произойти следующее. Во-первых, основной сервер должен отдать IP-адрес. Если он загорелся или нашел другую кончину, это произойдет по умолчанию, но если heartbeat останавливается на другом (исправном) сервере, адрес, очевидно, нужно забрать назад. Другая проблема – обновление записей в ARP-кэше. Доставка сетевого пакета на конкретный компьютер в конечном счете основана на его MAC-адресе – уникальном 48-битном номере, зашитом в каждую сетевую карту. Чтобы определить MAC-адрес компьютера по его IP-адресу, используется протокол ARP (Address Resolution Protocol – протокол разрешения адресов). Записи о соответствии IP-адресов и MAC-адресов обычно хранятся в кэше ARP 10–15 минут. Чтобы принудительно обновить ARP-кэш на других компьютерах, heartbeat рассылает в сеть так называемые «незаконные» [gratuitous] ARP-пакеты с компьютера, перенявшего IP-адрес.
|Ширина=200px}}

На обоих компьютерах действия ''Heartbeat'' будут писаться в журнал. На основном сервере среди прочего должно появиться сообщение типа:
<code>
logger: /etc/ha.d/resource.d/tester called with argument start
</code>

Оно означает, что основной сервер, как и ожидалось, запустил сервис '''tester'''.

{{Врезка
|Заголовок=Загружаем heartbeat
|Содержание=''Heartbeat'' нужно установить и на основном, и на запасном сервере. У меня на обоих компьютерах была установлена CentOS 5 (фактически, RHEL5). Я просто установил ''heartbeat'' вместе с зависимостями (которые включали ''heartbeat-pils'' и ''heartbeat-stonith'') из репозиториев CentOS с помощью ''yum''. Похожие пакеты есть и в репозиториях других дистрибутивов, таких как Ubuntu; в виде пакета RPMs для SUSE/Novell Linux их можно найти на сайте http://www.linux-ha.org/ или загрузить архив с исходными кодами с этого же сайта и скомпилировать программу из них.
|Ширина=200px}}

''Heartbeat'' запущен, и мы можем проверить поведение системы в случае отказа. Я просто выдернул шнур электропитания из основного сервера и наблюдал за сообщениями в файле журнала запасного. По истечении заданного времени запасной сервер сообщил об отказе основного и запустил сервис '''tester'''. Вот соответствующие строки журнала:
<code>
heartbeat: [9615]: WARN: node primary.example.com: is dead
heartbeat: [9615]: WARN: No STONITH device configured.
heartbeat: [9615]: WARN: Shared disks are not protected.
heartbeat: [9615]: info: Resources being acquired from primary.example.
com.
heartbeat: [9615]: info: Link primary.example.com:/dev/ttyS0 dead.
heartbeat: [10305]: info: No local resources [/usr/share/heartbeat/
ResourceManager listkeys backup.example.com] to acquire.
harc[10304]: [10323]: info: Running /etc/ha.d/rc.d/status status
mach_down[10329]: [10350]: info: Taking over resource group tester
ResourceManager[10351]: [10362]: info: Acquiring resource group:
primary.example.com tester
logger: /etc/ha.d/resource.d/tester called with argument status
ResourceManager[10351]: [10379]: info: Running /etc/ha.d/resource.d/
tester start
logger: /etc/ha.d/resource.d/tester called with argument start
mach_down[10329]: [10384]: info: mach_down takeover complete for
node primary.example.com.
</code>

Первая проверка завершилась успешно, и пора поручить ''Heartbeat'' управление полноценным сервисом. Для этого проекта я выбрал httpd. Таким образом, сейчас нам нужно убедиться, что ''Apache'' установлен на обоих компьютерах, и положить в корневой каталог web-сервера какие-нибудь легко распознаваемые файлы. Я просто создал два файла '''/var/www/html/index.html''', по одному для основного и запасного серверов; в файле для основного сервера была строка “This is the website from the primary server”, для запасного – “This is the website from the backup server” («Это сайт с основного/запасного сервера»). На обоих компьютерах запустите ''httpd'':
<code>
/etc/init.d/httpd start
</code>
и проверьте, что, открыв в браузере адрес <nowiki>http://localhost</nowiki>, вы видите эти файлы. Теперь остановите ''Apache'' и убедитесь, что он не запустится автоматически при загрузке системы. Воспользуйтесь командами:
<code>
/etc/init.d/httpd stop
chkconfig httpd --del
</code>

Это важно, потому что ''Apache'' должен запуститься не во время загрузки, а только если ''Heartbeat'' запустил его.

Теперь нужно изменить файл ''haresources'' так:
<code>
primary.example.com httpd
primary.example.com 192.168.0.50
</code>

В первой строке указывается сервис, которым будет управлять ''Heartbeat'', а во второй – IP-адрес, используемый клиентом для доступа к сервису. При запуске ''Heartbeat'' этот адрес назначается на основной сервер как второй IP-адрес. Если основной сервер откажет, копия ''Heartbeat'', запущенная на запасном сервере, перенесет этот IP-адрес на свой сетевой интерфейс.

Предполагается, что ''Heartbeat'' будет управлять сервисами путем запуска скрипта, указанного в '''haresources''', с аргументами start, stop или status. Конечно, это те самые аргументы скриптов каталога '''/etc/init.d''', что используются для запуска сервисов во время загрузки системы, и, по правде говоря, ''Heartbeat'' будет автоматически искать скрипт '''httpd''' в каталоге '''/etc/init.d'''.

После внесения этих изменений в конфигурацию основного и запасного серверов можно снова запустить ''Heartbeat'' на каждом из них:
<code>
/etc/init.d/heartbeat start
</code>

Когда ''Heartbeat'' войдет в нормальный режим работы, нужно кое-что проверить. На основном сервере запустите:
<code>
ip addr show
</code>
и проверьте, что ''Heartbeat'' назначил второй IP-адрес (в нашем примере 192.168.0.50) на наш сетевой интерфейс. Также запустите команду
<code>
ps -ef | grep httpd
</code>
которая проверит, что сервис ''httpd'' запущен. На запасной сервер второй IP-адрес не назначается, а сервис ''httpd'' на нем не выполняется.

Теперь пора загрузить третий компьютер, чтобы использовать в качестве клиента. Убедитесь, что он может разрешить имя компьютера, на котором запущен сервис, по его IP-адресу. Для этого я просто добавил строку
<code>
192.168.0.50 www.example.com
</code>
в файл '''/etc/hosts'''. Проверьте, пингуется ли адрес <nowiki>www.example.com</nowiki> с компьютера клиента. Откройте в браузере на клиентском компьютере страницу <nowiki>http://www.example.com</nowiki>. Вы должны увидеть файл '''index.html''' основного сервера. На клиенте также можно проверить кэш '''arp''', запустив команду
<code>
arp -a
</code>
и обратить внимание на MAC-адрес, связанный с IP-адресом 192.168.0.50. В моем случае результат работы команды был таким:
<code>
www.example.com (192.168.0.50) at 00:0C:F1:96:A3:F7 [ether] on eth0
</code>

===Ладно, и как это работает?===

Мы подошли к драматической развязке: демонстрации переноса сервиса на запасной сервер в случае отказа основного. Можно было просто отключить питание основного сервера, как и в предыдущем эксперименте, но на сей раз я избрал более кроткий способ – просто остановил ''Heartbeat'' на основном сервере командой:
<code>
/etc/init.d/heartbeat stop
</code>

Остановившись, ''Heartbeat'' остановит ''httpd'' на основном сервере и проинформирует запасной сервер об отключении основного (через ''Heartbeat''-соединение). Запасной сервер сразу возьмет управление на себя, и в файле его журнала ('''/var/log/messages''') появятся новые сообщения. Два из них наиболее важны (время и другую информацию в начале строки я удалил):
<code>
Running /etc/init.d/httpd start
Registering new address record for 192.168.0.50 on eth0
</code>

В этом случае все заняло пару секунд. Если бы я просто выдернул из сети шнур питания основного сервера, то на восстановление системы потребовалось бы больше времени: в этом случае перед тем, как сделать вывод об отказе основного сервера и взять управление на себя, запасной сервер ожидал бы ответа 20 секунд (параметр deadtime в файле '''ha.cf''').

На клиентском компьютере следует провести пару важных тестов. Во-первых, попробуйте обновить страницу <nowiki>www.example.com</nowiki> в браузере. Должна появиться страница запасного сервера. Во-вторых, еще раз просмотрите содержимое ARP-кэша. На моем компьютере команда arp –a вернула следующий результат:
<code>
www.example.com (192.168.0.50) at 00:10:60:60:3E:8E [ether] on eth0
</code>

Это означает, что пакеты, предназначенные для адреса 192.168.0.50, теперь будут направляться на запасной сервер.

{{Врезка
|Заголовок=Дополнительная информация
|Содержание=Побольше узнать о ''heartbeat'' можно в документации '''/usr/share/doc/heartbeat''' (каталог зависит от конкретного дистрибутива), в частности, в файле '''GettingStarted'''. На сайте Linux HA также есть руководства и документация. Рекомендую вам прекрасную книжку “Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software” (No Starch Press, ISBN 1-59327-036-4).
|Ширина=200px}}

А что же дальше? Ну, наверное, со временем кто-то доберется до основного сервера, починит его и перезапустит. Когда ''Heartbeat'' перезапускается, он сообщает об этом запасному серверу через ''Heartbeat''-соединение. В журнале запасного сервера появятся такие строки:
<code>
Heartbeat restart on node primary.example.com
Releasing resource group: primary.example.com httpd
Running /etc/init.d/httpd stop
Withdrawing address record for 192.168.0.50 on eth0
</code>

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

Если у вас хватило духу дочитать до конца, поздравляю! Вы создали отказоустойчивый кластер в Linux и можете начать делать на этом деньги в реальном мире! Однако прежде чем пойти на собеседование в Google, NASA или даже Krazy Ken’s 24x7 Liquorice Emporium, быть может, вы захотите узнать о некоторых вопросах подробнее.

Один из них – это концепция «ограждения» (fencing). Когда запасной сервер перенимает ресурсы основного, нужно как-то гарантировать, чтобы основной сервер не попытался снова предоставить эти сервисы. ''Heartbeat'' может использовать для этого механизм STONITH (“shoot the other node in the head” – «контрольный выстрел в голову»), если вы купите устройство, программно отключающее питание компьютера. Второй вопрос – как синхронизировать содержимое двух web-серверов. В нашем примере мы умышленно сделали его разным, но на практике может потребоваться какое-то средство синхронизации их содержимого (''rsync'' или ''unison''). '''LXF'''

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

Обсуждение участника:Yaleks

2009-03-06T23:30:40Z

Kipruss: /* LXF100 ... */

Установил расширения Cite, ParserFunctions и SyntaxHighlight - проверяйте --17:21, 11 марта 2008 (MSK)

Вы вчера перенесли статью LXF97:TEX в LXF97:Препринт, но при этом некорректно изменили оглавление номера, оставив в нем ссылку на LXF97:TEX, но удалив при этом ссылку на следующую статью Андрея Боровского. Я ее найти в списке статей не могу. Верните ее пожалуйста на место. --[[Участник:Crazy Rebel|Crazy Rebel]] 08:07, 3 октября 2008 (MSD)
: Я просто очистил содержимое, сама статья была создана давно. Оглавление сейчас пофиксил. --[[Участник:Yaleks|Yaleks]] 15:07, 4 октября 2008 (MSD)

== Викификация LXF70-77 ==
До сих пор я занимался викификацией LXF c конца, а Вы с начала. Но теперь, когда остались не завершенными только самые начальные номера, причем в каждом из них уже сделана какая то часть работы, Валентин Синицин посоетовал обратиться непосредственно к Вам, чтобы разделить оставшиеся для викификации статьи. В принципе я могу пойти и другим путем - начиная викификацию 2008 года. Так что давайте решим как будет удобнее. --[[Участник:Crazy Rebel|Crazy Rebel]]

* Вот что осталось (если существующие оглавления полные):
<nowiki># <s>[[LXF74-75:Inkscape]] (13 ссылок)</s>
# <s>[[LXF71:GIMP]]</s> (7 ссылок)
# <s>[[LXF72:GIMP]]</s> (7 ссылок)
# <s>[[LXF73:GIMP]]</s> (7 ссылок)
# <s>[[LXF73:Сравнение: Электронные фотоальбомы]] (2 ссылки)</s>
# <s>[[LXF74-75:Технологии Linux-2006]] (2 ссылки)</s>
# <s>[[LXF71:VariCAD 2005]]</s>
# <s>[[LXF71:KOffice 1.4]]</s>
# <s>[[LXF71:SmoothWall Firewall 4]]</s>
# <s>[[LXF71:Amarok 1.3]]</s>
# <s>[[LXF71:Спецрепортаж]]</s>
# <s>[[LXF71:Настольный Linux]]</s>
# <s>[[LXF71:Гонка за лидером]]</s>
# <s>[[LXF71:Дневники Linux]]</s>
# <s>[[LXF71:Subversion]]</s>
# <s>[[LXF77:Realsoft 3D]]</s>
# <s>[[LXF72:Советы по ускорению]]</s>
# <s>[[LXF76:Азбука записи]]</s>
# <s>[[LXF73:Автомонтирование USB]]</s>
# <s>[[LXF73:Русификация Debian 3.1]]</s>
# <s>[[LXF72:Frequently Asked Questions]]</s>
# <s>[[LXF72:Краткая справка]]</s>
# <s>[[LXF71:Ответы]]</s>
# <s>[[LXF72:Ответы]]</s>
# <s>[[LXF73:Ответы]]</s>
# <s>[[LXF74-75:Ответы]]</s>
# <s>[[LXF77:Ответы]]</s>
# <s>[[LXF71:Первые шаги]]</s>
# <s>[[LXF72:Первые шаги Печать]]</s>
# <s>[[LXF74-75:Первые шаги]]</s>
# <s>[[LXF77:Сравнение]]</s>
# <s>[[LXF71:Сравнение]]</s>
# <s>[[LXF76:Сравнение]]</s>
# <s>[[LXF76:Что такое]] GPL V3</s>
# <s>[[LXF76:Интервью]] Джереми Элиссон</s>
# <s>[[LXF76:Трюки с железом]]</s>
# <s>[[LXF76:Интервью2]] Йон фон Течнер</s>
# <s>[[LXF76:Dynebolic]]</s>
# <s>[[LXF76:MythTV]]</s></nowiki>

Большое число из этого уже устарело и представляет лишь исторический интерес. Можно тут <s>отмечать</s> (<nowiki><s>...</s></nowiki>) перед викификаций, чтобы не было коллизий. --[[Участник:Yaleks|Yaleks]] 22:45, 3 февраля 2009 (MSK)

* Поздравляю! Позиции в списке закончились.
** Это да, но мне ещё спецрепортаж доделывать. --[[Участник:Yaleks|Yaleks]] 20:24, 5 марта 2009 (MSK)
*** Я так сильно подозреваю, что это не единственная проблема, хотя я старался и выверял все номера, но могли гдето и недоделки остаться и статьи спрятаться. Но в общем следует считать, что эта часть завершена. Тем более что спецрепортаж это большая но всего одна статья.--[[Участник:Crazy Rebel|Crazy Rebel]] 10:08, 6 марта 2009 (MSK)

== LXF72 Советы по ускорению ==

А зачем там было делать "LXF72..." загловком? Я тоже так вначале сделал, но мне крайне не понравилось, что советы нумеруются 1.1 ... 1.32 тогда как в моем варианта было 1, 2 .... Ну и еще почему заголовок статьи Вы выделяетя двумя знаками <nowiki>==</nowiki> ведь можно и одним, тогда каждый вопрос отделяется друг от друго горизонтальной линией.
:* <nowiki>==</nowiki> это заголовок 1-ого уровня вики-синтаксиса (= использовать некорректно). И где вы редактируете статьи, что там вставляется какой-то 2-х байтовый пробел? Через OCR что-ли пропускаете? --[[Участник:Yaleks|Yaleks]] 22:15, 26 февраля 2009 (MSK)
:::* Статьи я копирую из kpdf собственно сразу в окно Firefox, откуда там стали браться неразрывные пробелы я понятия не имею. Возможно такие pdf-ки потому что LXF99 я делал таким же способом но никаких неразрывных пробелов там нет. Или это так работает новый kpdf.
:::* Проблему решил так - сначала копирую текст в kate там удаляю всю гадость (заменой по тексту) и уже потом вставляю в окно Firefox.

== LXF100 ... ==

В общем то викификация LXF70-99 подходит к концу и Синицын уже спрашивал меня о продолжении работы. Я согласен и как я понимаю Вы тоже. Но у Вас несколько другой подход - викифицировать не номерами, а темами. В приципе я вижу и преимущества и недостатки такого подхода. Ну из перимуществ это то, что пользователь получает информацию которая должна быть для него наиболее интересна, а из недостатков- отдельный номер может быть так до конца и не закончен. Будет осутствовать общий стиль оформлния. В общем я готов на любой подход к викификации. Если мы будем пользоваться Вашим методом то предлагаю делать так чтобы не пересекаться - Заранее оглавления не делаем, кто создает статью, тот ее и викифицирует.
: Если вы посмотрите на статистику хотя-бы нескольких ресурсов, то поймёте, что удержать и заставить посмотреть хотя-бы 3 страницы очень сложно. Потому иметь законченные и связанные кластеры статей лучше, чем несвязанную подборку из одного номера. Очень мало людей приходят введя адрес первой страницы и читают по-порядку, в основном по ссылкам с других сайтов или поисковых систем. --[[Участник:Yaleks|Yaleks]] 15:24, 1 марта 2009 (MSK)
:: И всеже я предлагаю сначала закончить LXF71 и только после этого приступать к 100 и далее, а то Синицын мне как то писал что руководство недовольно, что викификация этих номеров не закончена. А в остальном полностью согласен. Предлагаю значит сделать как раз так - кто начал викификацию тот ее и заканчивает. Чтобы нам тут оглавление не составлять.
Надо не забывать делать редиректы на статьи в номере 100-101 с несуществующих номеров 100 и 101.

== Присоединение к проекту ==

Обращаюсь к Yaleks'у, как к координатору: я готов в меру сил помочь в викификации того, что наиболее нужно в настоящее время. Номера 100-106 имеются, скачал по ссылке, которую дал Валентин. Мой почтовый адрес: kipruss_A_mail.ru. После прочтения, думаю, этот раздел можно удалить. :)

* Ну так выбирайте статью, вроде как решили с учебников начать, а то и цикл, вписывайте на соответствующей странице(цах) его название и вперед. Валентин сказал что за оформлением оглавления журанлов он сам проследит, но всетаки постарайтесь как в журнале делать название статьи и аннотацию.--[[Участник:Crazy Rebel|Crazy Rebel]] 10:10, 6 марта 2009 (MSK)
** Раз с учебников, то беру цикл "Hardcore Linux". Потом - Django, но этот цикл начинается с мая, по-моему - наверное лучше сделать те, которые продолжаются с прошлого года.--[[Участник:Kipruss|Kipruss]] 23:36, 6 марта 2009 (MSK)
* Смотрите на оформление существующих статей и делайте по аналогии (также см. [[Информация для авторов]]). Crazy Rebel, осталось расхождение с наименование картинок, я всё-таки предлагаю, чтобы в названии был номер журнала и страницы (возможно выбранный в начале Img не очень логично и лучше перейти к LXF10X_YY_Z.{jpg/png}). --[[Участник:Yaleks|Yaleks]] 11:57, 6 марта 2009 (MSK)
** Поздно я обратил внимание на это замечание. Ну, ничего страшного, надеюсь. Проба пера: [[LXF100:Hardcore_Linux]]
** Хорошо. Со следующей статьи начну именовать так. Не думаю что надо что либо переделывать в уже викифицицированных журналах если только качество старых картинок не нравится.--[[Участник:Crazy Rebel|Crazy Rebel]] 16:35, 6 марта 2009 (MSK)

LXF101:Hardcore Linux

2009-03-06T23:27:55Z

Kipruss: Перенаправление на LXF100-101:Hardcore Linux

#REDIRECT [[LXF100-101:Hardcore Linux]]

LXF100:Hardcore Linux

2009-03-06T23:27:06Z

Kipruss: «LXF100:Hardcore Linux» переименована в «LXF100-101:Hardcore Linux» поверх перенаправления

#REDIRECT [[LXF100-101:Hardcore Linux]]

LXF100-101:Hardcore Linux

2009-03-06T23:27:06Z

Kipruss: «LXF100:Hardcore Linux» переименована в «LXF100-101:Hardcore Linux» поверх перенаправления

==Кластеры: Повышаем отказоустойчивость.==

Отказоустойчивость – то свойство, которое помогает кластеру пережить сбой электропитания и другие бедствия. '''Д-р Крис Браун''' покажет, как удержаться на плаву.

Журналы доступа к моей web-странице – не самое захватывающее чтиво. Если исключить случайные вторжения роботов поисковых систем, посетители заходят на сайт не чаще раза в неделю. Честно говоря, если сайт упадет, это заметят разве что через несколько месяцев. Даже грустно. Другая крайность – коммерческие web-сайты, приносящие владельцам ежедневный доход: несколько минут простоя такого сайта выливаются в ощутимые убытки для компании. На данном уроке я расскажу, как создать в Linux отказоустойчивый кластер. В случае краха основного сервера система автоматически переключается на запасной, а снаружи кластер выглядит как один очень надежный сервер. Нам поможет открытая программа ''Heartbeat'', найти которую можно на сайте www.linuxha.org. Кластер мы построим из двух компьютеров (основной и запасной сервер). ''Heartbeat'' будет отвечать за обнаружение отказа основного сервера и управлять запуском нужного нам сервиса на запасном. Мы воспользуемся сервисом ''Apache (httpd)'', но эта технология подойдет и для любого другого сервиса: FTP, DNS или почтового. В общем, все будет работать примерно так:

# В обычном режиме необходимые сервисы (типа ''httpd'') предоставляются основным сервером.
# Основной и запасной серверы постоянно обмениваются друг с другом сообщениями ''Heartbeat'' [англ. пульс], которые говорят запасному серверу, что с основным все в порядке.
# Если запасной сервер не получает сообщения, он перенимает ресурсы основного сервера (например, запускает собственную копию сервера ''httpd'').
# Запасной сервер перенимает IP-адрес, по которому предоставлялся сервис на основном сервере.

===Начинаем: компоненты системы===

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

На основном и запасном серверах должен быть установлен Linux, на клиенте – необязательно (хотя под Linux в вашем распоряжении окажутся лучшие средства диагностики). Компьютеры должны быть подключены к сети Ethernet. Для обмена сигналами ''Heartbeat'' на основном и запасном серверах должна быть вторая сетевая карта. Эти карты нужно соединить друг с другом либо перекрестным (crossover) кабелем, либо через мини-хаб. Если на обоих компьютерах есть последовательный порт, то вместо второго Ethernet-подключения можно соединить их последовательные порты перекрестным кабелем, по которому будет производиться обмен сигналами. Общая схема показана на [[:Изображение:Img_100_87_1.png|Рис. 1]].

===Установка heartbeat-соединения===

Если обмен сигналами ''Heartbeat'' будет осуществляться через Ethernet, соединить сетевые карты друг с другом можно двумя способами: либо через перекрестный кабель RJ45, либо парой обычных кабелей через мини-хаб. Первый вариант лучше, потому что здесь нечему выходить из строя. Каждой из карт нужно назначить статический IP-адрес, причем выбранный из частного диапазона, ни один адрес из которого не используется во внутренней сети. Например, первой карте можно назначить адрес 10.0.0.1, второй – 10.0.0.2. Убедитесь, что компьютеры могут достучаться друг до друга [ping].

Также можно использовать и соединение через последовательный порт. Тогда нам потребуется последовательный перекрестный кабель. На обоих концах этого кабеля, который еще называют нуль-модемным, имеется 9-контактный разъем типа «мама». Кабелем нужно соединить последовательные порты компьютеров. (Последовательные порты и кабели сейчас используются редко, и если на ваших компьютерах их нет, проще пойти и купить вторую сетевую карту для соединения по Ethernet.)

Чтобы проверить соединение через последовательные порты, выполните на основном сервере команду:
<code>
cat /dev/ttyS0
</code>
а на запасном – команду:
<code>
cat /etc/fstab > /dev/ttyS0
</code>

На основном сервере должно отображаться содержимое файла. Повторите эксперимент в обратном направлении.

''Heartbeat'' будет прекрасно работать с соединением любого типа. Преимущество Ethernet-соединения – трафик ''Heartbeat'' в этом случае можно отслеживать с помощью одной из утилит для отслеживания пакетов (например, wireshark). Можно даже использовать одновременно оба соединения, что позволит обойтись без ненужных откатов, если только одно из них выйдет из строя.

[[Изображение:Img_100_87_1.png|thumb|Рис. 1: Общая схема проекта; обратите внимание на IP-адреса.]]

===Настройка сетевых интерфейсов===

Оба сетевых интерфейса, которые участвуют в ''Heartbeat''-соединении, должны быть настроены на статические IP-адреса, так как DHCP-сервера в этой «сети» точно нет. Статические адреса должны быть и на основных интерфейсах, которые используются для подключения к основному и запасному серверам. Обратите внимание, что это НЕ те адреса, на которых предоставляется сервис. ''Heartbeat'' назначит сетевой карте исправного компьютера второй IP-адрес, и именно он будет использоваться клиентами для доступа к ресурсу.

===Три файла конфигурации===

Сразу после установки Heartbeat нужно создать в каталоге '''/etc/ha.d''' три (да, три!) файла конфигурации, а именно:

* '''ha.cf''' Файл содержит настройки самого ''Heartbeat''; в нем определяются используемые программой пути и устанавливаются некоторые временные параметры.
* '''haresources''' Этот файл определяет ресурсы (сервисы), которыми будет управлять Heartbeat, и основной сервер для каждого из этих ресурсов.
* '''authkey''' В этом файле задается пароль и метод шифрования, используемый для аутентификации Heartbeat-сообщений.

Начнем с '''ha.cf'''. Пример этого файла можно найти в документации на ''Heartbeat'' ('''/usr/share/doc/heartbeat/ha.cf'''). Это один из файлов типа «визгу много, проку мало», которые целиком состоят из документации и закомментированных примеров. Можно скопировать его в '''/etc/ha.d''' и использовать как отправную точку, или создать свой файл с нуля.

{{Врезка
|Заголовок=Ошибка!
|Содержание=В этой статье мы не говорим о том, как предотвратить неисправности других типов, например, те, что возникают в инфраструктуре самого интернета. В частности, мы не говорим о создании дополнительных информационных каналов для связи с сайтом. Впрочем, это не так уж и важно, потому что врожденная гибкость архитектуры интернета позволяет поглощать частные сбои. Часто даже говорят, что сеть ARPANET (предшественник интернета) разрабатывалась с таким расчетом, чтобы выдержать взрыв атомной бомбы. ARPANET и правда должна была справляться с утратой части сети, но главная причина была в том, что коммутация узлов сети и связей внутри нее была не особенно надежной, даже и без атомной бомбы.
|Ширина=200px}}

Вот минимальный вариант этого файла. Номера строк даны только для удобства ссылок, в самом файле их нет:
<code>
1. udpport 694
2. bcast eth1
3. serial /dev/ttyS0
4. baud 9600
5. keepalive 2
6. deadtime 20
7. initdead 60
8. node primary.example.com
9. node backup.example.com
</code>

Строки 1 и 2 задают номер порта и сетевой интерфейс, используемые для Heartbeat-соединения. Для соединения через последовательные порты в строках 3 и 3 задается порт и скорость соединения. Можно (и рекомендуется) использовать оба типа, но у меня было только соединение через последовательные порты, и я закомментировал строки 1 и 2. В строке 5 задается тайм-аут между сообщениями, а строка 6 определяет время, по истечении которого, не дождавшись очередного сообщения от основного сервера, запасной сочтет его покойником. В строке 7 указывается время, необходимое для активации сетевого интерфейса после включения компьютера, после чего ''Heartbeat'' начинает функционировать. В строках 8 и 9 задаются имена хостов для основного и запасного серверов (те, что возвращает команда uname -n).

Для начала попробуем управлять полностью фиктивным сервисом '''tester'''. Мы напишем скрипт, '''/etc/ha.d/resources.d/tester''', вызываемый ''Heartbeat''. Он будет всего лишь вызывать команду logger, которая сообщит нам (через ''syslogd''), что скрипт был запущен. Вот как он выглядит:
<code>
#!/bin/bash
logger $0 called with argument $1
</code>

Скрипт нужно сделать исполняемым, например, так:
<code>
chmod 755 tester
</code>

В следующем файле, ''haresources'', содержится список ресурсов, которыми управляет ''Heartbeat''. Когда компьютер выходит из строя, эти ресурсы перемещаются с одного узла сети на другой. (попробуйте произносить это как “ha-resources”, а не “hare-sauces” [англ. hare – заяц, source – источник, sauce – соус, – прим. ред.]. По правде говоря, я сроду не ел зайчатины, но первым делом подумал о кролике и решил, что подойдет клюквенный соус.) Опять же, пример этого файла можно найти в документации ('''/usr/share/doc/Heartbeat''') – можете просто скопировать его в '''/etc/ha.d''' или создать свой собственный файл с нуля. Для нашего первого теста в этом файле должна быть всего одна строка:
<code>
primary.example.com tester
</code>

Также нужно создать файл '''/etc/ha.d/authkeys''', содержащий ключи, используемые для аутентификации ''Heartbeat''-сообщений, например:
<code>
auth1
1 sha1 foobar
</code>

Нужно позаботиться, чтобы читать этот файл мог только администратор:
<code>
chmod 600 authkeys
</code>

Если права доступа к этому файлу есть у кого-то еще, ''Heartbeat'' не запустится.

Скопируйте эти четыре файла с основного сервера на запасной в соответствующие каталоги. Файл '''ha.cf''', возможно, придется подправить в зависимости от аппаратного обеспечения компьютера, а остальные файлы должны быть одинаковыми на обоих компьютерах.

Теперь можно запустить ''Heartbeat''. Для отслеживания сообщений ''Heartbeat'' на обоих компьютерах запустите tail -f для файла журнала ('''/var/log/messages'''). Запустите программу с помощью команды:
<code>
/etc/init.d/heartbeat start
</code>

{{Врезка
|Заголовок=Украденная личность
|Содержание=Перенос IP-адреса на другой компьютер – компьютерный эквивалент «воровства личности»: вы притворяетесь кем-то другим, а потом убеждаете весь мир, что вы настоящий. В процессе переноса системы на запасной сервер обязано произойти следующее. Во-первых, основной сервер должен отдать IP-адрес. Если он загорелся или нашел другую кончину, это произойдет по умолчанию, но если heartbeat останавливается на другом (исправном) сервере, адрес, очевидно, нужно забрать назад. Другая проблема – обновление записей в ARP-кэше. Доставка сетевого пакета на конкретный компьютер в конечном счете основана на его MAC-адресе – уникальном 48-битном номере, зашитом в каждую сетевую карту. Чтобы определить MAC-адрес компьютера по его IP-адресу, используется протокол ARP (Address Resolution Protocol – протокол разрешения адресов). Записи о соответствии IP-адресов и MAC-адресов обычно хранятся в кэше ARP 10–15 минут. Чтобы принудительно обновить ARP-кэш на других компьютерах, heartbeat рассылает в сеть так называемые «незаконные» [gratuitous] ARP-пакеты с компьютера, перенявшего IP-адрес.
|Ширина=200px}}

На обоих компьютерах действия ''Heartbeat'' будут писаться в журнал. На основном сервере среди прочего должно появиться сообщение типа:
<code>
logger: /etc/ha.d/resource.d/tester called with argument start
</code>

Оно означает, что основной сервер, как и ожидалось, запустил сервис '''tester'''.

{{Врезка
|Заголовок=Загружаем heartbeat
|Содержание=''Heartbeat'' нужно установить и на основном, и на запасном сервере. У меня на обоих компьютерах была установлена CentOS 5 (фактически, RHEL5). Я просто установил ''heartbeat'' вместе с зависимостями (которые включали ''heartbeat-pils'' и ''heartbeat-stonith'') из репозиториев CentOS с помощью ''yum''. Похожие пакеты есть и в репозиториях других дистрибутивов, таких как Ubuntu; в виде пакета RPMs для SUSE/Novell Linux их можно найти на сайте http://www.linux-ha.org/ или загрузить архив с исходными кодами с этого же сайта и скомпилировать программу из них.
|Ширина=200px}}

''Heartbeat'' запущен, и мы можем проверить поведение системы в случае отказа. Я просто выдернул шнур электропитания из основного сервера и наблюдал за сообщениями в файле журнала запасного. По истечении заданного времени запасной сервер сообщил об отказе основного и запустил сервис '''tester'''. Вот соответствующие строки журнала:
<code>
heartbeat: [9615]: WARN: node primary.example.com: is dead
heartbeat: [9615]: WARN: No STONITH device configured.
heartbeat: [9615]: WARN: Shared disks are not protected.
heartbeat: [9615]: info: Resources being acquired from primary.example.
com.
heartbeat: [9615]: info: Link primary.example.com:/dev/ttyS0 dead.
heartbeat: [10305]: info: No local resources [/usr/share/heartbeat/
ResourceManager listkeys backup.example.com] to acquire.
harc[10304]: [10323]: info: Running /etc/ha.d/rc.d/status status
mach_down[10329]: [10350]: info: Taking over resource group tester
ResourceManager[10351]: [10362]: info: Acquiring resource group:
primary.example.com tester
logger: /etc/ha.d/resource.d/tester called with argument status
ResourceManager[10351]: [10379]: info: Running /etc/ha.d/resource.d/
tester start
logger: /etc/ha.d/resource.d/tester called with argument start
mach_down[10329]: [10384]: info: mach_down takeover complete for
node primary.example.com.
</code>

Первая проверка завершилась успешно, и пора поручить ''Heartbeat'' управление полноценным сервисом. Для этого проекта я выбрал httpd. Таким образом, сейчас нам нужно убедиться, что ''Apache'' установлен на обоих компьютерах, и положить в корневой каталог web-сервера какие-нибудь легко распознаваемые файлы. Я просто создал два файла '''/var/www/html/index.html''', по одному для основного и запасного серверов; в файле для основного сервера была строка “This is the website from the primary server”, для запасного – “This is the website from the backup server” («Это сайт с основного/запасного сервера»). На обоих компьютерах запустите ''httpd'':
<code>
/etc/init.d/httpd start
</code>
и проверьте, что, открыв в браузере адрес <nowiki>http://localhost</nowiki>, вы видите эти файлы. Теперь остановите ''Apache'' и убедитесь, что он не запустится автоматически при загрузке системы. Воспользуйтесь командами:
<code>
/etc/init.d/httpd stop
chkconfig httpd --del
</code>

Это важно, потому что ''Apache'' должен запуститься не во время загрузки, а только если ''Heartbeat'' запустил его.

Теперь нужно изменить файл ''haresources'' так:
<code>
primary.example.com httpd
primary.example.com 192.168.0.50
</code>

В первой строке указывается сервис, которым будет управлять ''Heartbeat'', а во второй – IP-адрес, используемый клиентом для доступа к сервису. При запуске ''Heartbeat'' этот адрес назначается на основной сервер как второй IP-адрес. Если основной сервер откажет, копия ''Heartbeat'', запущенная на запасном сервере, перенесет этот IP-адрес на свой сетевой интерфейс.

Предполагается, что ''Heartbeat'' будет управлять сервисами путем запуска скрипта, указанного в '''haresources''', с аргументами start, stop или status. Конечно, это те самые аргументы скриптов каталога '''/etc/init.d''', что используются для запуска сервисов во время загрузки системы, и, по правде говоря, ''Heartbeat'' будет автоматически искать скрипт '''httpd''' в каталоге '''/etc/init.d'''.

После внесения этих изменений в конфигурацию основного и запасного серверов можно снова запустить ''Heartbeat'' на каждом из них:
<code>
/etc/init.d/heartbeat start
</code>

Когда ''Heartbeat'' войдет в нормальный режим работы, нужно кое-что проверить. На основном сервере запустите:
<code>
ip addr show
</code>
и проверьте, что ''Heartbeat'' назначил второй IP-адрес (в нашем примере 192.168.0.50) на наш сетевой интерфейс. Также запустите команду
<code>
ps -ef | grep httpd
</code>
которая проверит, что сервис ''httpd'' запущен. На запасной сервер второй IP-адрес не назначается, а сервис ''httpd'' на нем не выполняется.

Теперь пора загрузить третий компьютер, чтобы использовать в качестве клиента. Убедитесь, что он может разрешить имя компьютера, на котором запущен сервис, по его IP-адресу. Для этого я просто добавил строку
<code>
192.168.0.50 www.example.com
</code>
в файл '''/etc/hosts'''. Проверьте, пингуется ли адрес <nowiki>www.example.com</nowiki> с компьютера клиента. Откройте в браузере на клиентском компьютере страницу <nowiki>http://www.example.com</nowiki>. Вы должны увидеть файл '''index.html''' основного сервера. На клиенте также можно проверить кэш '''arp''', запустив команду
<code>
arp -a
</code>
и обратить внимание на MAC-адрес, связанный с IP-адресом 192.168.0.50. В моем случае результат работы команды был таким:
<code>
www.example.com (192.168.0.50) at 00:0C:F1:96:A3:F7 [ether] on eth0
</code>

===Ладно, и как это работает?===

Мы подошли к драматической развязке: демонстрации переноса сервиса на запасной сервер в случае отказа основного. Можно было просто отключить питание основного сервера, как и в предыдущем эксперименте, но на сей раз я избрал более кроткий способ – просто остановил ''Heartbeat'' на основном сервере командой:
<code>
/etc/init.d/heartbeat stop
</code>

Остановившись, ''Heartbeat'' остановит ''httpd'' на основном сервере и проинформирует запасной сервер об отключении основного (через ''Heartbeat''-соединение). Запасной сервер сразу возьмет управление на себя, и в файле его журнала ('''/var/log/messages''') появятся новые сообщения. Два из них наиболее важны (время и другую информацию в начале строки я удалил):
<code>
Running /etc/init.d/httpd start
Registering new address record for 192.168.0.50 on eth0
</code>

В этом случае все заняло пару секунд. Если бы я просто выдернул из сети шнур питания основного сервера, то на восстановление системы потребовалось бы больше времени: в этом случае перед тем, как сделать вывод об отказе основного сервера и взять управление на себя, запасной сервер ожидал бы ответа 20 секунд (параметр deadtime в файле '''ha.cf''').

На клиентском компьютере следует провести пару важных тестов. Во-первых, попробуйте обновить страницу <nowiki>www.example.com</nowiki> в браузере. Должна появиться страница запасного сервера. Во-вторых, еще раз просмотрите содержимое ARP-кэша. На моем компьютере команда arp –a вернула следующий результат:
<code>
www.example.com (192.168.0.50) at 00:10:60:60:3E:8E [ether] on eth0
</code>

Это означает, что пакеты, предназначенные для адреса 192.168.0.50, теперь будут направляться на запасной сервер.

{{Врезка
|Заголовок=Дополнительная информация
|Содержание=Побольше узнать о ''heartbeat'' можно в документации '''/usr/share/doc/heartbeat''' (каталог зависит от конкретного дистрибутива), в частности, в файле '''GettingStarted'''. На сайте Linux HA также есть руководства и документация. Рекомендую вам прекрасную книжку “Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software” (No Starch Press, ISBN 1-59327-036-4).
|Ширина=200px}}

А что же дальше? Ну, наверное, со временем кто-то доберется до основного сервера, починит его и перезапустит. Когда ''Heartbeat'' перезапускается, он сообщает об этом запасному серверу через ''Heartbeat''-соединение. В журнале запасного сервера появятся такие строки:
<code>
Heartbeat restart on node primary.example.com
Releasing resource group: primary.example.com httpd
Running /etc/init.d/httpd stop
Withdrawing address record for 192.168.0.50 on eth0
</code>

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

Если у вас хватило духу дочитать до конца, поздравляю! Вы создали отказоустойчивый кластер в Linux и можете начать делать на этом деньги в реальном мире! Однако прежде чем пойти на собеседование в Google, NASA или даже Krazy Ken’s 24x7 Liquorice Emporium, быть может, вы захотите узнать о некоторых вопросах подробнее.

Один из них – это концепция «ограждения» (fencing). Когда запасной сервер перенимает ресурсы основного, нужно как-то гарантировать, чтобы основной сервер не попытался снова предоставить эти сервисы. ''Heartbeat'' может использовать для этого механизм STONITH (“shoot the other node in the head” – «контрольный выстрел в голову»), если вы купите устройство, программно отключающее питание компьютера. Второй вопрос – как синхронизировать содержимое двух web-серверов. В нашем примере мы умышленно сделали его разным, но на практике может потребоваться какое-то средство синхронизации их содержимого (''rsync'' или ''unison''). '''LXF'''

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

LXF100-101:Hardcore Linux

2009-03-06T23:26:03Z

Kipruss: /* Три файла конфигурации */

==Кластеры: Повышаем отказоустойчивость.==

Отказоустойчивость – то свойство, которое помогает кластеру пережить сбой электропитания и другие бедствия. '''Д-р Крис Браун''' покажет, как удержаться на плаву.

Журналы доступа к моей web-странице – не самое захватывающее чтиво. Если исключить случайные вторжения роботов поисковых систем, посетители заходят на сайт не чаще раза в неделю. Честно говоря, если сайт упадет, это заметят разве что через несколько месяцев. Даже грустно. Другая крайность – коммерческие web-сайты, приносящие владельцам ежедневный доход: несколько минут простоя такого сайта выливаются в ощутимые убытки для компании. На данном уроке я расскажу, как создать в Linux отказоустойчивый кластер. В случае краха основного сервера система автоматически переключается на запасной, а снаружи кластер выглядит как один очень надежный сервер. Нам поможет открытая программа ''Heartbeat'', найти которую можно на сайте www.linuxha.org. Кластер мы построим из двух компьютеров (основной и запасной сервер). ''Heartbeat'' будет отвечать за обнаружение отказа основного сервера и управлять запуском нужного нам сервиса на запасном. Мы воспользуемся сервисом ''Apache (httpd)'', но эта технология подойдет и для любого другого сервиса: FTP, DNS или почтового. В общем, все будет работать примерно так:

# В обычном режиме необходимые сервисы (типа ''httpd'') предоставляются основным сервером.
# Основной и запасной серверы постоянно обмениваются друг с другом сообщениями ''Heartbeat'' [англ. пульс], которые говорят запасному серверу, что с основным все в порядке.
# Если запасной сервер не получает сообщения, он перенимает ресурсы основного сервера (например, запускает собственную копию сервера ''httpd'').
# Запасной сервер перенимает IP-адрес, по которому предоставлялся сервис на основном сервере.

===Начинаем: компоненты системы===

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

На основном и запасном серверах должен быть установлен Linux, на клиенте – необязательно (хотя под Linux в вашем распоряжении окажутся лучшие средства диагностики). Компьютеры должны быть подключены к сети Ethernet. Для обмена сигналами ''Heartbeat'' на основном и запасном серверах должна быть вторая сетевая карта. Эти карты нужно соединить друг с другом либо перекрестным (crossover) кабелем, либо через мини-хаб. Если на обоих компьютерах есть последовательный порт, то вместо второго Ethernet-подключения можно соединить их последовательные порты перекрестным кабелем, по которому будет производиться обмен сигналами. Общая схема показана на [[:Изображение:Img_100_87_1.png|Рис. 1]].

===Установка heartbeat-соединения===

Если обмен сигналами ''Heartbeat'' будет осуществляться через Ethernet, соединить сетевые карты друг с другом можно двумя способами: либо через перекрестный кабель RJ45, либо парой обычных кабелей через мини-хаб. Первый вариант лучше, потому что здесь нечему выходить из строя. Каждой из карт нужно назначить статический IP-адрес, причем выбранный из частного диапазона, ни один адрес из которого не используется во внутренней сети. Например, первой карте можно назначить адрес 10.0.0.1, второй – 10.0.0.2. Убедитесь, что компьютеры могут достучаться друг до друга [ping].

Также можно использовать и соединение через последовательный порт. Тогда нам потребуется последовательный перекрестный кабель. На обоих концах этого кабеля, который еще называют нуль-модемным, имеется 9-контактный разъем типа «мама». Кабелем нужно соединить последовательные порты компьютеров. (Последовательные порты и кабели сейчас используются редко, и если на ваших компьютерах их нет, проще пойти и купить вторую сетевую карту для соединения по Ethernet.)

Чтобы проверить соединение через последовательные порты, выполните на основном сервере команду:
<code>
cat /dev/ttyS0
</code>
а на запасном – команду:
<code>
cat /etc/fstab > /dev/ttyS0
</code>

На основном сервере должно отображаться содержимое файла. Повторите эксперимент в обратном направлении.

''Heartbeat'' будет прекрасно работать с соединением любого типа. Преимущество Ethernet-соединения – трафик ''Heartbeat'' в этом случае можно отслеживать с помощью одной из утилит для отслеживания пакетов (например, wireshark). Можно даже использовать одновременно оба соединения, что позволит обойтись без ненужных откатов, если только одно из них выйдет из строя.

[[Изображение:Img_100_87_1.png|thumb|Рис. 1: Общая схема проекта; обратите внимание на IP-адреса.]]

===Настройка сетевых интерфейсов===

Оба сетевых интерфейса, которые участвуют в ''Heartbeat''-соединении, должны быть настроены на статические IP-адреса, так как DHCP-сервера в этой «сети» точно нет. Статические адреса должны быть и на основных интерфейсах, которые используются для подключения к основному и запасному серверам. Обратите внимание, что это НЕ те адреса, на которых предоставляется сервис. ''Heartbeat'' назначит сетевой карте исправного компьютера второй IP-адрес, и именно он будет использоваться клиентами для доступа к ресурсу.

===Три файла конфигурации===

Сразу после установки Heartbeat нужно создать в каталоге '''/etc/ha.d''' три (да, три!) файла конфигурации, а именно:

* '''ha.cf''' Файл содержит настройки самого ''Heartbeat''; в нем определяются используемые программой пути и устанавливаются некоторые временные параметры.
* '''haresources''' Этот файл определяет ресурсы (сервисы), которыми будет управлять Heartbeat, и основной сервер для каждого из этих ресурсов.
* '''authkey''' В этом файле задается пароль и метод шифрования, используемый для аутентификации Heartbeat-сообщений.

Начнем с '''ha.cf'''. Пример этого файла можно найти в документации на ''Heartbeat'' ('''/usr/share/doc/heartbeat/ha.cf'''). Это один из файлов типа «визгу много, проку мало», которые целиком состоят из документации и закомментированных примеров. Можно скопировать его в '''/etc/ha.d''' и использовать как отправную точку, или создать свой файл с нуля.

{{Врезка
|Заголовок=Ошибка!
|Содержание=В этой статье мы не говорим о том, как предотвратить неисправности других типов, например, те, что возникают в инфраструктуре самого интернета. В частности, мы не говорим о создании дополнительных информационных каналов для связи с сайтом. Впрочем, это не так уж и важно, потому что врожденная гибкость архитектуры интернета позволяет поглощать частные сбои. Часто даже говорят, что сеть ARPANET (предшественник интернета) разрабатывалась с таким расчетом, чтобы выдержать взрыв атомной бомбы. ARPANET и правда должна была справляться с утратой части сети, но главная причина была в том, что коммутация узлов сети и связей внутри нее была не особенно надежной, даже и без атомной бомбы.
|Ширина=200px}}

Вот минимальный вариант этого файла. Номера строк даны только для удобства ссылок, в самом файле их нет:
<code>
1. udpport 694
2. bcast eth1
3. serial /dev/ttyS0
4. baud 9600
5. keepalive 2
6. deadtime 20
7. initdead 60
8. node primary.example.com
9. node backup.example.com
</code>

Строки 1 и 2 задают номер порта и сетевой интерфейс, используемые для Heartbeat-соединения. Для соединения через последовательные порты в строках 3 и 3 задается порт и скорость соединения. Можно (и рекомендуется) использовать оба типа, но у меня было только соединение через последовательные порты, и я закомментировал строки 1 и 2. В строке 5 задается тайм-аут между сообщениями, а строка 6 определяет время, по истечении которого, не дождавшись очередного сообщения от основного сервера, запасной сочтет его покойником. В строке 7 указывается время, необходимое для активации сетевого интерфейса после включения компьютера, после чего ''Heartbeat'' начинает функционировать. В строках 8 и 9 задаются имена хостов для основного и запасного серверов (те, что возвращает команда uname -n).

Для начала попробуем управлять полностью фиктивным сервисом '''tester'''. Мы напишем скрипт, '''/etc/ha.d/resources.d/tester''', вызываемый ''Heartbeat''. Он будет всего лишь вызывать команду logger, которая сообщит нам (через ''syslogd''), что скрипт был запущен. Вот как он выглядит:
<code>
#!/bin/bash
logger $0 called with argument $1
</code>

Скрипт нужно сделать исполняемым, например, так:
<code>
chmod 755 tester
</code>

В следующем файле, ''haresources'', содержится список ресурсов, которыми управляет ''Heartbeat''. Когда компьютер выходит из строя, эти ресурсы перемещаются с одного узла сети на другой. (попробуйте произносить это как “ha-resources”, а не “hare-sauces” [англ. hare – заяц, source – источник, sauce – соус, – прим. ред.]. По правде говоря, я сроду не ел зайчатины, но первым делом подумал о кролике и решил, что подойдет клюквенный соус.) Опять же, пример этого файла можно найти в документации ('''/usr/share/doc/Heartbeat''') – можете просто скопировать его в '''/etc/ha.d''' или создать свой собственный файл с нуля. Для нашего первого теста в этом файле должна быть всего одна строка:
<code>
primary.example.com tester
</code>

Также нужно создать файл '''/etc/ha.d/authkeys''', содержащий ключи, используемые для аутентификации ''Heartbeat''-сообщений, например:
<code>
auth1
1 sha1 foobar
</code>

Нужно позаботиться, чтобы читать этот файл мог только администратор:
<code>
chmod 600 authkeys
</code>

Если права доступа к этому файлу есть у кого-то еще, ''Heartbeat'' не запустится.

Скопируйте эти четыре файла с основного сервера на запасной в соответствующие каталоги. Файл '''ha.cf''', возможно, придется подправить в зависимости от аппаратного обеспечения компьютера, а остальные файлы должны быть одинаковыми на обоих компьютерах.

Теперь можно запустить ''Heartbeat''. Для отслеживания сообщений ''Heartbeat'' на обоих компьютерах запустите tail -f для файла журнала ('''/var/log/messages'''). Запустите программу с помощью команды:
<code>
/etc/init.d/heartbeat start
</code>

{{Врезка
|Заголовок=Украденная личность
|Содержание=Перенос IP-адреса на другой компьютер – компьютерный эквивалент «воровства личности»: вы притворяетесь кем-то другим, а потом убеждаете весь мир, что вы настоящий. В процессе переноса системы на запасной сервер обязано произойти следующее. Во-первых, основной сервер должен отдать IP-адрес. Если он загорелся или нашел другую кончину, это произойдет по умолчанию, но если heartbeat останавливается на другом (исправном) сервере, адрес, очевидно, нужно забрать назад. Другая проблема – обновление записей в ARP-кэше. Доставка сетевого пакета на конкретный компьютер в конечном счете основана на его MAC-адресе – уникальном 48-битном номере, зашитом в каждую сетевую карту. Чтобы определить MAC-адрес компьютера по его IP-адресу, используется протокол ARP (Address Resolution Protocol – протокол разрешения адресов). Записи о соответствии IP-адресов и MAC-адресов обычно хранятся в кэше ARP 10–15 минут. Чтобы принудительно обновить ARP-кэш на других компьютерах, heartbeat рассылает в сеть так называемые «незаконные» [gratuitous] ARP-пакеты с компьютера, перенявшего IP-адрес.
|Ширина=200px}}

На обоих компьютерах действия ''Heartbeat'' будут писаться в журнал. На основном сервере среди прочего должно появиться сообщение типа:
<code>
logger: /etc/ha.d/resource.d/tester called with argument start
</code>

Оно означает, что основной сервер, как и ожидалось, запустил сервис '''tester'''.

{{Врезка
|Заголовок=Загружаем heartbeat
|Содержание=''Heartbeat'' нужно установить и на основном, и на запасном сервере. У меня на обоих компьютерах была установлена CentOS 5 (фактически, RHEL5). Я просто установил ''heartbeat'' вместе с зависимостями (которые включали ''heartbeat-pils'' и ''heartbeat-stonith'') из репозиториев CentOS с помощью ''yum''. Похожие пакеты есть и в репозиториях других дистрибутивов, таких как Ubuntu; в виде пакета RPMs для SUSE/Novell Linux их можно найти на сайте http://www.linux-ha.org/ или загрузить архив с исходными кодами с этого же сайта и скомпилировать программу из них.
|Ширина=200px}}

''Heartbeat'' запущен, и мы можем проверить поведение системы в случае отказа. Я просто выдернул шнур электропитания из основного сервера и наблюдал за сообщениями в файле журнала запасного. По истечении заданного времени запасной сервер сообщил об отказе основного и запустил сервис '''tester'''. Вот соответствующие строки журнала:
<code>
heartbeat: [9615]: WARN: node primary.example.com: is dead
heartbeat: [9615]: WARN: No STONITH device configured.
heartbeat: [9615]: WARN: Shared disks are not protected.
heartbeat: [9615]: info: Resources being acquired from primary.example.
com.
heartbeat: [9615]: info: Link primary.example.com:/dev/ttyS0 dead.
heartbeat: [10305]: info: No local resources [/usr/share/heartbeat/
ResourceManager listkeys backup.example.com] to acquire.
harc[10304]: [10323]: info: Running /etc/ha.d/rc.d/status status
mach_down[10329]: [10350]: info: Taking over resource group tester
ResourceManager[10351]: [10362]: info: Acquiring resource group:
primary.example.com tester
logger: /etc/ha.d/resource.d/tester called with argument status
ResourceManager[10351]: [10379]: info: Running /etc/ha.d/resource.d/
tester start
logger: /etc/ha.d/resource.d/tester called with argument start
mach_down[10329]: [10384]: info: mach_down takeover complete for
node primary.example.com.
</code>

Первая проверка завершилась успешно, и пора поручить ''Heartbeat'' управление полноценным сервисом. Для этого проекта я выбрал httpd. Таким образом, сейчас нам нужно убедиться, что ''Apache'' установлен на обоих компьютерах, и положить в корневой каталог web-сервера какие-нибудь легко распознаваемые файлы. Я просто создал два файла '''/var/www/html/index.html''', по одному для основного и запасного серверов; в файле для основного сервера была строка “This is the website from the primary server”, для запасного – “This is the website from the backup server” («Это сайт с основного/запасного сервера»). На обоих компьютерах запустите ''httpd'':
<code>
/etc/init.d/httpd start
</code>
и проверьте, что, открыв в браузере адрес <nowiki>http://localhost</nowiki>, вы видите эти файлы. Теперь остановите ''Apache'' и убедитесь, что он не запустится автоматически при загрузке системы. Воспользуйтесь командами:
<code>
/etc/init.d/httpd stop
chkconfig httpd --del
</code>

Это важно, потому что ''Apache'' должен запуститься не во время загрузки, а только если ''Heartbeat'' запустил его.

Теперь нужно изменить файл ''haresources'' так:
<code>
primary.example.com httpd
primary.example.com 192.168.0.50
</code>

В первой строке указывается сервис, которым будет управлять ''Heartbeat'', а во второй – IP-адрес, используемый клиентом для доступа к сервису. При запуске ''Heartbeat'' этот адрес назначается на основной сервер как второй IP-адрес. Если основной сервер откажет, копия ''Heartbeat'', запущенная на запасном сервере, перенесет этот IP-адрес на свой сетевой интерфейс.

Предполагается, что ''Heartbeat'' будет управлять сервисами путем запуска скрипта, указанного в '''haresources''', с аргументами start, stop или status. Конечно, это те самые аргументы скриптов каталога '''/etc/init.d''', что используются для запуска сервисов во время загрузки системы, и, по правде говоря, ''Heartbeat'' будет автоматически искать скрипт '''httpd''' в каталоге '''/etc/init.d'''.

После внесения этих изменений в конфигурацию основного и запасного серверов можно снова запустить ''Heartbeat'' на каждом из них:
<code>
/etc/init.d/heartbeat start
</code>

Когда ''Heartbeat'' войдет в нормальный режим работы, нужно кое-что проверить. На основном сервере запустите:
<code>
ip addr show
</code>
и проверьте, что ''Heartbeat'' назначил второй IP-адрес (в нашем примере 192.168.0.50) на наш сетевой интерфейс. Также запустите команду
<code>
ps -ef | grep httpd
</code>
которая проверит, что сервис ''httpd'' запущен. На запасной сервер второй IP-адрес не назначается, а сервис ''httpd'' на нем не выполняется.

Теперь пора загрузить третий компьютер, чтобы использовать в качестве клиента. Убедитесь, что он может разрешить имя компьютера, на котором запущен сервис, по его IP-адресу. Для этого я просто добавил строку
<code>
192.168.0.50 www.example.com
</code>
в файл '''/etc/hosts'''. Проверьте, пингуется ли адрес <nowiki>www.example.com</nowiki> с компьютера клиента. Откройте в браузере на клиентском компьютере страницу <nowiki>http://www.example.com</nowiki>. Вы должны увидеть файл '''index.html''' основного сервера. На клиенте также можно проверить кэш '''arp''', запустив команду
<code>
arp -a
</code>
и обратить внимание на MAC-адрес, связанный с IP-адресом 192.168.0.50. В моем случае результат работы команды был таким:
<code>
www.example.com (192.168.0.50) at 00:0C:F1:96:A3:F7 [ether] on eth0
</code>

===Ладно, и как это работает?===

Мы подошли к драматической развязке: демонстрации переноса сервиса на запасной сервер в случае отказа основного. Можно было просто отключить питание основного сервера, как и в предыдущем эксперименте, но на сей раз я избрал более кроткий способ – просто остановил ''Heartbeat'' на основном сервере командой:
<code>
/etc/init.d/heartbeat stop
</code>

Остановившись, ''Heartbeat'' остановит ''httpd'' на основном сервере и проинформирует запасной сервер об отключении основного (через ''Heartbeat''-соединение). Запасной сервер сразу возьмет управление на себя, и в файле его журнала ('''/var/log/messages''') появятся новые сообщения. Два из них наиболее важны (время и другую информацию в начале строки я удалил):
<code>
Running /etc/init.d/httpd start
Registering new address record for 192.168.0.50 on eth0
</code>

В этом случае все заняло пару секунд. Если бы я просто выдернул из сети шнур питания основного сервера, то на восстановление системы потребовалось бы больше времени: в этом случае перед тем, как сделать вывод об отказе основного сервера и взять управление на себя, запасной сервер ожидал бы ответа 20 секунд (параметр deadtime в файле '''ha.cf''').

На клиентском компьютере следует провести пару важных тестов. Во-первых, попробуйте обновить страницу <nowiki>www.example.com</nowiki> в браузере. Должна появиться страница запасного сервера. Во-вторых, еще раз просмотрите содержимое ARP-кэша. На моем компьютере команда arp –a вернула следующий результат:
<code>
www.example.com (192.168.0.50) at 00:10:60:60:3E:8E [ether] on eth0
</code>

Это означает, что пакеты, предназначенные для адреса 192.168.0.50, теперь будут направляться на запасной сервер.

{{Врезка
|Заголовок=Дополнительная информация
|Содержание=Побольше узнать о ''heartbeat'' можно в документации '''/usr/share/doc/heartbeat''' (каталог зависит от конкретного дистрибутива), в частности, в файле '''GettingStarted'''. На сайте Linux HA также есть руководства и документация. Рекомендую вам прекрасную книжку “Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software” (No Starch Press, ISBN 1-59327-036-4).
|Ширина=200px}}

А что же дальше? Ну, наверное, со временем кто-то доберется до основного сервера, починит его и перезапустит. Когда ''Heartbeat'' перезапускается, он сообщает об этом запасному серверу через ''Heartbeat''-соединение. В журнале запасного сервера появятся такие строки:
<code>
Heartbeat restart on node primary.example.com
Releasing resource group: primary.example.com httpd
Running /etc/init.d/httpd stop
Withdrawing address record for 192.168.0.50 on eth0
</code>

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

Если у вас хватило духу дочитать до конца, поздравляю! Вы создали отказоустойчивый кластер в Linux и можете начать делать на этом деньги в реальном мире! Однако прежде чем пойти на собеседование в Google, NASA или даже Krazy Ken’s 24x7 Liquorice Emporium, быть может, вы захотите узнать о некоторых вопросах подробнее.

Один из них – это концепция «ограждения» (fencing). Когда запасной сервер перенимает ресурсы основного, нужно как-то гарантировать, чтобы основной сервер не попытался снова предоставить эти сервисы. ''Heartbeat'' может использовать для этого механизм STONITH (“shoot the other node in the head” – «контрольный выстрел в голову»), если вы купите устройство, программно отключающее питание компьютера. Второй вопрос – как синхронизировать содержимое двух web-серверов. В нашем примере мы умышленно сделали его разным, но на практике может потребоваться какое-то средство синхронизации их содержимого (''rsync'' или ''unison''). '''LXF'''

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

LXF100-101

2009-03-06T23:23:45Z

Kipruss:

=== Учебники ===

* [[LXF100-101:Hardcore Linux|'''Hardcore Linux.''' Кластеры: Повышаем отказоустойчивость.]]
Отказоустойчивость – то свойство, которое помогает кластеру пережить сбой электропитания и другие бедствия. Д-р Крис Браун покажет, как удержаться на плаву.
* [[LXF100-101:Ананас|Ананас]]
Документы и печатные формы
* Обработка данных
Введение в R

=== Игросторой ===
* [[LXF100-101:Стрелялка|Стрелялка за выходные]]

LXF101

2009-03-06T23:20:46Z

Kipruss: Перенаправление на LXF100-101

#REDIRECT [[LXF100-101]]

LXF100

2009-03-06T23:20:28Z

Kipruss: Перенаправление на LXF100-101

#REDIRECT [[LXF100-101]]

LXF101:Hardcore Linux

2009-03-06T23:19:08Z

Kipruss: Перенаправление на LXF100:Hardcore Linux

#REDIRECT [[LXF100:Hardcore Linux]]

Обсуждение участника:Yaleks

2009-03-06T23:12:40Z

Kipruss: /* Присоединение к проекту */

Установил расширения Cite, ParserFunctions и SyntaxHighlight - проверяйте --17:21, 11 марта 2008 (MSK)

Вы вчера перенесли статью LXF97:TEX в LXF97:Препринт, но при этом некорректно изменили оглавление номера, оставив в нем ссылку на LXF97:TEX, но удалив при этом ссылку на следующую статью Андрея Боровского. Я ее найти в списке статей не могу. Верните ее пожалуйста на место. --[[Участник:Crazy Rebel|Crazy Rebel]] 08:07, 3 октября 2008 (MSD)
: Я просто очистил содержимое, сама статья была создана давно. Оглавление сейчас пофиксил. --[[Участник:Yaleks|Yaleks]] 15:07, 4 октября 2008 (MSD)

== Викификация LXF70-77 ==
До сих пор я занимался викификацией LXF c конца, а Вы с начала. Но теперь, когда остались не завершенными только самые начальные номера, причем в каждом из них уже сделана какая то часть работы, Валентин Синицин посоетовал обратиться непосредственно к Вам, чтобы разделить оставшиеся для викификации статьи. В принципе я могу пойти и другим путем - начиная викификацию 2008 года. Так что давайте решим как будет удобнее. --[[Участник:Crazy Rebel|Crazy Rebel]]

* Вот что осталось (если существующие оглавления полные):
<nowiki># <s>[[LXF74-75:Inkscape]] (13 ссылок)</s>
# <s>[[LXF71:GIMP]]</s> (7 ссылок)
# <s>[[LXF72:GIMP]]</s> (7 ссылок)
# <s>[[LXF73:GIMP]]</s> (7 ссылок)
# <s>[[LXF73:Сравнение: Электронные фотоальбомы]] (2 ссылки)</s>
# <s>[[LXF74-75:Технологии Linux-2006]] (2 ссылки)</s>
# <s>[[LXF71:VariCAD 2005]]</s>
# <s>[[LXF71:KOffice 1.4]]</s>
# <s>[[LXF71:SmoothWall Firewall 4]]</s>
# <s>[[LXF71:Amarok 1.3]]</s>
# <s>[[LXF71:Спецрепортаж]]</s>
# <s>[[LXF71:Настольный Linux]]</s>
# <s>[[LXF71:Гонка за лидером]]</s>
# <s>[[LXF71:Дневники Linux]]</s>
# <s>[[LXF71:Subversion]]</s>
# <s>[[LXF77:Realsoft 3D]]</s>
# <s>[[LXF72:Советы по ускорению]]</s>
# <s>[[LXF76:Азбука записи]]</s>
# <s>[[LXF73:Автомонтирование USB]]</s>
# <s>[[LXF73:Русификация Debian 3.1]]</s>
# <s>[[LXF72:Frequently Asked Questions]]</s>
# <s>[[LXF72:Краткая справка]]</s>
# <s>[[LXF71:Ответы]]</s>
# <s>[[LXF72:Ответы]]</s>
# <s>[[LXF73:Ответы]]</s>
# <s>[[LXF74-75:Ответы]]</s>
# <s>[[LXF77:Ответы]]</s>
# <s>[[LXF71:Первые шаги]]</s>
# <s>[[LXF72:Первые шаги Печать]]</s>
# <s>[[LXF74-75:Первые шаги]]</s>
# <s>[[LXF77:Сравнение]]</s>
# <s>[[LXF71:Сравнение]]</s>
# <s>[[LXF76:Сравнение]]</s>
# <s>[[LXF76:Что такое]] GPL V3</s>
# <s>[[LXF76:Интервью]] Джереми Элиссон</s>
# <s>[[LXF76:Трюки с железом]]</s>
# <s>[[LXF76:Интервью2]] Йон фон Течнер</s>
# <s>[[LXF76:Dynebolic]]</s>
# <s>[[LXF76:MythTV]]</s></nowiki>

Большое число из этого уже устарело и представляет лишь исторический интерес. Можно тут <s>отмечать</s> (<nowiki><s>...</s></nowiki>) перед викификаций, чтобы не было коллизий. --[[Участник:Yaleks|Yaleks]] 22:45, 3 февраля 2009 (MSK)

* Поздравляю! Позиции в списке закончились.
** Это да, но мне ещё спецрепортаж доделывать. --[[Участник:Yaleks|Yaleks]] 20:24, 5 марта 2009 (MSK)
*** Я так сильно подозреваю, что это не единственная проблема, хотя я старался и выверял все номера, но могли гдето и недоделки остаться и статьи спрятаться. Но в общем следует считать, что эта часть завершена. Тем более что спецрепортаж это большая но всего одна статья.--[[Участник:Crazy Rebel|Crazy Rebel]] 10:08, 6 марта 2009 (MSK)

== LXF72 Советы по ускорению ==

А зачем там было делать "LXF72..." загловком? Я тоже так вначале сделал, но мне крайне не понравилось, что советы нумеруются 1.1 ... 1.32 тогда как в моем варианта было 1, 2 .... Ну и еще почему заголовок статьи Вы выделяетя двумя знаками <nowiki>==</nowiki> ведь можно и одним, тогда каждый вопрос отделяется друг от друго горизонтальной линией.
:* <nowiki>==</nowiki> это заголовок 1-ого уровня вики-синтаксиса (= использовать некорректно). И где вы редактируете статьи, что там вставляется какой-то 2-х байтовый пробел? Через OCR что-ли пропускаете? --[[Участник:Yaleks|Yaleks]] 22:15, 26 февраля 2009 (MSK)
:::* Статьи я копирую из kpdf собственно сразу в окно Firefox, откуда там стали браться неразрывные пробелы я понятия не имею. Возможно такие pdf-ки потому что LXF99 я делал таким же способом но никаких неразрывных пробелов там нет. Или это так работает новый kpdf.
:::* Проблему решил так - сначала копирую текст в kate там удаляю всю гадость (заменой по тексту) и уже потом вставляю в окно Firefox.

== LXF100 ... ==

В общем то викификация LXF70-99 подходит к концу и Синицын уже спрашивал меня о продолжении работы. Я согласен и как я понимаю Вы тоже. Но у Вас несколько другой подход - викифицировать не номерами, а темами. В приципе я вижу и преимущества и недостатки такого подхода. Ну из перимуществ это то, что пользователь получает информацию которая должна быть для него наиболее интересна, а из недостатков- отдельный номер может быть так до конца и не закончен. Будет осутствовать общий стиль оформлния. В общем я готов на любой подход к викификации. Если мы будем пользоваться Вашим методом то предлагаю делать так чтобы не пересекаться - Заранее оглавления не делаем, кто создает статью, тот ее и викифицирует.
: Если вы посмотрите на статистику хотя-бы нескольких ресурсов, то поймёте, что удержать и заставить посмотреть хотя-бы 3 страницы очень сложно. Потому иметь законченные и связанные кластеры статей лучше, чем несвязанную подборку из одного номера. Очень мало людей приходят введя адрес первой страницы и читают по-порядку, в основном по ссылкам с других сайтов или поисковых систем. --[[Участник:Yaleks|Yaleks]] 15:24, 1 марта 2009 (MSK)
:: И всеже я предлагаю сначала закончить LXF71 и только после этого приступать к 100 и далее, а то Синицын мне как то писал что руководство недовольно, что викификация этих номеров не закончена. А в остальном полностью согласен. Предлагаю значит сделать как раз так - кто начал викификацию тот ее и заканчивает. Чтобы нам тут оглавление не составлять.

== Присоединение к проекту ==

Обращаюсь к Yaleks'у, как к координатору: я готов в меру сил помочь в викификации того, что наиболее нужно в настоящее время. Номера 100-106 имеются, скачал по ссылке, которую дал Валентин. Мой почтовый адрес: kipruss_A_mail.ru. После прочтения, думаю, этот раздел можно удалить. :)

* Ну так выбирайте статью, вроде как решили с учебников начать, а то и цикл, вписывайте на соответствующей странице(цах) его название и вперед. Валентин сказал что за оформлением оглавления журанлов он сам проследит, но всетаки постарайтесь как в журнале делать название статьи и аннотацию.--[[Участник:Crazy Rebel|Crazy Rebel]] 10:10, 6 марта 2009 (MSK)
** Раз с учебников, то беру цикл "Hardcore Linux". Потом - Django, но этот цикл начинается с мая, по-моему - наверное лучше сделать те, которые продолжаются с прошлого года.--[[Участник:Kipruss|Kipruss]] 23:36, 6 марта 2009 (MSK)
* Смотрите на оформление существующих статей и делайте по аналогии (также см. [[Информация для авторов]]). Crazy Rebel, осталось расхождение с наименование картинок, я всё-таки предлагаю, чтобы в названии был номер журнала и страницы (возможно выбранный в начале Img не очень логично и лучше перейти к LXF10X_YY_Z.{jpg/png}). --[[Участник:Yaleks|Yaleks]] 11:57, 6 марта 2009 (MSK)
** Поздно я обратил внимание на это замечание. Ну, ничего страшного, надеюсь. Проба пера: [[LXF100:Hardcore_Linux]]
** Хорошо. Со следующей статьи начну именовать так. Не думаю что надо что либо переделывать в уже викифицицированных журналах если только качество старых картинок не нравится.--[[Участник:Crazy Rebel|Crazy Rebel]] 16:35, 6 марта 2009 (MSK)

LXF100-101:Hardcore Linux

2009-03-06T23:08:56Z

Kipruss: оформление

==Кластеры: Повышаем отказоустойчивость.==

Отказоустойчивость – то свойство, которое помогает кластеру пережить сбой электропитания и другие бедствия. '''Д-р Крис Браун''' покажет, как удержаться на плаву.

Журналы доступа к моей web-странице – не самое захватывающее чтиво. Если исключить случайные вторжения роботов поисковых систем, посетители заходят на сайт не чаще раза в неделю. Честно говоря, если сайт упадет, это заметят разве что через несколько месяцев. Даже грустно. Другая крайность – коммерческие web-сайты, приносящие владельцам ежедневный доход: несколько минут простоя такого сайта выливаются в ощутимые убытки для компании. На данном уроке я расскажу, как создать в Linux отказоустойчивый кластер. В случае краха основного сервера система автоматически переключается на запасной, а снаружи кластер выглядит как один очень надежный сервер. Нам поможет открытая программа ''Heartbeat'', найти которую можно на сайте www.linuxha.org. Кластер мы построим из двух компьютеров (основной и запасной сервер). ''Heartbeat'' будет отвечать за обнаружение отказа основного сервера и управлять запуском нужного нам сервиса на запасном. Мы воспользуемся сервисом ''Apache (httpd)'', но эта технология подойдет и для любого другого сервиса: FTP, DNS или почтового. В общем, все будет работать примерно так:

# В обычном режиме необходимые сервисы (типа ''httpd'') предоставляются основным сервером.
# Основной и запасной серверы постоянно обмениваются друг с другом сообщениями ''Heartbeat'' [англ. пульс], которые говорят запасному серверу, что с основным все в порядке.
# Если запасной сервер не получает сообщения, он перенимает ресурсы основного сервера (например, запускает собственную копию сервера ''httpd'').
# Запасной сервер перенимает IP-адрес, по которому предоставлялся сервис на основном сервере.

===Начинаем: компоненты системы===

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

На основном и запасном серверах должен быть установлен Linux, на клиенте – необязательно (хотя под Linux в вашем распоряжении окажутся лучшие средства диагностики). Компьютеры должны быть подключены к сети Ethernet. Для обмена сигналами ''Heartbeat'' на основном и запасном серверах должна быть вторая сетевая карта. Эти карты нужно соединить друг с другом либо перекрестным (crossover) кабелем, либо через мини-хаб. Если на обоих компьютерах есть последовательный порт, то вместо второго Ethernet-подключения можно соединить их последовательные порты перекрестным кабелем, по которому будет производиться обмен сигналами. Общая схема показана на [[:Изображение:Img_100_87_1.png|Рис. 1]].

===Установка heartbeat-соединения===

Если обмен сигналами ''Heartbeat'' будет осуществляться через Ethernet, соединить сетевые карты друг с другом можно двумя способами: либо через перекрестный кабель RJ45, либо парой обычных кабелей через мини-хаб. Первый вариант лучше, потому что здесь нечему выходить из строя. Каждой из карт нужно назначить статический IP-адрес, причем выбранный из частного диапазона, ни один адрес из которого не используется во внутренней сети. Например, первой карте можно назначить адрес 10.0.0.1, второй – 10.0.0.2. Убедитесь, что компьютеры могут достучаться друг до друга [ping].

Также можно использовать и соединение через последовательный порт. Тогда нам потребуется последовательный перекрестный кабель. На обоих концах этого кабеля, который еще называют нуль-модемным, имеется 9-контактный разъем типа «мама». Кабелем нужно соединить последовательные порты компьютеров. (Последовательные порты и кабели сейчас используются редко, и если на ваших компьютерах их нет, проще пойти и купить вторую сетевую карту для соединения по Ethernet.)

Чтобы проверить соединение через последовательные порты, выполните на основном сервере команду:
<code>
cat /dev/ttyS0
</code>
а на запасном – команду:
<code>
cat /etc/fstab > /dev/ttyS0
</code>

На основном сервере должно отображаться содержимое файла. Повторите эксперимент в обратном направлении.

''Heartbeat'' будет прекрасно работать с соединением любого типа. Преимущество Ethernet-соединения – трафик ''Heartbeat'' в этом случае можно отслеживать с помощью одной из утилит для отслеживания пакетов (например, wireshark). Можно даже использовать одновременно оба соединения, что позволит обойтись без ненужных откатов, если только одно из них выйдет из строя.

[[Изображение:Img_100_87_1.png|thumb|Рис. 1: Общая схема проекта; обратите внимание на IP-адреса.]]

===Настройка сетевых интерфейсов===

Оба сетевых интерфейса, которые участвуют в ''Heartbeat''-соединении, должны быть настроены на статические IP-адреса, так как DHCP-сервера в этой «сети» точно нет. Статические адреса должны быть и на основных интерфейсах, которые используются для подключения к основному и запасному серверам. Обратите внимание, что это НЕ те адреса, на которых предоставляется сервис. ''Heartbeat'' назначит сетевой карте исправного компьютера второй IP-адрес, и именно он будет использоваться клиентами для доступа к ресурсу.

===Три файла конфигурации===

Сразу после установки Heartbeat нужно создать в каталоге '''/etc/ha.d''' три (да, три!) файла конфигурации, а именно:

* '''ha.cf''' Файл содержит настройки самого ''Heartbeat''; в нем определяются используемые программой пути и устанавливаются некоторые временные параметры.
* '''haresources''' Этот файл определяет ресурсы (сервисы), которыми будет управлять Heartbeat, и основной сервер для каждого из этих ресурсов.
* '''authkey''' В этом файле задается пароль и метод шифрования, используемый для аутентификации Heartbeat-сообщений.

Начнем с '''ha.cf'''. Пример этого файла можно найти в документации на ''Heartbeat'' ('''/usr/share/doc/heartbeat/ha.cf'''). Это один из файлов типа «визгу много, проку мало», которые целиком состоят из документации и закомментированных примеров. Можно скопировать его в '''/etc/ha.d''' и использовать как отправную точку, или создать свой файл с нуля.

{{Врезка
|Заголовок=Ошибка!
|Содержание=В этой статье мы не говорим о том, как предотвратить неисправности других типов, например, те, что возникают в инфраструктуре самого интернета. В частности, мы не говорим о создании дополнительных информационных каналов для связи с сайтом. Впрочем, это не так уж и важно, потому что врожденная гибкость архитектуры интернета позволяет поглощать частные сбои. Часто даже говорят, что сеть ARPANET (предшественник интернета) разрабатывалась с таким расчетом, чтобы выдержать взрыв атомной бомбы. ARPANET и правда должна была справляться с утратой части сети, но главная причина была в том, что коммутация узлов сети и связей внутри нее была не особенно надежной, даже и без атомной бомбы.
|Ширина=200px}}

Вот минимальный вариант этого файла. Номера строк даны только для удобства ссылок, в самом файле их нет:
<code>
1. udpport 694
2. bcast eth1
3. serial /dev/ttyS0
4. baud 9600
5. keepalive 2
6. deadtime 20
7. initdead 60
8. node primary.example.com
9. node backup.example.com
</code>

Строки 1 и 2 задают номер порта и сетевой интерфейс, используемые для Heartbeat-соединения. Для соединения через последовательные порты в строках 3 и 3 задается порт и скорость соединения. Можно (и рекомендуется) использовать оба типа, но у меня было только соединение через последовательные порты, и я закомментировал строки 1 и 2. В строке 5 задается тайм-аут между сообщениями, а строка 6 определяет время, по истечении которого, не дождавшись очередного сообщения от основного сервера, запасной сочтет его покойником. В строке 7 указывается время, необходимое для активации сетевого интерфейса после включения компьютера, после чего ''Heartbeat'' начинает функционировать. В строках 9 и 9 задаются имена хостов для основного и запасного серверов (те, что возвращает команда uname -n).

Для начала попробуем управлять полностью фиктивным сервисом '''tester'''. Мы напишем скрипт, '''/etc/ha.d/resources.d/tester''', вызываемый ''Heartbeat''. Он будет всего лишь вызывать команду logger, которая сообщит нам (через ''syslogd''), что скрипт был запущен. Вот как он выглядит:
<code>
#!/bin/bash
logger $0 called with argument $1
</code>

Скрипт нужно сделать исполняемым, например, так:
<code>
chmod 755 tester
</code>

В следующем файле, ''haresources'', содержится список ресурсов, которыми управляет ''Heartbeat''. Когда компьютер выходит из строя, эти ресурсы перемещаются с одного узла сети на другой. (попробуйте произносить это как “ha-resources”, а не “hare-sauces” [англ. hare – заяц, source – источник, sauce – соус, – прим. ред.]. По правде говоря, я сроду не ел зайчатины, но первым делом подумал о кролике и решил, что подойдет клюквенный соус.) Опять же, пример этого файла можно найти в документации ('''/usr/share/doc/Heartbeat''') – можете просто скопировать его в '''/etc/ha.d''' или создать свой собственный файл с нуля. Для нашего первого теста в этом файле должна быть всего одна строка:
<code>
primary.example.com tester
</code>

Также нужно создать файл '''/etc/ha.d/authkeys''', содержащий ключи, используемые для аутентификации ''Heartbeat''-сообщений, например:
<code>
auth1
1 sha1 foobar
</code>

Нужно позаботиться, чтобы читать этот файл мог только администратор:
<code>
chmod 600 authkeys
</code>

Если права доступа к этому файлу есть у кого-то еще, ''Heartbeat'' не запустится.

Скопируйте эти четыре файла с основного сервера на запасной в соответствующие каталоги. Файл '''ha.cf''', возможно, придется подправить в зависимости от аппаратного обеспечения компьютера, а остальные файлы должны быть одинаковыми на обоих компьютерах.

Теперь можно запустить ''Heartbeat''. Для отслеживания сообщений ''Heartbeat'' на обоих компьютерах запустите tail -f для файла журнала ('''/var/log/messages'''). Запустите программу с помощью команды:
<code>
/etc/init.d/heartbeat start
</code>

{{Врезка
|Заголовок=Украденная личность
|Содержание=Перенос IP-адреса на другой компьютер – компьютерный эквивалент «воровства личности»: вы притворяетесь кем-то другим, а потом убеждаете весь мир, что вы настоящий. В процессе переноса системы на запасной сервер обязано произойти следующее. Во-первых, основной сервер должен отдать IP-адрес. Если он загорелся или нашел другую кончину, это произойдет по умолчанию, но если heartbeat останавливается на другом (исправном) сервере, адрес, очевидно, нужно забрать назад. Другая проблема – обновление записей в ARP-кэше. Доставка сетевого пакета на конкретный компьютер в конечном счете основана на его MAC-адресе – уникальном 48-битном номере, зашитом в каждую сетевую карту. Чтобы определить MAC-адрес компьютера по его IP-адресу, используется протокол ARP (Address Resolution Protocol – протокол разрешения адресов). Записи о соответствии IP-адресов и MAC-адресов обычно хранятся в кэше ARP 10–15 минут. Чтобы принудительно обновить ARP-кэш на других компьютерах, heartbeat рассылает в сеть так называемые «незаконные» [gratuitous] ARP-пакеты с компьютера, перенявшего IP-адрес.
|Ширина=200px}}

На обоих компьютерах действия ''Heartbeat'' будут писаться в журнал. На основном сервере среди прочего должно появиться сообщение типа:
<code>
logger: /etc/ha.d/resource.d/tester called with argument start
</code>

Оно означает, что основной сервер, как и ожидалось, запустил сервис '''tester'''.

{{Врезка
|Заголовок=Загружаем heartbeat
|Содержание=''Heartbeat'' нужно установить и на основном, и на запасном сервере. У меня на обоих компьютерах была установлена CentOS 5 (фактически, RHEL5). Я просто установил ''heartbeat'' вместе с зависимостями (которые включали ''heartbeat-pils'' и ''heartbeat-stonith'') из репозиториев CentOS с помощью ''yum''. Похожие пакеты есть и в репозиториях других дистрибутивов, таких как Ubuntu; в виде пакета RPMs для SUSE/Novell Linux их можно найти на сайте http://www.linux-ha.org/ или загрузить архив с исходными кодами с этого же сайта и скомпилировать программу из них.
|Ширина=200px}}

''Heartbeat'' запущен, и мы можем проверить поведение системы в случае отказа. Я просто выдернул шнур электропитания из основного сервера и наблюдал за сообщениями в файле журнала запасного. По истечении заданного времени запасной сервер сообщил об отказе основного и запустил сервис '''tester'''. Вот соответствующие строки журнала:
<code>
heartbeat: [9615]: WARN: node primary.example.com: is dead
heartbeat: [9615]: WARN: No STONITH device configured.
heartbeat: [9615]: WARN: Shared disks are not protected.
heartbeat: [9615]: info: Resources being acquired from primary.example.
com.
heartbeat: [9615]: info: Link primary.example.com:/dev/ttyS0 dead.
heartbeat: [10305]: info: No local resources [/usr/share/heartbeat/
ResourceManager listkeys backup.example.com] to acquire.
harc[10304]: [10323]: info: Running /etc/ha.d/rc.d/status status
mach_down[10329]: [10350]: info: Taking over resource group tester
ResourceManager[10351]: [10362]: info: Acquiring resource group:
primary.example.com tester
logger: /etc/ha.d/resource.d/tester called with argument status
ResourceManager[10351]: [10379]: info: Running /etc/ha.d/resource.d/
tester start
logger: /etc/ha.d/resource.d/tester called with argument start
mach_down[10329]: [10384]: info: mach_down takeover complete for
node primary.example.com.
</code>

Первая проверка завершилась успешно, и пора поручить ''Heartbeat'' управление полноценным сервисом. Для этого проекта я выбрал httpd. Таким образом, сейчас нам нужно убедиться, что ''Apache'' установлен на обоих компьютерах, и положить в корневой каталог web-сервера какие-нибудь легко распознаваемые файлы. Я просто создал два файла '''/var/www/html/index.html''', по одному для основного и запасного серверов; в файле для основного сервера была строка “This is the website from the primary server”, для запасного – “This is the website from the backup server” («Это сайт с основного/запасного сервера»). На обоих компьютерах запустите ''httpd'':
<code>
/etc/init.d/httpd start
</code>
и проверьте, что, открыв в браузере адрес <nowiki>http://localhost</nowiki>, вы видите эти файлы. Теперь остановите ''Apache'' и убедитесь, что он не запустится автоматически при загрузке системы. Воспользуйтесь командами:
<code>
/etc/init.d/httpd stop
chkconfig httpd --del
</code>

Это важно, потому что ''Apache'' должен запуститься не во время загрузки, а только если ''Heartbeat'' запустил его.

Теперь нужно изменить файл ''haresources'' так:
<code>
primary.example.com httpd
primary.example.com 192.168.0.50
</code>

В первой строке указывается сервис, которым будет управлять ''Heartbeat'', а во второй – IP-адрес, используемый клиентом для доступа к сервису. При запуске ''Heartbeat'' этот адрес назначается на основной сервер как второй IP-адрес. Если основной сервер откажет, копия ''Heartbeat'', запущенная на запасном сервере, перенесет этот IP-адрес на свой сетевой интерфейс.

Предполагается, что ''Heartbeat'' будет управлять сервисами путем запуска скрипта, указанного в '''haresources''', с аргументами start, stop или status. Конечно, это те самые аргументы скриптов каталога '''/etc/init.d''', что используются для запуска сервисов во время загрузки системы, и, по правде говоря, ''Heartbeat'' будет автоматически искать скрипт '''httpd''' в каталоге '''/etc/init.d'''.

После внесения этих изменений в конфигурацию основного и запасного серверов можно снова запустить ''Heartbeat'' на каждом из них:
<code>
/etc/init.d/heartbeat start
</code>

Когда ''Heartbeat'' войдет в нормальный режим работы, нужно кое-что проверить. На основном сервере запустите:
<code>
ip addr show
</code>
и проверьте, что ''Heartbeat'' назначил второй IP-адрес (в нашем примере 192.168.0.50) на наш сетевой интерфейс. Также запустите команду
<code>
ps -ef | grep httpd
</code>
которая проверит, что сервис ''httpd'' запущен. На запасной сервер второй IP-адрес не назначается, а сервис ''httpd'' на нем не выполняется.

Теперь пора загрузить третий компьютер, чтобы использовать в качестве клиента. Убедитесь, что он может разрешить имя компьютера, на котором запущен сервис, по его IP-адресу. Для этого я просто добавил строку
<code>
192.168.0.50 www.example.com
</code>
в файл '''/etc/hosts'''. Проверьте, пингуется ли адрес <nowiki>www.example.com</nowiki> с компьютера клиента. Откройте в браузере на клиентском компьютере страницу <nowiki>http://www.example.com</nowiki>. Вы должны увидеть файл '''index.html''' основного сервера. На клиенте также можно проверить кэш '''arp''', запустив команду
<code>
arp -a
</code>
и обратить внимание на MAC-адрес, связанный с IP-адресом 192.168.0.50. В моем случае результат работы команды был таким:
<code>
www.example.com (192.168.0.50) at 00:0C:F1:96:A3:F7 [ether] on eth0
</code>

===Ладно, и как это работает?===

Мы подошли к драматической развязке: демонстрации переноса сервиса на запасной сервер в случае отказа основного. Можно было просто отключить питание основного сервера, как и в предыдущем эксперименте, но на сей раз я избрал более кроткий способ – просто остановил ''Heartbeat'' на основном сервере командой:
<code>
/etc/init.d/heartbeat stop
</code>

Остановившись, ''Heartbeat'' остановит ''httpd'' на основном сервере и проинформирует запасной сервер об отключении основного (через ''Heartbeat''-соединение). Запасной сервер сразу возьмет управление на себя, и в файле его журнала ('''/var/log/messages''') появятся новые сообщения. Два из них наиболее важны (время и другую информацию в начале строки я удалил):
<code>
Running /etc/init.d/httpd start
Registering new address record for 192.168.0.50 on eth0
</code>

В этом случае все заняло пару секунд. Если бы я просто выдернул из сети шнур питания основного сервера, то на восстановление системы потребовалось бы больше времени: в этом случае перед тем, как сделать вывод об отказе основного сервера и взять управление на себя, запасной сервер ожидал бы ответа 20 секунд (параметр deadtime в файле '''ha.cf''').

На клиентском компьютере следует провести пару важных тестов. Во-первых, попробуйте обновить страницу <nowiki>www.example.com</nowiki> в браузере. Должна появиться страница запасного сервера. Во-вторых, еще раз просмотрите содержимое ARP-кэша. На моем компьютере команда arp –a вернула следующий результат:
<code>
www.example.com (192.168.0.50) at 00:10:60:60:3E:8E [ether] on eth0
</code>

Это означает, что пакеты, предназначенные для адреса 192.168.0.50, теперь будут направляться на запасной сервер.

{{Врезка
|Заголовок=Дополнительная информация
|Содержание=Побольше узнать о ''heartbeat'' можно в документации '''/usr/share/doc/heartbeat''' (каталог зависит от конкретного дистрибутива), в частности, в файле '''GettingStarted'''. На сайте Linux HA также есть руководства и документация. Рекомендую вам прекрасную книжку “Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software” (No Starch Press, ISBN 1-59327-036-4).
|Ширина=200px}}

А что же дальше? Ну, наверное, со временем кто-то доберется до основного сервера, починит его и перезапустит. Когда ''Heartbeat'' перезапускается, он сообщает об этом запасному серверу через ''Heartbeat''-соединение. В журнале запасного сервера появятся такие строки:
<code>
Heartbeat restart on node primary.example.com
Releasing resource group: primary.example.com httpd
Running /etc/init.d/httpd stop
Withdrawing address record for 192.168.0.50 on eth0
</code>

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

Если у вас хватило духу дочитать до конца, поздравляю! Вы создали отказоустойчивый кластер в Linux и можете начать делать на этом деньги в реальном мире! Однако прежде чем пойти на собеседование в Google, NASA или даже Krazy Ken’s 24x7 Liquorice Emporium, быть может, вы захотите узнать о некоторых вопросах подробнее.

Один из них – это концепция «ограждения» (fencing). Когда запасной сервер перенимает ресурсы основного, нужно как-то гарантировать, чтобы основной сервер не попытался снова предоставить эти сервисы. ''Heartbeat'' может использовать для этого механизм STONITH (“shoot the other node in the head” – «контрольный выстрел в голову»), если вы купите устройство, программно отключающее питание компьютера. Второй вопрос – как синхронизировать содержимое двух web-серверов. В нашем примере мы умышленно сделали его разным, но на практике может потребоваться какое-то средство синхронизации их содержимого (''rsync'' или ''unison''). '''LXF'''

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

LXF100-101:Hardcore Linux

2009-03-06T23:06:29Z

Kipruss: новая статья

==Кластеры: Повышаем отказоустойчивость.==

Отказоустойчивость – то свойство, которое помогает кластеру пережить сбой электропитания и другие бедствия. '''Д-р Крис Браун''' покажет, как удержаться на плаву.

Журналы доступа к моей web-странице – не самое захватывающее чтиво. Если исключить случайные вторжения роботов поисковых систем, посетители заходят на сайт не чаще раза в неделю. Честно говоря, если сайт упадет, это заметят разве что через несколько месяцев. Даже грустно. Другая крайность – коммерческие web-сайты, приносящие владельцам ежедневный доход: несколько минут простоя такого сайта выливаются в ощутимые убытки для компании. На данном уроке я расскажу, как создать в Linux отказоустойчивый кластер. В случае краха основного сервера система автоматически переключается на запасной, а снаружи кластер выглядит как один очень надежный сервер. Нам поможет открытая программа ''Heartbeat'', найти которую можно на сайте www.linuxha.org. Кластер мы построим из двух компьютеров (основной и запасной сервер). ''Heartbeat'' будет отвечать за обнаружение отказа основного сервера и управлять запуском нужного нам сервиса на запасном. Мы воспользуемся сервисом ''Apache (httpd)'', но эта технология подойдет и для любого другого сервиса: FTP, DNS или почтового. В общем, все будет работать примерно так:

# В обычном режиме необходимые сервисы (типа ''httpd'') предоставляются основным сервером.
# Основной и запасной серверы постоянно обмениваются друг с другом сообщениями ''Heartbeat'' [англ. пульс], которые говорят запасному серверу, что с основным все в порядке.
# Если запасной сервер не получает сообщения, он перенимает ресурсы основного сервера (например, запускает собственную копию сервера ''httpd'').
# Запасной сервер перенимает IP-адрес, по которому предоставлялся сервис на основном сервере.

===Начинаем: компоненты системы===

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

На основном и запасном серверах должен быть установлен Linux, на клиенте – необязательно (хотя под Linux в вашем распоряжении окажутся лучшие средства диагностики). Компьютеры должны быть подключены к сети Ethernet. Для обмена сигналами ''Heartbeat'' на основном и запасном серверах должна быть вторая сетевая карта. Эти карты нужно соединить друг с другом либо перекрестным (crossover) кабелем, либо через мини-хаб. Если на обоих компьютерах есть последовательный порт, то вместо второго Ethernet-подключения можно соединить их последовательные порты перекрестным кабелем, по которому будет производиться обмен сигналами. Общая схема показана на [[:Изображение:Img_100_87_1.png|Рис. 1]].

===Установка heartbeat-соединения===

Если обмен сигналами ''Heartbeat'' будет осуществляться через Ethernet, соединить сетевые карты друг с другом можно двумя способами: либо через перекрестный кабель RJ45, либо парой обычных кабелей через мини-хаб. Первый вариант лучше, потому что здесь нечему выходить из строя. Каждой из карт нужно назначить статический IP-адрес, причем выбранный из частного диапазона, ни один адрес из которого не используется во внутренней сети. Например, первой карте можно назначить адрес 10.0.0.1, второй – 10.0.0.2. Убедитесь, что компьютеры могут достучаться друг до друга [ping].

Также можно использовать и соединение через последовательный порт. Тогда нам потребуется последовательный перекрестный кабель. На обоих концах этого кабеля, который еще называют нуль-модемным, имеется 9-контактный разъем типа «мама». Кабелем нужно соединить последовательные порты компьютеров. (Последовательные порты и кабели сейчас используются редко, и если на ваших компьютерах их нет, проще пойти и купить вторую сетевую карту для соединения по Ethernet.)

Чтобы проверить соединение через последовательные порты, выполните на основном сервере команду:
<code>
cat /dev/ttyS0
</code>
а на запасном – команду:
<code>
cat /etc/fstab > /dev/ttyS0
</code>

На основном сервере должно отображаться содержимое файла. Повторите эксперимент в обратном направлении.

''Heartbeat'' будет прекрасно работать с соединением любого типа. Преимущество Ethernet-соединения – трафик ''Heartbeat'' в этом случае можно отслеживать с помощью одной из утилит для отслеживания пакетов (например, wireshark). Можно даже использовать одновременно оба соединения, что позволит обойтись без ненужных откатов, если только одно из них выйдет из строя.

[[Изображение:Img_100_87_1.png|thumb|Рис. 1: Общая схема проекта; обратите внимание на IP-адреса.]]

===Настройка сетевых интерфейсов===

Оба сетевых интерфейса, которые участвуют в ''Heartbeat''-соединении, должны быть настроены на статические IP-адреса, так как DHCP-сервера в этой «сети» точно нет. Статические адреса должны быть и на основных интерфейсах, которые используются для подключения к основному и запасному серверам. Обратите внимание, что это НЕ те адреса, на которых предоставляется сервис. ''Heartbeat'' назначит сетевой карте исправного компьютера второй IP-адрес, и именно он будет использоваться клиентами для доступа к ресурсу.

===Три файла конфигурации===

Сразу после установки Heartbeat нужно создать в каталоге '''/etc/ha.d''' три (да, три!) файла конфигурации, а именно:

* '''ha.cf''' Файл содержит настройки самого ''Heartbeat''; в нем определяются используемые программой пути и устанавливаются некоторые временные параметры.
* '''haresources''' Этот файл определяет ресурсы (сервисы), которыми будет управлять Heartbeat, и основной сервер для каждого из этих ресурсов.
* '''authkey''' В этом файле задается пароль и метод шифрования, используемый для аутентификации Heartbeat-сообщений.

Начнем с '''ha.cf'''. Пример этого файла можно найти в документации на ''Heartbeat'' ('''/usr/share/doc/heartbeat/ha.cf'''). Это один из файлов типа «визгу много, проку мало», которые целиком состоят из документации и закомментированных примеров. Можно скопировать его в '''/etc/ha.d''' и использовать как отправную точку, или создать свой файл с нуля.

{{Врезка
|Заголовок=Ошибка!
|Содержание=В этой статье мы не говорим о том, как предотвратить неисправности других типов, например, те, что возникают в инфраструктуре самого интернета. В частности, мы не говорим о создании дополнительных информационных каналов для связи с сайтом. Впрочем, это не так уж и важно, потому что врожденная гибкость архитектуры интернета позволяет поглощать частные сбои. Часто даже говорят, что сеть ARPANET (предшественник интернета) разрабатывалась с таким расчетом, чтобы выдержать взрыв атомной бомбы. ARPANET и правда должна была справляться с утратой части сети, но главная причина была в том, что коммутация узлов сети и связей внутри нее была не особенно надежной, даже и без атомной бомбы.
|Ширина=200px}}

Вот минимальный вариант этого файла. Номера строк даны только для удобства ссылок, в самом файле их нет:
<code>
1. udpport 694
2. bcast eth1
3. serial /dev/ttyS0
4. baud 9600
5. keepalive 2
6. deadtime 20
7. initdead 60
8. node primary.example.com
9. node backup.example.com
</code>

Строки 1 и 2 задают номер порта и сетевой интерфейс, используемые для Heartbeat-соединения. Для соединения через последовательные порты в строках 3 и 3 задается порт и скорость соединения. Можно (и рекомендуется) использовать оба типа, но у меня было только соединение через последовательные порты, и я закомментировал строки 1 и 2. В строке 5 задается тайм-аут между сообщениями, а строка 6 определяет время, по истечении которого, не дождавшись очередного сообщения от основного сервера, запасной сочтет его покойником. В строке 7 указывается время, необходимое для активации сетевого интерфейса после включения компьютера, после чего ''Heartbeat'' начинает функционировать. В строках 9 и 9 задаются имена хостов для основного и запасного серверов (те, что возвращает команда uname -n).

Для начала попробуем управлять полностью фиктивным сервисом '''tester'''. Мы напишем скрипт, '''/etc/ha.d/resources.d/tester''', вызываемый ''Heartbeat''. Он будет всего лишь вызывать команду logger, которая сообщит нам (через ''syslogd''), что скрипт был запущен. Вот как он выглядит:
<code>
#!/bin/bash
logger $0 called with argument $1
</code>

Скрипт нужно сделать исполняемым, например, так:
<code>
chmod 755 tester
</code>

В следующем файле, ''haresources'', содержится список ресурсов, которыми управляет ''Heartbeat''. Когда компьютер выходит из строя, эти ресурсы перемещаются с одного узла сети на другой. (попробуйте произносить это как “ha-resources”, а не “hare-sauces” [англ. hare – заяц, source – источник, sauce – соус, – прим. ред.]. По правде говоря, я сроду не ел зайчатины, но первым делом подумал о кролике и решил, что подойдет клюквенный соус.) Опять же, пример этого файла можно найти в документации ('''/usr/share/doc/Heartbeat''') – можете просто скопировать его в '''/etc/ha.d''' или создать свой собственный файл с нуля. Для нашего первого теста в этом файле должна быть всего одна строка:
<code>
primary.example.com tester
</code>

Также нужно создать файл '''/etc/ha.d/authkeys''', содержащий ключи, используемые для аутентификации ''Heartbeat''-сообщений, например:
<code>
auth1
1 sha1 foobar
</code>

Нужно позаботиться, чтобы читать этот файл мог только администратор:
<code>
chmod 600 authkeys
</code>

Если права доступа к этому файлу есть у кого-то еще, ''Heartbeat'' не запустится.

Скопируйте эти четыре файла с основного сервера на запасной в соответствующие каталоги. Файл '''ha.cf''', возможно, придется подправить в зависимости от аппаратного обеспечения компьютера, а остальные файлы должны быть одинаковыми на обоих компьютерах.

Теперь можно запустить ''Heartbeat''. Для отслеживания сообщений ''Heartbeat'' на обоих компьютерах запустите tail -f для файла журнала ('''/var/log/messages'''). Запустите программу с помощью команды:
<code>
/etc/init.d/heartbeat start
</code>

{{Врезка
|Заголовок=Украденная личность
|Содержание=Перенос IP-адреса на другой компьютер – компьютерный эквивалент «воровства личности»: вы притворяетесь кем-то другим, а потом убеждаете весь мир, что вы настоящий. В процессе переноса системы на запасной сервер обязано произойти следующее. Во-первых, основной сервер должен отдать IP-адрес. Если он загорелся или нашел другую кончину, это произойдет по умолчанию, но если heartbeat останавливается на другом (исправном) сервере, адрес, очевидно, нужно забрать назад. Другая проблема – обновление записей в ARP-кэше. Доставка сетевого пакета на конкретный компьютер в конечном счете основана на его MAC-адресе – уникальном 48-битном номере, зашитом в каждую сетевую карту. Чтобы определить MAC-адрес компьютера по его IP-адресу, используется протокол ARP (Address Resolution Protocol – протокол разрешения адресов). Записи о соответствии IP-адресов и MAC-адресов обычно хранятся в кэше ARP 10–15 минут. Чтобы принудительно обновить ARP-кэш на других компьютерах, heartbeat рассылает в сеть так называемые «незаконные» [gratuitous] ARP-пакеты с компьютера, перенявшего IP-адрес.
|Ширина=200px}}

На обоих компьютерах действия ''Heartbeat'' будут писаться в журнал. На основном сервере среди прочего должно появиться сообщение типа:
<code>
logger: /etc/ha.d/resource.d/tester called with argument start
</code>

Оно означает, что основной сервер, как и ожидалось, запустил сервис '''tester'''.

{{Врезка
|Заголовок=Загружаем heartbeat
|Содержание=''Heartbeat'' нужно установить и на основном, и на запасном сервере. У меня на обоих компьютерах была установлена CentOS 5 (фактически, RHEL5). Я просто установил ''heartbeat'' вместе с зависимостями (которые включали ''heartbeat-pils'' и ''heartbeat-stonith'') из репозиториев CentOS с помощью ''yum''. Похожие пакеты есть и в репозиториях других дистрибутивов, таких как Ubuntu; в виде пакета RPMs для SUSE/Novell Linux их можно найти на сайте http://www.linux-ha.org/ или загрузить архив с исходными кодами с этого же сайта и скомпилировать программу из них.
|Ширина=200px}}

''Heartbeat'' запущен, и мы можем проверить поведение системы в случае отказа. Я просто выдернул шнур электропитания из основного сервера и наблюдал за сообщениями в файле журнала запасного. По истечении заданного времени запасной сервер сообщил об отказе основного и запустил сервис '''tester'''. Вот соответствующие строки журнала:
<code>
heartbeat: [9615]: WARN: node primary.example.com: is dead
heartbeat: [9615]: WARN: No STONITH device configured.
heartbeat: [9615]: WARN: Shared disks are not protected.
heartbeat: [9615]: info: Resources being acquired from primary.example.
com.
heartbeat: [9615]: info: Link primary.example.com:/dev/ttyS0 dead.
heartbeat: [10305]: info: No local resources [/usr/share/heartbeat/
ResourceManager listkeys backup.example.com] to acquire.
harc[10304]: [10323]: info: Running /etc/ha.d/rc.d/status status
mach_down[10329]: [10350]: info: Taking over resource group tester
ResourceManager[10351]: [10362]: info: Acquiring resource group:
primary.example.com tester
logger: /etc/ha.d/resource.d/tester called with argument status
ResourceManager[10351]: [10379]: info: Running /etc/ha.d/resource.d/
tester start
logger: /etc/ha.d/resource.d/tester called with argument start
mach_down[10329]: [10384]: info: mach_down takeover complete for
node primary.example.com.
</code>

Первая проверка завершилась успешно, и пора поручить ''Heartbeat'' управление полноценным сервисом. Для этого проекта я выбрал httpd. Таким образом, сейчас нам нужно убедиться, что ''Apache'' установлен на обоих компьютерах, и положить в корневой каталог web-сервера какие-нибудь легко распознаваемые файлы. Я просто создал два файла '''/var/www/html/index.html''', по одному для основного и запасного серверов; в файле для основного сервера была строка “This is the website from the primary server”, для запасного – “This is the website from the backup server” («Это сайт с основного/запасного сервера»). На обоих компьютерах запустите ''httpd'':
<code>
/etc/init.d/httpd start
</code>
и проверьте, что, открыв в браузере адрес <nowiki>http://localhost</nowiki>, вы видите эти файлы. Теперь остановите ''Apache'' и убедитесь, что он не запустится автоматически при загрузке системы. Воспользуйтесь командами:
<code>
/etc/init.d/httpd stop
chkconfig httpd --del
</code>

Это важно, потому что ''Apache'' должен запуститься не во время загрузки, а только если ''Heartbeat'' запустил его.

Теперь нужно изменить файл ''haresources'' так:
<code>
primary.example.com httpd
primary.example.com 192.168.0.50
</code>

В первой строке указывается сервис, которым будет управлять ''Heartbeat'', а во второй – IP-адрес, используемый клиентом для доступа к сервису. При запуске ''Heartbeat'' этот адрес назначается на основной сервер как второй IP-адрес. Если основной сервер откажет, копия ''Heartbeat'', запущенная на запасном сервере, перенесет этот IP-адрес на свой сетевой интерфейс.

Предполагается, что ''Heartbeat'' будет управлять сервисами путем запуска скрипта, указанного в '''haresources''', с аргументами start, stop или status. Конечно, это те самые аргументы скриптов каталога '''/etc/init.d''', что используются для запуска сервисов во время загрузки системы, и, по правде говоря, ''Heartbeat'' будет автоматически искать скрипт '''httpd''' в каталоге '''/etc/init.d'''.

После внесения этих изменений в конфигурацию основного и запасного серверов можно снова запустить ''Heartbeat'' на каждом из них:
<code>
/etc/init.d/heartbeat start
</code>

Когда ''Heartbeat'' войдет в нормальный режим работы, нужно кое-что проверить. На основном сервере запустите:
<code>
ip addr show
</code>
и проверьте, что ''Heartbeat'' назначил второй IP-адрес (в нашем примере 192.168.0.50) на наш сетевой интерфейс. Также запустите команду
<code>
ps -ef | grep httpd
</code>
которая проверит, что сервис ''httpd'' запущен. На запасной сервер второй IP-адрес не назначается, а сервис ''httpd'' на нем не выполняется.

Теперь пора загрузить третий компьютер, чтобы использовать в качестве клиента. Убедитесь, что он может разрешить имя компьютера, на котором запущен сервис, по его IP-адресу. Для этого я просто добавил строку
<code>
192.168.0.50 www.example.com
</code>
в файл '''/etc/hosts'''. Проверьте, пингуется ли адрес <nowiki>www.example.com</nowiki> с компьютера клиента. Откройте в браузере на клиентском компьютере страницу <nowiki>http://www.example.com</nowiki>. Вы должны увидеть файл '''index.html''' основного сервера. На клиенте также можно проверить кэш '''arp''', запустив команду
<code>
arp -a
</code>
и обратить внимание на MAC-адрес, связанный с IP-адресом 192.168.0.50. В моем случае результат работы команды был таким:
<code>
www.example.com (192.168.0.50) at 00:0C:F1:96:A3:F7 [ether] on eth0
</code>

===Ладно, и как это работает?===

Мы подошли к драматической развязке: демонстрации переноса сервиса на запасной сервер в случае отказа основного. Можно было просто отключить питание основного сервера, как и в предыдущем эксперименте, но на сей раз я избрал более кроткий способ – просто остановил ''Heartbeat'' на основном сервере командой:
<code>
/etc/init.d/heartbeat stop
</code>

Остановившись, ''Heartbeat'' остановит ''httpd'' на основном сервере и проинформирует запасной сервер об отключении основного (через ''Heartbeat''-соединение). Запасной сервер сразу возьмет управление на себя, и в файле его журнала ('''/var/log/messages''') появятся новые сообщения. Два из них наиболее важны (время и другую информацию в начале строки я удалил):
<code>
Running /etc/init.d/httpd start
Registering new address record for 192.168.0.50 on eth0
</code>

В этом случае все заняло пару секунд. Если бы я просто выдернул из сети шнур питания основного сервера, то на восстановление системы потребовалось бы больше времени: в этом случае перед тем, как сделать вывод об отказе основного сервера и взять управление на себя, запасной сервер ожидал бы ответа 20 секунд (параметр deadtime в файле '''ha.cf''').

На клиентском компьютере следует провести пару важных тестов. Во-первых, попробуйте обновить страницу <nowiki>www.example.com</nowiki> в браузере. Должна появиться страница запасного сервера. Во-вторых, еще раз просмотрите содержимое ARP-кэша. На моем компьютере команда arp –a вернула следующий результат:
<code>
www.example.com (192.168.0.50) at 00:10:60:60:3E:8E [ether] on eth0
</code>

Это означает, что пакеты, предназначенные для адреса 192.168.0.50, теперь будут направляться на запасной сервер.

А что же дальше? Ну, наверное, со временем кто-то доберется до основного сервера, починит его и перезапустит. Когда ''Heartbeat'' перезапускается, он сообщает об этом запасному серверу через ''Heartbeat''-соединение. В журнале запасного сервера появятся такие строки:
<code>
Heartbeat restart on node primary.example.com
Releasing resource group: primary.example.com httpd
Running /etc/init.d/httpd stop
Withdrawing address record for 192.168.0.50 on eth0
</code>

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

Если у вас хватило духу дочитать до конца, поздравляю! Вы создали отказоустойчивый кластер в Linux и можете начать делать на этом деньги в реальном мире! Однако прежде чем пойти на собеседование в Google, NASA или даже Krazy Ken’s 24x7 Liquorice Emporium, быть может, вы захотите узнать о некоторых вопросах подробнее.

Один из них – это концепция «ограждения» (fencing). Когда запасной сервер перенимает ресурсы основного, нужно как-то гарантировать, чтобы основной сервер не попытался снова предоставить эти сервисы. ''Heartbeat'' может использовать для этого механизм STONITH (“shoot the other node in the head” – «контрольный выстрел в голову»), если вы купите устройство, программно отключающее питание компьютера. Второй вопрос – как синхронизировать содержимое двух web-серверов. В нашем примере мы умышленно сделали его разным, но на практике может потребоваться какое-то средство синхронизации их содержимого (''rsync'' или ''unison''). '''LXF'''

{{Врезка
|Заголовок=Дополнительная информация
|Содержание=Побольше узнать о ''heartbeat'' можно в документации '''/usr/share/doc/heartbeat''' (каталог зависит от конкретного дистрибутива), в частности, в файле '''GettingStarted'''. На сайте Linux HA также есть руководства и документация. Рекомендую вам прекрасную книжку “Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software” (No Starch Press, ISBN 1-59327-036-4).
|Ширина=200px}}

[[Категория:Учебники]]
[[Категория:Hardcore Linux]]
[[Категория:Крис Браун]]

Файл:Img 100 87 1.png

2009-03-06T22:10:18Z

Kipruss: Рис. 1: Общая схема проекта; обратите внимание на IP-адреса.

Рис. 1: Общая схема проекта; обратите внимание на IP-адреса.

Обсуждение участника:Yaleks

2009-03-06T20:36:34Z

Kipruss: /* Присоединение к проекту */

Установил расширения Cite, ParserFunctions и SyntaxHighlight - проверяйте --17:21, 11 марта 2008 (MSK)

Вы вчера перенесли статью LXF97:TEX в LXF97:Препринт, но при этом некорректно изменили оглавление номера, оставив в нем ссылку на LXF97:TEX, но удалив при этом ссылку на следующую статью Андрея Боровского. Я ее найти в списке статей не могу. Верните ее пожалуйста на место. --[[Участник:Crazy Rebel|Crazy Rebel]] 08:07, 3 октября 2008 (MSD)
: Я просто очистил содержимое, сама статья была создана давно. Оглавление сейчас пофиксил. --[[Участник:Yaleks|Yaleks]] 15:07, 4 октября 2008 (MSD)

== Викификация LXF70-77 ==
До сих пор я занимался викификацией LXF c конца, а Вы с начала. Но теперь, когда остались не завершенными только самые начальные номера, причем в каждом из них уже сделана какая то часть работы, Валентин Синицин посоетовал обратиться непосредственно к Вам, чтобы разделить оставшиеся для викификации статьи. В принципе я могу пойти и другим путем - начиная викификацию 2008 года. Так что давайте решим как будет удобнее. --[[Участник:Crazy Rebel|Crazy Rebel]]

* Вот что осталось (если существующие оглавления полные):
<nowiki># <s>[[LXF74-75:Inkscape]] (13 ссылок)</s>
# <s>[[LXF71:GIMP]]</s> (7 ссылок)
# <s>[[LXF72:GIMP]]</s> (7 ссылок)
# <s>[[LXF73:GIMP]]</s> (7 ссылок)
# <s>[[LXF73:Сравнение: Электронные фотоальбомы]] (2 ссылки)</s>
# <s>[[LXF74-75:Технологии Linux-2006]] (2 ссылки)</s>
# <s>[[LXF71:VariCAD 2005]]</s>
# <s>[[LXF71:KOffice 1.4]]</s>
# <s>[[LXF71:SmoothWall Firewall 4]]</s>
# <s>[[LXF71:Amarok 1.3]]</s>
# <s>[[LXF71:Спецрепортаж]]</s>
# <s>[[LXF71:Настольный Linux]]</s>
# <s>[[LXF71:Гонка за лидером]]</s>
# <s>[[LXF71:Дневники Linux]]</s>
# <s>[[LXF71:Subversion]]</s>
# <s>[[LXF77:Realsoft 3D]]</s>
# <s>[[LXF72:Советы по ускорению]]</s>
# <s>[[LXF76:Азбука записи]]</s>
# <s>[[LXF73:Автомонтирование USB]]</s>
# <s>[[LXF73:Русификация Debian 3.1]]</s>
# <s>[[LXF72:Frequently Asked Questions]]</s>
# <s>[[LXF72:Краткая справка]]</s>
# <s>[[LXF71:Ответы]]</s>
# <s>[[LXF72:Ответы]]</s>
# <s>[[LXF73:Ответы]]</s>
# <s>[[LXF74-75:Ответы]]</s>
# <s>[[LXF77:Ответы]]</s>
# <s>[[LXF71:Первые шаги]]</s>
# <s>[[LXF72:Первые шаги Печать]]</s>
# <s>[[LXF74-75:Первые шаги]]</s>
# <s>[[LXF77:Сравнение]]</s>
# <s>[[LXF71:Сравнение]]</s>
# <s>[[LXF76:Сравнение]]</s>
# <s>[[LXF76:Что такое]] GPL V3</s>
# <s>[[LXF76:Интервью]] Джереми Элиссон</s>
# <s>[[LXF76:Трюки с железом]]</s>
# <s>[[LXF76:Интервью2]] Йон фон Течнер</s>
# <s>[[LXF76:Dynebolic]]</s>
# <s>[[LXF76:MythTV]]</s></nowiki>

Большое число из этого уже устарело и представляет лишь исторический интерес. Можно тут <s>отмечать</s> (<nowiki><s>...</s></nowiki>) перед викификаций, чтобы не было коллизий. --[[Участник:Yaleks|Yaleks]] 22:45, 3 февраля 2009 (MSK)

* Поздравляю! Позиции в списке закончились.
** Это да, но мне ещё спецрепортаж доделывать. --[[Участник:Yaleks|Yaleks]] 20:24, 5 марта 2009 (MSK)
*** Я так сильно подозреваю, что это не единственная проблема, хотя я старался и выверял все номера, но могли гдето и недоделки остаться и статьи спрятаться. Но в общем следует считать, что эта часть завершена. Тем более что спецрепортаж это большая но всего одна статья.--[[Участник:Crazy Rebel|Crazy Rebel]] 10:08, 6 марта 2009 (MSK)

== LXF72 Советы по ускорению ==

А зачем там было делать "LXF72..." загловком? Я тоже так вначале сделал, но мне крайне не понравилось, что советы нумеруются 1.1 ... 1.32 тогда как в моем варианта было 1, 2 .... Ну и еще почему заголовок статьи Вы выделяетя двумя знаками <nowiki>==</nowiki> ведь можно и одним, тогда каждый вопрос отделяется друг от друго горизонтальной линией.
:* <nowiki>==</nowiki> это заголовок 1-ого уровня вики-синтаксиса (= использовать некорректно). И где вы редактируете статьи, что там вставляется какой-то 2-х байтовый пробел? Через OCR что-ли пропускаете? --[[Участник:Yaleks|Yaleks]] 22:15, 26 февраля 2009 (MSK)
:::* Статьи я копирую из kpdf собственно сразу в окно Firefox, откуда там стали браться неразрывные пробелы я понятия не имею. Возможно такие pdf-ки потому что LXF99 я делал таким же способом но никаких неразрывных пробелов там нет. Или это так работает новый kpdf.
:::* Проблему решил так - сначала копирую текст в kate там удаляю всю гадость (заменой по тексту) и уже потом вставляю в окно Firefox.

== LXF100 ... ==

В общем то викификация LXF70-99 подходит к концу и Синицын уже спрашивал меня о продолжении работы. Я согласен и как я понимаю Вы тоже. Но у Вас несколько другой подход - викифицировать не номерами, а темами. В приципе я вижу и преимущества и недостатки такого подхода. Ну из перимуществ это то, что пользователь получает информацию которая должна быть для него наиболее интересна, а из недостатков- отдельный номер может быть так до конца и не закончен. Будет осутствовать общий стиль оформлния. В общем я готов на любой подход к викификации. Если мы будем пользоваться Вашим методом то предлагаю делать так чтобы не пересекаться - Заранее оглавления не делаем, кто создает статью, тот ее и викифицирует.
: Если вы посмотрите на статистику хотя-бы нескольких ресурсов, то поймёте, что удержать и заставить посмотреть хотя-бы 3 страницы очень сложно. Потому иметь законченные и связанные кластеры статей лучше, чем несвязанную подборку из одного номера. Очень мало людей приходят введя адрес первой страницы и читают по-порядку, в основном по ссылкам с других сайтов или поисковых систем. --[[Участник:Yaleks|Yaleks]] 15:24, 1 марта 2009 (MSK)
:: И всеже я предлагаю сначала закончить LXF71 и только после этого приступать к 100 и далее, а то Синицын мне как то писал что руководство недовольно, что викификация этих номеров не закончена. А в остальном полностью согласен. Предлагаю значит сделать как раз так - кто начал викификацию тот ее и заканчивает. Чтобы нам тут оглавление не составлять.

== Присоединение к проекту ==

Обращаюсь к Yaleks'у, как к координатору: я готов в меру сил помочь в викификации того, что наиболее нужно в настоящее время. Номера 100-106 имеются, скачал по ссылке, которую дал Валентин. Мой почтовый адрес: kipruss_A_mail.ru. После прочтения, думаю, этот раздел можно удалить. :)

* Ну так выбирайте статью, вроде как решили с учебников начать, а то и цикл, вписывайте на соответствующей странице(цах) его название и вперед. Валентин сказал что за оформлением оглавления журанлов он сам проследит, но всетаки постарайтесь как в журнале делать название статьи и аннотацию.--[[Участник:Crazy Rebel|Crazy Rebel]] 10:10, 6 марта 2009 (MSK)
** Раз с учебников, то беру цикл "Hardcore Linux". Потом - Django, но этот цикл начинается с мая, по-моему - наверное лучше сделать те, которые продолжаются с прошлого года.--[[Участник:Kipruss|Kipruss]] 23:36, 6 марта 2009 (MSK)
* Смотрите на оформление существующих статей и делайте по аналогии (также см. [[Информация для авторов]]). Crazy Rebel, осталось расхождение с наименование картинок, я всё-таки предлагаю, чтобы в названии был номер журнала и страницы (возможно выбранный в начале Img не очень логично и лучше перейти к LXF10X_YY_Z.{jpg/png}). --[[Участник:Yaleks|Yaleks]] 11:57, 6 марта 2009 (MSK)
** Хорошо. Со следующей статьи начну именовать так. Не думаю что надо что либо переделывать в уже викифицицированных журналах если только качество старых картинок не нравится.--[[Участник:Crazy Rebel|Crazy Rebel]] 16:35, 6 марта 2009 (MSK)

Обсуждение участника:Yaleks

2009-03-05T22:39:01Z

Kipruss: /* LXF100 ... */

Установил расширения Cite, ParserFunctions и SyntaxHighlight - проверяйте --17:21, 11 марта 2008 (MSK)

Вы вчера перенесли статью LXF97:TEX в LXF97:Препринт, но при этом некорректно изменили оглавление номера, оставив в нем ссылку на LXF97:TEX, но удалив при этом ссылку на следующую статью Андрея Боровского. Я ее найти в списке статей не могу. Верните ее пожалуйста на место. --[[Участник:Crazy Rebel|Crazy Rebel]] 08:07, 3 октября 2008 (MSD)
: Я просто очистил содержимое, сама статья была создана давно. Оглавление сейчас пофиксил. --[[Участник:Yaleks|Yaleks]] 15:07, 4 октября 2008 (MSD)

== Викификация LXF70-77 ==
До сих пор я занимался викификацией LXF c конца, а Вы с начала. Но теперь, когда остались не завершенными только самые начальные номера, причем в каждом из них уже сделана какая то часть работы, Валентин Синицин посоетовал обратиться непосредственно к Вам, чтобы разделить оставшиеся для викификации статьи. В принципе я могу пойти и другим путем - начиная викификацию 2008 года. Так что давайте решим как будет удобнее. --[[Участник:Crazy Rebel|Crazy Rebel]]

* Вот что осталось (если существующие оглавления полные):
# <s>[[LXF74-75:Inkscape]] (13 ссылок)</s>
# <s>[[LXF71:GIMP]]</s> (7 ссылок)
# <s>[[LXF72:GIMP]]</s> (7 ссылок)
# <s>[[LXF73:GIMP]]</s> (7 ссылок)
# <s>[[LXF73:Сравнение: Электронные фотоальбомы]] (2 ссылки)</s>
# <s>[[LXF74-75:Технологии Linux-2006]] (2 ссылки)</s>
# <s>[[LXF71:VariCAD 2005]]</s>
# <s>[[LXF71:KOffice 1.4]]</s>
# <s>[[LXF71:SmoothWall Firewall 4]]</s>
# <s>[[LXF71:Amarok 1.3]]</s>
# <s>[[LXF71:Спецрепортаж]]</s>
# <s>[[LXF71:Настольный Linux]]</s>
# <s>[[LXF71:Гонка за лидером]]</s>
# <s>[[LXF71:Дневники Linux]]</s>
# <s>[[LXF71:Subversion]]</s>
# <s>[[LXF77:Realsoft 3D]]</s>
# <s>[[LXF72:Советы по ускорению]]</s>
# <s>[[LXF76:Азбука записи]]</s>
# <s>[[LXF73:Автомонтирование USB]]</s>
# <s>[[LXF73:Русификация Debian 3.1]]</s>
# <s>[[LXF72:Frequently Asked Questions]]</s>
# <s>[[LXF72:Краткая справка]]</s>
# <s>[[LXF71:Ответы]]</s>
# <s>[[LXF72:Ответы]]</s>
# <s>[[LXF73:Ответы]]</s>
# <s>[[LXF74-75:Ответы]]</s>
# <s>[[LXF77:Ответы]]</s>
# <s>[[LXF71:Первые шаги]]</s>
# <s>[[LXF72:Первые шаги Печать]]</s>
# <s>[[LXF74-75:Первые шаги]]</s>
# <s>[[LXF77:Сравнение]]</s>
# <s>[[LXF71:Сравнение]]</s>
# <s>[[LXF76:Сравнение]]</s>
# <s>[[LXF76:Что такое]] GPL V3</s>
# <s>[[LXF76:Интервью]] Джереми Элиссон</s>
# <s>[[LXF76:Трюки с железом]]</s>
# <s>[[LXF76:Интервью2]] Йон фон Течнер</s>
# <s>[[LXF76:Dynebolic]]</s>
# <s>[[LXF76:MythTV]]</s>

Большое число из этого уже устарело и представляет лишь исторический интерес. Можно тут <s>отмечать</s> (<nowiki><s>...</s></nowiki>) перед викификаций, чтобы не было коллизий. --[[Участник:Yaleks|Yaleks]] 22:45, 3 февраля 2009 (MSK)

* Поздравляю! Позиции в списке закончились.
** Это да, но мне ещё спецрепортаж доделывать. --[[Участник:Yaleks|Yaleks]] 20:24, 5 марта 2009 (MSK)

== LXF72 Советы по ускорению ==

А зачем там было делать "LXF72..." загловком? Я тоже так вначале сделал, но мне крайне не понравилось, что советы нумеруются 1.1 ... 1.32 тогда как в моем варианта было 1, 2 .... Ну и еще почему заголовок статьи Вы выделяетя двумя знаками <nowiki>==</nowiki> ведь можно и одним, тогда каждый вопрос отделяется друг от друго горизонтальной линией.
:* <nowiki>==</nowiki> это заголовок 1-ого уровня вики-синтаксиса (= использовать некорректно). И где вы редактируете статьи, что там вставляется какой-то 2-х байтовый пробел? Через OCR что-ли пропускаете? --[[Участник:Yaleks|Yaleks]] 22:15, 26 февраля 2009 (MSK)
:::* Статьи я копирую из kpdf собственно сразу в окно Firefox, откуда там стали браться неразрывные пробелы я понятия не имею. Возможно такие pdf-ки потому что LXF99 я делал таким же способом но никаких неразрывных пробелов там нет. Или это так работает новый kpdf.
:::* Проблему решил так - сначала копирую текст в kate там удаляю всю гадость (заменой по тексту) и уже потом вставляю в окно Firefox.

== LXF100 ... ==

В общем то викификация LXF70-99 подходит к концу и Синицын уже спрашивал меня о продолжении работы. Я согласен и как я понимаю Вы тоже. Но у Вас несколько другой подход - викифицировать не номерами, а темами. В приципе я вижу и преимущества и недостатки такого подхода. Ну из перимуществ это то, что пользователь получает информацию которая должна быть для него наиболее интересна, а из недостатков- отдельный номер может быть так до конца и не закончен. Будет осутствовать общий стиль оформлния. В общем я готов на любой подход к викификации. Если мы будем пользоваться Вашим методом то предлагаю делать так чтобы не пересекаться - Заранее оглавления не делаем, кто создает статью, тот ее и викифицирует.
: Если вы посмотрите на статистику хотя-бы нескольких ресурсов, то поймёте, что удержать и заставить посмотреть хотя-бы 3 страницы очень сложно. Потому иметь законченные и связанные кластеры статей лучше, чем несвязанную подборку из одного номера. Очень мало людей приходят введя адрес первой страницы и читают по-порядку, в основном по ссылкам с других сайтов или поисковых систем. --[[Участник:Yaleks|Yaleks]] 15:24, 1 марта 2009 (MSK)
:: И всеже я предлагаю сначала закончить LXF71 и только после этого приступать к 100 и далее, а то Синицын мне как то писал что руководство недовольно, что викификация этих номеров не закончена. А в остальном полностью согласен. Предлагаю значит сделать как раз так - кто начал викификацию тот ее и заканчивает. Чтобы нам тут оглавление не составлять.

== Присоединение к проекту ==

Обращаюсь к Yaleks'у, как к координатору: я готов в меру сил помочь в викификации того, что наиболее нужно в настоящее время. Номера 100-106 имеются, скачал по ссылке, которую дал Валентин. Мой почтовый адрес: kipruss@mail.ru. После прочтения, думаю, этот раздел можно удалить. :)

Обсуждение:LXF94:OpenVPN

2008-03-17T09:10:24Z

Kipruss: Новая: Lodger, а зачем ты убрал примеры конфигурационных файлов? Они вроде места много не занимают, а без них кар...

Lodger, а зачем ты убрал примеры конфигурационных файлов? Они вроде места много не занимают, а без них картина неполная.

Обсуждение участника:Kipruss

2008-03-16T20:02:50Z

Kipruss:

Kipruss, спасибо конечно за помощь.. но я сам переведу свой номер в вики ;)

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

LXF94:OpenVPN

2008-03-15T22:04:29Z

Kipruss: /* Шаг 2: Создаем ключи */

== OpenVPN за 10 минут ==

''Технология VPN во многом напоминает перевозку денег в бронированной инкассаторской машине
по улицам многолюдного города. Но какую модель следует выбрать, чтобы ваши ценности не
достались злоумышленникам? Спросите у '''Валентина Яценко'''.''

VPN – Virtual Private Network, Виртуальная Частная Сеть – технология, позволяющая соединять между собой локальные сети и отдельные компьютеры, находящиеся на расстоянии тысяч километров друг от друга; подключаться к локальной сети через Интернет, используя шифрованный канал связи, организовывать безопасный туннель для передачи важных данных... Возможности применения VPN безграничны! Вам необходимо соединить офисы в разных концах страны единой сетью, не прокладывая километры кабелей? Вы хотите подключаться к домашней локальной сети из Интернет-кафе? Требуется передать важные данные на большое расстояние без риска утечки информации? Может быть, большинство данных, которые вы передаете через Интернет, составляют тайну, и их необходимо обезопасить? Если вы хотя бы на один вопрос ответили утвердительно, VPN – это именно то, что вам нужно!

=== Шаг 1: Устанавливаем ===

Пакеты с ''OpenVPN'' доступны для большинства распространенных дистрибутивов, в том числе для RedHat/Fedora, Mandriva, OpenSUSE, Slackware, Debian и Ubuntu. Если ''OpenVPN'' не включен в ваш любимый дистрибутив, попробуйте поискать пакет на [http://rpmfind.net rpmfind.net] (для систем, использующих RPM) или [http://linuxpackages.net linuxpackages.net] (Slackware и производные) Наконец, программу можно загрузить в исходных текстах с официального сайта ([http://openvpn.net openvpn.net]).

Для установки ''OpenVPN'' также необходимо установить ''OpenSSL'' (openssl.org) и ''liblzo'' (http://www.oberhumer.com/opensource/lzo), которые есть во многих дистрибутивах. Для работы ''OpenVPN'' нужен модуль ядра ''tun''. Он присутствует в большинстве систем, но если команда modrpobe tun завершается с ошибкой «Can’t locale module tun», вам придется пересобрать ядро – о том, как это сделать, подробно рассказано в [[LXF89]]. Необходимо включить опцию CONFIG_TUN (Device Drivers –> Network device support –> Universal TUN/TAP device driver support).

Если вы собираетесь использовать ''OpenVPN'' постоянно, пропишите модуль ''tun'' в '''/etc/modules''' для автоматической инициализации при загрузке либо включите его непосредственно в ядро. В противном случае перед запуском ''OpenVPN'' вам нужно будет загружать модуль ''tun'' самостоятельно (командой modrpobe tun). Если вы планируете предоставлять клиентам доступ в Интернет через ''VPN'', необходимо настроить NAT (Network Address Translation). Скорее всего, это уже сделано за вас разработчиками дистрибутива, но на случай возникновения проблем имейте в виду, что нам потребуется опция CONFIG_IP_NF_TARGET_MASQUERADE (Networking –> Networking options –> Network packet filtering –> IP tables support –> Full NAT). Для работы с NAT используется утилита ''iptables'' (см. [[LXF87/88]]), которая, скорее всего, уже установлена в вашей системе. Проверьте это и, в случае необходимости, добавьте ее через менеджер пакетов вашего дистрибутива.

===Шаг 2: Создаем ключи===

Итак, ''OpenVPN'' установлен. Что дальше? В первую очередь необходимо создать ключи и сертификаты для сервера и клиентов. Скрипты, облегчающие эту задачу, находятся в каталоге '''easy-rsa''' (''см. врезку «Где же easy-rsa?» внизу'').

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

* '''KEY_COUNTRY''' – равным двухсимвольному коду вашей страны (для России это RU).
* '''KEY_PROVINCE''' – названию вашего региона (например, Moscow region или MSK).
* '''KEY_CITY''', соответственно – ваш город (скажем, Moscow).
* '''KEY_ORG''' – организация (OpenVPN Solutions подойдет).
* '''KEY_EMAIL''' – ваш e-mail адрес (me@my.e-ma.il).

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

Также можно изменить параметр KEY_SIZE, отвечающий за размер ключей (максимальный размер ключа, поддерживаемый ''OpenVPN'' – 2048 бит).

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

. ./vars

и, на всякий случай, удалить существующие ключи командой

./clean-all

После этого следует сгенерировать корневой сертификат (см. [[LXF93]]):

./build-ca

В процессе выполнения последнего скрипта вам будет задано несколько вопросов. Нужно ввести только Common Name для сертификата (например, RootCA), все остальные параметры уже заданы в качестве переменных окружения скриптом vars.

После создания корневого сертификата необходимо сгенерировать для сервера секретный ключ. В этом вам поможет скрипт ''build-key-server''. Как и в предыдущем случае, для большинства вопросов можно оставить ответы по умолчанию. На вопрос о Common Name введите “server”, на два последних вопроса (подписать ли сертификат и – каламбур, но перевод именно такой – сертифицировать ли его) ответьте утвердительно; когда вас спросят о пароле (“A challenge password”) – введите пароль для ключа сервера (запоминать его не нужно). Наберите

./build-key-server server

Далее, создайте ключи для необходимого количества клиентов. Эта процедура аналогична созданию ключа для сервера, за исключением того, что для клиентов ключи создаются скриптом build-key, а не build-key-server. У каждого ключа, конечно же, должно быть указано свое значение в поле Common Name:

./build-key clientname

Если вы хотите защитить паролем ключи клиентов, воспользуйтесь вместо ''build-key'' скриптом ''build-key-pass''. И наконец, в довершение ко всем сертификатам и ключам необходимо создать файл параметров Диффи (Diffie) и Хеллмэна (Hellman). Алгоритм Диффи и Хеллмэна позволяет обмениваться секретными ключами по небезопасным каналам. Для их генерации запустите скрипт
''build-dh'' без параметров:

./build-dh

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

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

* '''ca.crt''' (Root CA certificate) необходим серверу и всем клиентам, он не является секретным.
* '''clientname.crt''' (сертификат клиента clientname) необходим только клиенту clientname, он не является секретным.
* '''clientname.key''' (ключ клиента clientname) необходим только клиенту clientname, это секретный ключ.

Эти файлы можно найти в подкаталоге '''keys''' каталога '''easy-rsa'''.

===Шаг 3: Настраиваем===

Итак, у нас есть все необходимые для работы ''OpenVPN'' файлы – все, кроме конфигурационных, созданием которых мы и займемся. Начнем с сервера. Для создания новых конфигурационных файлов удобно использовать примеры из поставки ''OpenVPN'', они находятся в подкаталоге '''sample-config-files''' каталога ''OpenVPN'' ('''../sample-config-files''', если вы находитесь в каталоге '''easy-rsa'''). В принципе, можно использовать стандартный конфигурационный файл для сервера, изменив некоторые параметры. Вот список этих параметров (некоторые из них, например, port и protocol, изменять не обязательно):

* '''ca''' – полный путь до корневого сертификата, который мы создали скриптом ''build-ca''.
* '''cert''' – полный путь до сертификата сервера, который мы создали его скриптом ''build-key-server''.
* '''key''' – путь до ключа сервера, созданного все тем же скриптом ''build-key-server''.
* '''dh''' – путь до файла параметров Диффи и Хеллмэна, созданного скриптом ''build-dh''.
* '''server''' – режим запуска ''OpenVPN''. В строке с режимом запуска для сервера должна быть указана подсеть и маска подсети (пример – server 10.8.0.0 255.255.255.0). Подсеть, указанная по умолчанию – 10.8.0.0/24. Если в вашей сети она уже используется, задайте другую локальную подсеть.
* '''port''' – порт, на котором будет запущен сервер. Стандартный порт ''OpenVPN'' – 1194, но вы можете изменить его по своему желанию.
* '''protocol''' – протокол. По умолчанию ''OpenVPN'' использует экономичный UDP, но вы можете предпочесть надежный TCP.

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

Для создания конфигурационного файла клиента также можно использовать пример, идущий в поставке с ''OpenVPN''. В нем надо изменить пути к необходимым файлам на свои, указать адрес и порт сервера в директиве remote и, кроме того, удостоверится, что выбранные настройки совпадают с настройками сервера (протокол, сжатие и т.п.). Пример конфигурационного файла клиента можно также взять с диска LXF. Тех же, кто хочет предоставлять ''VPN''-клиентам доступ в Интернет, ждет еще один шаг: включение NAT (Network Address Translation, Трансляция сетевых адресов) и настройка маршрутизации. Для начала необходимо написать соответствующее правило ''IPTables'':

iptables -t nat -A POSTROUTING -s маска_подсети -o внешний_интерфейс -j MASQUERADE

например:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ppp0 -j MASQUERADE

Его необходимо сохранить, добавив в файл с правилами iptables или в скрипты загрузки. Затем необходимо включить маршрутизацию, записав в '''/etc/sysctl.conf''' строку “net.ipv4.ip_forward = 1” и выполнив команду

sysctl -w net.ipv4.ip_forward=1

===Шаг 4: Проверка связи===

Если вы дошли до этого места, спешу вас обрадовать – остался всего
один, очень простой шаг. Надо запустить ''OpenVPN'' на сервере, а потом
и на всех клиентах. Для сервера: перейдите в каталог с ключами (keys)
и выполните:

openvpn --config ../sample-config-files/server.conf

После чего вы должны увидеть подобные строки:

Thu Aug 31 12:04:20 2006 OpenVPN 2.0.7 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Jul 22 2006
Thu Aug 31 12:04:20 2006 Diffie-Hellman initialized with 1024 bit key
Thu Aug 31 12:04:20 2006 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Aug 31 12:04:20 2006 TUN/TAP device tun0 opened <Skipped>
Thu Aug 31 12:04:20 2006 Initialization Sequence Completed

На клиенте (клиентах) выполните команду

openvpn --config client.conf

после чего проверьте наличие tun-интерфейса командой ifconfig:

ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00:00:00:00:00:00
inet addr:85.140.161.153 P-t-P:10.8.0.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Обратите внимание на статус (UP): он означает, что интерфейс находится в активном состоянии. Если в вашей системе имеется более одного tun-интерфейса (это можно проверить командой ifconfig без параметров), замените tun0 на tun1, tun2 и т.п.

Если интерфейс сконфигурирован правильно, проверьте доступность других хостов. Когда путь к файлу соответствий «клиент-IP» (опция ifconfig-pool-persist в конфигурационном файле сервера) не указан, их адреса назначаются сервером ''OpenVPN'' случайным образом. Наберите:

ping 10.8.0.2

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

Приходящие ответы свидетельствуют о том, что ''VPN''-соединение установлено и работает.

===Примечание 1. Врезки===

'''Почему OpenVPN?'''

Существует множество реализаций VPN, самые популярные из них – PPTP, ''FreeS/WAN'' и ''OpenVPN''. Почему же в этой статье мы рассмотрим именно последний вариант? PPTP навевает мысли о Microsoft, ''FreeS/WAN'' давно не обновлялся – на его официальном сайте сказано, что последняя версия датируется 22 апреля 2004 года, более того, дальнейших обновлений ''FreeS/WAN'' не будет, а это, согласитесь, недопустимо для проекта, одной из целей которого является обеспечение безопасности... ''OpenVPN'' же активно развивается и регулярно обновляется, использует стойкие криптографические алгоритмы и предлагает множество способов идентификации, в том числе комбинированных, что немаловажно для безопасности. Кроме того, ''OpenVPN'' работает на большинстве распространенных платформ – Linux, Windows 2000/XP, OpenBSD, FreeBSD, NetBSD, Mac OS X, Solaris, благодаря чему его можно использовать в гетерогенных сетях. Все это, безусловно, делает ''OpenVPN'' лучшим выбором для организации VPN.

'''Где искать easy-rsa?'''

Каталог '''easy-rsa''' может находиться в '''/usr/share/doc/openvpn-2.0''', '''/usr/share/doc/openvpn''', '''/usr/share/doc/openvpn/examples''', '''/usr/share/openvpn''' или в '''/usr/share/doc/packages/openvpn''' – в зависимости от дистрибутива. Его также можно найти в архиве с исходными текстами.

===Примечание 2. Примеры конфигурационных файлов (с диска)===

'''server.conf'''

# Конфигурационный файл сервера OpenVPN (Linux-версия)
# Порт
port 1194
# Протокол
proto udp
# Использовать tun (tunneling) вместо tap (ethernet bridging)
dev tun
# Полные пути к необходимым файлам (измените на свои пути)
ca /usr/local/etc/openvpn/easy-rsa/keys/ca.crt
cert /usr/local/etc/openvpn/easy-rsa/keys/server.crt
key /usr/local/etc/openvpn/easy-rsa/keys/server.key
# Путь к dh (измените на свой)
dh dh1024.pem
# Режим сервера,подсеть 10.8.0.0/24
server 10.8.0.0 255.255.255.0
# Файл соответствий клиент - виртуальный IP (по-умолчанию выдаётся динамический IP)
ifconfig-pool-persist ipp.txt
# Раскомментируйте если хотите, чтобы клиенты "видели" друг друга
;client-to-client
# Отключать после ... секунд без обмена данными (второй параметр)
keepalive 10 120
# Включить сжатие
comp-lzo
# Максимум клиентов одновременно - раскомментируйте если вам нужно ограничение по числу клиентов
;max-clients 100
# Снижение привилегий до указанных (в целях безопасности) (раскомментируйте если необходимо, в этом случае OpenVPN надо запускать с правами root)
;user nobody
;group nogroup

'''client.conf'''

# Конфигурационный файл клиента OpenVPN (Linux-версия)
client
# Использовать tun (tunneling) вместо tap (ethernet bridging)
dev tun
# Протокол
proto udp
# Адрес и порт сервера
remote 192.168.0.1 1194
# Если не получается установить соответствие между именем и адресом сервера - продолжать попытки
resolv-retry infinite
# Для клиента не нужно слушать порты
nobind
# Снижение привилегий до указанных (в целях безопасности) (раскомментируйте если необходимо, в этом случае OpenVPN надо запускать с правами root)
;user nobody
;group nogroup
# Сохранять определённые параметры
persist-key
persist-tun
# Полные пути к необходимым файлам (измените на свои пути)
ca /home/qweo/tmp/article/keys/ca.crt
cert /home/qweo/tmp/article/keys/clientname.crt
key /home/qweo/tmp/article/keys/clientname.key
# Включить сжатие (не включайте сжатие если на сервере оно отключено)
comp-lzo
# Уровень журналирования
verb 3

--[[Участник:Kipruss|Kipruss]] 00:35, 16 марта 2008 (MSK)

LXF87/88

2008-03-15T21:45:25Z

Kipruss: Внес из-за отсутствия в содержании. Пока пустой

==LXF87/88==

LXF94:OpenVPN

2008-03-15T21:44:06Z

Kipruss: /* OpenVPN за 10 минут */

== OpenVPN за 10 минут ==

''Технология VPN во многом напоминает перевозку денег в бронированной инкассаторской машине
по улицам многолюдного города. Но какую модель следует выбрать, чтобы ваши ценности не
достались злоумышленникам? Спросите у '''Валентина Яценко'''.''

VPN – Virtual Private Network, Виртуальная Частная Сеть – технология, позволяющая соединять между собой локальные сети и отдельные компьютеры, находящиеся на расстоянии тысяч километров друг от друга; подключаться к локальной сети через Интернет, используя шифрованный канал связи, организовывать безопасный туннель для передачи важных данных... Возможности применения VPN безграничны! Вам необходимо соединить офисы в разных концах страны единой сетью, не прокладывая километры кабелей? Вы хотите подключаться к домашней локальной сети из Интернет-кафе? Требуется передать важные данные на большое расстояние без риска утечки информации? Может быть, большинство данных, которые вы передаете через Интернет, составляют тайну, и их необходимо обезопасить? Если вы хотя бы на один вопрос ответили утвердительно, VPN – это именно то, что вам нужно!

=== Шаг 1: Устанавливаем ===

Пакеты с ''OpenVPN'' доступны для большинства распространенных дистрибутивов, в том числе для RedHat/Fedora, Mandriva, OpenSUSE, Slackware, Debian и Ubuntu. Если ''OpenVPN'' не включен в ваш любимый дистрибутив, попробуйте поискать пакет на [http://rpmfind.net rpmfind.net] (для систем, использующих RPM) или [http://linuxpackages.net linuxpackages.net] (Slackware и производные) Наконец, программу можно загрузить в исходных текстах с официального сайта ([http://openvpn.net openvpn.net]).

Для установки ''OpenVPN'' также необходимо установить ''OpenSSL'' (openssl.org) и ''liblzo'' (http://www.oberhumer.com/opensource/lzo), которые есть во многих дистрибутивах. Для работы ''OpenVPN'' нужен модуль ядра ''tun''. Он присутствует в большинстве систем, но если команда modrpobe tun завершается с ошибкой «Can’t locale module tun», вам придется пересобрать ядро – о том, как это сделать, подробно рассказано в [[LXF89]]. Необходимо включить опцию CONFIG_TUN (Device Drivers –> Network device support –> Universal TUN/TAP device driver support).

Если вы собираетесь использовать ''OpenVPN'' постоянно, пропишите модуль ''tun'' в '''/etc/modules''' для автоматической инициализации при загрузке либо включите его непосредственно в ядро. В противном случае перед запуском ''OpenVPN'' вам нужно будет загружать модуль ''tun'' самостоятельно (командой modrpobe tun). Если вы планируете предоставлять клиентам доступ в Интернет через ''VPN'', необходимо настроить NAT (Network Address Translation). Скорее всего, это уже сделано за вас разработчиками дистрибутива, но на случай возникновения проблем имейте в виду, что нам потребуется опция CONFIG_IP_NF_TARGET_MASQUERADE (Networking –> Networking options –> Network packet filtering –> IP tables support –> Full NAT). Для работы с NAT используется утилита ''iptables'' (см. [[LXF87/88]]), которая, скорее всего, уже установлена в вашей системе. Проверьте это и, в случае необходимости, добавьте ее через менеджер пакетов вашего дистрибутива.

===Шаг 2: Создаем ключи===

Итак, ''OpenVPN'' установлен. Что дальше? В первую очередь необходимо создать ключи и сертификаты для сервера и клиентов. Скрипты, облегчающие эту задачу, находятся в каталоге '''easy-rsa''' (''см. врезку «Где же easy-rsa?» внизу'').

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

* '''KEY_COUNTRY''' – равным двухсимвольному коду вашей страны (для России это RU).
* '''KEY_PROVINCE''' – названию вашего региона (например, Moscow region или MSK).
* '''KEY_CITY''', соответственно – ваш город (скажем, Moscow).
* '''KEY_ORG''' – организация (OpenVPN Solutions подойдет).
* '''KEY_EMAIL''' – ваш e-mail адрес (me@my.e-ma.il).

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

Также можно изменить параметр KEY_SIZE, отвечающий за размер ключей (максимальный размер ключа, поддерживаемый ''OpenVPN'' – 2048 бит).

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

. ./vars

и, на всякий случай, удалить существующие ключи командой

./clean-all

После этого следует сгенерировать корневой сертификат (см. [[LXF93]]):

./build-ca

В процессе выполнения последнего скрипта вам будет задано несколько вопросов. Нужно ввести только Common Name для сертификата (например, RootCA), все остальные параметры уже заданы в качестве переменных окружения скриптом vars.

После создания корневого сертификата необходимо сгенерировать для сервера секретный ключ. В этом вам поможет скрипт ''build-key-server''. Как и в предыдущем случае, для большинства вопросов
можно оставить ответы по умолчанию. На вопрос о Common Name введите “server”, на два последних вопроса (подписать ли сертификат и – каламбур, но перевод именно такой – сертифицировать ли
его) ответьте утвердительно; когда вас спросят о пароле (“A challenge password”) – введите пароль для ключа сервера (запоминать его не нужно). Наберите

./build-key-server server

Далее, создайте ключи для необходимого количества клиентов. Эта процедура аналогична созданию ключа для сервера, за исключением того, что для клиентов ключи создаются скриптом build-key, а не build-key-server. У каждого ключа, конечно же, должно быть указано свое значение в поле Common Name:

./build-key clientname

Если вы хотите защитить паролем ключи клиентов, воспользуйтесь вместо ''build-key'' скриптом ''build-key-pass''. И наконец, в довершение ко всем сертификатам и ключам необходимо создать файл параметров Диффи (Diffie) и Хеллмэна (Hellman). Алгоритм Диффи и Хеллмэна позволяет обмениваться секретными ключами по небезопасным каналам. Для их генерации запустите скрипт
''build-dh'' без параметров:

./build-dh

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

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

* '''ca.crt''' (Root CA certificate) необходим серверу и всем клиентам, он не
является секретным.
* '''clientname.crt''' (сертификат клиента clientname) необходим только клиенту clientname, он не является секретным.
* '''clientname.key''' (ключ клиента clientname) необходим только клиенту clientname, это секретный ключ.

Эти файлы можно найти в подкаталоге '''keys''' каталога '''easy-rsa'''.

===Шаг 3: Настраиваем===

Итак, у нас есть все необходимые для работы ''OpenVPN'' файлы – все, кроме конфигурационных, созданием которых мы и займемся. Начнем с сервера. Для создания новых конфигурационных файлов удобно использовать примеры из поставки ''OpenVPN'', они находятся в подкаталоге '''sample-config-files''' каталога ''OpenVPN'' ('''../sample-config-files''', если вы находитесь в каталоге '''easy-rsa'''). В принципе, можно использовать стандартный конфигурационный файл для сервера, изменив некоторые параметры. Вот список этих параметров (некоторые из них, например, port и protocol, изменять не обязательно):

* '''ca''' – полный путь до корневого сертификата, который мы создали скриптом ''build-ca''.
* '''cert''' – полный путь до сертификата сервера, который мы создали его скриптом ''build-key-server''.
* '''key''' – путь до ключа сервера, созданного все тем же скриптом ''build-key-server''.
* '''dh''' – путь до файла параметров Диффи и Хеллмэна, созданного скриптом ''build-dh''.
* '''server''' – режим запуска ''OpenVPN''. В строке с режимом запуска для сервера должна быть указана подсеть и маска подсети (пример – server 10.8.0.0 255.255.255.0). Подсеть, указанная по умолчанию – 10.8.0.0/24. Если в вашей сети она уже используется, задайте другую локальную подсеть.
* '''port''' – порт, на котором будет запущен сервер. Стандартный порт ''OpenVPN'' – 1194, но вы можете изменить его по своему желанию.
* '''protocol''' – протокол. По умолчанию ''OpenVPN'' использует экономичный UDP, но вы можете предпочесть надежный TCP.

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

Для создания конфигурационного файла клиента также можно использовать пример, идущий в поставке с ''OpenVPN''. В нем надо изменить пути к необходимым файлам на свои, указать адрес и порт сервера в директиве remote и, кроме того, удостоверится, что выбранные настройки совпадают с настройками сервера (протокол, сжатие и т.п.). Пример конфигурационного файла клиента можно также взять с диска LXF. Тех же, кто хочет предоставлять ''VPN''-клиентам доступ в Интернет, ждет еще один шаг: включение NAT (Network Address Translation, Трансляция сетевых адресов) и настройка маршрутизации. Для начала необходимо написать соответствующее правило ''IPTables'':

iptables -t nat -A POSTROUTING -s маска_подсети -o внешний_интерфейс -j MASQUERADE

например:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ppp0 -j MASQUERADE

Его необходимо сохранить, добавив в файл с правилами iptables или в скрипты загрузки. Затем необходимо включить маршрутизацию, записав в '''/etc/sysctl.conf''' строку “net.ipv4.ip_forward = 1” и выполнив команду

sysctl -w net.ipv4.ip_forward=1

===Шаг 4: Проверка связи===

Если вы дошли до этого места, спешу вас обрадовать – остался всего
один, очень простой шаг. Надо запустить ''OpenVPN'' на сервере, а потом
и на всех клиентах. Для сервера: перейдите в каталог с ключами (keys)
и выполните:

openvpn --config ../sample-config-files/server.conf

После чего вы должны увидеть подобные строки:

Thu Aug 31 12:04:20 2006 OpenVPN 2.0.7 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Jul 22 2006
Thu Aug 31 12:04:20 2006 Diffie-Hellman initialized with 1024 bit key
Thu Aug 31 12:04:20 2006 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Aug 31 12:04:20 2006 TUN/TAP device tun0 opened <Skipped>
Thu Aug 31 12:04:20 2006 Initialization Sequence Completed

На клиенте (клиентах) выполните команду

openvpn --config client.conf

после чего проверьте наличие tun-интерфейса командой ifconfig:

ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00:00:00:00:00:00
inet addr:85.140.161.153 P-t-P:10.8.0.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Обратите внимание на статус (UP): он означает, что интерфейс находится в активном состоянии. Если в вашей системе имеется более одного tun-интерфейса (это можно проверить командой ifconfig без параметров), замените tun0 на tun1, tun2 и т.п.

Если интерфейс сконфигурирован правильно, проверьте доступность других хостов. Когда путь к файлу соответствий «клиент-IP» (опция ifconfig-pool-persist в конфигурационном файле сервера) не указан, их адреса назначаются сервером ''OpenVPN'' случайным образом. Наберите:

ping 10.8.0.2

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

Приходящие ответы свидетельствуют о том, что ''VPN''-соединение установлено и работает.

===Примечание 1. Врезки===

'''Почему OpenVPN?'''

Существует множество реализаций VPN, самые популярные из них – PPTP, ''FreeS/WAN'' и ''OpenVPN''. Почему же в этой статье мы рассмотрим именно последний вариант? PPTP навевает мысли о Microsoft, ''FreeS/WAN'' давно не обновлялся – на его официальном сайте сказано, что последняя версия датируется 22 апреля 2004 года, более того, дальнейших обновлений ''FreeS/WAN'' не будет, а это, согласитесь, недопустимо для проекта, одной из целей которого является обеспечение безопасности... ''OpenVPN'' же активно развивается и регулярно обновляется, использует стойкие криптографические алгоритмы и предлагает множество способов идентификации, в том числе комбинированных, что немаловажно для безопасности. Кроме того, ''OpenVPN'' работает на большинстве распространенных платформ – Linux, Windows 2000/XP, OpenBSD, FreeBSD, NetBSD, Mac OS X, Solaris, благодаря чему его можно использовать в гетерогенных сетях. Все это, безусловно, делает ''OpenVPN'' лучшим выбором для организации VPN.

'''Где искать easy-rsa?'''

Каталог '''easy-rsa''' может находиться в '''/usr/share/doc/openvpn-2.0''', '''/usr/share/doc/openvpn''', '''/usr/share/doc/openvpn/examples''', '''/usr/share/openvpn''' или в '''/usr/share/doc/packages/openvpn''' – в зависимости от дистрибутива. Его также можно найти в архиве с исходными текстами.

===Примечание 2. Примеры конфигурационных файлов (с диска)===

'''server.conf'''

# Конфигурационный файл сервера OpenVPN (Linux-версия)
# Порт
port 1194
# Протокол
proto udp
# Использовать tun (tunneling) вместо tap (ethernet bridging)
dev tun
# Полные пути к необходимым файлам (измените на свои пути)
ca /usr/local/etc/openvpn/easy-rsa/keys/ca.crt
cert /usr/local/etc/openvpn/easy-rsa/keys/server.crt
key /usr/local/etc/openvpn/easy-rsa/keys/server.key
# Путь к dh (измените на свой)
dh dh1024.pem
# Режим сервера,подсеть 10.8.0.0/24
server 10.8.0.0 255.255.255.0
# Файл соответствий клиент - виртуальный IP (по-умолчанию выдаётся динамический IP)
ifconfig-pool-persist ipp.txt
# Раскомментируйте если хотите, чтобы клиенты "видели" друг друга
;client-to-client
# Отключать после ... секунд без обмена данными (второй параметр)
keepalive 10 120
# Включить сжатие
comp-lzo
# Максимум клиентов одновременно - раскомментируйте если вам нужно ограничение по числу клиентов
;max-clients 100
# Снижение привилегий до указанных (в целях безопасности) (раскомментируйте если необходимо, в этом случае OpenVPN надо запускать с правами root)
;user nobody
;group nogroup

'''client.conf'''

# Конфигурационный файл клиента OpenVPN (Linux-версия)
client
# Использовать tun (tunneling) вместо tap (ethernet bridging)
dev tun
# Протокол
proto udp
# Адрес и порт сервера
remote 192.168.0.1 1194
# Если не получается установить соответствие между именем и адресом сервера - продолжать попытки
resolv-retry infinite
# Для клиента не нужно слушать порты
nobind
# Снижение привилегий до указанных (в целях безопасности) (раскомментируйте если необходимо, в этом случае OpenVPN надо запускать с правами root)
;user nobody
;group nogroup
# Сохранять определённые параметры
persist-key
persist-tun
# Полные пути к необходимым файлам (измените на свои пути)
ca /home/qweo/tmp/article/keys/ca.crt
cert /home/qweo/tmp/article/keys/clientname.crt
key /home/qweo/tmp/article/keys/clientname.key
# Включить сжатие (не включайте сжатие если на сервере оно отключено)
comp-lzo
# Уровень журналирования
verb 3

--[[Участник:Kipruss|Kipruss]] 00:35, 16 марта 2008 (MSK)

LXF94:OpenVPN

2008-03-15T21:43:33Z

Kipruss: /* Шаг 2: Создаем ключи */

== OpenVPN за 10 минут ==

''Технология VPN во многом напоминает перевозку денег в бронированной инкассаторской машине
по улицам многолюдного города. Но какую модель следует выбрать, чтобы ваши ценности не
достались злоумышленникам? Спросите у '''Валентина Яценко'''.''

VPN – Virtual Private Network, Виртуальная Частная Сеть – технология, позволяющая соединять между собой локальные сети и отдельные компьютеры, находящиеся на расстоянии тысяч километров друг от друга; подключаться к локальной сети через Интернет, используя шифрованный канал связи, организовывать безопасный туннель для передачи важных данных... Возможности применения VPN безграничны! Вам необходимо соединить офисы в разных концах страны единой сетью, не прокладывая километры кабелей? Вы хотите подключаться к домашней локальной сети из Интернет-кафе? Требуется передать важные данные на большое расстояние без риска утечки информации? Может быть, большинство данных, которые вы передаете через Интернет, составляют тайну, и их необходимо обезопасить? Если вы хотя бы на один вопрос ответили утвердительно, VPN – это именно то, что вам нужно!

=== Шаг 1: Устанавливаем ===

Пакеты с ''OpenVPN'' доступны для большинства распространенных дистрибутивов, в том числе для RedHat/Fedora, Mandriva, OpenSUSE, Slackware, Debian и Ubuntu. Если ''OpenVPN'' не включен в ваш любимый дистрибутив, попробуйте поискать пакет на [http://rpmfind.net rpmfind.net] (для систем, использующих RPM) или [http://linuxpackages.net linuxpackages.net] (Slackware и производные) Наконец, программу можно загрузить в исходных текстах с официального сайта ([http://openvpn.net openvpn.net]).

Для установки ''OpenVPN'' также необходимо установить ''OpenSSL'' (openssl.org) и ''liblzo'' (http://www.oberhumer.com/opensource/lzo), которые есть во многих дистрибутивах. Для работы ''OpenVPN'' нужен модуль ядра ''tun''. Он присутствует в большинстве систем, но если команда modrpobe tun завершается с ошибкой «Can’t locale module tun», вам придется пересобрать ядро – о том, как это сделать, подробно рассказано в [LXF89]. Необходимо включить опцию CONFIG_TUN (Device Drivers –> Network device support –> Universal TUN/TAP device driver support).

Если вы собираетесь использовать ''OpenVPN'' постоянно, пропишите модуль ''tun'' в '''/etc/modules''' для автоматической инициализации при загрузке либо включите его непосредственно в ядро. В противном случае перед запуском ''OpenVPN'' вам нужно будет загружать модуль ''tun'' самостоятельно (командой modrpobe tun). Если вы планируете предоставлять клиентам доступ в Интернет через ''VPN'', необходимо настроить NAT (Network Address Translation). Скорее всего, это уже сделано за вас разработчиками дистрибутива, но на случай возникновения проблем имейте в виду, что нам потребуется опция CONFIG_IP_NF_TARGET_MASQUERADE (Networking –> Networking options –> Network packet filtering –> IP tables support –> Full NAT). Для работы с NAT используется утилита ''iptables'' (см. [LXF87/88]), которая, скорее всего, уже установлена в вашей системе. Проверьте это и, в случае необходимости, добавьте ее через менеджер пакетов вашего дистрибутива.

===Шаг 2: Создаем ключи===

Итак, ''OpenVPN'' установлен. Что дальше? В первую очередь необходимо создать ключи и сертификаты для сервера и клиентов. Скрипты, облегчающие эту задачу, находятся в каталоге '''easy-rsa''' (''см. врезку «Где же easy-rsa?» внизу'').

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

* '''KEY_COUNTRY''' – равным двухсимвольному коду вашей страны (для России это RU).
* '''KEY_PROVINCE''' – названию вашего региона (например, Moscow region или MSK).
* '''KEY_CITY''', соответственно – ваш город (скажем, Moscow).
* '''KEY_ORG''' – организация (OpenVPN Solutions подойдет).
* '''KEY_EMAIL''' – ваш e-mail адрес (me@my.e-ma.il).

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

Также можно изменить параметр KEY_SIZE, отвечающий за размер ключей (максимальный размер ключа, поддерживаемый ''OpenVPN'' – 2048 бит).

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

. ./vars

и, на всякий случай, удалить существующие ключи командой

./clean-all

После этого следует сгенерировать корневой сертификат (см. [[LXF93]]):

./build-ca

В процессе выполнения последнего скрипта вам будет задано несколько вопросов. Нужно ввести только Common Name для сертификата (например, RootCA), все остальные параметры уже заданы в качестве переменных окружения скриптом vars.

После создания корневого сертификата необходимо сгенерировать для сервера секретный ключ. В этом вам поможет скрипт ''build-key-server''. Как и в предыдущем случае, для большинства вопросов
можно оставить ответы по умолчанию. На вопрос о Common Name введите “server”, на два последних вопроса (подписать ли сертификат и – каламбур, но перевод именно такой – сертифицировать ли
его) ответьте утвердительно; когда вас спросят о пароле (“A challenge password”) – введите пароль для ключа сервера (запоминать его не нужно). Наберите

./build-key-server server

Далее, создайте ключи для необходимого количества клиентов. Эта процедура аналогична созданию ключа для сервера, за исключением того, что для клиентов ключи создаются скриптом build-key, а не build-key-server. У каждого ключа, конечно же, должно быть указано свое значение в поле Common Name:

./build-key clientname

Если вы хотите защитить паролем ключи клиентов, воспользуйтесь вместо ''build-key'' скриптом ''build-key-pass''. И наконец, в довершение ко всем сертификатам и ключам необходимо создать файл параметров Диффи (Diffie) и Хеллмэна (Hellman). Алгоритм Диффи и Хеллмэна позволяет обмениваться секретными ключами по небезопасным каналам. Для их генерации запустите скрипт
''build-dh'' без параметров:

./build-dh

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

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

* '''ca.crt''' (Root CA certificate) необходим серверу и всем клиентам, он не
является секретным.
* '''clientname.crt''' (сертификат клиента clientname) необходим только клиенту clientname, он не является секретным.
* '''clientname.key''' (ключ клиента clientname) необходим только клиенту clientname, это секретный ключ.

Эти файлы можно найти в подкаталоге '''keys''' каталога '''easy-rsa'''.

===Шаг 3: Настраиваем===

Итак, у нас есть все необходимые для работы ''OpenVPN'' файлы – все, кроме конфигурационных, созданием которых мы и займемся. Начнем с сервера. Для создания новых конфигурационных файлов удобно использовать примеры из поставки ''OpenVPN'', они находятся в подкаталоге '''sample-config-files''' каталога ''OpenVPN'' ('''../sample-config-files''', если вы находитесь в каталоге '''easy-rsa'''). В принципе, можно использовать стандартный конфигурационный файл для сервера, изменив некоторые параметры. Вот список этих параметров (некоторые из них, например, port и protocol, изменять не обязательно):

* '''ca''' – полный путь до корневого сертификата, который мы создали скриптом ''build-ca''.
* '''cert''' – полный путь до сертификата сервера, который мы создали его скриптом ''build-key-server''.
* '''key''' – путь до ключа сервера, созданного все тем же скриптом ''build-key-server''.
* '''dh''' – путь до файла параметров Диффи и Хеллмэна, созданного скриптом ''build-dh''.
* '''server''' – режим запуска ''OpenVPN''. В строке с режимом запуска для сервера должна быть указана подсеть и маска подсети (пример – server 10.8.0.0 255.255.255.0). Подсеть, указанная по умолчанию – 10.8.0.0/24. Если в вашей сети она уже используется, задайте другую локальную подсеть.
* '''port''' – порт, на котором будет запущен сервер. Стандартный порт ''OpenVPN'' – 1194, но вы можете изменить его по своему желанию.
* '''protocol''' – протокол. По умолчанию ''OpenVPN'' использует экономичный UDP, но вы можете предпочесть надежный TCP.

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

Для создания конфигурационного файла клиента также можно использовать пример, идущий в поставке с ''OpenVPN''. В нем надо изменить пути к необходимым файлам на свои, указать адрес и порт сервера в директиве remote и, кроме того, удостоверится, что выбранные настройки совпадают с настройками сервера (протокол, сжатие и т.п.). Пример конфигурационного файла клиента можно также взять с диска LXF. Тех же, кто хочет предоставлять ''VPN''-клиентам доступ в Интернет, ждет еще один шаг: включение NAT (Network Address Translation, Трансляция сетевых адресов) и настройка маршрутизации. Для начала необходимо написать соответствующее правило ''IPTables'':

iptables -t nat -A POSTROUTING -s маска_подсети -o внешний_интерфейс -j MASQUERADE

например:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ppp0 -j MASQUERADE

Его необходимо сохранить, добавив в файл с правилами iptables или в скрипты загрузки. Затем необходимо включить маршрутизацию, записав в '''/etc/sysctl.conf''' строку “net.ipv4.ip_forward = 1” и выполнив команду

sysctl -w net.ipv4.ip_forward=1

===Шаг 4: Проверка связи===

Если вы дошли до этого места, спешу вас обрадовать – остался всего
один, очень простой шаг. Надо запустить ''OpenVPN'' на сервере, а потом
и на всех клиентах. Для сервера: перейдите в каталог с ключами (keys)
и выполните:

openvpn --config ../sample-config-files/server.conf

После чего вы должны увидеть подобные строки:

Thu Aug 31 12:04:20 2006 OpenVPN 2.0.7 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Jul 22 2006
Thu Aug 31 12:04:20 2006 Diffie-Hellman initialized with 1024 bit key
Thu Aug 31 12:04:20 2006 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Aug 31 12:04:20 2006 TUN/TAP device tun0 opened <Skipped>
Thu Aug 31 12:04:20 2006 Initialization Sequence Completed

На клиенте (клиентах) выполните команду

openvpn --config client.conf

после чего проверьте наличие tun-интерфейса командой ifconfig:

ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00:00:00:00:00:00
inet addr:85.140.161.153 P-t-P:10.8.0.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Обратите внимание на статус (UP): он означает, что интерфейс находится в активном состоянии. Если в вашей системе имеется более одного tun-интерфейса (это можно проверить командой ifconfig без параметров), замените tun0 на tun1, tun2 и т.п.

Если интерфейс сконфигурирован правильно, проверьте доступность других хостов. Когда путь к файлу соответствий «клиент-IP» (опция ifconfig-pool-persist в конфигурационном файле сервера) не указан, их адреса назначаются сервером ''OpenVPN'' случайным образом. Наберите:

ping 10.8.0.2

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

Приходящие ответы свидетельствуют о том, что ''VPN''-соединение установлено и работает.

===Примечание 1. Врезки===

'''Почему OpenVPN?'''

Существует множество реализаций VPN, самые популярные из них – PPTP, ''FreeS/WAN'' и ''OpenVPN''. Почему же в этой статье мы рассмотрим именно последний вариант? PPTP навевает мысли о Microsoft, ''FreeS/WAN'' давно не обновлялся – на его официальном сайте сказано, что последняя версия датируется 22 апреля 2004 года, более того, дальнейших обновлений ''FreeS/WAN'' не будет, а это, согласитесь, недопустимо для проекта, одной из целей которого является обеспечение безопасности... ''OpenVPN'' же активно развивается и регулярно обновляется, использует стойкие криптографические алгоритмы и предлагает множество способов идентификации, в том числе комбинированных, что немаловажно для безопасности. Кроме того, ''OpenVPN'' работает на большинстве распространенных платформ – Linux, Windows 2000/XP, OpenBSD, FreeBSD, NetBSD, Mac OS X, Solaris, благодаря чему его можно использовать в гетерогенных сетях. Все это, безусловно, делает ''OpenVPN'' лучшим выбором для организации VPN.

'''Где искать easy-rsa?'''

Каталог '''easy-rsa''' может находиться в '''/usr/share/doc/openvpn-2.0''', '''/usr/share/doc/openvpn''', '''/usr/share/doc/openvpn/examples''', '''/usr/share/openvpn''' или в '''/usr/share/doc/packages/openvpn''' – в зависимости от дистрибутива. Его также можно найти в архиве с исходными текстами.

===Примечание 2. Примеры конфигурационных файлов (с диска)===

'''server.conf'''

# Конфигурационный файл сервера OpenVPN (Linux-версия)
# Порт
port 1194
# Протокол
proto udp
# Использовать tun (tunneling) вместо tap (ethernet bridging)
dev tun
# Полные пути к необходимым файлам (измените на свои пути)
ca /usr/local/etc/openvpn/easy-rsa/keys/ca.crt
cert /usr/local/etc/openvpn/easy-rsa/keys/server.crt
key /usr/local/etc/openvpn/easy-rsa/keys/server.key
# Путь к dh (измените на свой)
dh dh1024.pem
# Режим сервера,подсеть 10.8.0.0/24
server 10.8.0.0 255.255.255.0
# Файл соответствий клиент - виртуальный IP (по-умолчанию выдаётся динамический IP)
ifconfig-pool-persist ipp.txt
# Раскомментируйте если хотите, чтобы клиенты "видели" друг друга
;client-to-client
# Отключать после ... секунд без обмена данными (второй параметр)
keepalive 10 120
# Включить сжатие
comp-lzo
# Максимум клиентов одновременно - раскомментируйте если вам нужно ограничение по числу клиентов
;max-clients 100
# Снижение привилегий до указанных (в целях безопасности) (раскомментируйте если необходимо, в этом случае OpenVPN надо запускать с правами root)
;user nobody
;group nogroup

'''client.conf'''

# Конфигурационный файл клиента OpenVPN (Linux-версия)
client
# Использовать tun (tunneling) вместо tap (ethernet bridging)
dev tun
# Протокол
proto udp
# Адрес и порт сервера
remote 192.168.0.1 1194
# Если не получается установить соответствие между именем и адресом сервера - продолжать попытки
resolv-retry infinite
# Для клиента не нужно слушать порты
nobind
# Снижение привилегий до указанных (в целях безопасности) (раскомментируйте если необходимо, в этом случае OpenVPN надо запускать с правами root)
;user nobody
;group nogroup
# Сохранять определённые параметры
persist-key
persist-tun
# Полные пути к необходимым файлам (измените на свои пути)
ca /home/qweo/tmp/article/keys/ca.crt
cert /home/qweo/tmp/article/keys/clientname.crt
key /home/qweo/tmp/article/keys/clientname.key
# Включить сжатие (не включайте сжатие если на сервере оно отключено)
comp-lzo
# Уровень журналирования
verb 3

--[[Участник:Kipruss|Kipruss]] 00:35, 16 марта 2008 (MSK)

LXF94:OpenVPN

2008-03-15T21:41:08Z

Kipruss: /* Исправление описок */

== OpenVPN за 10 минут ==

''Технология VPN во многом напоминает перевозку денег в бронированной инкассаторской машине
по улицам многолюдного города. Но какую модель следует выбрать, чтобы ваши ценности не
достались злоумышленникам? Спросите у '''Валентина Яценко'''.''

VPN – Virtual Private Network, Виртуальная Частная Сеть – технология, позволяющая соединять между собой локальные сети и отдельные компьютеры, находящиеся на расстоянии тысяч километров друг от друга; подключаться к локальной сети через Интернет, используя шифрованный канал связи, организовывать безопасный туннель для передачи важных данных... Возможности применения VPN безграничны! Вам необходимо соединить офисы в разных концах страны единой сетью, не прокладывая километры кабелей? Вы хотите подключаться к домашней локальной сети из Интернет-кафе? Требуется передать важные данные на большое расстояние без риска утечки информации? Может быть, большинство данных, которые вы передаете через Интернет, составляют тайну, и их необходимо обезопасить? Если вы хотя бы на один вопрос ответили утвердительно, VPN – это именно то, что вам нужно!

=== Шаг 1: Устанавливаем ===

Пакеты с ''OpenVPN'' доступны для большинства распространенных дистрибутивов, в том числе для RedHat/Fedora, Mandriva, OpenSUSE, Slackware, Debian и Ubuntu. Если ''OpenVPN'' не включен в ваш любимый дистрибутив, попробуйте поискать пакет на [http://rpmfind.net rpmfind.net] (для систем, использующих RPM) или [http://linuxpackages.net linuxpackages.net] (Slackware и производные) Наконец, программу можно загрузить в исходных текстах с официального сайта ([http://openvpn.net openvpn.net]).

Для установки ''OpenVPN'' также необходимо установить ''OpenSSL'' (openssl.org) и ''liblzo'' (http://www.oberhumer.com/opensource/lzo), которые есть во многих дистрибутивах. Для работы ''OpenVPN'' нужен модуль ядра ''tun''. Он присутствует в большинстве систем, но если команда modrpobe tun завершается с ошибкой «Can’t locale module tun», вам придется пересобрать ядро – о том, как это сделать, подробно рассказано в [LXF89]. Необходимо включить опцию CONFIG_TUN (Device Drivers –> Network device support –> Universal TUN/TAP device driver support).

Если вы собираетесь использовать ''OpenVPN'' постоянно, пропишите модуль ''tun'' в '''/etc/modules''' для автоматической инициализации при загрузке либо включите его непосредственно в ядро. В противном случае перед запуском ''OpenVPN'' вам нужно будет загружать модуль ''tun'' самостоятельно (командой modrpobe tun). Если вы планируете предоставлять клиентам доступ в Интернет через ''VPN'', необходимо настроить NAT (Network Address Translation). Скорее всего, это уже сделано за вас разработчиками дистрибутива, но на случай возникновения проблем имейте в виду, что нам потребуется опция CONFIG_IP_NF_TARGET_MASQUERADE (Networking –> Networking options –> Network packet filtering –> IP tables support –> Full NAT). Для работы с NAT используется утилита ''iptables'' (см. [LXF87/88]), которая, скорее всего, уже установлена в вашей системе. Проверьте это и, в случае необходимости, добавьте ее через менеджер пакетов вашего дистрибутива.

===Шаг 2: Создаем ключи===

Итак, ''OpenVPN'' установлен. Что дальше? В первую очередь необходимо создать ключи и сертификаты для сервера и клиентов. Скрипты, облегчающие эту задачу, находятся в каталоге '''easy-rsa''' (''см. врезку «Где же easy-rsa?» внизу'').

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

* '''KEY_COUNTRY''' – равным двухсимвольному коду вашей страны (для России это RU).
* '''KEY_PROVINCE''' – названию вашего региона (например, Moscow region или MSK).
* '''KEY_CITY''', соответственно – ваш город (скажем, Moscow).
* '''KEY_ORG''' – организация (OpenVPN Solutions подойдет).
* '''KEY_EMAIL''' – ваш e-mail адрес (me@my.e-ma.il).

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

Также можно изменить параметр KEY_SIZE, отвечающий за размер ключей (максимальный размер ключа, поддерживаемый ''OpenVPN'' – 2048 бит).

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

. ./vars

и, на всякий случай, удалить существующие ключи командой

./clean-all

После этого следует сгенерировать корневой сертификат (см. [LXF93]):

./build-ca

В процессе выполнения последнего скрипта вам будет задано несколько вопросов. Нужно ввести только Common Name для сертификата (например, RootCA), все остальные параметры уже заданы в качестве переменных окружения скриптом vars.

После создания корневого сертификата необходимо сгенерировать для сервера секретный ключ. В этом вам поможет скрипт ''build-key-server''. Как и в предыдущем случае, для большинства вопросов
можно оставить ответы по умолчанию. На вопрос о Common Name введите “server”, на два последних вопроса (подписать ли сертификат и – каламбур, но перевод именно такой – сертифицировать ли
его) ответьте утвердительно; когда вас спросят о пароле (“A challenge password”) – введите пароль для ключа сервера (запоминать его не нужно). Наберите

./build-key-server server

Далее, создайте ключи для необходимого количества клиентов. Эта процедура аналогична созданию ключа для сервера, за исключением того, что для клиентов ключи создаются скриптом build-key, а не build-key-server. У каждого ключа, конечно же, должно быть указано свое значение в поле Common Name:

./build-key clientname

Если вы хотите защитить паролем ключи клиентов, воспользуйтесь вместо ''build-key'' скриптом ''build-key-pass''. И наконец, в довершение ко всем сертификатам и ключам необходимо создать файл параметров Диффи (Diffie) и Хеллмэна (Hellman). Алгоритм Диффи и Хеллмэна позволяет обмениваться секретными ключами по небезопасным каналам. Для их генерации запустите скрипт
''build-dh'' без параметров:

./build-dh

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

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

* '''ca.crt''' (Root CA certificate) необходим серверу и всем клиентам, он не
является секретным.
* '''clientname.crt''' (сертификат клиента clientname) необходим только клиенту clientname, он не является секретным.
* '''clientname.key''' (ключ клиента clientname) необходим только клиенту clientname, это секретный ключ.

Эти файлы можно найти в подкаталоге '''keys''' каталога '''easy-rsa'''.

===Шаг 3: Настраиваем===

Итак, у нас есть все необходимые для работы ''OpenVPN'' файлы – все, кроме конфигурационных, созданием которых мы и займемся. Начнем с сервера. Для создания новых конфигурационных файлов удобно использовать примеры из поставки ''OpenVPN'', они находятся в подкаталоге '''sample-config-files''' каталога ''OpenVPN'' ('''../sample-config-files''', если вы находитесь в каталоге '''easy-rsa'''). В принципе, можно использовать стандартный конфигурационный файл для сервера, изменив некоторые параметры. Вот список этих параметров (некоторые из них, например, port и protocol, изменять не обязательно):

* '''ca''' – полный путь до корневого сертификата, который мы создали скриптом ''build-ca''.
* '''cert''' – полный путь до сертификата сервера, который мы создали его скриптом ''build-key-server''.
* '''key''' – путь до ключа сервера, созданного все тем же скриптом ''build-key-server''.
* '''dh''' – путь до файла параметров Диффи и Хеллмэна, созданного скриптом ''build-dh''.
* '''server''' – режим запуска ''OpenVPN''. В строке с режимом запуска для сервера должна быть указана подсеть и маска подсети (пример – server 10.8.0.0 255.255.255.0). Подсеть, указанная по умолчанию – 10.8.0.0/24. Если в вашей сети она уже используется, задайте другую локальную подсеть.
* '''port''' – порт, на котором будет запущен сервер. Стандартный порт ''OpenVPN'' – 1194, но вы можете изменить его по своему желанию.
* '''protocol''' – протокол. По умолчанию ''OpenVPN'' использует экономичный UDP, но вы можете предпочесть надежный TCP.

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

Для создания конфигурационного файла клиента также можно использовать пример, идущий в поставке с ''OpenVPN''. В нем надо изменить пути к необходимым файлам на свои, указать адрес и порт сервера в директиве remote и, кроме того, удостоверится, что выбранные настройки совпадают с настройками сервера (протокол, сжатие и т.п.). Пример конфигурационного файла клиента можно также взять с диска LXF. Тех же, кто хочет предоставлять ''VPN''-клиентам доступ в Интернет, ждет еще один шаг: включение NAT (Network Address Translation, Трансляция сетевых адресов) и настройка маршрутизации. Для начала необходимо написать соответствующее правило ''IPTables'':

iptables -t nat -A POSTROUTING -s маска_подсети -o внешний_интерфейс -j MASQUERADE

например:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ppp0 -j MASQUERADE

Его необходимо сохранить, добавив в файл с правилами iptables или в скрипты загрузки. Затем необходимо включить маршрутизацию, записав в '''/etc/sysctl.conf''' строку “net.ipv4.ip_forward = 1” и выполнив команду

sysctl -w net.ipv4.ip_forward=1

===Шаг 4: Проверка связи===

Если вы дошли до этого места, спешу вас обрадовать – остался всего
один, очень простой шаг. Надо запустить ''OpenVPN'' на сервере, а потом
и на всех клиентах. Для сервера: перейдите в каталог с ключами (keys)
и выполните:

openvpn --config ../sample-config-files/server.conf

После чего вы должны увидеть подобные строки:

Thu Aug 31 12:04:20 2006 OpenVPN 2.0.7 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Jul 22 2006
Thu Aug 31 12:04:20 2006 Diffie-Hellman initialized with 1024 bit key
Thu Aug 31 12:04:20 2006 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Aug 31 12:04:20 2006 TUN/TAP device tun0 opened <Skipped>
Thu Aug 31 12:04:20 2006 Initialization Sequence Completed

На клиенте (клиентах) выполните команду

openvpn --config client.conf

после чего проверьте наличие tun-интерфейса командой ifconfig:

ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00:00:00:00:00:00
inet addr:85.140.161.153 P-t-P:10.8.0.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Обратите внимание на статус (UP): он означает, что интерфейс находится в активном состоянии. Если в вашей системе имеется более одного tun-интерфейса (это можно проверить командой ifconfig без параметров), замените tun0 на tun1, tun2 и т.п.

Если интерфейс сконфигурирован правильно, проверьте доступность других хостов. Когда путь к файлу соответствий «клиент-IP» (опция ifconfig-pool-persist в конфигурационном файле сервера) не указан, их адреса назначаются сервером ''OpenVPN'' случайным образом. Наберите:

ping 10.8.0.2

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

Приходящие ответы свидетельствуют о том, что ''VPN''-соединение установлено и работает.

===Примечание 1. Врезки===

'''Почему OpenVPN?'''

Существует множество реализаций VPN, самые популярные из них – PPTP, ''FreeS/WAN'' и ''OpenVPN''. Почему же в этой статье мы рассмотрим именно последний вариант? PPTP навевает мысли о Microsoft, ''FreeS/WAN'' давно не обновлялся – на его официальном сайте сказано, что последняя версия датируется 22 апреля 2004 года, более того, дальнейших обновлений ''FreeS/WAN'' не будет, а это, согласитесь, недопустимо для проекта, одной из целей которого является обеспечение безопасности... ''OpenVPN'' же активно развивается и регулярно обновляется, использует стойкие криптографические алгоритмы и предлагает множество способов идентификации, в том числе комбинированных, что немаловажно для безопасности. Кроме того, ''OpenVPN'' работает на большинстве распространенных платформ – Linux, Windows 2000/XP, OpenBSD, FreeBSD, NetBSD, Mac OS X, Solaris, благодаря чему его можно использовать в гетерогенных сетях. Все это, безусловно, делает ''OpenVPN'' лучшим выбором для организации VPN.

'''Где искать easy-rsa?'''

Каталог '''easy-rsa''' может находиться в '''/usr/share/doc/openvpn-2.0''', '''/usr/share/doc/openvpn''', '''/usr/share/doc/openvpn/examples''', '''/usr/share/openvpn''' или в '''/usr/share/doc/packages/openvpn''' – в зависимости от дистрибутива. Его также можно найти в архиве с исходными текстами.

===Примечание 2. Примеры конфигурационных файлов (с диска)===

'''server.conf'''

# Конфигурационный файл сервера OpenVPN (Linux-версия)
# Порт
port 1194
# Протокол
proto udp
# Использовать tun (tunneling) вместо tap (ethernet bridging)
dev tun
# Полные пути к необходимым файлам (измените на свои пути)
ca /usr/local/etc/openvpn/easy-rsa/keys/ca.crt
cert /usr/local/etc/openvpn/easy-rsa/keys/server.crt
key /usr/local/etc/openvpn/easy-rsa/keys/server.key
# Путь к dh (измените на свой)
dh dh1024.pem
# Режим сервера,подсеть 10.8.0.0/24
server 10.8.0.0 255.255.255.0
# Файл соответствий клиент - виртуальный IP (по-умолчанию выдаётся динамический IP)
ifconfig-pool-persist ipp.txt
# Раскомментируйте если хотите, чтобы клиенты "видели" друг друга
;client-to-client
# Отключать после ... секунд без обмена данными (второй параметр)
keepalive 10 120
# Включить сжатие
comp-lzo
# Максимум клиентов одновременно - раскомментируйте если вам нужно ограничение по числу клиентов
;max-clients 100
# Снижение привилегий до указанных (в целях безопасности) (раскомментируйте если необходимо, в этом случае OpenVPN надо запускать с правами root)
;user nobody
;group nogroup

'''client.conf'''

# Конфигурационный файл клиента OpenVPN (Linux-версия)
client
# Использовать tun (tunneling) вместо tap (ethernet bridging)
dev tun
# Протокол
proto udp
# Адрес и порт сервера
remote 192.168.0.1 1194
# Если не получается установить соответствие между именем и адресом сервера - продолжать попытки
resolv-retry infinite
# Для клиента не нужно слушать порты
nobind
# Снижение привилегий до указанных (в целях безопасности) (раскомментируйте если необходимо, в этом случае OpenVPN надо запускать с правами root)
;user nobody
;group nogroup
# Сохранять определённые параметры
persist-key
persist-tun
# Полные пути к необходимым файлам (измените на свои пути)
ca /home/qweo/tmp/article/keys/ca.crt
cert /home/qweo/tmp/article/keys/clientname.crt
key /home/qweo/tmp/article/keys/clientname.key
# Включить сжатие (не включайте сжатие если на сервере оно отключено)
comp-lzo
# Уровень журналирования
verb 3

--[[Участник:Kipruss|Kipruss]] 00:35, 16 марта 2008 (MSK)