В работе веб сервера иногда есть необходимость разработчикам получить доступ к исходникам сайта напрямую. Проще всего и безопаснее это сделать по протоколу sftp. Эта на первый взгляд простая задача на деле может оказаться не такой уж и простой с множеством нюансов. В зависимости от настроек веб сервера, может использоваться разный подход. Я сейчас рассмотрю один из них, а два других упомяну в самом конце. Подробно рассказывать обо всех методах очень длинно получится.
Для примера возьму классический стек на базе nginx (angie) + php-fpm. Допустим, у нас nginx и php-fpm работают от пользователя
Сразу предвижу комментарии на тему того, что так делать неправильно и в код лезть напрямую не надо. Я был бы только рад, если бы туда никто не лазил. Мне так проще управлять и настраивать. Но иногда надо и выбирать не приходится. Разработчиков выбираю не я, как и их методы работы.
Первым делом добавляю в систему нового пользователя, для которого не будет установлен shell. Подключаться он сможет только по sftp:
Теперь нам нужно настроить sshd таким образом, чтобы он разрешил только указанному пользователю подключаться по sftp, не пускал его дальше указанного каталога с сайтами, а так же сразу указывал необходимые нам права доступа через umask. Позже я поясню, зачем это надо.
Находим в файле
Вместо неё добавляем:
Перезапускаем sshd:
Если сейчас попробовать подключиться пользователем webdev, то ничего не получится. Особенность настройки ChrootDirectory в sshd в том, что у указанной директории владелец должен быть root, а у всех остальных не должно быть туда прав на запись. В данном случае нам это не помешает, но в некоторых ситуациях возникают неудобства. На остальных директориях внутри ChrootDirectory права доступа и владельцы могут быть любыми.
Теперь пользователь webdev может подключиться по sftp. Он сразу попадёт в директорию
Благодаря указанной umask 002 в настройках sshd все созданные пользователем webdev файлы будут иметь права 664 и каталоги 775. То есть будет полный доступ и у пользователя, и у группы. Так что веб сервер сможет нормально работать с этими файлами, и наоборот.
Способ немного корявый и в некоторых случаях может приводить к некоторым проблемам, но решаемым. Я придумал это сам по ходу дела, так как изначально к этим исходникам прямого доступа не должно было быть. Если кто-то знает, как сделать лучше, поделитесь.
Если же вы заранее планируете прямой доступ к исходникам сайта или сайтов разными людьми или сервисами, то сделать лучше по-другому. Сразу создавайте под каждый сайт отдельного системного пользователя. Запускайте под ним php-fpm пул. Для каждого сайта он будет свой. Владельцем исходников сайта делайте этого пользователя и его группу. А пользователя, под которым работает веб сервер, добавьте в группу этого пользователя. Это более удобный, практичный и безопасный способ. Я его описывал в своей статье.
Третий вариант - создавайте новых пользователей для доступа к исходникам с таким же uid, как и у веб сервера. Чрутьте их в свои домашние каталоги, а сайты им добавляйте туда же через mount bind. Я когда то давно этот способ тоже описывал в статье.
#webserver
Для примера возьму классический стек на базе nginx (angie) + php-fpm. Допустим, у нас nginx и php-fpm работают от пользователя
www-data, исходники сайта лежат в /var/www/html. Владельцем файлов и каталогов будет пользователь и группа www-data. Типичная ситуация. Нам надо дать доступ разработчику напрямую к исходникам, чтобы он мог вносить изменения в код сайта. Сразу предвижу комментарии на тему того, что так делать неправильно и в код лезть напрямую не надо. Я был бы только рад, если бы туда никто не лазил. Мне так проще управлять и настраивать. Но иногда надо и выбирать не приходится. Разработчиков выбираю не я, как и их методы работы.
Первым делом добавляю в систему нового пользователя, для которого не будет установлен shell. Подключаться он сможет только по sftp:
# useradd -s /sbin/nologin webdev# passwd webdevТеперь нам нужно настроить sshd таким образом, чтобы он разрешил только указанному пользователю подключаться по sftp, не пускал его дальше указанного каталога с сайтами, а так же сразу указывал необходимые нам права доступа через umask. Позже я поясню, зачем это надо.
Находим в файле
/etc/ssh/sshd_config строку и комментируем её:#Subsystem sftp /usr/lib/openssh/sftp-serverВместо неё добавляем:
Subsystem sftp internal-sftp -u 002Match User webdev ChrootDirectory /var/www ForceCommand internal-sftp -u 002Перезапускаем sshd:
# systemctl restart sshdЕсли сейчас попробовать подключиться пользователем webdev, то ничего не получится. Особенность настройки ChrootDirectory в sshd в том, что у указанной директории владелец должен быть root, а у всех остальных не должно быть туда прав на запись. В данном случае нам это не помешает, но в некоторых ситуациях возникают неудобства. На остальных директориях внутри ChrootDirectory права доступа и владельцы могут быть любыми.
# chown root:root /var/www# chmod 0755 /var/wwwТеперь пользователь webdev может подключиться по sftp. Он сразу попадёт в директорию
/var/www и не сможет из неё выйти дальше в систему. Осталось решить вопрос с правами. Я сделал так. Добавил пользователя webdev в группу www-data, а пользователя www-data в группу webdev:# usermod -aG www-data webdev# usermod -aG webdev www-dataБлагодаря указанной umask 002 в настройках sshd все созданные пользователем webdev файлы будут иметь права 664 и каталоги 775. То есть будет полный доступ и у пользователя, и у группы. Так что веб сервер сможет нормально работать с этими файлами, и наоборот.
Способ немного корявый и в некоторых случаях может приводить к некоторым проблемам, но решаемым. Я придумал это сам по ходу дела, так как изначально к этим исходникам прямого доступа не должно было быть. Если кто-то знает, как сделать лучше, поделитесь.
Если же вы заранее планируете прямой доступ к исходникам сайта или сайтов разными людьми или сервисами, то сделать лучше по-другому. Сразу создавайте под каждый сайт отдельного системного пользователя. Запускайте под ним php-fpm пул. Для каждого сайта он будет свой. Владельцем исходников сайта делайте этого пользователя и его группу. А пользователя, под которым работает веб сервер, добавьте в группу этого пользователя. Это более удобный, практичный и безопасный способ. Я его описывал в своей статье.
Третий вариант - создавайте новых пользователей для доступа к исходникам с таким же uid, как и у веб сервера. Чрутьте их в свои домашние каталоги, а сайты им добавляйте туда же через mount bind. Я когда то давно этот способ тоже описывал в статье.
#webserver
Для быстрого доступа к СУБД Mysql очень удобно использовать небольшой скрипт Adminer, который представляет из себя ровно один php файл и запускается на любом хостинге. Я бы не писал о нём в очередной раз, если бы не столкнулся на днях с некоторыми нюансами при его использовании, так что решил оформить в заметку, чтобы самому потом не забыть.
С помощью Adminer можно создать пользователя и базу данных, назначить или изменить права, посмотреть содержимое таблиц, выгрузить или загрузить дамп. Лично мне для административных целей больше ничего и не надо. Разработчики, работая над сайтом, обычно просят phpmyadmin. Я не очень его люблю, потому что он монструозный, для него надо ставить дополнительные расширения php, поддерживать это дело.
Если я пользуюсь сам, то обычно просто закидываю adminer на сайт, делаю, что мне надо и потом сразу удаляю. В этот раз решил оставить на некоторое время и закрыть через basic_auth в Nginx (на самом деле в Angie). Вроде бы нет ничего проще:
Закрываем паролем. Создаём файл с учёткой:
Добавляем в Nginx:
Перезапускаю Nginx, проверяю. Пароль не спрашивает, доступ прямой. Всё внимательно проверяю, ошибок нет. Я 100 раз это проделывал. Тут нет никаких нюансов. Но не работает.
Быстро догадался, в чём тут дело. В Nginx есть определённые правила обработки locations. Я с этой темой когда-то разбирался подробно и кое-что в памяти осело. Ниже для php файлов уже есть location:
Он с регулярным выражением, поэтому обрабатывается раньше и при первом же совпадении поиск прекращается. Так что до моего location с паролем очередь просто не доходит. Сделать надо так:
Тут надо указать все те же настройки, что у вас стоят для всех остальных php файлов в
Затем nginx проверяет location’ы, заданные регулярными выражениями, в порядке их следования в конфигурационном файле. При первом же совпадении поиск прекращается и nginx использует совпавший location.
Вообще, это очень важная тема, так как сильно влияет на безопасность и многие другие вещи. Есть проект сложный с множеством locations, надо очень аккуратно их описывать и располагать в конфигурационном файле.
#webserver #nginx #mysql
С помощью Adminer можно создать пользователя и базу данных, назначить или изменить права, посмотреть содержимое таблиц, выгрузить или загрузить дамп. Лично мне для административных целей больше ничего и не надо. Разработчики, работая над сайтом, обычно просят phpmyadmin. Я не очень его люблю, потому что он монструозный, для него надо ставить дополнительные расширения php, поддерживать это дело.
Если я пользуюсь сам, то обычно просто закидываю adminer на сайт, делаю, что мне надо и потом сразу удаляю. В этот раз решил оставить на некоторое время и закрыть через basic_auth в Nginx (на самом деле в Angie). Вроде бы нет ничего проще:
# wget https://github.com/vrana/adminer/releases/download/v4.8.1/adminer-4.8.1-mysql-en.php# mv adminer-4.8.1-mysql-en.php /var/www/html/adminer.phpЗакрываем паролем. Создаём файл с учёткой:
# htpasswd -c /etc/nginx/.htpasswd admineruser21Добавляем в Nginx:
location /adminer.php { auth_basic "Administrator’s Area"; auth_basic_user_file /etc/nginx/.htpasswd; }Перезапускаю Nginx, проверяю. Пароль не спрашивает, доступ прямой. Всё внимательно проверяю, ошибок нет. Я 100 раз это проделывал. Тут нет никаких нюансов. Но не работает.
Быстро догадался, в чём тут дело. В Nginx есть определённые правила обработки locations. Я с этой темой когда-то разбирался подробно и кое-что в памяти осело. Ниже для php файлов уже есть location:
location ~ \.php$ { .... }Он с регулярным выражением, поэтому обрабатывается раньше и при первом же совпадении поиск прекращается. Так что до моего location с паролем очередь просто не доходит. Сделать надо так:
location ~ adminer.php { auth_basic "Administrator’s Area"; auth_basic_user_file /etc/nginx/.htpasswd; ....................... }Тут надо указать все те же настройки, что у вас стоят для всех остальных php файлов в
location ~ \.php$. И расположить location с adminer выше location для остальных php файлов. Это важно, так как судя по документации:Затем nginx проверяет location’ы, заданные регулярными выражениями, в порядке их следования в конфигурационном файле. При первом же совпадении поиск прекращается и nginx использует совпавший location.
Вообще, это очень важная тема, так как сильно влияет на безопасность и многие другие вещи. Есть проект сложный с множеством locations, надо очень аккуратно их описывать и располагать в конфигурационном файле.
#webserver #nginx #mysql
Ранее рассказывал о том, как можно выпустить самоподписанный сертификат, установить его в веб сервер и настроить доверие. В комментариях были замечания, что это неудобно делать вручную для многих серверов. То решение было описано для одного сервера. Ниже рассмотрю вариант, как решить эту же задачу, только для всей внутренней инфраструктуры.
Речь пойдёт про open source центр сертификации от компании SmallStep - step-ca. Его можно развернуть у себя и использовать для различных задач. Я расскажу на примере получения HTTPS-сертификатов X.509 для локальных веб ресурсов с помощью протокола ACME и одноимённой утилиты. Помимо этого на базе step-ca можно организовать:
◽выдачу SSH-сертификатов для пользователей
◽выпуск токенов единого входа OAuth OIDC
◽выпуск клиентских сертификатов X.509 для TLS аутентификации
Всё это описано в документации и в рамках заметки не раскрыть.
Установка step-ca описана в документации. Выглядит она относительно просто, так как есть готовые пакеты. А относительно, потому что юнит systemd и рабочие каталоги придётся делать вручную.
Вот инструкция для установки на Debian/Ubuntu:
После установки делаем начальную настройку, но перед этим выполним ручную инициализацию. Покажу свои ответы на вопросы в тестовой среде, чтобы вам не гадать, что там отвечать. Хотя по смыслу понятно.
Теперь переносим настройки в
В файл
Содержимое не привожу, оно длинное, в заметку не уместится. Взял 1 в 1 из документации, он же в репозитории.
Служба должна запуститься на порту 443. Можно браузером зайти. Там будет страница с ошибкой, потому что никакого веб интерфейса нет, но тем не менее будет видно, что сервис работает.
Сразу отмечу важный нюанс. По умолчанию step-ca выпускает сертификаты на 24 часа. Для каких-то задач это, наверное, нормально, но для веб серверов не вижу смысла перевыпускать так часто, даже с учётом того, что это автоматизировано. Можете оставить так, а можете увеличить время. Тут об этом рассказано в доках.
Активируем ACME провизионер в step-ca:
Эта команда добавит некоторые настройки в ca.json. Перезапускаем службу:
Теперь можно брать acme.sh или любой другой клиент (certbot и т.д.) и настраивать выпуск сертификатов через свой CA. Для этого надо либо на клиентских системах добавить root_ca.crt в системные, либо при запуске клиента указывать явно:
Работаем с этим CA так же, как и с другими: добавляем серты в веб сервера, настраиваем автообновление. И не забываем в клиентские машины добавить CA в доверенные, чтобы в браузерах не было предупреждения.
#security #webserver
Речь пойдёт про open source центр сертификации от компании SmallStep - step-ca. Его можно развернуть у себя и использовать для различных задач. Я расскажу на примере получения HTTPS-сертификатов X.509 для локальных веб ресурсов с помощью протокола ACME и одноимённой утилиты. Помимо этого на базе step-ca можно организовать:
◽выдачу SSH-сертификатов для пользователей
◽выпуск токенов единого входа OAuth OIDC
◽выпуск клиентских сертификатов X.509 для TLS аутентификации
Всё это описано в документации и в рамках заметки не раскрыть.
Установка step-ca описана в документации. Выглядит она относительно просто, так как есть готовые пакеты. А относительно, потому что юнит systemd и рабочие каталоги придётся делать вручную.
Вот инструкция для установки на Debian/Ubuntu:
# wget https://dl.smallstep.com/cli/docs-ca-install/latest/step-cli_amd64.deb# dpkg -i step-cli_amd64.deb# wget https://dl.smallstep.com/certificates/docs-ca-install/latest/step-ca_amd64.deb# dpkg -i step-ca_amd64.debПосле установки делаем начальную настройку, но перед этим выполним ручную инициализацию. Покажу свои ответы на вопросы в тестовой среде, чтобы вам не гадать, что там отвечать. Хотя по смыслу понятно.
# step-cli ca init✔ Deployment Type: Standalone✔ (e.g. Smallstep): PrivateCA (можно любое имя использовать)✔ (e.g. :443 or 127.0.0.1:443): :443✔ (e.g. you@smallstep.com): zeroxzed@gmail.com✔ [leave empty and we'll generate one]:✔ Password: E}b;-9DU9UyАВ8TU7$FINl-T8OMТеперь переносим настройки в
/etc/step-ca и запускаем как службу. # useradd --user-group --system --home /etc/step-ca --shell /bin/false step# setcap CAP_NET_BIND_SERVICE=+eip $(which step-ca)# mkdir /etc/step-ca# mv $(step path)/* /etc/step-ca# touch /etc/step-ca/password.txt# chmod 600 /etc/step-ca/password.txt# mcedit /etc/step-ca/password.txt# chown -R step:step /etc/step-caВ файл
password.txt записываем пароль от CA, который был создан во время инициализации. В файлах /etc/step-ca/config/ca.json и defaults.json меняем все пути с /root/.step на /etc/step-ca. И создаём юнит для systemd:# mcedit /etc/systemd/system/step-ca.serviceСодержимое не привожу, оно длинное, в заметку не уместится. Взял 1 в 1 из документации, он же в репозитории.
# systemctl daemon-reload# systemctl enable --now step-caСлужба должна запуститься на порту 443. Можно браузером зайти. Там будет страница с ошибкой, потому что никакого веб интерфейса нет, но тем не менее будет видно, что сервис работает.
Сразу отмечу важный нюанс. По умолчанию step-ca выпускает сертификаты на 24 часа. Для каких-то задач это, наверное, нормально, но для веб серверов не вижу смысла перевыпускать так часто, даже с учётом того, что это автоматизировано. Можете оставить так, а можете увеличить время. Тут об этом рассказано в доках.
Активируем ACME провизионер в step-ca:
# step ca provisioner add acme --type ACMEЭта команда добавит некоторые настройки в ca.json. Перезапускаем службу:
# systemctl restart step-caТеперь можно брать acme.sh или любой другой клиент (certbot и т.д.) и настраивать выпуск сертификатов через свой CA. Для этого надо либо на клиентских системах добавить root_ca.crt в системные, либо при запуске клиента указывать явно:
acme.sh --issue --standalone -d debian12-vm \ --server https://10.20.1.36/acme/acme/directory \ --ca-bundle ~/certs/root_ca.crt \ --fullchain-file debian12-vm.crt \ --key-file debian12-vm.keyРаботаем с этим CA так же, как и с другими: добавляем серты в веб сервера, настраиваем автообновление. И не забываем в клиентские машины добавить CA в доверенные, чтобы в браузерах не было предупреждения.
#security #webserver
Небезызвестный Василий Озеров открыл свой youtube канал (вовремя, как раз к блокировке ютуба) и выложил первое видео. Для тех, кто не знает, поясню. Василий - сооснователь школы Rebrain, рекламу которой вы тут периодически видите, и аутсорс компании Fevlake.
Ролик получился очень информативным, наглядным, нескучным, хоть и длинным - 50 минут. Я посмотрел его весь без перемотки и не в режиме только прослушивания. Большую часть того, что услышал, знал, но не всё. Почерпнул для себя новую информацию.
▶️ Разбор TLS параметров в Nginx: Подробная инструкция по настройке TLS
Для тех, у кого нет желания или времени всё смотреть, напишу несколько основных моментов, которые будут полезны даже в таком формате.
📌 Замена TLS 1.2 на TLS 1.3 даёт уменьшение времени отклика веб сервера. Тест Василия показал уменьшение со 170 мс до 130 мс только из-за смены версии протокола. Это связано с более быстрой инициализацией подключения клиента к серверу.
📌 Сертификат сервера, основанный на протоколе ECDSA, уменьшает при прочих равных условиях нагрузку на CPU сервера в сравнении с RSA где-то на 20-25%. Это связано с гораздо меньшей длиной сертификатов ECDSA.
📌 В конфигурацию Nginx можно добавить оба сертификата: ECDSA и RSA. Это обеспечит поддержку всех клиентов, и новых, и сильно старых, которые ECDSA не поддерживают.
📌 Если у вас только один веб сервер, то нет необходимости включать ssl_session_tickets, достаточно только ssl_session. Тикеты нужны, когда клиенту могут отвечать разные веб сервера с одинаковыми приватными ключами.
Очень подробно эти и некоторые другие моменты разобраны в видео. Рекомендую к просмотру. Реально полезная база, актуальная для любых сервисов, где используется TLS. Ну и не забывайте про лайк и подписку на канал, чтобы у Василия была мотивация записывать больше роликов. Видно, что для этого проделана большая работа.
#nginx #webserver
Ролик получился очень информативным, наглядным, нескучным, хоть и длинным - 50 минут. Я посмотрел его весь без перемотки и не в режиме только прослушивания. Большую часть того, что услышал, знал, но не всё. Почерпнул для себя новую информацию.
▶️ Разбор TLS параметров в Nginx: Подробная инструкция по настройке TLS
Для тех, у кого нет желания или времени всё смотреть, напишу несколько основных моментов, которые будут полезны даже в таком формате.
📌 Замена TLS 1.2 на TLS 1.3 даёт уменьшение времени отклика веб сервера. Тест Василия показал уменьшение со 170 мс до 130 мс только из-за смены версии протокола. Это связано с более быстрой инициализацией подключения клиента к серверу.
📌 Сертификат сервера, основанный на протоколе ECDSA, уменьшает при прочих равных условиях нагрузку на CPU сервера в сравнении с RSA где-то на 20-25%. Это связано с гораздо меньшей длиной сертификатов ECDSA.
📌 В конфигурацию Nginx можно добавить оба сертификата: ECDSA и RSA. Это обеспечит поддержку всех клиентов, и новых, и сильно старых, которые ECDSA не поддерживают.
📌 Если у вас только один веб сервер, то нет необходимости включать ssl_session_tickets, достаточно только ssl_session. Тикеты нужны, когда клиенту могут отвечать разные веб сервера с одинаковыми приватными ключами.
Очень подробно эти и некоторые другие моменты разобраны в видео. Рекомендую к просмотру. Реально полезная база, актуальная для любых сервисов, где используется TLS. Ну и не забывайте про лайк и подписку на канал, чтобы у Василия была мотивация записывать больше роликов. Видно, что для этого проделана большая работа.
#nginx #webserver
YouTube
Разбор TLS параметров в Nginx: Подробная инструкция по настройке TLS.
💬 Наш Telegram-канал: https://t.me/sysopslab
🎥 В этом видео разберемся, как настроить и оптимизировать протоколы TLS 1.2 и TLS 1.3 на веб-сервере. Узнаете, как выбрать конфигурации, повысить безопасность, и почему не стоит слепо копировать настройки из интернета.…
🎥 В этом видео разберемся, как настроить и оптимизировать протоколы TLS 1.2 и TLS 1.3 на веб-сервере. Узнаете, как выбрать конфигурации, повысить безопасность, и почему не стоит слепо копировать настройки из интернета.…
Если хотите быстро потестировать настройки веб сервера на предмет ограничения числа одновременных соединений в Nginx совместно с баном Fail2Ban, могу предложить готовый публичный сервис:
⇨ https://loadest.nodes-studio.com
Он вообще платный, причём принимает оплату в Bitcoin, что сразу вызывает подозрение. Так выглядят платные панели управления для ддоса. Подобных сервисов много и они не особо шифруются, а представляют себя как услуги по тестированию сайтов.
Этот сервис даёт небольшой тестовый баланс, который позволяет побомбить запросами какой-то сайт. Причём любой. Достаточно указать его адрес с главной страницы и свою почту (не проверяется), на которую будет зарегистрирован личный кабинет. В нём сразу же начнётся тест по нагрузке сайта.
Я толком не понял, с какой интенсивностью происходит тестирование, так как у меня все IP адреса сервиса улетели в бан за превышение лимита в 30 запросов в секунду с одного IP. Отработала настройка Nginx:
И фильтр Fail2Ban на записи о превышении этого лимита в лог файле nginx error.log с соответствующей строкой:
Забанил IP адреса в соответствии вот с этим правилом:
Не рассказываю подробно о настройке Fail2Ban, так как заметка не про него, а про сервис. Мне понравилось, что без лишних телодвижений запустил тестирование с посторонних IP. Мой указанный почтовый ящик, кстати, был указан в referrer запросов от сервиса:
Сервис, судя по всему, российский. Посмотрел заголовки писем, которые он шлёт. Там почтовый сервер из зоны .ru используется. И бомбил он меня российскими IP адресами.
#нагрузочное_тестирование #webserver
🦖 Selectel — дешёвые и не очень дедики с аукционом!
⇨ https://loadest.nodes-studio.com
Он вообще платный, причём принимает оплату в Bitcoin, что сразу вызывает подозрение. Так выглядят платные панели управления для ддоса. Подобных сервисов много и они не особо шифруются, а представляют себя как услуги по тестированию сайтов.
Этот сервис даёт небольшой тестовый баланс, который позволяет побомбить запросами какой-то сайт. Причём любой. Достаточно указать его адрес с главной страницы и свою почту (не проверяется), на которую будет зарегистрирован личный кабинет. В нём сразу же начнётся тест по нагрузке сайта.
Я толком не понял, с какой интенсивностью происходит тестирование, так как у меня все IP адреса сервиса улетели в бан за превышение лимита в 30 запросов в секунду с одного IP. Отработала настройка Nginx:
limit_req_zone $binary_remote_addr zone=lim_20r:10m rate=20r/s;И фильтр Fail2Ban на записи о превышении этого лимита в лог файле nginx error.log с соответствующей строкой:
limiting requests, excess: 30.080 by zone "lim_20r", client: 194.87.110.21Забанил IP адреса в соответствии вот с этим правилом:
[Definition]ngx_limit_req_zones = [^"]+failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting requests, excess: [\d\.]+ by zone "(?:%(ngx_limit_req_zones)s)", client: <HOST>,ignoreregex =.datepattern = {^LN-BEG}Не рассказываю подробно о настройке Fail2Ban, так как заметка не про него, а про сервис. Мне понравилось, что без лишних телодвижений запустил тестирование с посторонних IP. Мой указанный почтовый ящик, кстати, был указан в referrer запросов от сервиса:
referer=http://loadest.io user_agent="<username@gmail.com> via http://loadest.io"Сервис, судя по всему, российский. Посмотрел заголовки писем, которые он шлёт. Там почтовый сервер из зоны .ru используется. И бомбил он меня российскими IP адресами.
#нагрузочное_тестирование #webserver
Please open Telegram to view this post
VIEW IN TELEGRAM
Заметил по статистике, что один сайт стали донимать какие-то роботы сканированием несуществующих страниц. В статистике 404 ошибок стало существенно больше, чем 200-х ответов. Я обычно не практикую блокировку по этому признаку, так как можно словить неявные проблемы от каких-нибудь поисковиков или других легитимных пользователей. В этот раз решил сделать исключение.
С помощью fail2ban нетрудно выполнить блокировку. Не буду подробно рассказывать про настройку fail2ban, так как это не тема заметки. Покажу, как я забанил тех, от кого сыпется много 404 кодов ответа веб сервера.
Для начала создаём правило фильтрации в директории
Закомментированная строка подойдёт для стандартного формата логов Nginx или Apache. Вторая для моего изменённого. Я обычно использую свой формат, если собираю логи в ELK и анализирую. У меня есть набор готовых grok фильтров для этого. Вот мой модернизированный формат логов:
Соответственно, получаем вот такую запись в логе:
Для тех, кто использует logstash, покажу grok фильтр для этого формата. Он позволяет анализировать некоторые метрики и выводить их на графики и дашборды. Даю для справки без объяснений, так как это отдельная большая тема.
Приведённая в
⇨ https://regex101.com/
⇨ https://regexper.com/
Постоянно ими пользуюсь. Вот тут была хорошая подборка по этой теме. Дальше создаём файл настроек блокировки в
Баню на 30 минут тех, кто за последние 10 минут получил 30 раз 404 ответ. На мой взгляд это достаточно мягкое условие, которое отсечёт явных ботов, но не тронет легитимных пользователей.
Если кто-то тоже банит по признаку 404 ответа, поделитесь опытом, как это лучше делать и к каким проблемам может привести. Я немного понаблюдал, вроде никто лишний не попадается на это правило.
#fail2ban #webserver
С помощью fail2ban нетрудно выполнить блокировку. Не буду подробно рассказывать про настройку fail2ban, так как это не тема заметки. Покажу, как я забанил тех, от кого сыпется много 404 кодов ответа веб сервера.
Для начала создаём правило фильтрации в директории
/etc/fail2ban/filter.d. Назвал его nginx-4xx.conf:[Definition]#failregex = ^<HOST>.*"(GET|POST).*" (404|429) .*$failregex = ^<HOST>.*"(GET|POST).*" *.* (status=404|status=429) .*$ignoreregex =Закомментированная строка подойдёт для стандартного формата логов Nginx или Apache. Вторая для моего изменённого. Я обычно использую свой формат, если собираю логи в ELK и анализирую. У меня есть набор готовых grok фильтров для этого. Вот мой модернизированный формат логов:
log_format full '$remote_addr - $host [$time_local] "$request" ' 'request_length=$request_length ' 'status=$status bytes_sent=$bytes_sent ' 'body_bytes_sent=$body_bytes_sent ' 'referer=$http_referer ' 'user_agent="$http_user_agent" ' 'upstream_status=$upstream_status ' 'request_time=$request_time ' 'upstream_response_time=$upstream_response_time ' 'upstream_connect_time=$upstream_connect_time ' 'upstream_header_time=$upstream_header_time';Соответственно, получаем вот такую запись в логе:
178.218.43.55 - site01.ru [01/Oct/2024:13:46:24 +0300] "GET /about HTTP/2.0" request_length=123 status=200 bytes_sent=489 body_bytes_sent=8 referer=https://site01.ru/ user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101" upstream_status=200 request_time=0.075 upstream_response_time=0.069 upstream_connect_time=0.000 upstream_header_time=0.069Для тех, кто использует logstash, покажу grok фильтр для этого формата. Он позволяет анализировать некоторые метрики и выводить их на графики и дашборды. Даю для справки без объяснений, так как это отдельная большая тема.
%{IPORHOST:remote_ip} - %{DATA:virt_host} \[%{HTTPDATE:access_time}\] \"%{WORD:http_method} %{DATA:url} HTTP/%{NUMBER:http_version}\" request_length=%{INT:request_length} status=%{INT:status} bytes_sent=%{INT:bytes_sent} body_bytes_sent=%{NUMBER:body_bytes_sent} referer=%{DATA:referer} user_agent=\"%{DATA:user_agent}\" upstream_status=%{DATA:upstream_status} request_time=%{NUMBER:request_time} upstream_response_time=%{DATA:upstream_response_time} upstream_connect_time=%{DATA:upstream_connect_time} upstream_header_time=%{DATA:upstream_header_time}Приведённая в
nginx-4xx.conf регулярка находит 404 и 429 ответы в таком логе. Я не силён в написании регулярок, поэтому хз, правильно составил или нет, но на практике работает. В составлении регулярок помогают вот эти сервисы:⇨ https://regex101.com/
⇨ https://regexper.com/
Постоянно ими пользуюсь. Вот тут была хорошая подборка по этой теме. Дальше создаём файл настроек блокировки в
/etc/fail2ban/jail.d, назвал его так же nginx-4xx.conf:[nginx-4xx]enabled = truefilter = nginx-4xxport = http,httpsaction = iptables-multiport[name=Nginx404, port="http,https", protocol=tcp]logpath = /web/sites/*/logs/access.logmaxretry = 30findtime = 10mbantime = 30mБаню на 30 минут тех, кто за последние 10 минут получил 30 раз 404 ответ. На мой взгляд это достаточно мягкое условие, которое отсечёт явных ботов, но не тронет легитимных пользователей.
Если кто-то тоже банит по признаку 404 ответа, поделитесь опытом, как это лучше делать и к каким проблемам может привести. Я немного понаблюдал, вроде никто лишний не попадается на это правило.
#fail2ban #webserver
Одной из обязательных настроек, которую делаю на новом сервере, касается ротации текстовых логов. Несмотря на то, что их активно заменяют бинарные логи systemd, я предпочитаю возвращать текстовые логи syslog. Для этого на чистый сервер устанавливаю rsyslog:
Далее выполняю некоторые настройки, которые относятся к ротации логов с помощью logrotate. В первую очередь в фале
Он нужен, чтобы в имени файла была указана дата, когда лог-файл был ротирован. С этой настройкой связан один очень важный момент, если вы хотите ротировать логи чаще, чем раз в сутки. По умолчанию logrotate во время ротации лога с этой настройкой переименовывает текущий лог файл, назначая ему имя вида access.log.20241001.gz. То есть в имени файла будет указан текущий день. Второй раз в этот день ротация закончится ошибкой, так как logrotate скажет, что не могу переименовать лог, так как файл с таким именем уже существует. Для тех логов, что точно будут ротироваться чаще, чем раз в сутки, нужно обязательно добавить параметр:
В таком случае каждое имя файла будет уникальным и проблем не возникнет.
Далее в обязательном порядке нужно настроить запуск logrotate чаще, чем раз в сутки. По умолчанию в Debian запуск logrotate настроен в
Эти настройки особенно актуальны для веб серверов, где очень быстро могут разрастись лог файлы.
Все возможные настройки файлов logrotate можно почитать в man. Там довольно подробно всё описано. Если не хочется читать man, можно воспользоваться простым конфигуратором:
🌐 https://scoin.github.io/logrotate-tool
Там наглядно перечислены настройки с описанием. Можно мышкой потыкать и посмотреть, как меняется конфигурационный файл. Вот пример моего файла ротации логов веб сервера:
Маска
◽️/web/sites/site01.ru/logs/
◽️/web/sites/site02.ru/logs/
и т.д.
Когда будете настраивать ротацию логов, проверяйте, чтобы у службы, для которой управляем логами, в итоге оказался доступ к этим логам. Я иногда ошибаюсь и потом приходится разбираться, почему после ротации логи нулевого размера. Это актуально, когда логи куда-то выносятся из /var/log и отдельно настраиваются права, например, для того, чтобы какие-то пользователи имели к ним доступ, к примеру, только на чтение.
#linux #logs #logrotate #webserver
# apt install rsyslogДалее выполняю некоторые настройки, которые относятся к ротации логов с помощью logrotate. В первую очередь в фале
/etc/logrotate.conf включаю параметр:dateextОн нужен, чтобы в имени файла была указана дата, когда лог-файл был ротирован. С этой настройкой связан один очень важный момент, если вы хотите ротировать логи чаще, чем раз в сутки. По умолчанию logrotate во время ротации лога с этой настройкой переименовывает текущий лог файл, назначая ему имя вида access.log.20241001.gz. То есть в имени файла будет указан текущий день. Второй раз в этот день ротация закончится ошибкой, так как logrotate скажет, что не могу переименовать лог, так как файл с таким именем уже существует. Для тех логов, что точно будут ротироваться чаще, чем раз в сутки, нужно обязательно добавить параметр:
dateformat -%Y-%m-%d_%H-%sВ таком случае каждое имя файла будет уникальным и проблем не возникнет.
Далее в обязательном порядке нужно настроить запуск logrotate чаще, чем раз в сутки. По умолчанию в Debian запуск logrotate настроен в
/etc/cron.daily и запускается не чаще раза в сутки. Я обычно просто добавляю запуск в /etc/crontab каждые 5 минут:*/5 * * * * root logrotate /etc/logrotate.confЭти настройки особенно актуальны для веб серверов, где очень быстро могут разрастись лог файлы.
Все возможные настройки файлов logrotate можно почитать в man. Там довольно подробно всё описано. Если не хочется читать man, можно воспользоваться простым конфигуратором:
Там наглядно перечислены настройки с описанием. Можно мышкой потыкать и посмотреть, как меняется конфигурационный файл. Вот пример моего файла ротации логов веб сервера:
/web/sites/*/logs/*.log { create 644 angie webuser size=50M dateext dateformat -%Y-%m-%d_%H-%s missingok rotate 30 compress notifempty sharedscripts postrotate if [ -f /run/angie.pid ]; then kill -USR1 $(cat /run/angie.pid) fi endscript}Маска
/web/sites/*/logs/*.log захватывает все виртуальные хосты веб сервера, где логи располагаются в директориях:◽️/web/sites/site01.ru/logs/
◽️/web/sites/site02.ru/logs/
и т.д.
Когда будете настраивать ротацию логов, проверяйте, чтобы у службы, для которой управляем логами, в итоге оказался доступ к этим логам. Я иногда ошибаюсь и потом приходится разбираться, почему после ротации логи нулевого размера. Это актуально, когда логи куда-то выносятся из /var/log и отдельно настраиваются права, например, для того, чтобы какие-то пользователи имели к ним доступ, к примеру, только на чтение.
#linux #logs #logrotate #webserver
Please open Telegram to view this post
VIEW IN TELEGRAM
Немного информации для тех, кто имеет дело с обычными веб серверами под php сайты. Вчера провозился несколько часов с одним сайтом, который передали разработчики для публикации. Причём провозился из-за ерунды. Это был немного навороченный мультиязычный сайт на базе Wordpress, но с полностью самописной темой.
Я этих вордпрессов десятки устанавливал и поддерживал. Никак не ожидал проблем с этим движком. Но разработчики сумели меня удивить и нагрузить работой. Для начала пришлось повозиться с тем, что режим работы сайта http или https был жёстко зашит в коде сайта. И не где-то в настройках Wordpress или базе, а в коде темы. Это создавало некоторые проблемы при публикации за Cloudflare и Nginx в режиме proxy_pass. Пока всё развернул, разобрался, нашёл и вычистил в коде, немного подустал. Плюс, сайт под Apache разрабатывали, запустил под Nginx.
В итоге на сайте кое-где всплывали ошибки php, что-то не работало. В логе тоже ошибки и предупреждения со стороны php. Причём ошибки какие-то странные, типа скобки не закрыты, переменная не объявлена и т.д. Сначала подумал, что сайт написали под старую версию php. На веб сервере стояла относительно свежая 8.2. Уточнил у разработчиков, у них на 8.1 нормально работает. Разница в этих версиях не такая большая, должно нормально работать. Потом подумал, что по ошибке скинули какой-то черновик, а не итоговую работу.
Немного поразбирался в ошибках и выяснил, в чём проблема. В php по умолчанию параметр short_open_tag выключен. Это нормальная история, так как стандартному коду Wordpress он не нужен. Мне и в голову не пришло его включить. В версиях php до 6-й он был включен, потом стали отключать из соображений совместимости с другим кодом. Например, с тэгами
В коде этого сайта были конструкции типа
Если где-то придётся писать код php, то пишите сразу полные тэги <?php, а не короткие. Сейчас это более правильный подход, который улучшает переносимость проекта и не вызывает проблем с совместимостью с другим кодом, который использует тэги. Вот наглядный пример, где будут проблемы с короткими тэгами:
Это элемент xml разметки, а с включённым short_open_tag это будет интерпретироваться как php код.
#webserver #php
Я этих вордпрессов десятки устанавливал и поддерживал. Никак не ожидал проблем с этим движком. Но разработчики сумели меня удивить и нагрузить работой. Для начала пришлось повозиться с тем, что режим работы сайта http или https был жёстко зашит в коде сайта. И не где-то в настройках Wordpress или базе, а в коде темы. Это создавало некоторые проблемы при публикации за Cloudflare и Nginx в режиме proxy_pass. Пока всё развернул, разобрался, нашёл и вычистил в коде, немного подустал. Плюс, сайт под Apache разрабатывали, запустил под Nginx.
В итоге на сайте кое-где всплывали ошибки php, что-то не работало. В логе тоже ошибки и предупреждения со стороны php. Причём ошибки какие-то странные, типа скобки не закрыты, переменная не объявлена и т.д. Сначала подумал, что сайт написали под старую версию php. На веб сервере стояла относительно свежая 8.2. Уточнил у разработчиков, у них на 8.1 нормально работает. Разница в этих версиях не такая большая, должно нормально работать. Потом подумал, что по ошибке скинули какой-то черновик, а не итоговую работу.
Немного поразбирался в ошибках и выяснил, в чём проблема. В php по умолчанию параметр short_open_tag выключен. Это нормальная история, так как стандартному коду Wordpress он не нужен. Мне и в голову не пришло его включить. В версиях php до 6-й он был включен, потом стали отключать из соображений совместимости с другим кодом. Например, с тэгами
<?xml.В коде этого сайта были конструкции типа
<? вместо <?php, а для их корректной работы как раз и нужен параметр short_open_tag. Есть проекты, где явно пишут, что надо включить этот параметр. А тут мне никто ни слова насчёт него не сказал. Включил параметр и всё заработало. Если где-то придётся писать код php, то пишите сразу полные тэги <?php, а не короткие. Сейчас это более правильный подход, который улучшает переносимость проекта и не вызывает проблем с совместимостью с другим кодом, который использует тэги. Вот наглядный пример, где будут проблемы с короткими тэгами:
<?xml version="1.0"?>Это элемент xml разметки, а с включённым short_open_tag это будет интерпретироваться как php код.
#webserver #php
Если обратиться к веб серверу на базе Nginx по IP адресу, то увидите либо первый виртуальных хост в конфигурации, либо тот, где указана директива default в параметре listen. Показывать виртуальный хост не очень хочется, поэтому обычно на IP адрес ставят какую-то заглушку. Например, так:
С 80-м портом и протоколом HTTP проблем обычно нет. А вот с HTTPS есть нюансы, так как нам нужно использовать сертификат. Доверенный сертификат на IP адрес получить нельзя. По крайней мере я не знаю, как это сделать. Если сертификат не указать, то будет использован сертификат первого в конфигурации виртуального хоста, где он указан. То есть если сделать вот так:
То пользователь, который зайдёт по IP адресу на сервер, увидит сначала предупреждение о том, что имя домена в сертификате не соответствует домену в адресной строке браузера. А когда согласится перейти по адресу, в свойствах сертификата можно будет увидеть адрес виртуального домена, сертификат которого использован.
Можно выйти из этой ситуации, выпустив самоподписанный сертификат-пустышку, не заполняя там вообще никаких полей:
Используем его:
Больше мы домены не светим, но пользователь по прежнему видит предупреждение о сертификате, что тоже не очень красиво. Хотя в целом можно оставить и так. Я всегда так и делал. А недавно увидел новое для себя решение этой же проблемы, чтобы пользователю показать сразу ошибку, без всяких предупреждений. Выглядит это вот так. Показываю сразу итоговый вариант:
Объединил для удобства оба протокола. Ключевой момент тут в настройке
Не увидел тут никаких подводных камней. Взял на вооружение, обновил свой стандартный конфиг default.conf для подобных настроек.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #webserver #angie
server { listen 80 default_server; server_name _; return 404;}С 80-м портом и протоколом HTTP проблем обычно нет. А вот с HTTPS есть нюансы, так как нам нужно использовать сертификат. Доверенный сертификат на IP адрес получить нельзя. По крайней мере я не знаю, как это сделать. Если сертификат не указать, то будет использован сертификат первого в конфигурации виртуального хоста, где он указан. То есть если сделать вот так:
server { listen 443 ssl default_server; server_name _; return 404;}То пользователь, который зайдёт по IP адресу на сервер, увидит сначала предупреждение о том, что имя домена в сертификате не соответствует домену в адресной строке браузера. А когда согласится перейти по адресу, в свойствах сертификата можно будет увидеть адрес виртуального домена, сертификат которого использован.
Можно выйти из этой ситуации, выпустив самоподписанный сертификат-пустышку, не заполняя там вообще никаких полей:
# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/certs/nginx.key -out /etc/nginx/certs/nginx.crtИспользуем его:
server { listen 443 ssl default_server; server_name _; ssl_certificate /etc/nginx/certs/nginx.crt; ssl_certificate_key /etc/nginx/certs/nginx.key; return 404;}Больше мы домены не светим, но пользователь по прежнему видит предупреждение о сертификате, что тоже не очень красиво. Хотя в целом можно оставить и так. Я всегда так и делал. А недавно увидел новое для себя решение этой же проблемы, чтобы пользователю показать сразу ошибку, без всяких предупреждений. Выглядит это вот так. Показываю сразу итоговый вариант:
server { listen 80 default_server; listen 443 ssl default_server; server_name _; ssl_reject_handshake on; return 404;}Объединил для удобства оба протокола. Ключевой момент тут в настройке
ssl_reject_handshake on. Когда она включена, веб сервер отклоняет все попытки соединения, где адрес сервера не совпадает с тем, что указано в директиве server_name. Тут у нас в этой директиве _, так что все соединения будут сразу отклоняться. Пользователь сразу увидит ошибку без необходимости выполнять какие-либо действия. Не увидел тут никаких подводных камней. Взял на вооружение, обновил свой стандартный конфиг default.conf для подобных настроек.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #webserver #angie
Небольшое предупреждение для тех, кто администрирует сайты и получает на них Abuse от РКН. Если на сайтах открыта регистрация пользователей и есть возможность публиковать текст, то это только вопрос времени, когда вы получите требование удалить ту или иную информацию, нарушающую закон. Боты или реальные люди будут пытаться оставить ссылку на запрещёнку везде, где это возможно: комментарии, отзывы, сообщения на форуме, поля для комментариев в профиле и т.д.
Уведомления приходят сначала провайдерам, а они уже уведомляют владельцев сайтов. Даются сутки на удаление противозаконной информации. Вот точная информация на этот счёт:
Провайдер хостинга или иное лицо, обеспечивающее размещение информационного ресурса в сети «Интернет» (далее – иное лицо, разместившее информационный ресурс), с момента получения настоящего уведомления обязаны:
- незамедлительно проинформировать владельца информационного ресурса о необходимости незамедлительного удаления распространяемой с нарушением закона информации;
- по истечении суток ограничить доступ к информационному ресурсу в случае отказа или бездействия владельца информационного ресурса в удалении распространяемой с нарушением закона информации.
В сообщении от провайдера обычно в тикете указана вся необходимая информация. Я просто иду и удаляю то, что там указано. Когда удалю, пишу провайдеру, что сделал это. На этом всё, больше ничего не предпринимаю. К тикету прикладывается исходное уведомление от РКН, которое я обычно не читаю, так как там всё то же самое, только канцелярским языком.
На днях получил подобное уведомление. Информацию удалил. Решил прочитать исходный текст уведомления от РКН. А он существенно изменился в сравнении с тем, что я получал ещё в сентябре. В заявлении указан уникальный идентификатор. Используя этот идентификатор, необходимо отчитаться об удалении либо по email, либо через специальную форму на сайте 398-fz.rkn.gov.ru. В уведомлении есть ссылка с зашитой информацией об основных данных по этому уведомлению.
Если вы владелец или администратор сайта, то нельзя просто так взять и позволить пользователям без премодерации что-то публиковать. Вы должны либо в течении суток реагировать на обращения, либо включать премодерацию и удалять весь возможный противоправный контент заранее. Если быстро не отреагировать, то можно получить блокировку сайта.
❗️И ещё дам небольшой совет, который может сэкономить ваше время. В требовании может прийти ссылка как со слешом на конце, так и без. Я не знаю, кто и как её формирует, но сталкивался не раз. На веб сервере может быть не настроен редирект ссылок без слеша на слеш и наоборот. Речь вот о чём. Ссылки https://398-fz.rkn.gov.ru/toproviders/ и https://398-fz.rkn.gov.ru/toproviders по сути разные.
Вам может прийти требование, где указана ссылка без слеша на конце. Вы идёте на сайт и видите, что такой страницы нет, либо, что ещё хуже, можете увидеть вообще какую-то информацию, не относящуюся непосредственно к этому урлу. Некоторые CMS или самописные сайты могут по разному обрабатывать эти ситуации. Так что проверяйте на всякий случай оба варианта.
#webserver
Уведомления приходят сначала провайдерам, а они уже уведомляют владельцев сайтов. Даются сутки на удаление противозаконной информации. Вот точная информация на этот счёт:
Провайдер хостинга или иное лицо, обеспечивающее размещение информационного ресурса в сети «Интернет» (далее – иное лицо, разместившее информационный ресурс), с момента получения настоящего уведомления обязаны:
- незамедлительно проинформировать владельца информационного ресурса о необходимости незамедлительного удаления распространяемой с нарушением закона информации;
- по истечении суток ограничить доступ к информационному ресурсу в случае отказа или бездействия владельца информационного ресурса в удалении распространяемой с нарушением закона информации.
В сообщении от провайдера обычно в тикете указана вся необходимая информация. Я просто иду и удаляю то, что там указано. Когда удалю, пишу провайдеру, что сделал это. На этом всё, больше ничего не предпринимаю. К тикету прикладывается исходное уведомление от РКН, которое я обычно не читаю, так как там всё то же самое, только канцелярским языком.
На днях получил подобное уведомление. Информацию удалил. Решил прочитать исходный текст уведомления от РКН. А он существенно изменился в сравнении с тем, что я получал ещё в сентябре. В заявлении указан уникальный идентификатор. Используя этот идентификатор, необходимо отчитаться об удалении либо по email, либо через специальную форму на сайте 398-fz.rkn.gov.ru. В уведомлении есть ссылка с зашитой информацией об основных данных по этому уведомлению.
Если вы владелец или администратор сайта, то нельзя просто так взять и позволить пользователям без премодерации что-то публиковать. Вы должны либо в течении суток реагировать на обращения, либо включать премодерацию и удалять весь возможный противоправный контент заранее. Если быстро не отреагировать, то можно получить блокировку сайта.
❗️И ещё дам небольшой совет, который может сэкономить ваше время. В требовании может прийти ссылка как со слешом на конце, так и без. Я не знаю, кто и как её формирует, но сталкивался не раз. На веб сервере может быть не настроен редирект ссылок без слеша на слеш и наоборот. Речь вот о чём. Ссылки https://398-fz.rkn.gov.ru/toproviders/ и https://398-fz.rkn.gov.ru/toproviders по сути разные.
Вам может прийти требование, где указана ссылка без слеша на конце. Вы идёте на сайт и видите, что такой страницы нет, либо, что ещё хуже, можете увидеть вообще какую-то информацию, не относящуюся непосредственно к этому урлу. Некоторые CMS или самописные сайты могут по разному обрабатывать эти ситуации. Так что проверяйте на всякий случай оба варианта.
#webserver
На неделе возникла небольшая задача по публикации баз 1С через веб сервер. Сделал всё быстро, так как выполнял эту задачу не раз и не два. Там всё относительно просто, если понимаешь, что к чему и как работает. Да и статей ни одну написал по этой теме. Но всё это было давно ещё на базе Centos. А сейчас у меня всё на Debian, так что решил сразу написать статью по этой теме.
⇨ Публикация баз 1С на веб севере Apache в Debian
Хотел по-быстрому всё сделать, чтобы потом, если придётся настраивать, просто копипастом всё сделать. Но как обычно разошёлся, написал и про лицензии, и про сеансы, и про обратное проксирование через второй веб сервер, и про распределение функциональности по виртуалкам. В общем, написал всё, что вспомнил по ходу дела. Хотел ещё и про логи, мониторинг, файрвол написать, но не стал. Времени не осталось, да и не захотелось всё в кучу мешать. Надо разделять на темы и объединять ссылками.
Давно не писал новые статьи. А мне это нравится. Прям натуральное удовольствие получаю от их написания. Есть какое-то призвание и способности к этому. Мечтаю, когда дети подрастут и снизится финансовая нагрузка, потратить часть времени на создание какой-то связанной информационной библиотеки или обучающих курсов на отдельные изолированные темы, типа мониторинга или сбора логов. Жаль, что современные технологии напрочь убили монетизацию обычных статейных сайтов. Уже по-всякому прикидывал и тестировал монетизацию, но увы, дохода там почти нет. На это не прожить и даже как дополнительный заработок не тянет, поэтому остаётся только как хобби.
Это я на всякий случай предупреждаю тех, кто может строить планы по созданию сайта и получению какого-то прямого дохода с него. Я по всем своим делам строго веду бухгалтерию и точно знаю, где и как я получаю доход. В лучшие годы баннеры от рекламных сетей приносили по 20-30 т.р. ещё в то время, когда их покупательская способность была выше. Это примерно 2019-2020 год. Потом в 22-м заблокировали Adsense и доход упал где-то до 5 т.р. Я сетевые баннеры вообще снял. Оставил ровно один от Яндекса в середине статей, чтобы он ранжирование не понижал. Яндекс отдаёт больше предпочтения тем сайтам, где есть его реклама.
С тех пор поддерживаю сайт в минимально живом виде, чтобы совсем не забрасывать. Хочется ещё когда-нибудь поработать над ним и сделать что-то интересное и полезное.
#1С #webserver
⇨ Публикация баз 1С на веб севере Apache в Debian
Хотел по-быстрому всё сделать, чтобы потом, если придётся настраивать, просто копипастом всё сделать. Но как обычно разошёлся, написал и про лицензии, и про сеансы, и про обратное проксирование через второй веб сервер, и про распределение функциональности по виртуалкам. В общем, написал всё, что вспомнил по ходу дела. Хотел ещё и про логи, мониторинг, файрвол написать, но не стал. Времени не осталось, да и не захотелось всё в кучу мешать. Надо разделять на темы и объединять ссылками.
Давно не писал новые статьи. А мне это нравится. Прям натуральное удовольствие получаю от их написания. Есть какое-то призвание и способности к этому. Мечтаю, когда дети подрастут и снизится финансовая нагрузка, потратить часть времени на создание какой-то связанной информационной библиотеки или обучающих курсов на отдельные изолированные темы, типа мониторинга или сбора логов. Жаль, что современные технологии напрочь убили монетизацию обычных статейных сайтов. Уже по-всякому прикидывал и тестировал монетизацию, но увы, дохода там почти нет. На это не прожить и даже как дополнительный заработок не тянет, поэтому остаётся только как хобби.
Это я на всякий случай предупреждаю тех, кто может строить планы по созданию сайта и получению какого-то прямого дохода с него. Я по всем своим делам строго веду бухгалтерию и точно знаю, где и как я получаю доход. В лучшие годы баннеры от рекламных сетей приносили по 20-30 т.р. ещё в то время, когда их покупательская способность была выше. Это примерно 2019-2020 год. Потом в 22-м заблокировали Adsense и доход упал где-то до 5 т.р. Я сетевые баннеры вообще снял. Оставил ровно один от Яндекса в середине статей, чтобы он ранжирование не понижал. Яндекс отдаёт больше предпочтения тем сайтам, где есть его реклама.
С тех пор поддерживаю сайт в минимально живом виде, чтобы совсем не забрасывать. Хочется ещё когда-нибудь поработать над ним и сделать что-то интересное и полезное.
#1С #webserver
Server Admin
Настройка публикации баз 1С на веб сервере в Debian
Пошаговая настройка веб-публикации баз 1С, расположенных на сервере на базе ОС Debian с помощью веб сервера Apache.
Уже довольно давно существует веб сервер Caddy. Он особо не на слуху в плане использования в качестве одиночного веб сервера. Но лично я его часто вижу в составе каких-то программных комплексов, собранных из различных open source проектов.
В простых случаях Caddy может очень серьёзно упростить задачу по веб доступу к чему-либо или проксированию запросов на внутренний веб ресурс. Покажу сразу на примерах, чтобы вы оценили, взяли на вооружение и использовали по мере необходимости.
Устанавливаем Caddy на сервер с Debian:
Это если вы хотите, чтобы у вас всё было как обычно - обновление из репозитория, конфигурационный файл, systemd служба и т.д. Сам по себе Caddy - это одиночный бинарный файл. Его можно просто скачать и установить на любой Linux сервер:
Windows, он, кстати, тоже поддерживает. Это может быть хорошим решением для проксирования веб публикации баз 1С в Windows с помощью Apache. Принимаем все запросы в Caddy, передаём в Apache.
По умолчанию Caddy работает сразу по протоколу HTTPS. Если для доменного имени настроена DNS запись, то он автоматом при запуске получает сертификат от let's encrypt и использует. Достаточно нарисовать вот такой простой конфиг
После перезапуска Caddy автоматически получит сертификаты для домена example.com и запустит статический сайт на HTTPS.
Пример конфигурации для проксирования:
Тут всё то же самое. Caddy автоматом получит сертификат, запустится с использованием HTTPS и будет работать в качестве reverse proxy для указанного адреса.
Всё то же самое можно запустить сразу в консоли, если вам это нужно для каких-то разовых задач:
В консольном режиме Caddy удобно использовать даже для разового получения сертификатов. Запустил по примеру выше и получил на выходе сертификаты в директории
Пример для php сайта, типа Worpdress:
Простой и функциональный веб сервер. У него нормальная документация, где все возможности описаны. Я показал примеры для консольного режима и обычного конфигурационного файла. Дополнительно он поддерживает конфигурацию в формате JSON, которую помимо текстового файла, можно передавать напрямую через API. В документации есть примеры.
Если вы не хотите или вам не нужно разбираться в конфигурация Nginx или Apache, а надо, чтобы просто работало, то Caddy - отличный вариант типового веб сервера для общих прикладных задач. При этом он обладает дополнительными возможностями, актуальными для современной эксплуатации:
◽️логи в формате json;
◽️экспорт метрик в формате prometheus;
◽️обновление и перезагрузка конфигурации на лету через API;
◽️снятие профилей для профилировщика pprof.
Он в настройках по умолчанию простой, но при желании можно много всего добавить.
⇨ 🌐 Сайт / Исходники (58.5k⭐️ 😱)
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver
В простых случаях Caddy может очень серьёзно упростить задачу по веб доступу к чему-либо или проксированию запросов на внутренний веб ресурс. Покажу сразу на примерах, чтобы вы оценили, взяли на вооружение и использовали по мере необходимости.
Устанавливаем Caddy на сервер с Debian:
# apt install debian-keyring debian-archive-keyring apt-transport-https curl# curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg# curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.listapt update && apt install caddyЭто если вы хотите, чтобы у вас всё было как обычно - обновление из репозитория, конфигурационный файл, systemd служба и т.д. Сам по себе Caddy - это одиночный бинарный файл. Его можно просто скачать и установить на любой Linux сервер:
# curl -sS https://webi.sh/caddy | shWindows, он, кстати, тоже поддерживает. Это может быть хорошим решением для проксирования веб публикации баз 1С в Windows с помощью Apache. Принимаем все запросы в Caddy, передаём в Apache.
По умолчанию Caddy работает сразу по протоколу HTTPS. Если для доменного имени настроена DNS запись, то он автоматом при запуске получает сертификат от let's encrypt и использует. Достаточно нарисовать вот такой простой конфиг
/etc/caddy/Caddyfile:example.com { root * /var/www file_server}# systemctl restart caddyПосле перезапуска Caddy автоматически получит сертификаты для домена example.com и запустит статический сайт на HTTPS.
Пример конфигурации для проксирования:
example.com { reverse_proxy 10.20.1.50:5000}Тут всё то же самое. Caddy автоматом получит сертификат, запустится с использованием HTTPS и будет работать в качестве reverse proxy для указанного адреса.
Всё то же самое можно запустить сразу в консоли, если вам это нужно для каких-то разовых задач:
# caddy file-server --domain example.com --root /var/www # caddy reverse-proxy --from example.com --to 10.20.1.50:5000В консольном режиме Caddy удобно использовать даже для разового получения сертификатов. Запустил по примеру выше и получил на выходе сертификаты в директории
~/.local/share/caddy/certificates/. Если используется служба, то она по умолчанию хранит сертификаты в /var/lib/caddy/.local/share/caddy/certificates/. Пример для php сайта, типа Worpdress:
example.com { root * /var/www file_server { index index.php } php_fastcgi unix//run/php/php8.2-fpm.sock}Простой и функциональный веб сервер. У него нормальная документация, где все возможности описаны. Я показал примеры для консольного режима и обычного конфигурационного файла. Дополнительно он поддерживает конфигурацию в формате JSON, которую помимо текстового файла, можно передавать напрямую через API. В документации есть примеры.
Если вы не хотите или вам не нужно разбираться в конфигурация Nginx или Apache, а надо, чтобы просто работало, то Caddy - отличный вариант типового веб сервера для общих прикладных задач. При этом он обладает дополнительными возможностями, актуальными для современной эксплуатации:
◽️логи в формате json;
◽️экспорт метрик в формате prometheus;
◽️обновление и перезагрузка конфигурации на лету через API;
◽️снятие профилей для профилировщика pprof.
Он в настройках по умолчанию простой, но при желании можно много всего добавить.
⇨ 🌐 Сайт / Исходники (58.5k⭐️ 😱)
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver
Познакомлю вас с очень любопытной веб панелью для мониторинга и управления сайтами. Речь пойдёт про Tianji. В недавней подборке видео я добавлял ролик с обзором этой панели. Она мне показалась интересной, поэтому развернул и попробовал сам. Расскажу про неё подробнее.
Сразу отмечу, кому будет наиболее актуальна эта панель - тем, кто работает непосредственно с сайтами, с их аналитикой, и немного с поддержкой самого сервера, но не обязательно. Можно развернуть панель и отдать кому-то в пользование даже без знаний администрирования.
📌 Основные возможноcти Tianji:
1️⃣ Аналитика посещений. Условный аналог Яндекс метрики и Google Analytics. Построена на базе Umami. Размещаете небольшой js код на своём сайте и смотрите в Tianji основные метрики посещений. Может быть неплохим дополнением к публичной аналитике, которая блокируется блокировщиками рекламы. Можно изменить имя js скрипта и проходить мимо блокировщиков.
2️⃣ Мониторинг сайтов и серверов. Используется встроенная Uptime Kuma. Доступны базовые проверки ICMP, TCP, HTTP запросов и ответов.
3️⃣ Мониторинг базовых метрик серверов путём установки на них небольшого агента. В описании нигде не увидел, что за агент используется. На вид самописный на GO. Показывает имя сервера, загрузку процессора, памяти, диска, текущий и суммарный сетевой трафик на интерфейсах, время работы сервера.
4️⃣ Телеметрия. Так назван раздел, который позволяет произвольно на сайте расставлять метки для мониторинга посещаемости. Выбираете любую страницу на сайте и помещаете в код прозрачную картинку в 1 пиксель. Каждая загрузка этой картинки будет увеличивать счётчик посещений. Таким образом можно отслеживать посещаемость отдельных страниц на сайте. Собранную метрику можно расположить где-то на сайте в виде кнопки со статистикой.
5️⃣ Публичные страницы мониторинга. Вы можете создать отдельную страницу, на которую можно поместить выбранные метрики из мониторинга.
Остальные возможности показались не особо полезными и доработанными. А то, что я перечислил уже работает нормально.
Запустить эту панель можно через Docker. В репозитории лежит docker-compose.yml. Сразу скажу, что в нём нужно изменить для успешного запуска. Во-первых, удалите:
Это в современных версиях композа не нужно. Далее удаляем сборку образа, так как будет использоваться готовый с docker hub:
Указываем последнюю версию образа:
Переменную ALLOW_OPENAPI выставляем в false:
И добавляем любой ключ в переменную OPENAI_API_KEY. Без неё контейнер будет падать с ошибкой, даже если вы OpenAI отключили :
После этого можно запускать. Вот моя итоговая рабочая версия. Веб панель будет доступна по IP адресу сервера и порту 12345. Учётка по умолчанию: admin / admin.
Когда будете тестировать посещаемость сайта, имейте ввиду, что по умолчанию панель работает по HTTP, соответственно, код счётчика тоже будет загружаться по HTTP. Скорее всего браузеры будут его блокировать, так как все сайты сейчас по HTTPS работают. В боевом режиме панель надо размещать за обратный прокси с HTTPS. Ну а для теста можете разместить на каком-то внутреннем сайте, работающем по HTTP.
Панель мне понравилась. Сделана удобно и добротно. Проект молодой, но в репозитории большая активность, как по обновлениям, так и по ошибкам. Она идеально подойдёт для каких-нибудь веб-мастеров и сеошников, которые сами умеют покупать хостинг и разворачивать там сайты. Панелька сильно упростить жизнь, добавив некоторые удобства. Не нужны знания системного администрирования. Развернул и добавляй свои сайты, сервера через веб панель.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #мониторинг #сайт
Сразу отмечу, кому будет наиболее актуальна эта панель - тем, кто работает непосредственно с сайтами, с их аналитикой, и немного с поддержкой самого сервера, но не обязательно. Можно развернуть панель и отдать кому-то в пользование даже без знаний администрирования.
📌 Основные возможноcти Tianji:
1️⃣ Аналитика посещений. Условный аналог Яндекс метрики и Google Analytics. Построена на базе Umami. Размещаете небольшой js код на своём сайте и смотрите в Tianji основные метрики посещений. Может быть неплохим дополнением к публичной аналитике, которая блокируется блокировщиками рекламы. Можно изменить имя js скрипта и проходить мимо блокировщиков.
2️⃣ Мониторинг сайтов и серверов. Используется встроенная Uptime Kuma. Доступны базовые проверки ICMP, TCP, HTTP запросов и ответов.
3️⃣ Мониторинг базовых метрик серверов путём установки на них небольшого агента. В описании нигде не увидел, что за агент используется. На вид самописный на GO. Показывает имя сервера, загрузку процессора, памяти, диска, текущий и суммарный сетевой трафик на интерфейсах, время работы сервера.
4️⃣ Телеметрия. Так назван раздел, который позволяет произвольно на сайте расставлять метки для мониторинга посещаемости. Выбираете любую страницу на сайте и помещаете в код прозрачную картинку в 1 пиксель. Каждая загрузка этой картинки будет увеличивать счётчик посещений. Таким образом можно отслеживать посещаемость отдельных страниц на сайте. Собранную метрику можно расположить где-то на сайте в виде кнопки со статистикой.
5️⃣ Публичные страницы мониторинга. Вы можете создать отдельную страницу, на которую можно поместить выбранные метрики из мониторинга.
Остальные возможности показались не особо полезными и доработанными. А то, что я перечислил уже работает нормально.
Запустить эту панель можно через Docker. В репозитории лежит docker-compose.yml. Сразу скажу, что в нём нужно изменить для успешного запуска. Во-первых, удалите:
version: '3'Это в современных версиях композа не нужно. Далее удаляем сборку образа, так как будет использоваться готовый с docker hub:
build: context: ./ dockerfile: ./DockerfileУказываем последнюю версию образа:
image: moonrailgun/tianji:latestПеременную ALLOW_OPENAPI выставляем в false:
ALLOW_OPENAPI: "false"И добавляем любой ключ в переменную OPENAI_API_KEY. Без неё контейнер будет падать с ошибкой, даже если вы OpenAI отключили :
OPENAI_API_KEY: "12333333333333333333"После этого можно запускать. Вот моя итоговая рабочая версия. Веб панель будет доступна по IP адресу сервера и порту 12345. Учётка по умолчанию: admin / admin.
Когда будете тестировать посещаемость сайта, имейте ввиду, что по умолчанию панель работает по HTTP, соответственно, код счётчика тоже будет загружаться по HTTP. Скорее всего браузеры будут его блокировать, так как все сайты сейчас по HTTPS работают. В боевом режиме панель надо размещать за обратный прокси с HTTPS. Ну а для теста можете разместить на каком-то внутреннем сайте, работающем по HTTP.
Панель мне понравилась. Сделана удобно и добротно. Проект молодой, но в репозитории большая активность, как по обновлениям, так и по ошибкам. Она идеально подойдёт для каких-нибудь веб-мастеров и сеошников, которые сами умеют покупать хостинг и разворачивать там сайты. Панелька сильно упростить жизнь, добавив некоторые удобства. Не нужны знания системного администрирования. Развернул и добавляй свои сайты, сервера через веб панель.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #мониторинг #сайт
На прошлой неделе смотрел видео про необычную систему под названием Pangolin. Не стал про него упоминать, потому что толком не понял, что это за штука, хоть и подозревал, что что-то полезное. В итоге я её развернул, разобрался, как работает, и теперь расскажу своими словами. Это очень крутой и полезный софт, который, думаю, многим пригодится.
Pangolin - обратный прокси на базе Traefik со своей системой аутентификации или IAM (Identity and Access Management). Он способен объединять разрозненные веб сервера с помощью встроенной интеграции с Wireguard. Расскажу сразу на конкретном примере, как это работает.
Допустим у вас есть веб сервер с каким-то сайтом или другим веб-приложением, к которому вы хотите ограничить доступ, так как у него нет своей аутентификации, или вы просто хотите его скрыть от посторонних глаз. Рассказываю по шагам, что вам нужно будет сделать.
1️⃣ Покупаете или создаёте любую VPS с внешним IP и настроенной DNS записью. Устанавливаете туда Pangolin.
2️⃣ Создаёте в веб панели Pangolin так называемый сайт, что на самом деле означает отдельный веб сервер.
3️⃣ Получаете в Pangolin параметры подключения внешнего веб сервера к серверу с Pangolin. Он может использовать как стандартный WireGuard клиент, так и свой собственный под названием Newt. Это консольная программа, не требующая для установки туннеля прав root. В Pangolin вы получите готовую строку подключения типа:
для подключения веб сервера к Pangolin.
4️⃣ После того, как веб сервер подключится к Pangolin, создаёте у него в веб интерфейсе новый ресурс, который по сути является сайтом, к которому нужно ограничить доступ. Указываете URL, по которому он должен отвечать, IP адрес и порт на веб сервере, куда будут проксироваться запросы.
5️⃣ Меняете DNS запись сайта на IP адрес сервера Pangolin. Теперь он будет перенаправлять все запросы через WG туннель настроенного урла на веб сервер. То есть работает как обычный обратный прокси, только все запросы к веб серверу заворачивает в VPN.
6️⃣ В свойствах сайта в веб интерфейсе Pangolin настраиваете параметры доступа. Это может быть пользователь или роль на самом Pangolin, одиночный пароль или 6-ти значный PIN код.
7️⃣ Теперь при открытие настроенного урла, запрос будет уходить на сервер Pangolin. После успешной аутентификации запрос будет перенаправлен на веб сервер.
Всё это работает по HTTPS, сертификаты Let's Encrypt получаются автоматически. Сервер Pangolin собран в Docker контейнеры. Можно запускать его вручную через Docker Compose или использовать готовый установщик:
Я развернул, довольно быстро разобрался и закрыл аутентификацией тестовый сайт, который запустил на этом же VPS через Nginx на других портах. Каких-то особых проблем не было.
Я не раз видел в чате вопросы на тему того, как закрыть аутентификацией сайт, в котором её нет. До этого я рекомендовал взять Authentik, настроить там интеграцию с каким-то обратным прокси и его basic_auth и таким образом закрыть доступ. Но этот путь гораздо сложнее того, что я описал сейчас. Тут всё проще и быстрее. Разворачиваете Pangolin, создаёте пользователей, настраиваете проксирование и закрываете доступ к сайту.
⇨ 🌐 Сайт / Исходники / Видеообзор
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #wireguard #traefik #sso
Pangolin - обратный прокси на базе Traefik со своей системой аутентификации или IAM (Identity and Access Management). Он способен объединять разрозненные веб сервера с помощью встроенной интеграции с Wireguard. Расскажу сразу на конкретном примере, как это работает.
Допустим у вас есть веб сервер с каким-то сайтом или другим веб-приложением, к которому вы хотите ограничить доступ, так как у него нет своей аутентификации, или вы просто хотите его скрыть от посторонних глаз. Рассказываю по шагам, что вам нужно будет сделать.
# newt --id qqsyaa51zaovqdn --secret wyfbohgwk1uohzj2u8n2t4xn9gny9czgw7jmx3dk1nys755r --endpoint https://336261.simplecloud.ruдля подключения веб сервера к Pangolin.
Всё это работает по HTTPS, сертификаты Let's Encrypt получаются автоматически. Сервер Pangolin собран в Docker контейнеры. Можно запускать его вручную через Docker Compose или использовать готовый установщик:
# wget -O installer "https://github.com/fosrl/pangolin/releases/download/1.0.0-beta.8/installer_linux_amd64" && chmod +x ./installerЯ развернул, довольно быстро разобрался и закрыл аутентификацией тестовый сайт, который запустил на этом же VPS через Nginx на других портах. Каких-то особых проблем не было.
Я не раз видел в чате вопросы на тему того, как закрыть аутентификацией сайт, в котором её нет. До этого я рекомендовал взять Authentik, настроить там интеграцию с каким-то обратным прокси и его basic_auth и таким образом закрыть доступ. Но этот путь гораздо сложнее того, что я описал сейчас. Тут всё проще и быстрее. Разворачиваете Pangolin, создаёте пользователей, настраиваете проксирование и закрываете доступ к сайту.
⇨ 🌐 Сайт / Исходники / Видеообзор
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #wireguard #traefik #sso
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Протокол НТТРv3, или как ещё называют эту версию QUIC, появился довольно давно. Практические реализации появились ещё в 2020-м году. Я всё как-то мимо него проходил, не погружался и не настраивал. На прошлой неделе вышло видео:
▶️ Ускоряем HTTP/3: DNS-записи HTTPS
В настройке HTTPv3 ничего сложного нет, так что решил разобраться, попробовать и дальше уже включать по умолчанию. Никаких технических преград сейчас к этому нет.
Для работы HTTP версии 3 нужно выполнить несколько шагов.
1️⃣ В настройке веб сервера включить его поддержку. В Nginx/Angie это делается следующим образом. Добавляем уже к существующим параметрам виртуального хоста с HTTPS следующие настройки:
Обращаю внимание на важный момент. В пакетах Angie из репозиториев разработчиков модуль http_v3_module включён по умолчанию. Не проверял его наличие в пакетах с Nginx. DeepSeek посоветовал вручную собрать Nginx с параметром
И второй момент. Я изначально add_header добавил не в корневой location, а в параметры сервера, где добавляются другие заголовки. HTTPv3 не заработал. Долго выяснял, в чём дело. Думал, это формальность. Я обычно всегда заголовки ко всему серверу применяю, а не location. Но тут, судя по всему, это имеет принципиальное значение.
2️⃣ Открываем на файрволе порт 443 UDP, так как QUIC работает по UDP. Я сначала тоже забыл это сделать. У меня по умолчанию всё, что не надо, закрыто, поэтому ничего не заработало. Быстро сообразил, что надо открыть UDP порт.
Этих настроек уже достаточно, чтобы HTTPv3 заработал, но не с первого запроса. По умолчанию браузер обращается по v2 и только после того, как придёт настроенный заголовок, переходит на v3. А первые несколько запросов улетают по v2.
Чтобы это исправить, придумана новая DNS запись типа HTTPS. Браузер, при обращении к сайту, ищет A запись и параллельно запрашивает HTTPS. Если она есть и там указано, что сайт поддерживает работу HTTPv3, он сразу обращается по v3.
Не все DNS хостинги поддерживают этот тип записи. Например, DNS от Яндекса не позволяет создать эту запись. Я в итоге от него отказался. Бесплатный DNS хостинг есть у Selectel. Причём недавно они выпустили новую версию этого хостинга и всем предлагают туда перейти. Мне как-то лень переносить было, и так всё работает. Но старая версия DNS хостинга не поддерживает эти записи. Пришлось перейти на новую. Там без проблем создал HTTPS запись. Выглядит она примерно так:
1 - приоритет
. - основное доменное имя, аналог serveradmin.ru
alpn="h3,h2" - указание на поддержку версии HTTPv3 и HTTPv2
3️⃣ Таким образом, третий пункт – добавление DNS записи типа HTTPS.
После этого сайт с первого запроса стал работать по протоколу третьей версии.
В настройке нет никаких проблем, можно прямо сейчас использовать новую версию протокола. К тому же это максимально безопасно, так как современные браузеры всегда делают попытку открыть сайт и по v2. Если вы где-то ошибётесь в настройке, то v3 просто не заработает. Я в этом убедился на практике. Когда что-то было не так, сайт работал как и прежде. И только после того, как всё сделал правильно, заработал HTTPv3.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #angie
▶️ Ускоряем HTTP/3: DNS-записи HTTPS
В настройке HTTPv3 ничего сложного нет, так что решил разобраться, попробовать и дальше уже включать по умолчанию. Никаких технических преград сейчас к этому нет.
Для работы HTTP версии 3 нужно выполнить несколько шагов.
1️⃣ В настройке веб сервера включить его поддержку. В Nginx/Angie это делается следующим образом. Добавляем уже к существующим параметрам виртуального хоста с HTTPS следующие настройки:
listen 443 quic reuseport;http3 on;location / { add_header Alt-Svc 'h3=":443"; ma=86400';}Обращаю внимание на важный момент. В пакетах Angie из репозиториев разработчиков модуль http_v3_module включён по умолчанию. Не проверял его наличие в пакетах с Nginx. DeepSeek посоветовал вручную собрать Nginx с параметром
--with-http_v3_module. И второй момент. Я изначально add_header добавил не в корневой location, а в параметры сервера, где добавляются другие заголовки. HTTPv3 не заработал. Долго выяснял, в чём дело. Думал, это формальность. Я обычно всегда заголовки ко всему серверу применяю, а не location. Но тут, судя по всему, это имеет принципиальное значение.
2️⃣ Открываем на файрволе порт 443 UDP, так как QUIC работает по UDP. Я сначала тоже забыл это сделать. У меня по умолчанию всё, что не надо, закрыто, поэтому ничего не заработало. Быстро сообразил, что надо открыть UDP порт.
Этих настроек уже достаточно, чтобы HTTPv3 заработал, но не с первого запроса. По умолчанию браузер обращается по v2 и только после того, как придёт настроенный заголовок, переходит на v3. А первые несколько запросов улетают по v2.
Чтобы это исправить, придумана новая DNS запись типа HTTPS. Браузер, при обращении к сайту, ищет A запись и параллельно запрашивает HTTPS. Если она есть и там указано, что сайт поддерживает работу HTTPv3, он сразу обращается по v3.
Не все DNS хостинги поддерживают этот тип записи. Например, DNS от Яндекса не позволяет создать эту запись. Я в итоге от него отказался. Бесплатный DNS хостинг есть у Selectel. Причём недавно они выпустили новую версию этого хостинга и всем предлагают туда перейти. Мне как-то лень переносить было, и так всё работает. Но старая версия DNS хостинга не поддерживает эти записи. Пришлось перейти на новую. Там без проблем создал HTTPS запись. Выглядит она примерно так:
# dig serveradmin.ru HTTPSserveradmin.ru. 3600 IN HTTPS 1 . alpn="h3,h2"1 - приоритет
. - основное доменное имя, аналог serveradmin.ru
alpn="h3,h2" - указание на поддержку версии HTTPv3 и HTTPv2
3️⃣ Таким образом, третий пункт – добавление DNS записи типа HTTPS.
После этого сайт с первого запроса стал работать по протоколу третьей версии.
В настройке нет никаких проблем, можно прямо сейчас использовать новую версию протокола. К тому же это максимально безопасно, так как современные браузеры всегда делают попытку открыть сайт и по v2. Если вы где-то ошибётесь в настройке, то v3 просто не заработает. Я в этом убедился на практике. Когда что-то было не так, сайт работал как и прежде. И только после того, как всё сделал правильно, заработал HTTPv3.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #angie
С момента первого моего упоминания сервиса axiom.co, продолжаю его использовать. Вновь пишу о нём, чтобы рассказать тем, кто не видел эту информацию. Очень простой в настройке и удобный в использовании для хранения и анализа логов веб сервера. Я пользуюсь полностью бесплатным тарифом, который не требует никаких подтверждений и персональных данных. Аутентификация через учётку на github. При этом позволяет хранить 500GB логов в месяц. Мне этого за глаза.
Про настройку и использование я уже писал ранее. По настройке с тех пор ничего не поменялось. Для отправки используется Vector (иногда падает, надо мониторить и переподнимать), у него встроенная интеграция с axiom.
Axiom условно можно назвать аналогом ELK, только сильно урезанным в плане функциональности. Из-за этого его особо не надо изучать. Отправляешь туда логи, заходишь и мышкой создаёшь нужные дашборды, запросы, отчёты. С ELK так не получится. В новых версиях даже заходить не хочется в виджеты и дашборды. Каждый раз, как первый раз, приходится вспоминать, как тут что-то сделать и построить нужную визуализацию.
Например, я позавчера включил на сайте протокол HTTPv3. Решил сходить посмотреть, сколько запросов по этому протоколу выполняется. Сбор логов настроен по указанной выше ссылке. В веб интерфейсе axiom иду в раздел Query и мышкой в конструкторе строю запрос: Dataset = serveradmin.ru, Where != http_version, Summarize count(), group by http_version.
И получил график растущего использования HTTPv3. Протокол используется.
Или вот ещё пример. Посмотрим, по каким url на запросы выходят 404 коды ответов. Dataset = serveradmin.ru, Where status =~ "404", Summarize count(), group by url.
Думаю, идея понятна. В сервисе ничего такого особенного нет, чего нельзя было бы сделать где-то в другом месте. То же самое можно сделать в ELK, Graylog, Loki, Goaccess. Но тут всё бесплатно, ничего настраивать не надо. Просто оправляем логи и пользуемся. Разумеется, если у вас там ничего секретного нет. А то уже предвижу комментарии на тему того, что я свои секретные логи веб сервера никому показывать не могу. Если не можете, то не используйте облачные сервисы. Тут всё очевидно. Наверняка они эти данные как-то используют, иначе откуда такая щедрость.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #webserver
Про настройку и использование я уже писал ранее. По настройке с тех пор ничего не поменялось. Для отправки используется Vector (иногда падает, надо мониторить и переподнимать), у него встроенная интеграция с axiom.
Axiom условно можно назвать аналогом ELK, только сильно урезанным в плане функциональности. Из-за этого его особо не надо изучать. Отправляешь туда логи, заходишь и мышкой создаёшь нужные дашборды, запросы, отчёты. С ELK так не получится. В новых версиях даже заходить не хочется в виджеты и дашборды. Каждый раз, как первый раз, приходится вспоминать, как тут что-то сделать и построить нужную визуализацию.
Например, я позавчера включил на сайте протокол HTTPv3. Решил сходить посмотреть, сколько запросов по этому протоколу выполняется. Сбор логов настроен по указанной выше ссылке. В веб интерфейсе axiom иду в раздел Query и мышкой в конструкторе строю запрос: Dataset = serveradmin.ru, Where != http_version, Summarize count(), group by http_version.
['serveradmin.ru']| where isnotempty(http_version)| summarize count() by bin_auto(_time), http_versionИ получил график растущего использования HTTPv3. Протокол используется.
Или вот ещё пример. Посмотрим, по каким url на запросы выходят 404 коды ответов. Dataset = serveradmin.ru, Where status =~ "404", Summarize count(), group by url.
['serveradmin.ru']| where status =~ "404"| summarize count() by bin_auto(_time), urlДумаю, идея понятна. В сервисе ничего такого особенного нет, чего нельзя было бы сделать где-то в другом месте. То же самое можно сделать в ELK, Graylog, Loki, Goaccess. Но тут всё бесплатно, ничего настраивать не надо. Просто оправляем логи и пользуемся. Разумеется, если у вас там ничего секретного нет. А то уже предвижу комментарии на тему того, что я свои секретные логи веб сервера никому показывать не могу. Если не можете, то не используйте облачные сервисы. Тут всё очевидно. Наверняка они эти данные как-то используют, иначе откуда такая щедрость.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #webserver
Основной вопрос, который возникает при включении прокола HTTPv3 для сайта: "А какая разница с прошлым протоколом? Зачем включать?". Я решил провести некоторые тесты на своём реальном сайте, включая и отключая h3. Для тестов взял хорошо известный мне инструмент WebPageTest и запустил у себя.
Как обычно, он не собрался без ошибок, пришлось поковыряться. Если кому-то интересен этот локальный сервис для теста производительности сайтов, дайте знать. Сделаю по нему свежую заметку, как собрать и запустить самую свежую версию сервера и агента. Его удобно использовать, так как можно запускать локально и исключать влияние сторонних факторов, которые обязательно будут в публичных сервисах.
Запустил я локальную версию WebPageTest на своём сервере и прогнал серию тестов с отключенным h3 и включенным. Для каждого прогона делал по 9 тестов с двумя запусками, когда второй использует кэш после первого запуска. И сравнил результаты, как между одинаковыми тестами в рамках h2 и h3, так и между ними. Различия между однотипными тестами были минимальны. И между h2 и h3 разница была стабильная.
Результаты получились неоднозначными. Поленился поднять локальную копию сайта. Тестировал на рабочем, который опубликован в интернет. Интересно увидеть практические результаты, а не лабораторные. В итоге разница получилась незначительная в пользу h2. Можно сказать в пределах погрешности, кроме одного значения - Time To first Byte и как его следствие - время начала отрисовки Time to Start Render. В режиме h3 она неизменно была выше, чем в h2. То есть дольше приходил ответ на первый запрос, и позже начиналась отрисовка. Параметр TTFB важный с точки зрения СЕО, так что даже не знаю, как реагировать на эти измерения. По идее надо отключать h3.
Внимательно смотрел на результаты и сравнивал. H3 даёт по всем параметрам результаты не хуже h2, а где-то даже лучше. DNS Lookup одинаковый, то есть проседания на DNS запросы нет, Total Connection Time у h3 неизменно ниже, загрузка всех элементов чуть быстрее, но Time to First Byte, за который по идее отвечает непосредственно сервер, всегда у h3 выше и из-за этого едут все остальные метрики, так как и отрисовка, и полная загрузка начинают отставать. Такое ощущение, что причина в реализации h3 в самом веб сервере. Надо тестировать с другими, но это довольно хлопотно, если разворачивать реальный сайт, а не синтетические странички.
Внизу показал результат сравнения, где получилась наиболее усреднённая картинка. Думаю, что разверну сайт отдельно локально и потестирую. Надо понять, в каком режиме всё же лучше оставлять сайты. В целом, с обоими версиями HTTP у меня результат получился хорошим, ниже рекомендованного порога, который считается хорошим результатом. Но всё равно, чем меньше, тем лучше. HTTPv3 пока отключил.
Было бы интересно узнать, если кто-то делал подобные тесты или видел где-то результаты. Нет возможности посвятить много времени этому вопросу, чтобы окончательно разобраться. Один сайт и веб сервер - не показатель. Надо массовые тесты делать.
#webserver #webpagetest
Как обычно, он не собрался без ошибок, пришлось поковыряться. Если кому-то интересен этот локальный сервис для теста производительности сайтов, дайте знать. Сделаю по нему свежую заметку, как собрать и запустить самую свежую версию сервера и агента. Его удобно использовать, так как можно запускать локально и исключать влияние сторонних факторов, которые обязательно будут в публичных сервисах.
Запустил я локальную версию WebPageTest на своём сервере и прогнал серию тестов с отключенным h3 и включенным. Для каждого прогона делал по 9 тестов с двумя запусками, когда второй использует кэш после первого запуска. И сравнил результаты, как между одинаковыми тестами в рамках h2 и h3, так и между ними. Различия между однотипными тестами были минимальны. И между h2 и h3 разница была стабильная.
Результаты получились неоднозначными. Поленился поднять локальную копию сайта. Тестировал на рабочем, который опубликован в интернет. Интересно увидеть практические результаты, а не лабораторные. В итоге разница получилась незначительная в пользу h2. Можно сказать в пределах погрешности, кроме одного значения - Time To first Byte и как его следствие - время начала отрисовки Time to Start Render. В режиме h3 она неизменно была выше, чем в h2. То есть дольше приходил ответ на первый запрос, и позже начиналась отрисовка. Параметр TTFB важный с точки зрения СЕО, так что даже не знаю, как реагировать на эти измерения. По идее надо отключать h3.
Внимательно смотрел на результаты и сравнивал. H3 даёт по всем параметрам результаты не хуже h2, а где-то даже лучше. DNS Lookup одинаковый, то есть проседания на DNS запросы нет, Total Connection Time у h3 неизменно ниже, загрузка всех элементов чуть быстрее, но Time to First Byte, за который по идее отвечает непосредственно сервер, всегда у h3 выше и из-за этого едут все остальные метрики, так как и отрисовка, и полная загрузка начинают отставать. Такое ощущение, что причина в реализации h3 в самом веб сервере. Надо тестировать с другими, но это довольно хлопотно, если разворачивать реальный сайт, а не синтетические странички.
Внизу показал результат сравнения, где получилась наиболее усреднённая картинка. Думаю, что разверну сайт отдельно локально и потестирую. Надо понять, в каком режиме всё же лучше оставлять сайты. В целом, с обоими версиями HTTP у меня результат получился хорошим, ниже рекомендованного порога, который считается хорошим результатом. Но всё равно, чем меньше, тем лучше. HTTPv3 пока отключил.
Было бы интересно узнать, если кто-то делал подобные тесты или видел где-то результаты. Нет возможности посвятить много времени этому вопросу, чтобы окончательно разобраться. Один сайт и веб сервер - не показатель. Надо массовые тесты делать.
#webserver #webpagetest
Для Nginx существует очень много всевозможных веб панелей для управления. Сегодня расскажу об ещё одной, которая отличается от большинства из них. Речь пойдёт об open source проекте Nginx UI. Сразу перейду к сути и отмечу то, что понравилось больше всего:
🟢 Nginx UI не меняет стандартную структуру каталогов и расположение конфигурационных файлов, которые приняты в системе. Я проверял в Debian, всё на своих местах в
🟢 Вся панель - это бинарник
Остальные возможности Nginx UI:
◽️Управление виртуальными хостами, в том числе для проксирования: добавление, удаление, редактирование конфигурации через браузер.
◽️Получение и использование сертификатов от Let's Encrypt.
◽️Дашборд с базовыми метриками мониторинга сервера.
◽️Просмотр логов.
◽️Доступ к консоли сервера.
◽️Есть на выбор наборы готовых настроек для типовых проектов под веб сервер, типа wordpress, drupal и т.д. Они просто добавляют некоторые правила в виртуальные хосты.
◽️Своё состояние хранит в локальной sqlite базе рядом с конфигурационным файлом.
В целом ничего особенного, но сделано легко и аккуратно. Приятный и удобный веб интерфейс. Я быстро развернул сервер, всё настроил, попробовал.
Установка простая:
Я посмотрел скрипт, там ничего особенного. Скачивается бинарник, формируется конфигурация, создаётся юнит systemd. Есть собранный контейнер Docker. Не смотрел его.
После установки можно идти по IP адресу сервера на порт 9000 и выполнять настройку. У панели есть русский язык, но есть непереведённые разделы. Проект живой, поддерживается и развивается.
Можно посмотреть demo: https://demo.nginxui.com, учётка - admin / admin.
Панель в целом понравилась. Осталось приятное впечатление. Пользоваться удобно. Возможности ограничены только управлением стандартными конфигурациями Nginx. Для кого-то это будет плюс, для кого-то, возможно, минус.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #webserver
🟢 Nginx UI не меняет стандартную структуру каталогов и расположение конфигурационных файлов, которые приняты в системе. Я проверял в Debian, всё на своих местах в
/etc/nginx. Формат конфигурационных файлов такой, что можно свободно туда заглянуть, поправить, забрать и использовать там, где nginx-ui нет вообще. Если удалить панель, то Nginx со всеми настройками будет работать без неё.🟢 Вся панель - это бинарник
/usr/local/bin/nginx-ui и конфигурационный файл к нему /usr/local/etc/nginx-ui/app.ini(чувствуется старая школа в выборе размещения файлов). Указал конечное расположение файлов, если использовать предложенный скрипт для установки. Он скачивает исполняемый файл, формирует конфигурацию и создаёт службу в systemd.Остальные возможности Nginx UI:
◽️Управление виртуальными хостами, в том числе для проксирования: добавление, удаление, редактирование конфигурации через браузер.
◽️Получение и использование сертификатов от Let's Encrypt.
◽️Дашборд с базовыми метриками мониторинга сервера.
◽️Просмотр логов.
◽️Доступ к консоли сервера.
◽️Есть на выбор наборы готовых настроек для типовых проектов под веб сервер, типа wordpress, drupal и т.д. Они просто добавляют некоторые правила в виртуальные хосты.
◽️Своё состояние хранит в локальной sqlite базе рядом с конфигурационным файлом.
В целом ничего особенного, но сделано легко и аккуратно. Приятный и удобный веб интерфейс. Я быстро развернул сервер, всё настроил, попробовал.
Установка простая:
# apt install nginx# bash -c "$(curl -L https://raw.githubusercontent.com/0xJacky/nginx-ui/main/install.sh)" @ installЯ посмотрел скрипт, там ничего особенного. Скачивается бинарник, формируется конфигурация, создаётся юнит systemd. Есть собранный контейнер Docker. Не смотрел его.
После установки можно идти по IP адресу сервера на порт 9000 и выполнять настройку. У панели есть русский язык, но есть непереведённые разделы. Проект живой, поддерживается и развивается.
Можно посмотреть demo: https://demo.nginxui.com, учётка - admin / admin.
Панель в целом понравилась. Осталось приятное впечатление. Пользоваться удобно. Возможности ограничены только управлением стандартными конфигурациями Nginx. Для кого-то это будет плюс, для кого-то, возможно, минус.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#nginx #webserver
Если вам приходится обслуживать сайты, работающие на php, то расскажу про небольшую настройку, которая по умолчанию отключена, но в некоторых случаях её имеет смысл включить. Речь пойдёт про логирование использования функции mail(), с помощью которой можно отправлять email сообщения.
Хорошо, если веб приложение умеет использовать сторонние SMTP сервера для отправки почты, а не прямую отправку через встроенную функцию. Но это не всегда так. Другая сторона медали - если сайт или хостинг взломают, то часто начинают слать спам через php напрямую. Это самое популярное использование взломанного каким-нибудь ботом сайта через публичную уязвимость. Через него либо сразу спам начинают слать, либо ддосить кого-нибудь, реже - майнить. Майнинг сразу видно по возросшей нагрузке. А вот почту можно и не заметить.
Я обычно в таких случаях ставлю для локальной отправки postfix и слежу за его логом. Если вы с почтовыми серверами не особо знакомы, а вам нужен просто список отправленных писем, где одно письмо - одна строчка, то с логированием сдрествами php будет проще всего. К тому же этот лог в том числе покажет, какой конкретно скрипт сделал отправку, что в логе почтового сервера не увидеть, там этой информации в принципе нет.
Идём в настройки php, в файл
Можно направить вывод в какой-то текстовый файл вместо syslog, но могут возникнуть нюансы с доступом, если, к примеру, у вас используется php-fpm и для каждого сайта запускается пул под своим отдельным пользователем. Использовать syslog как единое централизованное хранилище - более универсальное решение. Но тут уже вам решать, как удобнее, в зависимости от ваших настроек. Можно и из syslog сложить все записи в отдельный файл, отфильтровав их по вхождению фразы mail().
Для этого рисуем конфиг для rsyslog в файле
Перезапускаем rsyslog:
И перезапускаем службу php в зависимости от того, в каком виде она используется. Отдельно отмечу, что, к примеру, в Debian файл php.ini для модуля Apache, для php-fpm, для запуска консольных скриптов через cli свой. Не перепутайте, куда будете вносить правки. Либо вносите сразу во все. Лучше создать отдельный файл, вместо правки общего. То есть для php-fpm кладём настройку примерно сюда:
Принудительно проверить работу можно простейшим скриптом такого содержания:
Запускаем скрипт:
В файле
Видим скрипт
Не забудьте настроить ротацию этого файла, если будете хранить лог в отдельном файле. Добавьте примерно такой конфиг для logrotate в файле
Я обычно складываю все старые логи в отдельную директорию. Не забудьте её создать, если скопируете этот конфиг. Если будете логировать не по дням, а по размеру файла, то не забудьте настроить запуск logrotate чаще, чем раз в сутки. И так же туда надо будет добавить вместо daily дополнительные параметры:
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #php
Хорошо, если веб приложение умеет использовать сторонние SMTP сервера для отправки почты, а не прямую отправку через встроенную функцию. Но это не всегда так. Другая сторона медали - если сайт или хостинг взломают, то часто начинают слать спам через php напрямую. Это самое популярное использование взломанного каким-нибудь ботом сайта через публичную уязвимость. Через него либо сразу спам начинают слать, либо ддосить кого-нибудь, реже - майнить. Майнинг сразу видно по возросшей нагрузке. А вот почту можно и не заметить.
Я обычно в таких случаях ставлю для локальной отправки postfix и слежу за его логом. Если вы с почтовыми серверами не особо знакомы, а вам нужен просто список отправленных писем, где одно письмо - одна строчка, то с логированием сдрествами php будет проще всего. К тому же этот лог в том числе покажет, какой конкретно скрипт сделал отправку, что в логе почтового сервера не увидеть, там этой информации в принципе нет.
Идём в настройки php, в файл
php.ini и раскомментируем там строку:mail.log = syslogМожно направить вывод в какой-то текстовый файл вместо syslog, но могут возникнуть нюансы с доступом, если, к примеру, у вас используется php-fpm и для каждого сайта запускается пул под своим отдельным пользователем. Использовать syslog как единое централизованное хранилище - более универсальное решение. Но тут уже вам решать, как удобнее, в зависимости от ваших настроек. Можно и из syslog сложить все записи в отдельный файл, отфильтровав их по вхождению фразы mail().
Для этого рисуем конфиг для rsyslog в файле
/etc/rsyslog.d/php-mail.conf::msg, contains, "mail()" /var/log/mail-php.log& stopПерезапускаем rsyslog:
# systemctl restart rsyslogИ перезапускаем службу php в зависимости от того, в каком виде она используется. Отдельно отмечу, что, к примеру, в Debian файл php.ini для модуля Apache, для php-fpm, для запуска консольных скриптов через cli свой. Не перепутайте, куда будете вносить правки. Либо вносите сразу во все. Лучше создать отдельный файл, вместо правки общего. То есть для php-fpm кладём настройку примерно сюда:
/etc/php/8.2/fpm/conf.d/mail-log.conf.Принудительно проверить работу можно простейшим скриптом такого содержания:
<?php$to = "user@example.com";$subject = "Привет от PHP!";$message = "Это тестовое письмо, отправленное через PHP скрипт.";mail($to, $subject, $message);?>Запускаем скрипт:
# php mail.phpВ файле
/var/log/mail-php.log наблюдаем запись:2025-06-09T00:07:09.607068+03:00 debian12-vm php: mail() on [/root/mail.php:5]: To: user@example.com -- Headers: -- Subject: Привет от PHP!Видим скрипт
/root/mail.php и конкретную строку 5, где сработала функция mail(). Это может очень пригодится при отладке неправомерных отправлений с сервера.Не забудьте настроить ротацию этого файла, если будете хранить лог в отдельном файле. Добавьте примерно такой конфиг для logrotate в файле
/etc/logrotate.d/mail-php:/var/log/mail-php.log { rotate 30 daily missingok notifempty compress olddir /var/log/old}Я обычно складываю все старые логи в отдельную директорию. Не забудьте её создать, если скопируете этот конфиг. Если будете логировать не по дням, а по размеру файла, то не забудьте настроить запуск logrotate чаще, чем раз в сутки. И так же туда надо будет добавить вместо daily дополнительные параметры:
size=50M dateext dateformat -%Y-%m-%d_%H-%s❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#webserver #php
Существует известный сервис Ngrok для публикации веб приложений без прямого доступа к ним из интернета. Сервис выступает условно как публичный обратный прокси для вашего проекта. У него есть аналоги - localtunnel и Cloudflare Argo Tunnel. На днях в Яндексе вбил Ngrok, хотел освежить о нём информацию, и тут же первой строкой мне выскочила реклама аналогичного российского сервиса cloudpub. У него есть бесплатный тарифный план, так что решил попробовать.
Кратко поясню, как эти сервисы работают. Допустим, вы запускаете где-то у себя в локальном окружении какой-то веб сервер, например Nginx. Для него нет никаких пробросов портов, он никак не опубликован в интернет. А вы хотите, чтобы из интернета кто-то на него попадал. Например, это ваш личный Proxmox, у вас серый IP от провайдера, вы не хотите настраивать VPN, но хотите попадать в веб интерфейс откуда угодно.
Для этого вы регистрируетесь в сервисе, скачиваете к себе на сервер их клиент, запускаете его. И дальше через личный кабинет настраиваете публикацию вашего локального веб сервиса, куда вы поставили этого клиента. Получаете какой-то URL на временном домене или подключаете свой. И по этому урлу заходите через интернет на свой сервис. Плюс, этот сервис обычно поддерживает дополнительную функциональность в виде TLS сертификатов, дополнительной аутентификации и т.д. Всё это довольно удобно и пользуется спросом как в корпоративном сегменте, так и у продвинутых домашних пользователей.
В cloudpub всё примерно так же. Зарегистрировался на сайте, достаточно только email. Телефон или что-то ещё не нужно. В личном кабинете сразу же открывается инструкция, как пользоваться:
1️⃣ Скачиваешь на машину клиент. Поддерживаются клиенты под Windows, Linux, macOS, либо универсальный в Docker. Есть как с GUI, так и полностью консольные.
2️⃣ Распаковываешь клиент, проходишь аутентификацию:
3️⃣ Публикуешь веб сервис, который тут крутится:
Получаешь ссылку на случайный поддомен на базе cloudpub.ru.
4️⃣ В личном кабинете видно эту публикацию. Её можно изменить: поменять поддомен, включить дополнительную аутентификацию, добавить какие-то заголовки к HTTP запросам.
Это я описал работу бесплатного тарифного плана, который автоматом подключается после регистрации. В целом всё просто и удобно. Нигде не столкнулся с какими-то проблемами. Отмечу, что сервис мне незнаком, увидел впервые. Автора или компанию, которая его поддерживает, тоже не знаю. Используйте на свой страх и риск. Код клиента, кстати, открыт. Сделан на базе rathole.
Сразу предупрежу, не надо писать, что это реклама и т.д. У меня никто не заказывал никакую рекламу. Первый раз увидел сервис и попробовал. Почему-то когда я обозреваю какие-то иностранные сервисы, никто не пишет, что это реклама. Стоит написать про что-то отечественное, так сразу появляются претензии, что я что-то рекламирую. Вся заказная реклама публикуется с маркировкой в соответствии с законом о рекламе. Без исключений. Всё, что без отметок, это моя личная инициатива. За всё время ведения канала не было ни одного исключения.
#webserver #отечественное
Кратко поясню, как эти сервисы работают. Допустим, вы запускаете где-то у себя в локальном окружении какой-то веб сервер, например Nginx. Для него нет никаких пробросов портов, он никак не опубликован в интернет. А вы хотите, чтобы из интернета кто-то на него попадал. Например, это ваш личный Proxmox, у вас серый IP от провайдера, вы не хотите настраивать VPN, но хотите попадать в веб интерфейс откуда угодно.
Для этого вы регистрируетесь в сервисе, скачиваете к себе на сервер их клиент, запускаете его. И дальше через личный кабинет настраиваете публикацию вашего локального веб сервиса, куда вы поставили этого клиента. Получаете какой-то URL на временном домене или подключаете свой. И по этому урлу заходите через интернет на свой сервис. Плюс, этот сервис обычно поддерживает дополнительную функциональность в виде TLS сертификатов, дополнительной аутентификации и т.д. Всё это довольно удобно и пользуется спросом как в корпоративном сегменте, так и у продвинутых домашних пользователей.
В cloudpub всё примерно так же. Зарегистрировался на сайте, достаточно только email. Телефон или что-то ещё не нужно. В личном кабинете сразу же открывается инструкция, как пользоваться:
1️⃣ Скачиваешь на машину клиент. Поддерживаются клиенты под Windows, Linux, macOS, либо универсальный в Docker. Есть как с GUI, так и полностью консольные.
# wget https://cloudpub.ru/download/stable/clo-1.7.0-stable-linux-x86_64.tar.gz2️⃣ Распаковываешь клиент, проходишь аутентификацию:
# tar xzvf clo-1.7.0-stable-linux-x86_64.tar.gz # ./clo login3️⃣ Публикуешь веб сервис, который тут крутится:
# ./clo publish http 80Получаешь ссылку на случайный поддомен на базе cloudpub.ru.
4️⃣ В личном кабинете видно эту публикацию. Её можно изменить: поменять поддомен, включить дополнительную аутентификацию, добавить какие-то заголовки к HTTP запросам.
Это я описал работу бесплатного тарифного плана, который автоматом подключается после регистрации. В целом всё просто и удобно. Нигде не столкнулся с какими-то проблемами. Отмечу, что сервис мне незнаком, увидел впервые. Автора или компанию, которая его поддерживает, тоже не знаю. Используйте на свой страх и риск. Код клиента, кстати, открыт. Сделан на базе rathole.
Сразу предупрежу, не надо писать, что это реклама и т.д. У меня никто не заказывал никакую рекламу. Первый раз увидел сервис и попробовал. Почему-то когда я обозреваю какие-то иностранные сервисы, никто не пишет, что это реклама. Стоит написать про что-то отечественное, так сразу появляются претензии, что я что-то рекламирую. Вся заказная реклама публикуется с маркировкой в соответствии с законом о рекламе. Без исключений. Всё, что без отметок, это моя личная инициатива. За всё время ведения канала не было ни одного исключения.
#webserver #отечественное