Как проверить почтовый сервер на open relay

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

Есть довольно неплохой сервис, который тестирует на разного рода виды открытого релея.
Использовать его очень просто - необходимо подключиться telnet-ом (порт 23) с хоста, где запущен почтовый сервер, вот на этот адрес: relay-test.mail-abuse.org

Почти сразу после подключения начнется тестирование почтового сервера. Этот сервис подключится по SMTP обратно на хост, откуда инициировано telnet-подключение и будет пробовать различные варианты тестирования.
Результаты тестов отображаются тут же в telnet сессии.

Примерно так:

# telnet relay-test.mail-abuse.org
Trying 168.61.4.13...
Connected to Cygnus.mail-abuse.org.
Escape character is '^]'.
Connecting to 193.1x.x.x ...
< << 220 server1.host.net ESMTP Exim
>>> HELO cygnus.mail-abuse.org
< << 250 server1.host.net Hello cygnus.mail-abuse.org [168.61.4.13]
:Relay test: #Quote test
>>> mail from: 
< << 250 OK
>>> rcpt to: < "nobody@mail-abuse.org">
< << 501 <"nobody@mail-abuse.org">: recipient address must contain a domain
>>> rset
< << 250 Reset OK
:Relay test: #Test 1
>>> mail from: 
< << 250 OK
>>> rcpt to: 
< << 451 Temporary error, please try again later
>>> rset
< << 250 Reset OK
:Relay test: #Test 2
>>> mail from: 
< << 250 OK
>>> rcpt to: 
< << 451 Temporary error, please try again later
>>> rset
< << 250 Reset OK
:Relay test: #test 3
>>> mail from: 
< << 250 OK
>>> rcpt to: 
< << 451 Temporary error, please try again later
>>> rset
< << 250 Reset OK
:Relay test: #Test 4
>>> mail from: 
< << 501 : sender address must contain a domain
Connecting to 193.1x.x.x ...
< << 220 server1.host.net ESMTP Exim
>>> HELO cygnus.mail-abuse.org
< << 250 server1.host.net Hello cygnus.mail-abuse.org [168.61.4.13]
>>> mail from: 
< << 501 : sender address must contain a domain
>>> rset
< << 250 Reset OK
:Relay test: #Test 5
>>> mail from: <>
< << 250 OK
>>> rcpt to: 
< << 550 Relay not permitted
>>> rset
< << 250 Reset OK
:Relay test: #Test 6
>>> mail from: 
< << 250 OK
>>> rcpt to: 
< << 451 Temporary error, please try again later
>>> rset
< << 250 Reset OK
:Relay test: #Test 7
>>> mail from: 
< << 501 : domain literals not allowed
Connecting to 193.1x.x.x ...
< << 220 server1.host.net ESMTP Exim
>>> HELO cygnus.mail-abuse.org
< << 250 server1.host.net Hello cygnus.mail-abuse.org [168.61.4.13]
>>> mail from: 
< << 501 : domain literals not allowed
>>> rset
< << 250 Reset OK
:Relay test: #Test 8
>>> mail from: 
< << 250 OK
>>> rcpt to: 
< << 550 ERR. not allowed symbols in domain name
>>> rset
< << 250 Reset OK
:Relay test: #Test 9
>>> mail from: 
< << 250 OK
>>> rcpt to: 
< << 501 : domain literals not allowed
>>> rset
< << 250 Reset OK
:Relay test: #Test 10
>>> mail from: 
< << 250 OK
>>> rcpt to: < "nobody@mail-abuse.org">
< << 501 <"nobody@mail-abuse.org">: recipient address must contain a domain
>>> rset
< << 250 Reset OK
:Relay test: #Test 11
>>> mail from: 
< << 250 OK
>>> rcpt to: < "nobody%mail-abuse.org">
< << 501 <"nobody%mail-abuse.org">: recipient address must contain a domain
>>> rset
< << 250 Reset OK
:Relay test: #Test 12
>>> mail from: 
< << 501 : domain literals not allowed
Connecting to 193.1x.x.x ...
< << 220 server1.host.net ESMTP Exim
>>> HELO cygnus.mail-abuse.org
< << 250 server1.fs-host.net Hello cygnus.mail-abuse.org [168.61.4.13]
>>> mail from: 
< << 501 : domain literals not allowed
>>> rset
< << 250 Reset OK
:Relay test: #Test 13
>>> mail from: 
< << 250 OK
>>> rcpt to: < "nobody@mail-abuse.org"@[193.1x.x.x]>
< << 501 <"nobody@mail-abuse.org"@[193.1x.x.x]>: domain literals not allowed
>>> rset
< << 250 Reset OK
:Relay test: #Test 14
>>> mail from: 
< << 250 OK
>>> rcpt to: 
< << 501 : malformed address: @[193.1x.x.x]> may not follow >> rset
< << 250 Reset OK
:Relay test: #Test 15
>>> mail from: 
< << 501 Too many syntax or protocol errors
Connecting to 193.1x.x.x ...
<<< 220 server1.host.net ESMTP Exim
>>> HELO cygnus.mail-abuse.org
< << 250 server1.host.net Hello cygnus.mail-abuse.org [168.61.4.13]
>>> mail from: 
< << 501 : domain literals not allowed
>>> rset
< << 250 Reset OK
:Relay test: #Test 16
>>> mail from: 
< << 250 OK
>>> rcpt to: < @[193.1x.x.x]:nobody@mail-abuse.org>
< << 501 <@[193.1x.x.x]:nobody@mail-abuse.org>: domain literals not allowed
>>> rset
< << 250 Reset OK
:Relay test: #Test 17
>>> mail from: 
< << 501 : domain literals not allowed
Connecting to 193.1x.x.x ...
< << 220 server1.host.net ESMTP Exim
>>> HELO cygnus.mail-abuse.org
< << 250 server1.host.net Hello cygnus.mail-abuse.org [168.61.4.13]
>>> mail from: 
< << 501 : domain literals not allowed
>>> rset
< << 250 Reset OK
:Relay test: #test 18
>>> mail from: 
< << 250 OK
>>> rcpt to: 
< << 501 : domain literals not allowed
>>> rset
< << 250 Reset OK
:Relay test: #test 19
>>> mail from: 
< << 250 OK
>>> rcpt to: 
< << 550 Relay not permitted
>>> rset
< << 250 Reset OK
>>> QUIT
< << 221 server1.host.net closing connection
Tested host banner: 220 server1.host.net ESMTP Exim
System appeared to reject relay attempts
Connection closed by foreign host.

