Skurudo Blog(post): заметки с тегом Debian

Проверка срока годности SSL-сертификат(ов)

Tue, 20 Jul 2021 16:20:04 +0300

С приходом Let’s Encrypt сертификаты стали бесплатными, а https массово шагнул в эти ваши интернеты. Выпустить сертификат для домена, почты и сервисов стало просто, но срок действия сертификата в 90 дней не слишком велик, что ведет нас к тому, что периодически его нужно перевыпускать. В свою очередь приходится заниматься и тем, чтобы проверять, не истек ли сертификат, продлился ли он корректно.

Много раз сталкивался с тем, что сертификат не продлялся. Причин этому достаточно — ошибки при проверке, ошибки при конфигурировании сервера, изменения в DNS. Банальнейшая история, когда А запись для домена и WWW прописана на разные адреса и что-то в записях меняется, например при переезде. Бывают также превышения лимита запросов к Let’s Encrypt, на какое время сертификат перевыпустить не получится.

Именно для этого требуется хоть какой-нибудь мониторинг хозяйства из ssl сертификатов. Саму проверку мы по сути можем выполнить одной командой:

openssl s_client -servername <NAME> -connect <HOST:PORT> 2>/dev/null | openssl x509 -noout -dates

И смотреть, что у нас получилось в выходе notAfter. Решение для посмотреть по-быстрому, но пользоваться не слишком удобно. Что приводит нас к необходимости усложнить...

Если у нас нет четкого списка доменов или этот список меняется (возможно в будущем), сначала каким-то образом нам нужно получить список доменных имен, которые существуют на сервере и которые придется проверять. Исходя из того, что nginx почти везде, можем взять из него:

nginx -T | sed -r -e 's/[ \t]*$//' -e 's/^[ \t]*//' -e 's/^#.*$//' -e 's/[ \t]*#.*$//' -e '/^$/d' | \
sed -e ':a;N;$!ba;s/\([^;\{\}]\)\n/\1 /g' | \
grep -P 'server_name[ \t]' | grep -v '\$' | grep '\.' | \
sed -r -e 's/(\S)[ \t]+(\S)/\1\n\2/g' -e 's/[\t ]//g' -e 's/;//' -e 's/server_name//' | \
sort | uniq | xargs -L1 > /path/to/sitelist

Для тех, кто использует панели управления, вроде ISPManager — плохая новость, изящно список не получить — нужно пользоваться nginx и выборкой оттуда. А вот у VestaCP / HestiaCP / MyVesta есть аккуратная выборка:

v-list-users | tail -n +3 | awk '{print "v-list-web-domains "$1" | tail -n +3"}' | bash | awk '{ print ($1)":443" | "sort -d" }' > /path/to/sitelist

Далее можно попробовать что-то свое, а можно взять готовое решение от Джулио @elarraydejota из Мадрида — https://github.com/juliojsb/jota-cert-checker. Из многих скриптов этот понравился больше всего. Стабильная работа, понятный код и приятный выбор между отчетами. Остается только добавить в начало скрипта выборку по доменам или подключать ее в скрипте с помощью source, далее сможем получать отчеты в терминале или по почте.

В терминале это выглядит вот так:

На почте вот так:

Но не все же так хорошо? Да, не все. Удалось подружить скрипт с телеграмом, но вывод как для слаки при большом количестве доменов в виде картинки — очень неудачный вариант, для 1-5 еще ничего. Пока пришлось отказаться от этой затеи.. Также к минусам можно отнести и сложности с кириллическими доменами, даже в punnycode. Проверка их с помощью openssl s_client клиента проходит не всегда.

YASZAIT — Yet Another Simple Zabbix Agent Installer Tool

Fri, 21 May 2021 10:14:45 +0300

Понадобилось на несколько разных серверов на Debian/Ubuntu поставить агент Zabbix, чтобы подключить их к мониторингу. Вместо того, чтобы ставить совсем все руками, немного автоматизировал процесс и добавил интерактива и в конце немного покажет адреса, чтобы удобно добавить в inventory. Скрипт спрашивает ровно три вещи:

