2007/05/30

Инструкция по восстановлению Software RAID 1

В процессе установки Debian 4.0 (Etch) возможно создать Software (программный) RAID, повысив тем самым надежность хранения Ваших данных. Статья Install Debian Etch on a Software Raid 1 with S-ATA disks подробно описывает как это сделать в процессе инсталляции на примере создания RAID 1 (зеркальное копирование).
Советую протестировать "живучесть" работающего массива, сэмитировав возникновение проблемы с каким-либо диском в массиве. Приведенная ниже инструкция описывает как действовать в таких случаях на примере RAID 1 с двумя SCSI-дисками (/dev/sda, /dev/sdb) на Debian 4.0 (Etch).

Этап 1

Если проблемы с каким либо разделом в RAID (например, /dev/sdb2)
# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md1 : active raid1 sda2[0] sdb2[2](F)
63472704 blocks [2/1] [U_]
md2 : active raid1 sda3[0] sdb3[1]
3903680 blocks [2/1] [UU]
md0 : active raid1 sda1[0] sdb1[1]
3317312 blocks [2/1] [UU]
Необходимо удалить поврежденный раздел (прежде пометив его как fail), а потом его же добавить:
# mdadm /dev/md1 –f /dev/sdb2
# mdadm /dev/md1 -r /dev/sdb2
# mdadm /dev/md1 -a /dev/sdb2
После проделанных операций проверить его статус, как показано выше. Если проблема устранена, все md-разделы будут помечены как [UU].
Если это не помогает и массив по прежнему не восстанавливается, следует удалить все разделы испорченного диска (/dev/sdb1, /dev/sdb2), пометив прежде их как fail, и перейти к Этапу 2:
# mdadm /dev/md1 -f /dev/sdb1
# mdadm /dev/md1 -r /dev/sdb1
# mdadm /dev/md1 -f /dev/sdb2
# mdadm /dev/md1 -r /dev/sdb2
Этап 2

1. Выключить сервер
# shutdown -h now
2. Если проблема с вторичным диском - вставить новый диск на место старого, повторив установку перемычек (jumpers). Если проблема с первичным диском - вставить на место первичного диска (/dev/sda) вторичный диск (рабочий, /dev/sdb), повторив установку перемычек (jumpers), а на место вторичного установить новый диск.
3. Загрузить сервер.
4. Из под root выполнить комманды:
# sfdisk -d /dev/sda | sfdisk /dev/sdb # копирование таблицы разделов с /dev/sda на /dev/sdb
# fdisk -l # проверить, что оба диска имеют одинаковую разметку
# mdadm --add /dev/md0 /dev/sdb1 # добавление устройств в RAID
# mdadm --add /dev/md1 /dev/sdb2
# mdadm --add /dev/md2 /dev/sdb3
# grub
grub> root (hd1,0) # указать, где находится каталог /boot/grub на вторичном диске
grub> setup (hd1) # установить GRUB-загрузчик в MBR вторичного диска
grub> quit
5. Проверить состояние RAID устройств можно коммандой cat /proc/mdstat
Если всё, прошло успешно, вывод будет похож на:
# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md0 : active raid1 sda1[0] sdb1[1]
24418688 blocks [2/2] [UU]
md2 : active raid1 sda3[0] sdb3[1]
3903680 blocks [2/1] [UU]
md1 : active raid1 sda2[0] sdb2[1]
24418688 blocks [2/2] [UU]

6.Как только RAID восстановится, перегрузить сервер для проверки работоспособности.

Ссылки:
  1. GRUB - GRand мира загрузчиков
  2. How to boot Linux from RAID-1 with GRUB

2007/05/11

NRPE - мониторинг удаленных (недоступных извне) серверов средствами Nagios

NRPE - модуль для системы мониторинга Nagios, позволяющий запускать plugin'ы на удаленных серверах. Основная задача данного модуля - получить информацию о локальных данных удаленных серверов (check_load, check_users). Но с таким же успехом его можно использовать для мониторинга недоступных серверов, например, находящихся в локальной сети и не имеющих внешних адресов. Для этого достаточно установить на промежуточном сервере (195.43.68.11), имеющим доступ к локальной сети (192.168.1.0), nrpe-службу и на сервере мониторинга (195.43.68.2) установить nrpe-plugin.
Все описанные ниже действия были проделанны на серверах с Linux Debian 4.0 (Etch).