vsftpd: No /usr/sbin/vsftpd found running; none killed.

Итак, сервер: Debian Squeeze + ISPmanager + vsftpd.
При попытке перезапуска фтп демона пишет:

# /etc/init.d/vsftpd restart
Stopping FTP server: No /usr/sbin/vsftpd found running; none killed.

При этом init-скрипт пишет номер процесса:

# cat /var/run/vsftpd/vsftpd.pid
4634

Но пишет неправильный PID.
По всей видимости, при установке ftp из панели ISPmanager, в конфиг /etc/vsftpd.conf была добавлена строка:

background=YES

Соответственно, в pid файл записывался некорректный пид процесса. Это древний баг, оказывается
Собственно, про это же написано и в /usr/share/doc/vsftpd/README.Debian:

The included init script uses start-stop-daemon's --background option to run
vsftpd in the background.  If you have "background=yes" in your configuration,
the wrong PID will be recorded in /var/run/vsftpd/vsftpd.pid, and the init
script may fail to restart or stop vsftpd later.  Just remove "background=yes"
from vsftpd.conf.

Т.е. комментируем или убираем вообще строку "background=yes", после чего init-скрипт начинает нормально запускать/останавливать vsftpd

PS. Как все таки, иногда, полезно почитывать документацию 🙂

/lib/libc.so.6: version ‘GLIBC_2.11’ not found

Попал в руки сервер Debian Lenny 5.0.7 со следующими симптомами:
не добавляются юзеры,  часть сервисов отвалилась (exim и dovecot, в частности, остальное не проверял), а при попытке что-ли установить получаем:

dpkg: /lib/libc.so.6: version `GLIBC_2.8' not found (required by dpkg)
dpkg: /lib/libc.so.6: version `GLIBC_2.11' not found (required by dpkg)
E: Sub-process /usr/bin/dpkg returned an error code (1)

