Обновляем Exim для Directadmin

Все еще используете ексим 4.69 ?
Пора обновить версию.
Можно, конечно, собрать из исходников (как описано тут), а можно просто поставить уже готовый пакет.
Скачиваем и ставим пакет с сайта directadmin.
Для Debian:

# cd /usr/local/directadmin/custombuild
# wget http://files.directadmin.com/services/debian_5.0/da_exim-4.72.deb
# dpkg -i da_exim-4.72.deb

Для Debian 64bit:

http://files.directadmin.com/services/debian_5.0_64/da_exim-4.72.deb

Для CentOS:

# cd /usr/local/directadmin/custombuild
# wget http://files.directadmin.com/services/es_5.0/da_exim-4.72-2.i386.rpm
# rpm -Uvh da_exim-4.72-2.i386.rpm

Возможно понадобится доставить отсутствующие библиотеки (libperl5.10, db4 и т.д.).
Если отвалился TLS – выставить нужные права на /etc/exim.key (chown mail: /etc/exim.key)

Еще можно использовать dkim, достаточно поправить exim.conf и добавить проверки:

acl_smtp_dkim    = acl_check_dkim
.....
.....
###############################
#       ACL check_dkim        #
###############################
acl_check_dkim:

  defer dkim_status = fail
     logwrite   = DKIM test failed: $dkim_verify_reason
     message    = DKIM test failed: $dkim_verify_reason
     add_header = X-DKIM-FAIL: DKIM test failed: \
                  (address=$sender_address domain=$dkim_cur_signer), \
                  signature is bad.

  warn  dkim_status = invalid
     add_header = :at_start:Authentication-Results: \
                  $dkim_cur_signer ($dkim_verify_status); $dkim_verify_reason
     logwrite   = DKIM test passed (address=$sender_address domain=$dkim_cur_signer), \
                  but signature is invalid.

  accept dkim_status = pass
     add_header = :at_start:Authentication-Results: dkim=$dkim_verify_status, \
                  header.i=@$dkim_cur_signer
     logwrite   = DKIM test passed (address=$sender_address domain=$dkim_cur_signer), \
                  good signature.

  accept

Теперь ексим будет проверять цифровую подпись (если она есть) для входящих писем.
Для проверки можно отправить письмо с гугло- или mail.ru ящика. При получении письма в логе можно увидеть результат проверки:

2010-12-27 09:31:21 1PXxxx-000xxx-PR DKIM: d=gmail.com s=gamma c=relaxed/relaxed a=rsa-sha256 [verification succeeded]
2010-12-27 09:31:21 1PXxxx-000xxx-PR DKIM test passed (address=user@gmail.com domain=gmail.com), good signature.
...
2010-12-27 12:01:26 xxxx-xxx-FX DKIM: d=mail.ru s=mail c=relaxed/relaxed a=rsa-sha256 [verification succeeded]
2010-12-27 12:01:26 xxxx-xxx-FX DKIM test passed (address=user@mail.ru domain=mail.ru), good signature.

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

/dev/null: Permission denied

Попался тазик, где происходит сабж.
Клиент чудным образом выставил на /dev/null левые права:

# ls -la /dev/null
-rw-r--r-- 1 root munin 38 2010-12-23 21:01 /dev/null

Фикс простой – получаем root-овые права и чиним:

# rm /dev/null && mknod -m 0666 /dev/null c 1 3
# ls -la /dev/null
crw-rw-rw- 1 root root 1, 3 2010-12-24 01:53 /dev/null

Вот теперь правильно и все работает.

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

# grep null /etc/udev/rules.d/*permissions.rules 
KERNEL=="null",         MODE="0666"

Как закрыть sshd без iptables

Если лень возиться с iptables, то ограничить доступ к ssh (и не только) можно и без iptables.

Для этого достаточно дописать несколько строк в файлы
/etc/hosts.allow
/etc/hosts.deny

Например, открываем доступ к sshd с ip 192.168.1.12 и 192.168.250.250, а для остальных доступ к sshd будет закрыт.
Добавляем в файл /etc/hosts.allow строку, где указаны разрешенные ip:

sshd: 192.168.1.12, 192.168.250.250

А в файле /etc/hosts.deny закрываем доступ всем, кроме разрешенных:

sshd: ALL

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

# ssh 192.168.0.1
ssh_exchange_identification: Connection closed by remote host

А если подключаться с разрешенного, то увидим приглашение ssh.

