{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Skurudo Blog(post): заметки с тегом VestaCP", "_rss_description": "Бесплатная панель управления серверами — быстрая и очень простая. :)", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/www.skurudo.ru\/tags\/vestacp\/", "feed_url": "https:\/\/www.skurudo.ru\/tags\/vestacp\/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": "

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

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

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

openssl s_client -servername <NAME> -connect <HOST:PORT> 2>\/dev\/null | openssl x509 -noout -dates<\/code><\/pre>
И смотреть, что у нас получилось в выходе notAfter. Решение для посмотреть по-быстрому, но пользоваться не слишком удобно. Что приводит нас к необходимости усложнить...<\/p>\n
Если у нас нет четкого списка доменов или этот список меняется (возможно в будущем), сначала каким-то образом нам нужно получить список доменных имен, которые существуют на сервере и которые придется проверять. Исходя из того, что nginx почти везде, можем взять из него:<\/p>\n
nginx -T | sed -r -e 's\/[ \\t]*$\/\/' -e 's\/^[ \\t]*\/\/' -e 's\/^#.*$\/\/' -e 's\/[ \\t]*#.*$\/\/' -e '\/^$\/d' | \\\r\nsed -e ':a;N;$!ba;s\/\\([^;\\{\\}]\\)\\n\/\\1 \/g' | \\\r\ngrep -P 'server_name[ \\t]' | grep -v '\\$' | grep '\\.' | \\\r\nsed -r -e 's\/(\\S)[ \\t]+(\\S)\/\\1\\n\\2\/g' -e 's\/[\\t ]\/\/g' -e 's\/;\/\/' -e 's\/server_name\/\/' | \\\r\nsort | uniq | xargs -L1 > \/path\/to\/sitelist<\/code><\/pre>
Для тех, кто использует панели управления, вроде ISPManager — плохая новость, изящно список не получить — нужно пользоваться nginx и выборкой оттуда. А вот у VestaCP \/ HestiaCP \/ MyVesta есть аккуратная выборка:<\/p>\n
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<\/code><\/pre>
Далее можно попробовать что-то свое, а можно взять готовое решение от Джулио @elarraydejota из Мадрида — https:\/\/github.com\/juliojsb\/jota-cert-checker<\/a><\/a>. Из многих скриптов этот понравился больше всего. Стабильная работа, понятный код и приятный выбор между отчетами.  Остается только добавить в начало скрипта выборку по доменам или подключать ее в скрипте с помощью source, далее сможем получать отчеты в терминале или по почте.<\/p>\n
В терминале это выглядит вот так:<\/p>\n
\n\"\"\n<\/div>\n
На почте вот так:<\/p>\n
\n\"\"\n<\/div>\n
Но не все же так хорошо? Да, не все. Удалось подружить скрипт с телеграмом, но вывод как для слаки при большом количестве доменов в виде картинки — очень неудачный вариант, для 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": "158",
            "url": "https:\/\/www.skurudo.ru\/all\/vestacp-top-digitalocean-page\/",
            "title": "VestaCP на главной DO",
            "content_html": "
