W: Ошибка GPG: http://www.tataranovich.com wheezy Release

Если при apt-get update у вас произошла подобная ошибка

W: Ошибка GPG: http://www.tataranovich.com wheezy Release: Следующие подписи неверные: KEYEXPIRED 1379680799

то это говорит о моей лени (все никак не дойдут руки оформить ключ в виде пакета) и о том, что вам нужно обновить данные ключа в базе доверия APT. Делается это так

$ sudo apt-key adv --keyserver pgp.mit.edu --refresh-keys 2EE7EF82

После этого нужно снова запустить apt-get update

Как НЕ нужно делать logrotate

В одном из OpenVZ контейнеров постоянно дох munin-node, причем записи в логе говорили о том, что ему "помогли".

2013/10/26-04:02:02 Server closing!
2013/10/26-04:02:02 HUP'ing server
Can't exec "munin-node": Нет такого файла или каталога at /usr/share/perl5/Net/Server.pm line 1162.
shutdown() on closed socket GEN0 at /usr/lib/perl/5.10/IO/Socket.pm line 294.

В контейнере стоит Debian Squeeze и аналогичные контейнеры в сети еще есть, но постоянно дохнет только один. Судя по дате это что-то из набора cron.daily, который как правило стартует в 4:00, но в контейнере /etc/logrotate.d/munin-node, не шлет HUP после ротирования. Ради интереса стартанул весь logrotate

logrotate -f /etc/logrotate.conf

После завершения проверил munin-node - все в порядке. И тут меня осенило, ведь на сервере, который hardware node у OpenVZ тоже стоит munin-node. Разница лишь в том, что на hardware node установлен ALTLinux, а не Debian.

Иду смотреть /etc/logrotate.d/munin-node на ноде

/var/log/munin/munin-node.log {
        create 640 _munin root
        daily
        postrotate
                killall -q -HUP munin-node
        endscript
}

Редиски! Они шлют HUP всем процессам, а не только тому, который указан в PID-файле. Луч поноса QA команде ALTLinux и создателю этого костыля в частности.

Заменил вызов killall на /etc/init.d/munin-node reload - теперь и лог ротируется и в контейнере не дохнет.

Сломались отчёты sysstat: Invalid system activity file: /var/log/sysstat//sa24

Если вам на почту пришло письмо вроде этого

/etc/cron.daily/sysstat:
Invalid system activity file: /var/log/sysstat//sa24

то скорее всего у вас изменилась конфигурация железа (в моём случае проапгрейдили сервер и ядер процессора стало больше). Баг известный и исправить его можно так:

# rm /var/log/sysstat/sa`date +'%d'`
# service sysstat start

Для уверенности через минут 10 проверьте результат, выполнив

# sar -A

Три почивших диска за последних три месяца

Я не питаю иллюзий по поводу надёжности SATA дисков, но такое на моей памяти впервые. В течении трёх месяцев, один за другим умерло три диска Seagate NS серии (один 2TB и два 750GB).

Сейчас как раз переношу данные с последнего мертвеца. Прошлые ограничивались парой Offline Uncorrectable в S.M.A.R.T., но сегодняшний покойничек дал дуба эффектно

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x64
ata1.00: cmd 25/00:08:c3:74:25/00:00:52:00:00/e0 tag 0 dma 4096 in
         res 51/40:00:ca:74:25/40:00:52:00:00/00 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/133
ata1.01: configured for UDMA/133
sd 0:0:0:0: Unhandled sense code
sd 0:0:0:0: SCSI error: return code = 0x08000002
Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sda: Current [descriptor]: sense key: Medium Error
    Add. Sense: Unrecovered read error - auto reallocate failed

Descriptor sense data with sense descriptors (in hex):
        72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
        52 25 74 ca
EXT3-fs error (device sda3): ext3_get_inode_loc: <6>ata1: EH complete
unable to read inode block - inode=171738553, block=171737135

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

The following warning/error was logged by the smartd daemon:

Device: /dev/sda, FAILED SMART self-check. BACK UP DATA NOW!

For details see host's SYSLOG.

Дальше по уже накатанной дорожке.

Dell OpenManage installation on CentOS

Complete guide can be found here. If you want to skip reading you can execute following commands:

# wget -q -O - http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash
# yum install srvadmin-all

After packages installation you should start OMSA services and add them to autostart

# /opt/dell/srvadmin/sbin/srvadmin-services.sh start
# /opt/dell/srvadmin/sbin/srvadmin-services.sh enable

To enter OMSA you should navigate to https://your-server-ip:1311/ in your browser (login as user root and use related password). You may need to enable incoming connections to 1311/TCP port in your firewall.

# /sbin/iptables -A INPUT -p tcp --dport 1311 -j ACCEPT

Привел в порядок репозиторий

Вчера до меня довели просьбу пользователя, который просил добавить поддержку свежих релизов Ubuntu в сборочную среду пакетов для Midnight Commander и соответственно в свой репозиторий. Похоже это знак свыше, чтобы наконец навести там порядок.

Сейчас бинарные пакеты для Mignight Commander (release и nightly) собираются для Debian Squeeze/Wheezy/Jessie/Sid и Ubuntu Lucid/Precise/Quantal/Raring/Saucy (i386 и amd64).

Из репозитория окончательно удалены ветки для Debian Lenny и Ubuntu Natty/Maverick/Oneiric. Заодно удалены устаревшие версии wine-unstable и стабильного midnight commander.

Расчет критических значений Load Average для системы мониторинга сервера

Сегодня подкручивал настройки Nagios и решил добавить статью по расчету значений лимитов load average для различных конфигураций серверов. Чтобы понимать суть load average я советую прочесть эту статью.

Поскольку лимиты load average зависят от количества доступных ядер процессора, то у различных серверов будут значения будут различаться. Наиболее распространенные варианты конфигурации процессоров:

• 1 физическое ядро
• 2 физических ядра
• 2 физических ядра + hyperthreading (4 виртуальных ядра)
• 4 физических ядра
• 4 физических ядра + hyperthreading (8 виртуальных ядер)

Я не буду рассматривать варианты дальше, поскольку там все аналогично. Для себя я определил следующие лимиты, которые по моему мнению не приводят к заметному снижению производительности сервера относительно процессора.

State/Load Average	1 min	5 min	15 min
Warning	CPU cores * 2	CPU cores * 1.5	CPU cores * 1.25
Critical	CPU cores * 4	CPU cores * 2	CPU cores * 1.5

Поскольку ядро процессора, которое эмулируется hyperthreading, не является полноценным, то такие ядра я исключаю из расчета. Чтобы узнать свое количество физических ядер вы можете выполнить этот скрипт

#!/bin/bash
if [ `grep -c processor /proc/cpuinfo` != 1 ]; then
    grep 'core id' /proc/cpuinfo | sort | uniq | wc -l
else
    echo 1
fi

Готовые значения лимитов для плагина check_load из состава Nagios.

• Single core: check_load -w 2,1.5,1.25 -c 4,2,1.5
• Dual core: check_load -w 4,3,2.5 -c 8,4,3
• Quad core: check_load -w 8,6,5 -c 16,8,6