# ssh 192.168.0.1
user@host’s password:

Вот такой простой способ 🙂
Таким же способом, например, можно разрешить/запретить коннекты с mysqld, nfs или другим сервисам.

apache и mod_ruid – исполнение скриптов от имени пользователя

При использовании mod_php все скрипты исполняются от имени веб-сервера (www-data, apache, etc), из-за чего довольно трудно определить чем занят тот или иной процесс и кто делает нагрузку.
Да, можно использовать suPHP, fastCGI и т.д. Но в таком случае можно забыть про выставление параметров в .htaccess, потеря производительности, невозможность использования mod_php и другие фишки.
Можно использовать peruser или mpm-itk. В первом случае будут плодиться процессы, каждый из которых будет кушать память, что не особо хорошо.
Во втором случае – нужно пересобирать апач.

Как же быть ?
Как вариант – использовать модуль mod_ruid2. Почему именно mod_ruid ? Одна из причин – модуль поддерживается и развивается. Последний коммит в svn сделан неделю назад (от даты данного поста), это вселяет определенную надежду, что модуль и дальше будет развиваться, а найденные баги будут исправляться. mod_ruid не требует пересборки ни apache ни чего либо еще, будут нормально работать акселераторы (eAccelerator, xcache).

Read more apache и mod_ruid – исполнение скриптов от имени пользователя

Directadmin+nginx полный автомат

Доброго всем LOCALTIME ! 🙂

Решил поделиться с общественностью своими скриптами для связки directadmin и nginx.

В свое время для снижения нагрузки на apache было решено поставить nginx. После некоторого гугления была сделана первая попытка связать панель и nginx. На тот момент скрипт умел совсем немного – только создавать и удалять конфигурационные файлы виртуальных хостов. Он не умел работать ни с поддоменами, ни с алиасами, не умел и переименовывать конфиги доменов.

Затем последовала вторая попытка. Этот скрипт уже был немного “умнее”. Он умел создавать, удалять не только домены, но и поддомены. Однако, после того, как количество вирт. хостов выросло и управляться с большим количеством доменов стало как-то трудно, было решено полностью переписать всю схему работы связки directadmin и nginx. Все домены/поддомены/алиасы будут описываться в map-файле, а в конфиге будут использоваться соответствующие переменные, тем самым будет использоваться всего один небольшой общий конфиг, в котором и описывается виртуальный хост.
“Особые” домены описываются в отдельных конфигурационных файлах.
Кроме того, логи для всех вирт. хостов будет писать nginx, освободим нашего монстра apache от этой обязанности и оставим ему писать только error_log. Что положительно скажется на производительности.

Сказано – сделано.
По моей просьбе и некоторому подобию ТЗ, мой друг Александр Русских написал совсем новый и удобный скрипт, который и будет использоваться в этой статье.
Еще одна моя просьба была направлена Кириллу Коринскому, который написал небольшой патч для nginx. Данный патч выдает 503 ошибку, если уровень load average системы выше заданного в конфиге значения. Да, это грубо, но зато может уберечь сервер от ухода в глубокий своп. Поэтому уровень LA необходимо указывать заведомо высокий.

Итак, поехали.

Часть первая (Если nginx уже установлен – смотрим вторую часть)
У нас в распоряжении сервер с установленной панелькой DirectAdmin (отличная, кстати, панель). Чтобы не делать из системы свалку, nginx будет ставиться из репозитария.

Добавляем репозитарий в список, импортируем ключи и ставим nginx:

# echo "deb http://ftp2.debian.org.ua/debian-dou/ lenny main" >> /etc/apt/sources.list

# gpg --keyserver keys.gnupg.net --recv-keys 0A3D4789
gpg: requesting key 0A3D4789 from hkp server keys.gnupg.net
gpg: key 0A3D4789: public key "Debian.org.ua Custom Repository " imported
gpg: Total number processed: 1
gpg:               imported: 1

# gpg --armor --export 0A3D4789 | apt-key add -
OK

# aptitude update
# aptitude install nginx

Стоит заметить, что в этот пакет включено два неофициальных патча, которые описаны в блоге автора

После установки nginx не запустится – это нормально, так как на 80-м порту все еще работает apache.
Дальше будем приводить в порядок конфигурационные файлы apache и nginx.
Read more Directadmin+nginx полный автомат

Свежие версии mysql/php для Lenny