С момента добавления в список запросов<\/a> на включение VestaCP в список приложений на DigitalOcean прошло чуть больше десяти месяцев и вот момент настал. Vesta на главной странице голосований, потеснив другие интересные запросы: VLAN’ы, возможность делиться дроплетами, дополнительные линукс дистрибутивы (Kali, OpenBSD. OpenSUSE). Слегка стыдно перед японцами, пользователи добавили проекту бесплатной панели управления больше голосов, чем за строительство датацентра в стране восходящего солнца.<\/p>\n
Помню, как все начиналось. Мы написали письмо в DigitalOcean и спросили: «А ведь здорово было бы, если бы среди других приложений была бы и VestaCP?». На что лаконичный ответ: «Вы, мол, сначала добавьте, а там уж посмотрим, как пойдет». Процесс шел. Конечно не так быстро, как хотелось бы, но первая страница — большое достижение для небольшой команды и пользователей VestaCP. Именно благодаря поддержке удалось забраться так далеко. Надеюсь, DigitalOcean обратит внимание и решит положительно. :)<\/p>\n
\n\"\"\n<\/div>\n",
            "date_published": "2016-11-01T23:39:18+03:00",
            "date_modified": "2016-11-01T23:36:01+03:00",
            "tags": [
                "DigitalOcean",
                "VestaCP",
                "хостинг"
            ],
            "image": "https:\/\/www.skurudo.ru\/pictures\/-2016-11-01-23.08.33.png",
            "_date_published_rfc2822": "Tue, 01 Nov 2016 23:39:18 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "158",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/www.skurudo.ru\/pictures\/-2016-11-01-23.08.33.png"
                ]
            }
        },
        {
            "id": "144",
            "url": "https:\/\/www.skurudo.ru\/all\/ovh-you-failed-your-etc-issue\/",
            "title": "OVH, you failed your \/etc\/issue!",
            "content_html": "
После заметки о проблемах установки<\/a> VestaCP на серверах OVH, обнаружилось, что версия дистрибутива указывается не только в Debian, но в на других операционных системах: Ubuntu \/ CentOS. Почему оно так случилось в последних релизах ISOшников сказать сложно, но случилось и на эту тему придется что-то думать. Самый простой способ, скорее всего, административный — помимо универсального инсталлятора давать ссылки на инсталляторы для каждой операционной системы. Ничего позорного здесь в общем-то нет.<\/p>\n
Второй вариант чуть более экзотический и попахивает чисто инженерным подходом. Есть мысль, что нужно при определении операционной системы использовать два источника: т. е. не только \/etc\/issue, но и скажем \/etc\/os-release. Сравнивая данные выбирать, в среде какой операционной системы мы находимся. Причем основным источником видимо придется считать именно os-release.<\/p>\n
PS: Благодаря автоматическому выбору операционной системы сложности могут быть только у владельцев Debain\/Ubuntu. Как видно из элегантного кода пользователи CentOS всегда в выигрыше:<\/p>\n
# Detect OS\r\ncase $(head -n1 \/etc\/issue | cut -f 1 -d ' ') in\r\n    Debian)     type="debian" ;;\r\n    Ubuntu)     type="ubuntu" ;;\r\n    *)          type="rhel" ;;\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": "
В рамках поддержки проекта VestaCP<\/a> занялся патчем для phpmyadmin. Основная проблема в том, что дополнительные функции из коробки не работают, также как и contoluser.  Многим пользователям функционал по сути не нужен, он избыточен. Правда, не очень приятно видеть при входе сообщение о том, что у тебя часть функций отключено и не работает — «The phpMyAdmin configuration storage is not completely configured, some extended features have been deactivated».<\/p>\n
За вечер пятницы удалось изобразить скрипт, который правит конфигурационный файл и добавляет недостающие таблицы. Чтобы не возиться с определением версии операционной системы, сделал 3 разных скрипта для centos\/debian\/ubuntu. И еще слегка упростил себе жизнь — не стал изобретать генератор паролей, использовал дополнительный пакет.<\/p>\n
Интереснее было в процессе отладки. Выянил, что пихать много запросов в mysql из баша — это не очень хорошо, далеко не все отрабатывает. Гораздо правильнее разбить на несколько. Как оказалось, 3 и 4 ветка phpmyadmin имеют некоторые отличия. В четвертой ветке некоторые значения задаются явно и в дампе несколько больше таблиц, нежели в 3 версии. Довольно странное отличии в количестве нижних подчеркиваний в названии таблиц: в третьей — одно, в четвертой — два. Думаю, в следующих версиях увеличат :)<\/p>\n
По моим прикидкам скрипт успели протестировать более чем на полусотне серверов, не считая мои и тестовые — все вроде ровненько прошло. На неделе, наверное, закинем на гитхаб<\/s> прогоним тесты повторно.. возможно мой вроде-код даже появится в релизе VestaCP. Код добавил на Github, никакого терпения не хватило :)<\/p>\n
PS: Слегка удивило, что фикс никто не сделал раньше и не сэкономил мне время (специально поискал в интернетах), вроде ничего сложного не было. Подозреваю, что все-таки пользователи тратят на это 5-10 минут и забывают или забивают вовсе :-)<\/p>\n
VestaCP Forum<\/b> — phpmyadmin fixer<\/a>
\nGithub<\/b> — Fixes for phpmyadmin (configuration storage and some extended features) <\/a><\/p>\n
Ubuntu<\/b><\/p>\n
sudo wget --no-check-certificate \r\nhttps:\/\/raw.githubusercontent.com\/skurudo\/phpmyadmin-fixer\/master\/pma-ubuntu.sh \r\n&& chmod +x pma-ubuntu.sh && .\/pma-ubuntu.sh<\/code><\/pre>
Debian<\/b><\/p>\n
wget --no-check-certificate \r\nhttps:\/\/raw.githubusercontent.com\/skurudo\/phpmyadmin-fixer\/master\/pma-debian.sh \r\n&& chmod +x pma-debian.sh && .\/pma-debian.sh<\/code><\/pre>
CentOS<\/b><\/p>\n
wget --no-check-certificate \r\nhttps:\/\/raw.githubusercontent.com\/skurudo\/phpmyadmin-fixer\/master\/pma-centos.sh \r\n&& chmod +x pma-centos.sh && .\/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": "105",
            "url": "https:\/\/www.skurudo.ru\/all\/ovh-you-failed-your-debian-8\/",
            "title": "OVH, you failed your Debian 8!",
            "content_html": "
При попытке установить VestaCP на Debian 8 на сервере от Kimsufi натолкнулся на ошибку. Мне встречалась такая ошибка однажды, а раз уж встретилась повторно, то  нужно задокументировать.<\/p>\n
cut: \/etc\/redhat-release: No such file or directory\r\ngrep: \/etc\/redhat-release: No such file or directory\r\nvst-install-rhel.sh: line 20: [: : integer expression expected\r\nError: No access to Vesta repository<\/code><\/pre>
А все потому, что мудрые европейские ребята решили, что незачем писать версию дистрибутива в \/etc\/issue. Панель управления в свою очередь не может определить версию операционной системы и не может установиться. Для решения недоработки хостера достаточно указать версию и проблема будет решена.<\/p>\n
\n\"\"\n<\/div>\n
PS: Хочу заметить, что в инсталляциях с предыдущей версией Debain 7 версия указана корректно — Debian GNU\/Linux 7.8<\/p>\n",
            "date_published": "2015-12-10T00:53:58+03:00",
            "date_modified": "2015-12-10T01:23:31+03:00",
            "tags": [
                "Debian",
                "Kimsufi",
                "OVH",
                "VestaCP"
            ],
            "image": "https:\/\/www.skurudo.ru\/pictures\/you-failed---yoda-style.png",
            "_date_published_rfc2822": "Thu, 10 Dec 2015 00:53:58 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "105",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/www.skurudo.ru\/pictures\/you-failed---yoda-style.png"
                ]
            }
        }
    ],
    "_e2_version": 4116,
    "_e2_ua_string": "Aegea 11.2 (v4116)"
}