{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Skurudo Blog(post): заметки с тегом Ubuntu",
    "_rss_description": "Ubuntu ([ʊˈbʊntuː]; от зулу ubuntu — человечность; «Убу́нту») — операционная система, основанная на Debian GNU\/Linux",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/www.skurudo.ru\/tags\/ubuntu\/",
    "feed_url": "https:\/\/www.skurudo.ru\/tags\/ubuntu\/json\/",
    "icon": "https:\/\/www.skurudo.ru\/pictures\/userpic\/userpic@2x.jpg?1691593083",
    "authors": [
        {
            "name": "Pavel Galkin",
            "url": "https:\/\/www.skurudo.ru\/",
            "avatar": "https:\/\/www.skurudo.ru\/pictures\/userpic\/userpic@2x.jpg?1691593083"
        }
    ],
    "items": [
        {
            "id": "231",
            "url": "https:\/\/www.skurudo.ru\/all\/check-ssl-certificate-s-date\/",
            "title": "Проверка срока годности SSL-сертификат(ов)",
            "content_html": "<p>С приходом Let’s Encrypt сертификаты стали бесплатными, а https массово шагнул в эти ваши интернеты. Выпустить сертификат для домена, почты и сервисов стало просто, но срок действия сертификата в 90 дней не слишком велик, что ведет нас к тому, что периодически его нужно перевыпускать. В свою очередь приходится заниматься и тем, чтобы проверять, не истек ли сертификат, продлился ли он корректно.<\/p>\n<p>Много раз сталкивался с тем, что сертификат не продлялся. Причин этому достаточно — ошибки при проверке, ошибки при конфигурировании сервера, изменения в DNS. Банальнейшая история, когда А запись для домена и WWW прописана на разные адреса и что-то в записях меняется, например при переезде. Бывают также превышения лимита запросов к Let’s Encrypt, на какое время сертификат перевыпустить не получится.<\/p>\n<p>Именно для этого требуется хоть какой-нибудь мониторинг хозяйства из ssl сертификатов. Саму проверку мы по сути можем выполнить одной командой:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">openssl s_client -servername &lt;NAME&gt; -connect &lt;HOST:PORT&gt; 2&gt;\/dev\/null | openssl x509 -noout -dates<\/code><\/pre><p>И смотреть, что у нас получилось в выходе notAfter. Решение для посмотреть по-быстрому, но пользоваться не слишком удобно. Что приводит нас к необходимости усложнить...<\/p>\n<p>Если у нас нет четкого списка доменов или этот список меняется (возможно в будущем), сначала каким-то образом нам нужно получить список доменных имен, которые существуют на сервере и которые придется проверять. Исходя из того, что nginx почти везде, можем взять из него:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">nginx -T | sed -r -e &#039;s\/[ \\t]*$\/\/&#039; -e &#039;s\/^[ \\t]*\/\/&#039; -e &#039;s\/^#.*$\/\/&#039; -e &#039;s\/[ \\t]*#.*$\/\/&#039; -e &#039;\/^$\/d&#039; | \\\r\nsed -e &#039;:a;N;$!ba;s\/\\([^;\\{\\}]\\)\\n\/\\1 \/g&#039; | \\\r\ngrep -P &#039;server_name[ \\t]&#039; | grep -v &#039;\\$&#039; | grep &#039;\\.&#039; | \\\r\nsed -r -e &#039;s\/(\\S)[ \\t]+(\\S)\/\\1\\n\\2\/g&#039; -e &#039;s\/[\\t ]\/\/g&#039; -e &#039;s\/;\/\/&#039; -e &#039;s\/server_name\/\/&#039; | \\\r\nsort | uniq | xargs -L1 &gt; \/path\/to\/sitelist<\/code><\/pre><p>Для тех, кто использует панели управления, вроде ISPManager — плохая новость, изящно список не получить — нужно пользоваться nginx и выборкой оттуда. А вот у VestaCP \/ HestiaCP \/ MyVesta есть аккуратная выборка:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">v-list-users | tail -n +3 | awk &#039;{print &quot;v-list-web-domains &quot;$1&quot; | tail -n +3&quot;}&#039; | bash | awk &#039;{ print ($1)&quot;:443&quot; | &quot;sort -d&quot; }&#039; &gt; \/path\/to\/sitelist<\/code><\/pre><p>Далее можно попробовать что-то свое, а можно взять готовое решение от Джулио @elarraydejota из Мадрида — <a href=\"jota-cert-checker\"><a href=\"https:\/\/github.com\/juliojsb\/jota-cert-checker\">https:\/\/github.com\/juliojsb\/jota-cert-checker<\/a><\/a>. Из многих скриптов этот понравился больше всего. Стабильная работа, понятный код и приятный выбор между отчетами.  Остается только добавить в начало скрипта выборку по доменам или подключать ее в скрипте с помощью source, далее сможем получать отчеты в терминале или по почте.<\/p>\n<p>В терминале это выглядит вот так:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.skurudo.ru\/pictures\/ssl-check-terminal.png\" width=\"1121\" height=\"334\" alt=\"\" \/>\n<\/div>\n<p>На почте вот так:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/www.skurudo.ru\/pictures\/ssl-check-mail.png\" width=\"817\" height=\"493\" alt=\"\" \/>\n<\/div>\n<p>Но не все же так хорошо? Да, не все. Удалось подружить скрипт с телеграмом, но вывод как для слаки при большом количестве доменов в виде картинки — очень неудачный вариант, для 1-5 еще ничего. Пока пришлось отказаться от этой затеи.. Также к минусам можно отнести и сложности с кириллическими доменами, даже в punnycode. Проверка их с помощью openssl s_client клиента проходит не всегда.<\/p>\n",
            "date_published": "2021-07-20T16:20:04+03:00",
            "date_modified": "2021-07-20T16:27:00+03:00",
            "tags": [
                "Debian",
                "GitHub",
                "HestiaCP",
                "Let's Encrypt",
                "MyVesta",
                "Ubuntu",
                "VestaCP"
            ],
            "image": "https:\/\/www.skurudo.ru\/pictures\/ssl-check-terminal.png",
            "_date_published_rfc2822": "Tue, 20 Jul 2021 16:20:04 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "231",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/www.skurudo.ru\/pictures\/ssl-check-terminal.png",
                    "https:\/\/www.skurudo.ru\/pictures\/ssl-check-mail.png"
                ]
            }
        },
        {
            "id": "230",
            "url": "https:\/\/www.skurudo.ru\/all\/yaszait-yet-another-simple-zabbix-agent-installer-tool\/",
            "title": "YASZAIT — Yet Another Simple Zabbix Agent Installer Tool",
            "content_html": "<p>Понадобилось на несколько разных серверов на Debian\/Ubuntu поставить агент Zabbix, чтобы подключить их к мониторингу. Вместо того, чтобы ставить совсем все руками, немного автоматизировал процесс и добавил интерактива и в конце немного покажет адреса, чтобы удобно добавить в inventory. Скрипт спрашивает ровно три вещи:<\/p>\n<ol start=\"1\">\n<li>хостнейм сервера — можно прощелкать, укажет автоматически<\/li>\n<li>адрес Zabbix сервера — указывать обязательно<\/li>\n<li>порт — можно прощелка, укажет стандартный 10050<\/li>\n<\/ol>\n<p>Для запуска скрипта:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">bash &lt;(wget -O - https:\/\/raw.githubusercontent.com\/skurudo\/usefulbash\/main\/zabbix-add-agent-on-debian.sh)<\/code><\/pre><p>Код приведен ниже и также доступен на <a href=\"https:\/\/github.com\/skurudo\/usefulbash\/blob\/main\/zabbix-add-agent-on-debian.sh\">Github<\/a>:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">#!\/bin\/bash\r\n# YASZAIT\r\n# Yet Another Simple Zabbix Agent Installer Tool\r\n##############################################################\r\n# enter some data to start\r\necho -n &quot;Enter this server name: &quot;\r\nread SRV_HOSTNAME\r\n# if SRV_HOSTNAME is empty, use server hostname\r\nif [ -z &quot;$SRV_HOSTNAME&quot; ]; then\r\n        SRV_HOSTNAME=($(hostname -f))\r\nfi\r\necho -n &quot;Enter Zabbix Server (FQDN or IP): &quot;\r\nread ZABBIX_SERVER\r\n# if ZABBIX_SERVER is empty, try again\r\nif [ -z &quot;$ZABBIX_SERVER&quot; ]; then\r\n    echo -n &quot;=&gt; Please enter address of your Zabbix server... [example.org or IP]: &quot;\r\n        read -r ZABBIX_SERVER\r\nfi\r\necho -n &quot;Listening port (10050): &quot;\r\nread LISTEN_PORT\r\n# if LISTEN_PORT is empty, set it to 10050\r\nif [ -z &quot;$LISTEN_PORT&quot; ]; then\r\n    LISTEN_PORT=10050\r\nfi\r\n\r\n# Zabbix agent simple installation\r\napt-get install zabbix-agent\r\n# change configuration file\r\ncat &gt; \/etc\/zabbix\/zabbix_agentd.conf &lt;&lt; EOF\r\n# simple core config file\r\n#\r\n# address of the server\r\nServer=$ZABBIX_SERVER\r\nServerActive=$ZABBIX_SERVER\r\n# port for Zabbix\r\nListenPort=$LISTEN_PORT\r\n# hostname \r\nHostname=$SRV_HOSTNAME\r\n#Hostname=$(hostname -f)\r\n# pid and logs\r\nPidFile=\/var\/run\/zabbix\/zabbix_agentd.pid\r\nLogFile=\/var\/log\/zabbix-agent\/zabbix_agentd.log\r\nLogFileSize=0\r\nEOF\r\n# restart the zabbix agent\r\nservice zabbix-agent restart \r\n# check agent status\r\nservice zabbix-agent status\r\n# show a little ip4 addresses for Zabbix server\r\necho &quot;######################################&quot;\r\necho &quot;# Information about IP addresses #####&quot;\r\necho &quot;######################################&quot;\r\necho &quot;Server ipv4 addresses:&quot;\r\nip addr show | grep &quot;inet &quot;<\/code><\/pre><p>Сейчас пока задач по доработкам нет — свои задачи скрипт выполнил, но некоторые мысли есть...<\/p>\n<ul>\n<li>* сейчас скрипт не проверяет OS и отработает только под Debian-подобной системой (поскольку CentOS и других под рукой уже нет — дописывать и проверять сложно, пока отложено);<\/li>\n<li>* скрипт не проверяет установлен ли сейчас какой-то агент, он просто перезапишет конфиг (не очень ясно, насколько это востребованная история);<\/li>\n<li>* скрипт не проверяет занятость порта (отсылка к предыдущему пункту по сути);<\/li>\n<li>* скрипт не использует сертификаты или PKI (при наличии задачи возможно стоило бы использовать);<\/li>\n<li>* при однородности серверов мониторинга можно было бы наверное использовать фиксированные значения или давать выбор (здесь опущено для универсальности, серверы были разные);<\/li>\n<li>* возможно стоило бы подумать и усложнить конфигурационный файл агента (стоит обдумать опции на досуге);<\/li>\n<\/ul>\n",
            "date_published": "2021-05-21T10:14:45+03:00",
            "date_modified": "2021-05-21T15:05:38+03:00",
            "tags": [
                "bash",
                "Debian",
                "Ubuntu",
                "Zabbix",
                "скрипт"
            ],
            "_date_published_rfc2822": "Fri, 21 May 2021 10:14:45 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "230",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "144",
            "url": "https:\/\/www.skurudo.ru\/all\/ovh-you-failed-your-etc-issue\/",
            "title": "OVH, you failed your \/etc\/issue!",
            "content_html": "<p>После заметки о <a href=\"https:\/\/skurudo.ru\/all\/ovh-you-failed-your-debian-8\/\">проблемах установки<\/a> VestaCP на серверах OVH, обнаружилось, что версия дистрибутива указывается не только в Debian, но в на других операционных системах: Ubuntu \/ CentOS. Почему оно так случилось в последних релизах ISOшников сказать сложно, но случилось и на эту тему придется что-то думать. Самый простой способ, скорее всего, административный — помимо универсального инсталлятора давать ссылки на инсталляторы для каждой операционной системы. Ничего позорного здесь в общем-то нет.<\/p>\n<p>Второй вариант чуть более экзотический и попахивает чисто инженерным подходом. Есть мысль, что нужно при определении операционной системы использовать два источника: т. е. не только \/etc\/issue, но и скажем \/etc\/os-release. Сравнивая данные выбирать, в среде какой операционной системы мы находимся. Причем основным источником видимо придется считать именно os-release.<\/p>\n<p>PS: Благодаря автоматическому выбору операционной системы сложности могут быть только у владельцев Debain\/Ubuntu. Как видно из элегантного кода пользователи CentOS всегда в выигрыше:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\"># Detect OS\r\ncase $(head -n1 \/etc\/issue | cut -f 1 -d &#039; &#039;) in\r\n    Debian)     type=&quot;debian&quot; ;;\r\n    Ubuntu)     type=&quot;ubuntu&quot; ;;\r\n    *)          type=&quot;rhel&quot; ;;\r\nesac<\/code><\/pre>",
            "date_published": "2016-02-08T00:35:21+03:00",
            "date_modified": "2016-02-08T00:32:47+03:00",
            "tags": [
                "CentOS",
                "Debian",
                "Kimsufi",
                "OVH",
                "Ubuntu",
                "VestaCP"
            ],
            "_date_published_rfc2822": "Mon, 08 Feb 2016 00:35:21 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "144",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "142",
            "url": "https:\/\/www.skurudo.ru\/all\/fix-for-phpmyadmin\/",
            "title": "Патч для phpmyadmin",
            "content_html": "<p>В рамках поддержки проекта <a href=\"https:\/\/vestacp.com\">VestaCP<\/a> занялся патчем для phpmyadmin. Основная проблема в том, что дополнительные функции из коробки не работают, также как и contoluser.  Многим пользователям функционал по сути не нужен, он избыточен. Правда, не очень приятно видеть при входе сообщение о том, что у тебя часть функций отключено и не работает — «The phpMyAdmin configuration storage is not completely configured, some extended features have been deactivated».<\/p>\n<p>За вечер пятницы удалось изобразить скрипт, который правит конфигурационный файл и добавляет недостающие таблицы. Чтобы не возиться с определением версии операционной системы, сделал 3 разных скрипта для centos\/debian\/ubuntu. И еще слегка упростил себе жизнь — не стал изобретать генератор паролей, использовал дополнительный пакет.<\/p>\n<p>Интереснее было в процессе отладки. Выянил, что пихать много запросов в mysql из баша — это не очень хорошо, далеко не все отрабатывает. Гораздо правильнее разбить на несколько. Как оказалось, 3 и 4 ветка phpmyadmin имеют некоторые отличия. В четвертой ветке некоторые значения задаются явно и в дампе несколько больше таблиц, нежели в 3 версии. Довольно странное отличии в количестве нижних подчеркиваний в названии таблиц: в третьей — одно, в четвертой — два. Думаю, в следующих версиях увеличат :)<\/p>\n<p>По моим прикидкам скрипт успели протестировать более чем на полусотне серверов, не считая мои и тестовые — все вроде ровненько прошло. На неделе<s>, наверное, закинем на гитхаб<\/s> прогоним тесты повторно.. возможно мой вроде-код даже появится в релизе VestaCP. Код добавил на Github, никакого терпения не хватило :)<\/p>\n<p>PS: Слегка удивило, что фикс никто не сделал раньше и не сэкономил мне время (специально поискал в интернетах), вроде ничего сложного не было. Подозреваю, что все-таки пользователи тратят на это 5-10 минут и забывают или забивают вовсе :-)<\/p>\n<p><b>VestaCP Forum<\/b> — <a href=\"https:\/\/forum.vestacp.com\/viewtopic.php?f=32&t=10306\">phpmyadmin fixer<\/a><br \/>\n<b>Github<\/b> — <a href=\"https:\/\/github.com\/skurudo\/phpmyadmin-fixer\">Fixes for phpmyadmin (configuration storage and some extended features) <\/a><\/p>\n<p><b>Ubuntu<\/b><\/p>\n<pre class=\"e2-text-code\"><code class=\"\">sudo wget --no-check-certificate \r\nhttps:\/\/raw.githubusercontent.com\/skurudo\/phpmyadmin-fixer\/master\/pma-ubuntu.sh \r\n&amp;&amp; chmod +x pma-ubuntu.sh &amp;&amp; .\/pma-ubuntu.sh<\/code><\/pre><p><b>Debian<\/b><\/p>\n<pre class=\"e2-text-code\"><code class=\"\">wget --no-check-certificate \r\nhttps:\/\/raw.githubusercontent.com\/skurudo\/phpmyadmin-fixer\/master\/pma-debian.sh \r\n&amp;&amp; chmod +x pma-debian.sh &amp;&amp; .\/pma-debian.sh<\/code><\/pre><p><b>CentOS<\/b><\/p>\n<pre class=\"e2-text-code\"><code class=\"\">wget --no-check-certificate \r\nhttps:\/\/raw.githubusercontent.com\/skurudo\/phpmyadmin-fixer\/master\/pma-centos.sh \r\n&amp;&amp; chmod +x pma-centos.sh &amp;&amp; .\/pma-centos.sh<\/code><\/pre>",
            "date_published": "2016-01-17T22:33:54+03:00",
            "date_modified": "2016-06-09T12:35:09+03:00",
            "tags": [
                "CentOS",
                "Debian",
                "MySQL",
                "php",
                "phpmyadmin",
                "Ubuntu",
                "VestaCP",
                "код"
            ],
            "_date_published_rfc2822": "Sun, 17 Jan 2016 22:33:54 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "142",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "98",
            "url": "https:\/\/www.skurudo.ru\/all\/nginx-too-many-open-files\/",
            "title": "Nginx — too many open files",
            "content_html": "<p>Самое распространенное решение с ошибкой «too many open files», когда увеличение лимитов ulimit (\/etc\/sysctl.conf и \/etc\/security\/limits.conf) не помогает:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">worker_rlimit_nofile 16384;<\/code><\/pre><p>Общеизвестное и разрекламированное решение, ноги его растут из <a href=\"https:\/\/sku.su\/Waj5c\">документации<\/a>. Однако в связи с широким появлением systemd в Debian 8 Jessie \/ CentOS 7, может возникнуть ситуация, когда перечисленные методы могут и не сработать. Идея фикса в принципе та же, но со стороны модной systemd:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">$ mkdir -p \/etc\/systemd\/system\/nginx.service.d\/\r\n$ nano \/etc\/systemd\/system\/nginx.service.d\/limits.conf<\/code><\/pre><p>Оглашаем лимиты для сервиса:<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">[Service]\r\nLimitNOFILE=22222<\/code><\/pre><p>Перезапускаем сервис и радуемся жизни.<br \/>\nРешение применимо и для других сервисов.<\/p>\n",
            "date_published": "2015-11-29T00:20:42+03:00",
            "date_modified": "2015-11-28T22:58:32+03:00",
            "tags": [
                "CentOS",
                "Debian",
                "nginx",
                "systemd",
                "Ubuntu"
            ],
            "_date_published_rfc2822": "Sun, 29 Nov 2015 00:20:42 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "98",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        }
    ],
    "_e2_version": 4116,
    "_e2_ua_string": "Aegea 11.2 (v4116)"
}