"The server responds but can't determine if things goes well" в aNag

На смартфоне смотрю статус Nagios через aNag (неофициальный клиент для Icinga, Thruk, Naemon и Nagios под Android). Недавно потребовалось подтвердить (acknowledge) оповещение чтобы оно не уведомляло при каждой проверке. В ответ на привычный свайп влево aNag ответил "The server responds but can't determine if things goes well". При этом никакого подтверждения в самом Nagios не произошло. Аналогично вела себя и принудительная проверка сервиса (reschedule check).

Проверил что установлена последняя версия aNag v6.4.0, нашёл на сайте разработчика ссылку в Discord и отправился просить помощи. В процессе обсуждения выяснилось что проблема на стороне aNag, который не переваривает недавнее исправление в Nagios, которое Debian выпустил в конце мая.

nagios4 (4.4.6-4.1+deb13u1) trixie-security; urgency=high

  * CSRF Security Fix backported from upstream 4.5.12 commit
    e5ed38e53a5d65721520c7c67be0746d63da28cb (cgi/cmd.c and
    html/index.php.in).  See
    https://www.nagios.com/security-disclosures/nagios-core/4-5-12/
    for the upstream disclosure.  No CVE assigned.
    Closes: #1136340.
  * This can break third party integrations that POST to cmd.cgi
    without first setting NagFormId (the CSRF check fails).  Upstream
    PR 1055 has been added as a workaround - see README.Debian.

 -- Russell Stuart <russell-debian@stuart.id.au>  Fri, 22 May 2026 20:45:00 +1000 

После нескольких итераций исправлений разработчик добился чтобы aNag правильно обрабатывал операции acknowledge и recheck. Исправленная версия aNag v6.4.1 уже опубликована в Play Market.

Исправление nagios-nrpe-server в Debian 13

Дошли руки поправить старую проблему с nagios-nrpe-server, которая появилась после обновления серверов на Debian 13 и воспроизводилась после каждой перезагрузки сервера. Последнее время обновления ядра выходят довольно часто и надоело перезагружать этот сервис руками.

DISK CRITICAL - /run/credentials/getty@tty1.service is not accessible: No such file or directory

В Debian 13 используется версия systemd в которой добавили ImportCredentials из systemd-creds для getty. В сочетании с опцией privateTmp=true для nagios-nrpe-server.service это приводит к такой ошибке.

В самом сервисе есть указание запускаться перед getty@tty1.service, но в моём случае это не даёт нужного эффекта. Чтобы ошибка не возникала при каждой перезагрузке достаточно выключить privateTmp для nagios-nrpe-server.service.

$ sudo systemctl edit nagios-nrpe-server.service

И переопределить значение privateTmp с true на false. Нужно добавить нужные строки до строки "### Edits below this comment will be discarded", примерно так:

Проверка подключения по IPv6 в Nagios

Несколько лет использовал www.google.com в Nagios чтобы проверять "связность" своих серверов с внешним миром по IPv6. На позапрошлой неделе сервера попали в "бан" и проверка перестала работать.

Поскольку www.google.com все же не предназначен для таких проверок, то переделал проверку на использование msftconnecttest.com. Для IPv6 вместо www.msftconnecttest.com нужно использовать ipv6.msftconnecttest.com.

Этот сервис использует Windows чтобы проверить подключение к Internet. Если при скачивании http://ipv6.msftconnecttest.com/connecttest.txt вы получаете строку "Microsoft Connect Test", то все IPv6 работает без ограничений.

$ /usr/lib/nagios/plugins/check_http -6 -H ipv6.msftconnecttest.com -u /connecttest.txt -s 'Microsoft Connect Test'
HTTP OK: HTTP/1.1 200 OK - 537 bytes in 0.012 second response time |time=0.012383s;;;0.000000;10.000000 size=537B;;;0

Расчет критических значений 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

TinyCA: Проверка срока действия сертификатов

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

Чтобы узнавать об этом заранее, я решил набросать небольшой скрипт, который проходится по хранилищу сертификатов и проверяет их "годность" (TinyCA хранит сертификаты в каталоге ~/.TinyCA/CAName/certs).

Выходит, что для проверки достаточно пройтись по всем ~/.TinyCA/CAName/certs/*.pem файлам. Нагуглил скрипт на perl, который проверяет срок действия сертификата. Скрипт завершается с кодом 2, если сертификат просрочен, с кодом 1, если истечет в течении двух недель и с нулевым, если с сертификатом все в порядке.

Далее дописал обвязку для крона, который проверяет сертификаты из ~/.TinyCA/CAName/certs

check-certificate-expire - проверка единичного сертификата

#!/bin/sh

openssl_get_CN_from_file() {
  if [ ! -f "$1" ]; then
    echo "Unable to find file: $1"
    return 1
  fi

  X509_CN=`openssl x509 -in "$1" -noout -subject | perl -pi -e 's/^.*\/?CN=([^\/]*).*$/\1/'`
  echo $X509_CN
}

if [ ! -f "$1" ]; then
  echo "Unable to find file: $1"
  exit 1
fi

check-expire -f /usr/local/etc/check-expire.cfg openssl_x509 -in "$1"

case $? in
  1)
    X509_CN=`openssl_get_CN_from_file "$1"`
    if [ ! -z "$X509_CN" ]; then
      echo "$X509_CN: certificate expires soon"
    else
      echo "$1: certificate expires soon"
    fi
    ;;
  2)
  X509_CN=`openssl_get_CN_from_file "$1"`
  if [ ! -z "$X509_CN" ]; then
    echo "$X509_CN: certificate expired!"
  else
    echo "$1: certificate expired!"
  fi
  ;;
esac

check_tinyca_certs - проверка сертификатов из директории

#!/bin/sh

if [ ! -d "$1" ]; then
  echo "Unable to find directory: $1"
  exit 1
fi

for sslcert in "$1"/*.pem
do
  if [ -f "$sslcert" ]; then
    check-certificate-expire "$sslcert"
  else
    echo "File $sslcert not found"
  fi
done

Конфиг для скрипта check-expire

<class default>
        <expired>
                exit_value 2
        </expired>

        <window>
                inside 2w
                exit_value 1
        </window>
</class>