На сервере вполне уютно живет Debian Lenny, однако хочется использовать более свежие версии софта, того же MySQL или PHP (речь идет о ветке 5.2). А учитывая, что в репозитарии ну очень уж древние версии, в бекпортах толком ничего нет, то возникает вопрос – как быть ?
Ставить из тестинга или собирать из сорцов как-то лениво, да 🙂
Однако есть люди, которым не лениво, за что им можно сказать “спасибо”.

Итак, подключаем репозитарий dotdeb.org и ставим свежие версии нужного нам софта.

deb http://packages.dotdeb.org  lenny all
deb-src http://packages.dotdeb.org lenny all

Импортируем ключики:

gpg --keyserver keys.gnupg.net --recv-key 89DF5277
gpg -a --export 89DF5277 | sudo apt-key add -

Обновляем списки пакетов

aptitude update

Теперь можно обновить устаревшие версии mysql и php на более свежие:

aptitude safe-upgrade

Если необходима версия php 5.3, тогда в source.list необходимо добавить:

deb http://php53.dotdeb.org lenny all
deb-src http://php53.dotdeb.org lenny all

В итоге получим мускуля версии 5.1.48-0.dotdeb.0-log
И php версии 5.2.13 или 5.3.2

Memcached master-to-master replication

Имеем два сервера (fail-over), на которых крутятся несколько веб сайтов. Естественно, оба mysql-сервера работают по схеме master-to-master replication. Все вроде бы хорошо, файлы автоматически обновляются раз в 15 минут (rsync), базы также (master-to-master replication). При падении одного из серверов – второй вполне нормально справляется. Для снижения нагрузки файлы сессий стали писать в мемкашед-сервер.
И вот тут столкнулись с проблемой потери сессий в случае сбоя одного из серверов.

Проблему решили благодаря использованию патча для мемкашед сервера – repcached
repcached – add data replication feature to memcached 1.2.x
Этот патч позволяет получить мульти-мастер репликации,
также поддерживается асинхронный режим репликаций,
поддерживаются все memcached команды: set, add, delete, incr/decr, flush_all, cas

Качаем уже патченые исходники и распаковываем.
Read more Memcached master-to-master replication

Восстановление software raid после сбоя

На днях “выпал” из софтварного raid1 один из разделов.

# cat /proc/mdstat
Personalities : [raid1] md2 : active raid1 sdb3[1] 34178176 blocks [2/1] [_U]

md1 : active raid1 sda2[0] sdb2[1]
      19534976 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      240832 blocks [2/2] [UU]

По данным smart-а диск в порядке, в логах ничего не замечено.

Пробуем восстановить. Помечаем диск как сбойный:

# mdadm /dev/md2 -f /dev/sda3

Удаляем его из рейда

# mdadm /dev/md2 -r /dev/sda3

И пробуем его добавить обратно

# mdadm /dev/md2 -a /dev/sda3
mdadm: re-added /dev/sda3

Статус раздела после добавления обратно в массив:

# mdadm --detail /dev/md2
/dev/md2:
        Version : 00.90
  Creation Time : Fri Mar 19 18:53:17 2010
     Raid Level : raid1
     Array Size : 34178176 (32.59 GiB 35.00 GB)
  Used Dev Size : 34178176 (32.59 GiB 35.00 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 2
    Persistence : Superblock is persistent

    Update Time : Sat May 15 01:42:31 2010
          State : active, degraded, recovering
 Active Devices : 1 Working Devices : 2 Failed Devices : 0 Spare Devices : 1 Rebuild Status : 7% complete

           UUID : d841d3cd:6e2537ed:02c08aff:db0fd513
         Events : 0.3905

    Number   Major   Minor   RaidDevice State
 2 8 4 0 spare rebuilding /dev/sda3
       1       8       19        1      active sync   /dev/sdb3

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

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

Помечаем все разделы сбойного диска как fail и удаляем их из рейда.


mdadm /dev/md0 -f /dev/sda1
mdadm /dev/md1 -f /dev/sda2
mdadm /dev/md2 -f /dev/sda3
mdadm /dev/md0 -r /dev/sda1
mdadm /dev/md1 -r /dev/sda2
mdadm /dev/md2 -r /dev/sda3

меняем диск на новый, стартуем.
Подготавливаем диск для добавления в рейд.

Копируем разметку с живого диска (sdb) на новый (sda)

# sfdisk -d /dev/sdb | sfdisk -f /dev/sda

Проверим, что оба диска имеют одинаковую разметку

# fdisk -l

Теперь добавим все разделы в массив рейда

# mdadm -a /dev/md0 /dev/sda1
# mdadm -a /dev/md1 /dev/sda2
# mdadm -a /dev/md2 /dev/sda3

Если сервер нагружен, можно указать максимальную скорость синхронизации дисков (указывается в кб/сек), это немного понизит нагрузку:

echo 3000 >/sys/block/md1/md/sync_speed_max

Не забываем установить grub на новый диск:

# grub
grub> root (hd0,1) # hd0 - указываем, что надо использовать диск sda, 1 - номер /boot раздела
grub> setup (hd0) # устанавливаем grub в MBR нового диска
grub> quit

Проверить текущий статус raid-массива можно так:

# cat /proc/mdstat

В принципе все … ну или как-то так 🙂

Как добавить XSL без пересборки php на сервере с DirectAdmin

Если после сборки остался каталог с исходниками php, то включить модуль довольно просто:

# cd /usr/local/directadmin/custombuild
# cd php-5.2.12/ext/xsl
# phpize
# ./configure
# make && make install

после чего, модуль xsl.so будет находится в /usr/local/lib/php/extensions/no-debug-non-zts-20060613

Добавляем в php.ini

extension=xsl.so

И напоследок делаем “мягкий” рестарт апача:

apachectl graceful

Exim + Greylist + Directadmin

В предыдущей статье я описывал как ставил грейлист  на тазик с панелью directAdmin на CentOS-е.

Нашел время написать как я ставил greylist  под Debian
Итак, имеем: Debian Lenny, DirectAdmin, exim из комплекта панели. Потребуется установить демон greylistd и после чуть подправить конфиг ексима.
Приступаем:

aptitude update
aptitude install  greylistd

Теперь необходимо поправить конфиг ексима. Ищем первый accept  в acl_smtp_rcpt и добавляем перед ним:
[eng]Now need to change exim.conf. Find first ‘accept’ in ‘acl_smtp_rcpt’ and add before:

# GreyListing
    defer   message    = Sender verification for $sender_host_address in progress. Please try later.
        log_message    = greylisted.
        !senders       = :
        !hosts         = : +relay_hosts : +whitelist_hosts : +whitelist_hosts_ip
        !authenticated = *
        !domains       = : ${if exists {/etc/greylistd/skip-greylist}\
                                 {/etc/greylistd/skip-greylist}{}}
        domains        = +local_domains : +relay_domains
        verify         = recipient/callout=20s,use_sender,defer_ok
        condition      = ${readsocket{/var/run/greylistd/socket}\
                            {--grey \
                                  $sender_host_address \
                                  $sender_address \
                                  @$domain}\
                              {5s}{}{false}}

    deny   message = $sender_host_address is blacklisted
        log_message = blacklisted.
        !senders       = :
        !authenticated = *
        verify         = recipient/callout=20s,use_sender,defer_ok
        condition      = ${readsocket{/var/run/greylistd/socket}\
                                 {--black \
                                  $sender_host_address \
                                  $sender_address \
                                  $local_part@$domain}\
                                 {5s}{}{false}}

Далее, ищем в ACL acl_smtp_data первый accept и вставляем перед ним:
Next, find first ‘accept’ in ACL acl_smtp_data and add before this code:

     defer
        message        = Sender verification for $sender_host_address in progress. Please try later.
        log_message    = greylisted.
        senders        = :
        !hosts         = : +relay_hosts : +whitelist_hosts : +whitelist_hosts_ip
        !authenticated = *
        condition      = ${readsocket{/var/run/greylistd/socket}\
                                 {--grey \
                                  $sender_host_address \
                                  $recipients}\
                                  {5s}{}{false}}

    deny
        message = $sender_host_address is blacklisted from delivering \
                     mail from <$sender_address> to <$recipients>.
        log_message   = blacklisted.
        !senders       = :
        !authenticated = *
        condition      = ${readsocket{/var/run/greylistd/socket}\
                                 {--black \
                                  $sender_host_address \
                                  $recipients}\
                                  {5s}{}{false}}

В файле /etc/greylistd/skip-greylist можно прописать домены (локальные) для которых не включать грейлистинг. Формат файла простой – один домен на строчку.
Вот собственно все.

In file /etc/greylistd/skip-greylist you can write whitelisted domains. One domain per line.

Если будет свободное время, напишу как прикрутить DSPAM  + Exim + Directadmin