1. На стороне remote-сервера установить nrpe-сервис и базовый набор nagios-plugin'ов
# apt-get install nagios-nrpe-server nagios-plugins-basic
...
Setting up nagios-nrpe-server (2.5.1-3) ...
Starting nagios-nrpe: nagios-nrpe.

# netstat -an | grep 5666
tcp 0 0 0.0.0.0:5666 0.0.0.0:* LISTEN
2. Изменить конфигурационный файл /etc/nagios/nrpe.cfg и перезапустить сервис с новыми параметрами
allowed_hosts=127.0.0.1,195.43.68.2
# разрешить использование аргументов при выхове plugin'ов
dont_blame_nrpe=1
# пример описания plugin'а
command[check_ftp]=/usr/lib/nagios/plugins/check_ftp -H $ARG1$

# /etc/init.d/nagios-nrpe-server restart
Stopping nagios-nrpe: nagios-nrpe.
Starting nagios-nrpe: nagios-nrpe.

3. На стороне мониторинг-сервера установить nrpe-plugin, протестировать его функциональность и добавить описания требуемых для мониторинга локальных сервисов. В приведенном ниже примере используется plugin check_ftp, для проверки работоспособности ftp-сервиса на локальном сервере 192.168.1.111.
# apt-get install nagios-nrpe-plugin
...
Setting up nagios-nrpe-plugin (2.5.1-3) ...

