SW RAID + LVM + Flashcache on Debian Jessie

Итак, поднимаем производительность дисковой системы за счет кеширования на SSD

Имеется тазик с Debian Jessie 8 и тремя дисками:
2х SATA 2 TB - SW RAID 1-го уровня (/dev/sdb, /dev/sdc)
1x SSD 240 Gb - не размеченный диск (/dev/sda)

Поверх рейда используется LVM2 для логических разделов. Читать дальше SW RAID + LVM + Flashcache on Debian Jessie

mdraid + mdadm + GPT+clone partitions

Итак, уже давно используются диски большого обьема. И вместо обычного MBR сейчас уже в ходу GPT.

Как известно, sfdisk не умеет работать с GPT, и в случае замены диска скопировать разделы с помощью этой утилиты уже не получится:
# sfdisk -s /dev/sda
WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util sfdisk doesn't support GPT. Use GNU Parted.

Что же делать ? Читать дальше mdraid + mdadm + GPT+clone partitions

proxmox: qm list — нулевой размер диска

После обновления версии Proxmox до v2.2 (pve-manager/2.2/e94e95e9)
qm list стал показывать нулевой размер диска виртуальных машин:

~# qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       101 vm1.linevps.net      running    1024               0.00 162695
       102 vm2.linevps.net      stopped    512                0.00 19795
       103 vm3.linevps.net      running    2048               0.00 55934
       ....
       116 vm14.linevps.net     running    2048               0.00 63224

Фикс простой: Читать дальше proxmox: qm list — нулевой размер диска

Аппаратный рейд и Smart мониторинг дисков

Ставим пакет smartmontools и настраиваем мониторинг дисков.

При использовании аппаратного рейд контроллера Adaptec 2405.

Физические диски в системе видны как /dev/sgX. Но это в том случае, если загружен модуль sg.
Если устройст /dev/sgX нет, пробуем подгрузить модуль sg:

modprobe sg

Проверяем:

ls -la /dev/sg*
crw------- 1 root root 21, 0 Jul  5 14:41 /dev/sg0
crw------- 1 root root 21, 1 Jul  5 14:41 /dev/sg1
crw------- 1 root root 21, 2 Jul  5 14:41 /dev/sg2
crw------- 1 root root 21, 3 Jul  5 14:41 /dev/sg3
crw------- 1 root root 21, 4 Jul  5 14:41 /dev/sg4

Все нормально, диски видны.
/dev/sg0 - это непосредственно сам контроллер, sg1-sg4 - наши диски.

Теперь настраиваем smartmontools. Читать дальше Аппаратный рейд и Smart мониторинг дисков

Couldn’t find PV pv1. Check your device.map

Виртуалка на базе KVM с lvm2 внутри.
В свое время для увеличения дискового пространства был добавлен второй диск.

И вот при очередном обновлении ядра вылезла ошибка:

Running update-initramfs.
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
Generating grub.cfg ...
/usr/sbin/grub-probe: error: Couldn't find PV pv1. Check your device.map.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.32-5-amd64.postinst line 799.
dpkg: error processing linux-image-2.6.32-5-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 2
Errors were encountered while processing:
 linux-image-2.6.32-5-amd64

При просмотре файла /boot/grub/device.map увидел, что там указан только один диск:

# cat /boot/grub/device.map
(hd0)   /dev/vda
#

После добавления второго диска в /boot/grub/device.map:

# cat /boot/grub/device.map
(hd0)   /dev/vda
(hd1)   /dev/vdb

обновление завершилось без ошибок:

# aptitude safe-upgrade
The following partially installed packages will be configured:
  linux-image-2.6.32-5-amd64
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up linux-image-2.6.32-5-amd64 (2.6.32-35) ...
Running depmod.
Running update-initramfs.
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-5-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-amd64
done

 

Что и требовалось.

Как проверить почтовый сервер на 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, а то мало ли откуда там файл вместо симлинка взялся.
После чего попытка взлететь с родного винта.

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

Обновляем 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"