5 заметок с тегом

Ubuntu

Ubuntu ([ʊˈbʊntuː]; от зулу ubuntu — человечность; «Убу́нту») — операционная система, основанная на Debian GNU/Linux. Основным разработчиком и спонсором является компания Canonical. В настоящее время проект активно развивается и поддерживается свободным сообществом.

По утверждениям Canonical, Ubuntu используется примерно 20 миллионами пользователей. Он является 4-м в списке самых популярных дистрибутивов Linux для веб-серверов. По версии DistroWatch.com (на 2014 год) занимает 2-е место по популярности для десктопов. Обычно новые версии дистрибутива выходят каждые полгода и поддерживаются обновлениями безопасности в течение 9 месяцев (начиная с версии 13.04, до этого поддержка осуществлялась в течение полутора лет).

Версии LTS, выпускаемые раз в 2 года, поддерживаются в течение 5 лет — как серверные, так и десктопные варианты. (До версии 12.04 LTS срок поддержки для десктопных LTS-версий составлял 3 года.) На другие дистрибутивы LTS семейства ubuntu действует полная поддержка в 3 года, а для основы системы (ядро, Xorg и прочие компоненты) — 5 лет.

Ubuntu поставляется с подборкой программного обеспечения для серверов и рабочих станций. Она устанавливается на настольные персональные компьютеры c помощью LiveCD (версия Desktop), LiveUSB или текстового установщика (версия Alternate, предоставлялась до версии Ubuntu 12.04.2). В версии LiveDVD присутствуют несколько бóльшие возможности — начиная от установки не только в графическом, но и в текстовом режимах, загрузки в режиме восстановления системы и заканчивая полной локализацией и бóльшим количеством пакетов на диске. Есть версии для официально поддерживаемых архитектур, таких как i386, amd64, ARM. Кроме того, с 2013 года начата разработка специальной версии Ubuntu для смартфонов на архитектуре ARM и x86.

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

С приходом 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

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

  1. хостнейм сервера — можно прощелкать, укажет автоматически
  2. адрес Zabbix сервера — указывать обязательно
  3. порт — можно прощелка, укажет стандартный 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 (при наличии задачи возможно стоило бы использовать);
  • * при однородности серверов мониторинга можно было бы наверное использовать фиксированные значения или давать выбор (здесь опущено для универсальности, серверы были разные);
  • * возможно стоило бы подумать и усложнить конфигурационный файл агента (стоит обдумать опции на досуге);
 1 комментарий   6 мес   bash   Debian   Ubuntu   Zabbix   скрипт

OVH, you failed your /etc/issue!

После заметки о проблемах установки 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
 1 комментарий   2016   CentOS   Debian   Kimsufi   OVH   Ubuntu   VestaCP

Патч для phpmyadmin

В рамках поддержки проекта 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

Nginx — too many open files

Самое распространенное решение с ошибкой «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

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

 1 комментарий   2015   CentOS   Debian   nginx   systemd   Ubuntu