Смотрим почему:

# ldd -v /usr/bin/dpkg
/usr/bin/dpkg: /lib/libc.so.6: version `GLIBC_2.8' not found (required by /usr/bin/dpkg)
/usr/bin/dpkg: /lib/libc.so.6: version `GLIBC_2.11' not found (required by /usr/bin/dpkg)
linux-vdso.so.1 => (0x00007fffeccfd000)
libc.so.6 => /lib/libc.so.6 (0x00007f4a09e8d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4a0a1e0000)
Version information:
/usr/bin/dpkg:
libc.so.6 (GLIBC_2.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.8) => not found
libc.so.6 (GLIBC_2.3) => /lib/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6
libc.so.6 (GLIBC_2.11) => not found
libc.so.6 (GLIBC_2.2.5) => /lib/libc.so.6
/lib/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

Примечательный факт: /lib/libc.so.6 был не симлинком на libc-2.7.so, а был самостоятельным файлом.
Мдааа.. ))
На всякий случай попросил клиента заказать ipkvm и liveCD, а также показать /etc/apt/source.list (Откуда в lenny libc-2.11 ??).
После увиденного я вообще удивился как оно еще жило. Были подключены репы stable и sid (жуть !), да в придачу еще и от убунты репа. Apt-Pinning , естественно не использовался.

Пришлось хаком приводить систему в чувства.
Убрал лишние репы, скачал нормальный штатный deb пакет dpkg.
Так как установить его все равно не получится, подменил файл /usr/bin/dpkg на тот который из deb-пакета.
dpkg заработал, уже лучше.

Ну а дальше пошли уже мытарства по вычистке системы от всего лишнего и чуждого для этой версии. Вот тут как раз и пригодился ipkvm.
Загрузился в rescue режиме, поднял сеть, потом chroot /dev/sda1 (диск был разбит на root и swap)
Перелинковал libc.so.6 на libc-2.7.so ну и на всякий случай переустановил libc6, а то мало ли откуда там файл вместо симлинка взялся.
После чего попытка взлететь с родного винта.

Скажу, что на этот раз повезло и система поднялась удачно.
Правда, после этого было потрачено пару часов на вычистку и переустановку пакетов.
Но в итоге, все заработало как и должно работать, клиент доволен.
Ну и я доволен, что смог помочь )

[warn] [client x.x.x.x] mod_fcgid: HTTP request length 138329 (so far) exceeds MaxRequestLen (131072)

Установлен apache + mod_fcgi. При аплоаде файлов свыше 128к получаем 500-ю ошибку, а в логе пишется сабж.
Фикс простой. Открываем конфиг mod_fcgi и увеличиваем максимальный размер, например в 10 мб:

# nano /etc/apache2/mods-enabled/fcgid.conf
<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  FcgidConnectTimeout 20
  MaxRequestLen 10485760
</IfModule>

после релоада апачи - все работает.

/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"

VirtualBox и warning in file ‘/var/lib/dpkg/available’ near line 53968 package ‘virtualbox-3.0’

При очередном обновлении "сквизи" вылезли варнинги

warning, in file '/var/lib/dpkg/available' near line 12159 package 'virtualbox':
error in Version string '1.6.6-35336_Debian_lenny': invalid character in revision number
.....

Если коротко, то это баг. Подробности описаны на bugs.debian.org

Лечится ручной правкой:

sed -i -e '/^Version:/ s/[^-a-zA-Z0-9:.+~ ]/+invalid+char+removed+by+dpkg+/g' /var/lib/dpkg/available

(Взято с баг-трекера)

Как закрыть 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 или другим сервисам.

Свежие версии 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

mysql init-скрипт для directadmin

Мне крайне не нравится дефолтовый mysql инит скрипт, который идет в поставке Directadmin, потому как работает он крайне некорректно. Взял я штатный дебиановский инит-скрипт и приспособил его для работы с mysqld, который поставляется с панелью Директадмин.
Работает на все 100%, как и полагается в Дебиане.

Сам скрипт качаем тут

Выслушаю любые предложения/пожелания относительно данной модификации.

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

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