# /usr/lib/nagios/plugins/check_nrpe -H
195.43.68.11
NRPE v2.5.1
# /usr/lib/nagios/plugins/check_nrpe -H 195.43.68.11 -c check_users
USERS OK - 1 users currently logged in |users=1;5;10;0
# /usr/lib/nagios/plugins/check_nrpe -H 195.43.68.11 -c check_load
OK - load average: 0.21, 0.16, 0.11|load1=0.210;15.000;30.000;0; load5=0.160;10.000;25.000;0; load15=0.110;5.000;20.000;0;
# /usr/lib/nagios/plugins/check_nrpe -H 195.43.68.11 -c check_total_procs
PROCS OK: 60 processes
# /usr/lib/nagios/plugins/check_nrpe -H 195.43.68.11 -c check_zombie_procs
PROCS OK: 0 processes with STATE = Z
# /usr/lib/nagios/plugins/check_nrpe -H 195.43.64.11 -c check_ftp -a 192.168.1.111
FTP OK - 0.024 second response time on port 21 [220 saule FTP server ready.]|time=0.024221s;0.000000;0.000000;0.000000;10.000000
Пример описания данного сервиса в конфигурации Nagios:
define service{
use generic-service
host_name remote
service_description NRPE_FTP
check_command check_nrpe!check_ftp!192.168.1.111
Ссылки:
  1. NRPE Documentation

2007/05/07

Exilog - инструмент для анализа логов MTA Exim

В Linux Debian в качестве default MTA используется Exim. Данный агент очень мощный в настройке и в отличие от sendmail более стабилен и безопасен. В комплекте с ним идут различные утилиты для работы с почтовой очередью, вывода статистики (existats), просмотра того, что в данный момент происходит (exiwhat) и т.п. Но у него есть один недостаток - для него не существует на данный момент активно разрабатываемого анализатора логов.
Exilog - продукт не имеющий релиза, застрявший в разработке (последняя версия 0.5 от 2005.10.23), но он вполне мог бы стать полноценным инструментом для работы с логами Exim'а. Сам активно использую уже больше года и могу только поблагодарить разработчиков.
Exilog - это перл-демон, который в реальном времени сканирует логи, результаты сбрасывает в MySQL базу и имеет приятный web-интерфейc.
Весь процесс установки подробно описан в README (необходимо устранить все зависимости (для Debian-системы это пакеты libdbd-mysql-perl и libnet-netmask-perl) и подправить конфигурационный файл). От себя же добавлю, что для окончательной интеграции в Debian-систему в /etc/init.d/exim4 необходимо внести следующие изменения:
...
start_exim()
{
/var/spool/exim4/exilog/exilog_agent.pl >> /var/log/exilog_agent.log 2>&1
...
}

stop_exim()
{
...
kill -s 15 `cat /var/run/exilog-agent.pid`
}
...

Ссылки:
Exilog - homepage

2007/05/03

The GNU Accounting Utilities - стандартный инструментарий для анализа произошедшего

The GNU Accounting Utilities (acct) - набор из нескольких утилит, помогающих проанализировать произошедшие инциденты и обнаружить слабые места в работе сервера.
Смысл простой - вы включаете запись всего происходящего, а потом анализируете накопленные данные (файлы /var/log/pacct и /var/log/wtmp). Слежение происходит на уровне ядра, поэтому ядро должно иметь соответствующую опцию (BSD-style process accounting) при сборке (мною опробованы стандартные ядра Debian 3.1, 4.0, Slackware 10 - с ними все в порядке). В Debian и Slackware - все элементарно ставится из репозитария - пакет acct.
В данный набор входят следующие утилиты:
Лучший способ рассказа об этих утилитах - пример ситуации. Итак, представьте себе, вы хорошо осведомлены о том, что происходит на ваших серверах, накапливаете статистику (например, по snmp с помощью Cacti) о загрузке, использовании памяти и процессорного времени, приходите утром смотрите на графики и видите дикую нагрузку на вашем веб-сервере ночью, когда обычно всё тихо. Естественно, первым делом идут в ход обычные логи (/var/log/messages, /var/log/auth.log, /var/log/syslog и .т.д.), но ситуация несколько осложняется - дело в том, что на веб-сервере запущен не только веб-сервис, но и с десяток других (mail, ftp, ldap, dns и т.д.). Если обычные логи ничего толкогого не говорят и вы не можете точно сказать, что за сервис вызвал такую нагрузку (да и сервис ли это был?), тогда в дело вступают Accounting Utilities (естественно, если вы прежде включили накопление результатов :) )
# lastcomm -f /var/log/pacct.1 > ~/lastcomm.log
Вывод будет примерно следующий:
...
apachectl root ?? 0.01 secs Tue May 1 18:50
lynx root ?? 0.01 secs Tue May 1 18:50
awk root ?? 0.01 secs Tue May 1 18:50
lynx root ?? 0.00 secs Tue May 1 18:50
cat root ?? 0.00 secs Tue May 1 18:50
httpd www ?? 0.13 secs Tue May 1 18:49
httpd www ?? 0.12 secs Tue May 1 18:49
httpd www ?? 0.15 secs Tue May 1 18:49
httpd www ?? 0.17 secs Tue May 1 18:49
httpd www ?? 0.25 secs Tue May 1 18:49
httpd www ?? 0.14 secs Tue May 1 18:49
httpd www ?? 0.14 secs Tue May 1 18:49
httpd www ?? 0.25 secs Tue May 1 18:49
httpd www ?? 1.56 secs Tue May 1 18:39
httpd www ?? 0.13 secs Tue May 1 18:49
httpd www ?? 0.14 secs Tue May 1 18:49
httpd www ?? 0.23 secs Tue May 1 18:49
httpd www ?? 1.92 secs Tue May 1 18:39
proftpd root ?? 0.01 secs Tue May 1 18:49
httpd www ?? 0.14 secs Tue May 1 18:49
httpd www ?? 0.14 secs Tue May 1 18:49
httpd www ?? 0.13 secs Tue May 1 18:48
httpd www ?? 0.15 secs Tue May 1 18:48
httpd www ?? 1.42 secs Tue May 1 18:39
httpd www ?? 361.29 secs Tue May 1 18:30
httpd www ?? 0.32 secs Tue May 1 18:45
httpd www ?? 0.75 secs Tue May 1 18:45
httpd www ?? 0.80 secs Tue May 1 18:45
httpd www ?? 0.19 secs Tue May 1 18:47
...
Колонки: команда, пользователь, терминал, время выполнения, время старта данной команды (еще могут быть различные флаги, о которых написано в документации)
Из приведенного выше лога видно, что веб-сервер что-то выполнял 360 секунд (видимо это был какой-то скрипт). Плюс число 360 - это явно какой-то лимит, видимо веб-сервер остановил выполнение скрипта по истечению timeout'а в 360 секунд. Ну а дальше - дело техники - в лог файлах выших сайтов найти что за скрипт был остановлен (и не раз) за то, что повисал.