хостнейм сервера — можно прощелкать, укажет автоматически
адрес Zabbix сервера — указывать обязательно
порт — можно прощелка, укажет стандартный 10050

Для запуска скрипта:

bash <(wget -O - https://raw.githubusercontent.com/skurudo/usefulbash/main/zabbix-add-agent-on-debian.sh)

Код приведен ниже и также доступен на Github:

#!/bin/bash
# YASZAIT
# Yet Another Simple Zabbix Agent Installer Tool
##############################################################
# enter some data to start
echo -n "Enter this server name: "
read SRV_HOSTNAME
# if SRV_HOSTNAME is empty, use server hostname
if [ -z "$SRV_HOSTNAME" ]; then
        SRV_HOSTNAME=($(hostname -f))
fi
echo -n "Enter Zabbix Server (FQDN or IP): "
read ZABBIX_SERVER
# if ZABBIX_SERVER is empty, try again
if [ -z "$ZABBIX_SERVER" ]; then
    echo -n "=> Please enter address of your Zabbix server... [example.org or IP]: "
        read -r ZABBIX_SERVER
fi
echo -n "Listening port (10050): "
read LISTEN_PORT
# if LISTEN_PORT is empty, set it to 10050
if [ -z "$LISTEN_PORT" ]; then
    LISTEN_PORT=10050
fi

# Zabbix agent simple installation
apt-get install zabbix-agent
# change configuration file
cat > /etc/zabbix/zabbix_agentd.conf << EOF
# simple core config file
#
# address of the server
Server=$ZABBIX_SERVER
ServerActive=$ZABBIX_SERVER
# port for Zabbix
ListenPort=$LISTEN_PORT
# hostname 
Hostname=$SRV_HOSTNAME
#Hostname=$(hostname -f)
# pid and logs
PidFile=/var/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix-agent/zabbix_agentd.log
LogFileSize=0
EOF
# restart the zabbix agent
service zabbix-agent restart 
# check agent status
service zabbix-agent status
# show a little ip4 addresses for Zabbix server
echo "######################################"
echo "# Information about IP addresses #####"
echo "######################################"
echo "Server ipv4 addresses:"
ip addr show | grep "inet "

Сейчас пока задач по доработкам нет — свои задачи скрипт выполнил, но некоторые мысли есть...

* сейчас скрипт не проверяет OS и отработает только под Debian-подобной системой (поскольку CentOS и других под рукой уже нет — дописывать и проверять сложно, пока отложено);
* скрипт не проверяет установлен ли сейчас какой-то агент, он просто перезапишет конфиг (не очень ясно, насколько это востребованная история);
* скрипт не проверяет занятость порта (отсылка к предыдущему пункту по сути);
* скрипт не использует сертификаты или PKI (при наличии задачи возможно стоило бы использовать);
* при однородности серверов мониторинга можно было бы наверное использовать фиксированные значения или давать выбор (здесь опущено для универсальности, серверы были разные);
* возможно стоило бы подумать и усложнить конфигурационный файл агента (стоит обдумать опции на досуге);

Привет nginx’a дебианщикам

Wed, 07 Sep 2016 21:02:24 +0300

При попытке обновить программное обеспечение на Debian 7/8 получаем милое сообщение о том, что ключик-то того — имел место истечь и неплохо бы его обновить:

W: A error occurred during the signature verification. 
The repository is not updated and the previous index files will be used. 
GPG error: https://nginx.org wheezy Release: The following signatures were invalid: KEYEXPIRED 1471427554

W: Failed to fetch https://nginx.org/packages/debian/dists/wheezy/Release
W: Some index files failed to download. They have been ignored, or old ones used instead.

Выясняем, что истекло:

apt-key list | grep "expired:"

Оказывается, вот что:

pub   2048R/7BD9BF62 2011-08-19 [expired: 2016-08-17]

Обновляем то, что истекло:

apt-key adv --recv-keys --keyserver keys.gnupg.net 7BD9BF62

OVH, you failed your /etc/issue!

Mon, 08 Feb 2016 00:35:21 +0300

После заметки о проблемах установки VestaCP на серверах OVH, обнаружилось, что версия дистрибутива указывается не только в Debian, но в на других операционных системах: Ubuntu / CentOS. Почему оно так случилось в последних релизах ISOшников сказать сложно, но случилось и на эту тему придется что-то думать. Самый простой способ, скорее всего, административный — помимо универсального инсталлятора давать ссылки на инсталляторы для каждой операционной системы. Ничего позорного здесь в общем-то нет.

Второй вариант чуть более экзотический и попахивает чисто инженерным подходом. Есть мысль, что нужно при определении операционной системы использовать два источника: т. е. не только /etc/issue, но и скажем /etc/os-release. Сравнивая данные выбирать, в среде какой операционной системы мы находимся. Причем основным источником видимо придется считать именно os-release.

PS: Благодаря автоматическому выбору операционной системы сложности могут быть только у владельцев Debain/Ubuntu. Как видно из элегантного кода пользователи CentOS всегда в выигрыше:

# Detect OS
case $(head -n1 /etc/issue | cut -f 1 -d ' ') in
    Debian)     type="debian" ;;
    Ubuntu)     type="ubuntu" ;;
    *)          type="rhel" ;;
