VestaCP – vesta-nginx failed with “libc.so.6: version `GLIBC_2.14′ not found”

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

/usr/local/vesta/nginx/sbin/vesta-nginx: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/local/vesta/nginx/sbin/vesta-nginx)

/usr/local/vesta/php/sbin/vesta-php: /usr/lib/x86_64-linux-gnu/libxml2.so.2: version `LIBXML2_2.9.0' not found (required by /usr/local/vesta/php/sbin/vesta-php)

/usr/local/vesta/php/sbin/vesta-php: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/local/vesta/php/sbin/vesta-php)

Фикс простой и написан на форуме Весты:

# apt-get update && apt-get –reinstall install vesta-nginx vesta-php

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.

Что же делать ? Read more 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 

Фикс простой: Read more 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. Read more Аппаратный рейд и Smart мониторинг дисков

CPU load 100%

Заметил, что с 1 июля 2012г на одной из виртуалок cpu стал загружен на все 100%.
strace на процесс, кушающий весь проц не дало результата особого

# strace -p 27653
Process 27653 attached - interrupt to quit
futex(0x7f022b74a9d0, FUTEX_WAIT, 27655, NULL

на этом все, но заставило погуглить подобное поведение у других. В процессе поиска выявилось, что виной всему баг в ядре linux [пруф], связанный с добавлением “60-й” секунды.
Шаманство в виде остановки/запуска демона NTP, установкой руками даты и т.д. не привели к успеху, к сожалению…
Пришлось ребутить клиенту виртуалку. После физического ребута нагрузка на процессор стала нормальной.

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

 

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

Домены *.ua и whois

с 15 мая сервер whois.net.ua, который использовался для whois-а украинских доменов, теперь выдает информацию только о доменах *.net.ua (что в принципе, как бы логично).
В этой связи, при попытке проверить информацию о любом украинском домене можно видеть такой текст:

# whois test.ks.ua

% This server contains information for .net.ua only.
% Please, refer to whois.ua for information on other .ua subdomains.

Отныне, официальным адресом whois-сервера по доменам .UA является WHOIS.UA

А пока пакет whois не обновился (whois-сервера прописаны непосредственно в коде), проверить домены можно так:
whois -h whois.ua имя_домена.ua

В результате получим ожидаемый ответ:

# whois -h whois.ua test.ks.ua
% This is the Ukrainian Whois query server #I.
% Rights restricted by copyright.
%

% % .UA whois
% Domain Record:
% =============
domain:     test.ks.ua
admin-c:    SP999-UANIC
tech-c:     SP999-UANIC
status:     OK-UNTIL 20120309140546
nserver:    ns1.linevps.net
nserver:    ns2.linevps.net
nserver:    ns3.linevps.net
created:    0-UANIC 20090309140547
changed:    UARR169-UANIC 20110514194558
source:     UANIC

apache и htaccess

Итак, дано: сервер с директадмином и стандартными настройками apache.
До определенного момента все прекрасно работало и “вдруг” перестало.

Симптомы:
у одного из юзеров перестали выполняться cgi скрипты, на многих доменах вместо сайта – 404 ошибка или 403.
В корне доменов (domain/public_html/…) файла htaccess нет, но такое впечатление, что делается переопределение с index.php на index.html и другие манипуляции с типами.
Конфиги апачи правильные, ничего подозительного нет. У пользователя в аккаунте более 300 доменов, подумалось, может какие грабли у апачи при таком количестве доменов на одном пользователе.
Оказалось что проблема совсем в другом и достаточно тривиальна.

Фикс проблемы.
Выяснил, что в корне хомки (/home/username/) лежит файлик .htaccess, где все и реврайтилось.
После переименования /home/username/.htaccess все заработало как прежде.

Дополнение.
Точно также себя ведет вебсервер под ISPmanager-ом.

Вывод.
Не создавайте .htaccess выше public_html, т.е. выше корня сайта.
По крайней мере это касается серверов с directadmin-ом

Установка IPSET, TARPIT и т.д. на Squeeze

Честно скопи-пастил отсюда 🙂

# aptitude update && aptitude install module-assistant xtables-addons-source
# m-a prepare
# m-a auto-install xtables-addons-source
# depmod -a

Новые таржеты для iptables:

  • CHAOS: randomly use REJECT, DELUDE or TARPIT targets.
    This will fool network scanners by returning random results
  • DELUDE: always reply to a SYN by a SYN-ACK. This will fool TCP half-open discovery
  • DHCPADDR: replace a MAC address from and to a VMware host
  • IPMARK: mark a packet, based on its IP address
  • LOGMARK: log packet and mark to syslog
  • SYSRQ: trigger a sysreq over the network (sending a saK over the network looks like a real funny ida
  • TARPIT: try to slow down (or DoS) remote host by capturing the session and holding it for a long time, using a 0-bytes TCP window. Run that on port 25 if you have no mail server to slow down spammers 😉

Новые совпадения (matches) для iptables:
condition: match on boolean value stored in /proc/net/nf_condition/name
dhcpaddr: match the DHCP Client Host address in a DHCP message
fuzzy: match a rate limit based on a fuzzy logic controller
geoip: match a packet by its source or destination country
ipp2p: match (certain) p2p protocols
quota2: named counters
pknock: port knock
…. и другие.

У себя собрал, но запустить в работу еще руки не дошли.