Ссылки:
  1. Accounting Utilities Manual
  2. Как отследить запущенные пользователями программы

ProFTPd + LDAP - пользователи и их квоты

Беря пример с Microsoft Active Directory, можно интегрировать LDAP-директорию пользователей с FTP-сервисом на основе ProFTPd. Кроме того, что в качестве аутентификационной базы пользователей можно использовать LDAP, в нем можно хранить и дополнительные средства авторизации - такие как данные о лимитах для пользователей (quota). ProFTPd должен быть собран с поддержкой LDAP (В Debian 4.0 Etch с этим всё в порядке). В качестве LDAP-сервиса использовался OpenLDAP 2.3.30 (тоже из Debian-репозитария пакетов).
Первым делом следует добавить описание атрибута ftpQuota в nis-схему (файл /etc/ldap/schema/nis.schema).
attributetype ( 1.3.6.1.1.1.1.28 NAME 'ftpQuota'
DESC 'Quota FTP'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )

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 $ ftpQuota ) )
После этого перезапустить LDAP-сервис и удостовериться, что он нормально принял внесенные изменения
# /etc/init.d/slapd restart
Stopping OpenLDAP: slapd.
Starting OpenLDAP: slapd.
Если всё нормально, создать в LDAP-директории пользовательскую запись для ftp-доступа. Как пример:
dn: cn=ftpuser,ou=Users,o=My Company,c=LT
cn: ftpuser
ipNetworkNumber: 12
uid: ftpuser
objectClass: ipNetwork
objectClass: posixAccount
objectClass: top
userPassword: {MD5}ce4O7AJ89gFcMRd7PVaE7Q==
gidNumber: 65534
uidNumber: 106
homeDirectory: /var/home/ftpuser
ftpQuota: false,hard,10485760,0,0,0,0,0
Отредактировать основной конфигурационный файл ftp-сервиса - /etc/proftpd/proftpd.conf. Добавить строки
LDAPServer localhost
LDAPDNInfo "cn=searcher,o=My Company,c=LT" password
LDAPDoAuth on "ou=Sites,o=
My Company,c=LT" "(&(uid=%v) (objectclass=posixAccount))"
LDAPDefaultGID 106
LDAPDefaultUID 65534
LDAPForceDefaultGID off
LDAPForceDefaultUID off
LDAPDoQuotaLookups on "ou=Users,o=
My Company,c=LT" "(&(uid=%v)(objectclass=posixAccount))"
QuotaLimitTable ldap:
QuotaLock /tmp/quota
QuotaEngine on
QuotaDirectoryTally on
QuotaDisplayUnits Mb
QuotaLog "/var/log/proftpd/quota.log"
QuotaShowQuotas on
QuotaTallyTable file:/var/log/ftpquota.tally
LDAPDNInfo - необходим, если у вас закрыт доступ для анонимного пользователя
LDAPDoAuth - аутентификация, база для поиска пользователя (по uid)
LDAPDoQuotaLookups - включить поиск квот, база для поиска

Перед перезапуском ftp-сервиса, чтобы изменения вступили в силу, необходимо создать файл /var/log/ftpquota.tally, который будет меняться, храня информацию об использовании лимитов ftp-пользователями.
# ftpquota --create-table --type=tally --units=Mb --table-path=/var/log/ftpquota.tally
# /etc/init.d/proftpd restart
Stopping ftp server: proftpd.
Starting ftp server: proftpd.
После перезапуска можно проверить
# ftp localhost
Connected to localhost.
220 ProFTPD 1.3.0 Server (Debian) [127.0.0.1]
Name (localhost:root): ftpuser
331 Password required for ftpuser.
Password:
230 User ftpuser logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quote SITE QUOTA
200-The current quota for this session are [current/limit]:
200-Name: ftpuser
200-Quota Type: User
200-Per Session: False
200-Limit Type: Soft
200- Uploaded Mb: 4.08/10.00
200- Downloaded Mb: unlimited
200- Transferred Mb: unlimited
200- Uploaded files: unlimited
200- Downloaded files: unlimited
200- Transferred files: unlimited
200 Please contact root@server if these entries are inaccurate

Ссылки:
  1. ProFTPd + OpenLDAP + quota
  2. ProFTPD module mod_quotatab_ldap
  3. ProFTPd - List of Directives