esac

Патч для phpmyadmin

Sun, 17 Jan 2016 22:33:54 +0300

В рамках поддержки проекта VestaCP занялся патчем для phpmyadmin. Основная проблема в том, что дополнительные функции из коробки не работают, также как и contoluser. Многим пользователям функционал по сути не нужен, он избыточен. Правда, не очень приятно видеть при входе сообщение о том, что у тебя часть функций отключено и не работает — «The phpMyAdmin configuration storage is not completely configured, some extended features have been deactivated».

За вечер пятницы удалось изобразить скрипт, который правит конфигурационный файл и добавляет недостающие таблицы. Чтобы не возиться с определением версии операционной системы, сделал 3 разных скрипта для centos/debian/ubuntu. И еще слегка упростил себе жизнь — не стал изобретать генератор паролей, использовал дополнительный пакет.

Интереснее было в процессе отладки. Выянил, что пихать много запросов в mysql из баша — это не очень хорошо, далеко не все отрабатывает. Гораздо правильнее разбить на несколько. Как оказалось, 3 и 4 ветка phpmyadmin имеют некоторые отличия. В четвертой ветке некоторые значения задаются явно и в дампе несколько больше таблиц, нежели в 3 версии. Довольно странное отличии в количестве нижних подчеркиваний в названии таблиц: в третьей — одно, в четвертой — два. Думаю, в следующих версиях увеличат :)

По моим прикидкам скрипт успели протестировать более чем на полусотне серверов, не считая мои и тестовые — все вроде ровненько прошло. На неделе~~, наверное, закинем на гитхаб~~ прогоним тесты повторно.. возможно мой вроде-код даже появится в релизе VestaCP. Код добавил на Github, никакого терпения не хватило :)

PS: Слегка удивило, что фикс никто не сделал раньше и не сэкономил мне время (специально поискал в интернетах), вроде ничего сложного не было. Подозреваю, что все-таки пользователи тратят на это 5-10 минут и забывают или забивают вовсе :-)

VestaCP Forum — phpmyadmin fixer
Github — Fixes for phpmyadmin (configuration storage and some extended features)

Ubuntu

sudo wget --no-check-certificate 
https://raw.githubusercontent.com/skurudo/phpmyadmin-fixer/master/pma-ubuntu.sh 
&& chmod +x pma-ubuntu.sh && ./pma-ubuntu.sh

Debian

wget --no-check-certificate 
https://raw.githubusercontent.com/skurudo/phpmyadmin-fixer/master/pma-debian.sh 
&& chmod +x pma-debian.sh && ./pma-debian.sh

CentOS

wget --no-check-certificate 
https://raw.githubusercontent.com/skurudo/phpmyadmin-fixer/master/pma-centos.sh 
&& chmod +x pma-centos.sh && ./pma-centos.sh

OVH, you failed your Debian 8!

Thu, 10 Dec 2015 00:53:58 +0300

При попытке установить VestaCP на Debian 8 на сервере от Kimsufi натолкнулся на ошибку. Мне встречалась такая ошибка однажды, а раз уж встретилась повторно, то нужно задокументировать.

cut: /etc/redhat-release: No such file or directory
grep: /etc/redhat-release: No such file or directory
vst-install-rhel.sh: line 20: [: : integer expression expected
Error: No access to Vesta repository

А все потому, что мудрые европейские ребята решили, что незачем писать версию дистрибутива в /etc/issue. Панель управления в свою очередь не может определить версию операционной системы и не может установиться. Для решения недоработки хостера достаточно указать версию и проблема будет решена.

PS: Хочу заметить, что в инсталляциях с предыдущей версией Debain 7 версия указана корректно — Debian GNU/Linux 7.8

Nginx — too many open files

Sun, 29 Nov 2015 00:20:42 +0300

Самое распространенное решение с ошибкой «too many open files», когда увеличение лимитов ulimit (/etc/sysctl.conf и /etc/security/limits.conf) не помогает:

worker_rlimit_nofile 16384;

Общеизвестное и разрекламированное решение, ноги его растут из документации. Однако в связи с широким появлением systemd в Debian 8 Jessie / CentOS 7, может возникнуть ситуация, когда перечисленные методы могут и не сработать. Идея фикса в принципе та же, но со стороны модной systemd:

$ mkdir -p /etc/systemd/system/nginx.service.d/
$ nano /etc/systemd/system/nginx.service.d/limits.conf

Оглашаем лимиты для сервиса:

[Service]
LimitNOFILE=22222

Перезапускаем сервис и радуемся жизни.
Решение применимо и для других сервисов.

php 5.4 все

Sun, 01 Nov 2015 22:41:34 +0300

Пришло при обновлении вот такое вот сообщение. Можно показывать всем подряд и, руководствуясь мерами безопасности, не ставить или ставить, но особо предупреждать об отсутствии ответственности.

php5 (5.4.45-0+deb7u2) wheezy-security; urgency=medium
  * PHP 5.4 has reached end-of-life on 14 Sep 2015 and as a result there
    will be no more new upstream releases.  The security support of PHP
    5.4 in Debian will be best effort only and you are strongly advised
    to upgrade to latest stable Debian release that includes PHP 5.6 that
    will reach end of security support on 28 Aug 2017.
 -- Ondřej Surý <ondrej@debian.org>

Меня больше смущает другой момент — как будет с поддержкой некоторых скриптов. Понимаю, что некоторые и так застряли с версией 5.3 и по-другому не работают никак. Но что будет с новыми версиями еще не ясно, что-нибудь да всплывет. Вспоминается история с libxml в ее реализации с php 5.3 и её работе в php 5.4 — вот уж капкан соблазнов.

Уничтожить перед передачей

Tue, 04 Feb 2014 23:26:24 +0300

Перед тем как отдать старый сервер в плане переезда значилось: «не забыть почистить данные на дисках». Редко, но все же случаются оказии, когда клиенту вместо чистого сервера достается бывший в употреблении и не переустановленный экземпляр. На моей памяти была пара таких эпизодов. Не смотря на то, что особой секретности данные вроде бы не представляют, пароли на новом сервере новые, как-то не безопасненько отдавать сервер как есть.

Сначала удалили данные пользователей и самих пользователей. Потому удалили и деинсталлировали базу данных, apache2 / nginx и некоторые другие. Затем удалили конфигурационные файлы и данные. Проверили, что рейд синхронизировался, и на втором диске то же, что и на первом. Для уверенности «dd if=/dev/zero of=/dev/drive bs=4M» на обоих дисках. Более простым вариантом, чтобы слегка потешить паранойю, загрузились с внешнего диска и вновь прошлись dd по обоим дискам. Подозрительность может спать спокойно, враг не пройдет.