Когда, как не в выходной день поговорить об играх. Если у вас есть желание установить и настроить свой игровой сервер какой-нибудь популярной игры, можно воспользоваться Open Source проектом LinuxGSM (Linux Game Server Manager)

Это набор готовых скриптов для установки одного из 126 поддерживаемых игровых серверов. Список игр представлен на сайте. Там же подробное руководство по установке и управлению игровым сервером. Покажу на примере установки сервера Minecraft. Мне уже приходилось его устанавливать и настраивать для сына, только через Pterodactyl. Это похожая панель, только там список игр значительно меньше и запускается всё в Docker.

Возвращаемся к LinuxGSM. Идём на страницу с инструкцией для Minecraft Server и устанавливаем его. Я устанавливал на Ubuntu 20.04:
# dpkg --add-architecture i386
# apt update
# apt install curl wget file tar bzip2 gzip unzip \
bsdmainutils python3 util-linux ca-certificates \
binutils bc jq tmux netcat lib32gcc1 lib32stdc++6
# adduser mcbserver
# su - mcbserver
# wget -O linuxgsm.sh https://linuxgsm.sh
# chmod +x linuxgsm.sh
# bash linuxgsm.sh mcbserver
# ./mcbserver install

Можете наблюдать за процессом установки. Когда он успешно завершится, запустите сервер:
# ./mcbserver start
Убедитесь, что он стартовал, и служба сервера слушает порт:
# netstat -tulnp | grep 19132
udp    0   0 0.0.0.0:19132   0.0.0.0:*    47190/bedrock_serve
Можно подключаться к серверу. На всякий случай проверьте firewall - настройте или отключите его.

Сайт linuxgsm.com у меня открылся только через американский vpn, хотя docs.linuxgsm.com нормально открывался с московского ip. Не знаю, с чем это связано, не разбирался.

Сайт - https://linuxgsm.com
Исходники - https://github.com/GameServerManagers/LinuxGSM

#игра

Запускаете новый проект или есть потребность в масштабировании? 💪

Если потребность в вычислительных ресурсах становится все ощутимее, а сколько еще понадобится бизнесу — рассчитать непросто, то у нас есть выгодное решение.

300 000 бонусных рублей для запуска ИТ-инфраструктуры при подключении облака IaaS сегмента Gold 3.0.

 На что потратить 300 000 бонусных рублей? 🤔

➖ Запускайте ИТ-системы и цифровые бизнес-сервисы
➖ Управляйте вычислительными ресурсами
➖ Снизьте расходы на ИТ

Знакомьтесь с полными условиями акции и оставляйте заявку ➡️https://bit.ly/3NTBRal

#реклама

​​У меня было много заметок на тему бэкапа данных и ни одной за всё время существования канала на тему бэкапа настроек сетевых устройств. А тема-то важная. Настраивать какой-нибудь роутер с нуля с кучей правил firewall, qos, vpn и так далее та ещё морока. Потеря конфигурации обычно не фатальна, но очень неприятна.

Существует популярный Open Source продукт для бэкапа сетевых устройств - Oxidized. О нём рассказывали еще в 2017 году на MUM Russia (MikroTik User Meeting). Ссылка на презентацию. Как вы понимаете, Микротики он тоже бэкапит. Так что тема серьезная 😎. Список поддерживаемых устройств внушительный. Всё популярное присутствует, даже Eltex есть.

Oxidized написан на Ruby. Установка простая и типовая для Unix систем. Ставим сначала ruby, а потом через gem install всё остальное. Есть docker контейнер с примером файла docker-compose.yaml. Не буду сюда копировать, в репозитории всё описано прямо на главной. Искать не надо.

Oxidized состоит в виде службы, которая по ssh или telnet ходит на устройства и собирает конфигурации, и веб интерфейса для просмотра и управления всем этим делом. Хранить конфигурации программа умеет в том числе в GIT репозитории. Это позволяет удобно просматривать изменения между разными версиями конфигураций. Веб интерфейс очень простой (список устройств и конфигурации к ним), аутентификации нет, так что надо хотя бы за прокси ставить с basic auth.

Продукт старый и известный, так что настройка не будет представлять каких-то сложностей. В сети масса руководств по этой теме. Я знал аналог этой программы, написанный русскоязычными программистами в 2018 году - cBackup. У них была обзорная статья на хабре в то время. Программа функциональная, удобная, внешний вид хороший. Можете сами оценить на сайте. К сожалению, развития так и не получила и на текущий момент она устарела и есть проблемы с микротиками, начиная с какого-то обновления. Подключения по SSH не работают, бэкапы не делаются. Жаль, что продукт не получил развития. Я хотел его попробовать, но увидел, что обновлений нет, так что это не имеет смысла, даже если получится запустить.

А вы что используете для бэкапа сетевых устройств? Вариантов может быть масса, начиная от готовых больших систем (NOC Project) и заканчивая банальными скриптами с отправкой конфигураций на почту или заливкой на ftp.

❗️Чуть не забыл упомянуть, что Oxidized поддерживает интеграцию с известной системой мониторинга LibreNMS. С помощью этой интеграции сможете просматривать конфигурации устройств прямо в мониторинге. Подробности интеграции в руководстве LibreNMS.

Исходники - https://github.com/ytti/oxidized

#backup #network #mikrotik

Коллеги, а кто как решает вопрос с централизованным получением и раздачей бесплатных сертификатов от Let's Encrypt внутри инфраструктуры? Например, у вас есть веб сервер, который принимает все HTTP запросы, а внутри инфраструктуры есть какой-нибудь почтовый сервер, которому тоже нужен сертификат. Либо это может быть внутренний сервис вообще без доступа в интернет, но ему тоже хочется дать валидный сертификат, чтобы браузеры не ругались. Да и просто удобно управлять всем этим делом из одного места.

Я обычно использую 2 разных способа.
1️⃣ Настраиваю получение сертификатов на одном сервере. Всем, кому нужны сертификаты, подключаю директорию /etc/letsencrypt по nfs. В целом, нормальный вариант, но бывают проблемы, когда инфраструктуру погасят, а потом запустят. Сервис может подняться раньше, чем загрузится виртуалка с сертификатами. Тогда будет ошибка и надо будет вручную сходить и разобраться с проблемой.
2️⃣ Конечные сервера регулярно с помощью rsync синхронизируют директорию со своим сертификатом. Тут немного больше хлопот, так как надо скрипты в cron класть и следить за ними, чтобы всё ок было.

В обоих случаях надо следить на конечном сервере за обновлением сертификатов и перезапускать службы, которые их используют. Это реализуется с помощью incron. Когда служба видит изменение файла, выполняет перезапуск сервиса.

В голову приходит и третий вариант. Настроить с веб сервера, где обновляются сертификаты, доступ по ssh к целевым серверам. Через хук letsencrypt после обновления сертификата копировать его на сервер и перезапускать там службу. По идее, тут будет проще всего настройка, плюс она полностью централизована, но мне кажется это небезопасно. На всякий случай я так не делаю.

А вы как решаете эту задачу? Она вообще для кого-то актуальна или я её сам себе придумал? Частенько приходится с этим разбираться. Сейчас сертификаты везде нужны.

#letsencrypt

​​Часто возникают ситуации, когда хочется вести контроль версий конфигурационных файлов в системе Linux. Это может быть актуально не только, когда сервером пользуются несколько человек, но и для единственного администратора. Простейший способ контроля версий - создание копии файла перед редактированием.

Я предлагаю автоматизировать эту процедуру и использовать систему контроля версий git для этих целей на примере ОС Debian или Ubuntu. Для любого другого дистрибутива всё настраивается аналогично.

Устанавливаем git:
# apt install git

Создаём файл конфигурации git:
# touch ~/.gitconfig
Добавляем информацию о пользователе:
[user]
name = root
email = root@debian11-websrv

Создадим репозиторий для конфигов и сразу переименуем его, чтобы потом не путать с другими:
# cd ~ && git init && mv .git system.git

Добавим в корень системы / информацию о том, где находится репозиторий:
# echo "gitdir: /root/system.git" > /.git

Устанавливаем права доступа:
# chmod 600 ~/.gitconfig
# chmod 600 /.git
# chmod 700 /root/system.git

Настраиваем с помощью списка exclude директории, за которыми будет следить git. Данном случае это /etc. Для этого добавляем в файл ~/system.git/info/exclude пару строк:
/*
!/etc

У нас всё готово. Делаем первый commit:
# cd ~
# git add -A && git commit -m 'Создание репозитория debian11-websrv'

Добавляем в системный cron выполнение задания с коммитом каждую минуту:
* * * * * root cd / && git add -A && git commit -m "Cron commit" > /dev/null

Теперь можно что-то изменить в конфигурации, дождаться коммита и проверить изменения. Например, добавьте пользователя:
# adduser user01

Посмотрите изменения:
# git log --follow -p /etc/passwd

Я показал пример, как это может быть настроено. При желании, можно добавить и другие директории. Например, /var/spool/cron/crontabs или /usr/local/etc. Последнее было очень актуально в Freebsd, но давно уже не вижу, чтобы там что-то полезное хранилось.

Дополнительно неплохо было бы хранить информацию об установленных пакетах. Все изменения отражаются в лог файле пакетного менеджера, но добавлять в git логи не очень хорошая идея. Удобнее было бы выгружать список пакетов с какой-то периодичностью в файл в /etc/ примерно так:
# rpm -qa > /etc/packages.list
# dpkg -l > /etc/packages.list

Статья по сути готовая инструкция, так что можно забрать в закладки. Если есть какие-то замечания, или более универсальное, удобное решение этой же задачи, делитесь в комментариях. Я знаю, что есть etckeeper, но мне кажется, для такой простой задачи, которую можно решить только с помощью git, нет смысла привлекать какой-то сторонний софт.

#linux #git

​​BookStack - open source платформа для создания документации и вики-контента.

Когда-то давно я рассказывал про готовую платформу wiki.js. Это зрелый и известный продукт. Написан, как не трудно догадаться, на JavaScript, работает под node.js. Если он вас по какой-то причине не устраивает, то предлагаю альтернативу. Речь пойдёт про похожий продукт, но написанный на PHP на базе Laravel. Данные хранит в MySQL.

Основные особенности BookStack:
◽ простой, минималистичный интерфейс;
◽ низкие требования к производительности железа, работает на самых минимальных VPS;
◽ встроенная интеграция с diagrams.net для рисования схем;
◽ полная русификация;
◽ наглядная иерархия вида полка-книга-лист;
◽ live-preview markdown редактор;
◽ аутентификация на базе локальных пользователей или сервисов типа GitHub, Google и других.

BookStack это не обязательно wiki портал, но и просто информационный сайт. Подойдёт для хранения документации, инструкций и т.д. Плюс в том, что работает на базе классического web сервера LAMP. У linuxserver.io есть поддерживаемый docker образ. По ссылке есть пример docker-compose для запуска всего стека сразу.

Условно можно считать BookStack бесплатным аналогом Confluence. Он пытается решать те же задачи.

Вы сами какую wiki платформу используете?

Demo - https://demo.bookstackapp.com
Сайт - https://www.bookstackapp.com
Исходники - https://github.com/BookStackApp/BookStack

#wiki

Недавно затрагивал тему централизованного управления сертификатами Lets's Encrypt. Получил в TG много советов, всем спасибо за них. В VK предложили необычный вариант - хранить серты в GIT. Идея отличная, а мне даже в голову не приходила. Ведь действительно удобно. Я пока сам ещё не пробовал, но общая концепция в голове сложилась.

1️⃣ Получаем новый сертификат, хуком его отправляем в репозиторий. Можно сразу сделать скрипт, который будет создавать готовую цепочку сертификатов в зависимости от софта, который будет использовать сертификат. Postfix и Dovecot, к примеру, хотят готовую цепочку. Думаю, удобно будет под каждый домен свою ветку держать.
2️⃣ На целевом сервере создаём локальный репозиторий и копируем туда содержимое ветки с актуальными сертификатами.
3️⃣ С помощью git fetch и сравнения $(git rev-parse HEAD) с $(git rev-parse @{upstream}) проверяем наличие новых коммитов в нужной ветке репозитория. Если есть обновление, делаем git pull и запускаем какой-то скрипт, который скопирует новый сертификат в заданное место и выполнит необходимые действия для того, чтобы софт применил новый сертификат.

Это пример последовательности действий для ручной настройки на нескольких серверах. Если у вас есть какая-то система для CI/CD, можно то же самое через неё реализовать. Сертификаты можно хранить не в GIT, а в каком-то хранилище секретов. У меня нет опыта работы с ними, так что конечную реализацию не представляю, но смысл там будет тот же.

Если придётся где-то настраивать подобное, реализую такую схему.

#letsencrypt #devops

​​Рассказал на днях про популярную систему для ведения документации. На удивление, куча людей отписались, что используют DocuWIKI до сих пор. Я прекрасно знаю эту систему, активно использовал её для хранения документации. Несомненный плюс, что все заметки хранятся в текстовых файлах. Никаких баз данных и лишних прослоек для доступа к контенту. Но лично я никогда не любил писать в классическом wiki формате. Для меня это страдание.

Расскажу про ещё один подход для создания документации с помощью так называемых генераторов статического контента. Одним из популярных представителей подобного рода проектов является MkDocs. Конкретно его тема Material for MkDocs является самой популярной на github по количеству звёзд среди подобных проектов для ведения документации.

Идея там такая. Вы пишите какой-то контент в формате Markdown и сохраняете его в отдельных .md файлах. Потом берёте MkDocs, пишите для него конфиг в формате yaml, где настраиваете структуру и внешний вид сайта, и прогоняете генератор по этому контенту. На выходе получаете статический html сайт.

Основная идея такого подхода в том, что контент хранится в GIT, а потом с помощью CI после обновления репозитория генерируется сайт. Для этого используется docker контейнер с MkDocs. Можно автоматизировать создание документации, выработав определённые правила написания документации в репозиториях.

С помощью подобной системы выполнена публичная wiki RockyLinux. Там впервые и увидел Material for MkDocs. Сходил, посмотрел, что это такое и благополучно забыл. А на днях вспомнил, когда обсуждали wiki системы. Документация самой Material for MkDocs тоже выполнена на ней же. Там всё более красиво и аккуратно, нежели в wiki от Rocky. Хороший пример для оценки.

Сайт - https://squidfunk.github.io/mkdocs-material/
Исходники - https://github.com/squidfunk/mkdocs-material

#wiki #devops #docs

​​Существует известное сообщество авторов, объединённых проектом linuxserver.io. Они создают общедоступные Docker контейнеры с преднастроенным софтом внутри. Они их не только создают, но и постоянно поддерживают, выпуская обновления. Полный список образов представлен на отдельной странице, либо сразу на dockerhub.

Я уже пару раз ссылался на образы этого проекта, когда рассказывал про Heimdall и BookStack. Сами эти проекты не имеют готовых Docker образов, но популярность их такова, что в сообществе есть запрос на контейнеры. Linuxserver.io создали их и поддерживают.

Я не берусь судить, насколько можно доверять этому проекту. В любом случае, я бы предпочёл использовать эти образы, вместо каких-то безымянных авторов. Как минимум, поддержка образов linuxserver оплачивается самим Docker, так как они имеют статус Sponsored OSS. Ему выгодно существование и поддержка подобного проекта.

Вот, к примеру, готовый образ недавно упоминаемой dokuwiki:
https://docs.linuxserver.io/images/docker-dokuwiki
Тут описание образа, примеры использования. В одну команду запускаем контейнер и начинаем пользоваться приложением:
docker run -d \
 --name=dokuwiki \
 -e PUID=1000 \
 -e PGID=1000 \
 -e TZ=Europe/Moscow \
 -p 80:80 \
 -v ~/docuconfig:/config \
 --restart unless-stopped \
 lscr.io/linuxserver/dokuwiki:latest
После запуска идём на https://$IP:$PORT/install.php и настраиваем wiki.

Подобная страница с документацией есть для каждого образа.

#docker

​​Сейчас много людей в поиске, чем заменить Active Directory. Нужно понимать, что аналогов этого продукта просто не существует. Придётся искать какие-то приемлемые для себя альтернативы. Одну из таких условных альтернатив хочу вам показать.

Есть немецкий проект Univention Corporate Server (UCS). Это LDAP сервер на базе Samba с управлением через web интерфейс. Есть бесплатная и платная версия. Основные отличия - в бесплатной версии нет поддержки и после выхода очередного релиза, старый поддерживается только 6 месяцев, в то время как платный - 5 лет.

Основная фишка UCS - магазин приложений, которые сразу же после установки настроены на использование этого LDAP сервера. Я развернул Nextcloud, к нему для редактирования документов OnlyOffice Docs и почтовый сервер поставил, который на базе Postfix и Dovecot. Добавил в систему нового пользователя. Под ним можно сразу авторизоваться в любом установленном приложении.

Всё управление через web интерфейс. Подразумевается, что в консоль вам вообще ходить не нужно. Дистрибутив построен на базе Debian. Это сразу становится очевидно в момент установки. Для загрузки дистрибутива необходимо будет указать свой email. Туда же придёт файл с бесплатной бессрочной лицензии. Без неё невозможна установка дополнительных приложений.

Из полезных приложений, что есть в App Center (полный список) я заметил, помимо тех, что уже указал, следующие: Guacamole, Rocket.Chat, Squid, Prometheus Alertmanager, Wekan (Канбан доска и To-Do менеджер), Wordpress. Все они настроены на работу с LDAP сервером по умолчанию.

Я не знаю, что там со стабильностью и надёжностью, но в целом неплохое готовое решение из коробки. Я всё настроил, не залезая в консоль вообще. Создал юзеров, ящики. Проверил работу редактора документов, подключил почту через Thunderbird. Всё запустилось без каких-либо проблем.

Сайт - https://www.univention.com/products/ucs/ucs-management-system/
Исходники - https://github.com/univention/univention-corporate-server
Demo - https://demo.univention.de

#ldap #samba #docs

Предлагаю вашему вниманию некоторые изменения стандартного конфига Nginx, которые я лично выполняю. К каждому параметру сделаю небольшое пояснение.

▪ worker_connections 8192;
Количество соединений для одного рабочего процесса. Повышать следует в зависимости от производительности сервера, но дефолтные значения я в любом случае увеличиваю.

▪ worker_rlimit_nofile 65536;
Параметр указывает, сколько файловых дескрипторов будет использовать Nginx. На каждое соединение надо выделять по два дескриптора: один на соединение с клиентом, второй на открытие файла. Число соединений = worker_connections * worker_processes.

▪ pcre_jit on;
Использование PCRE JIT способно существенно ускорить обработку регулярных выражений.

▪ multi_accept on;
Позволяет рабочему процессу сразу принять все новые соединения. Иначе он их будет принимать по одному.

▪ sendfile on; 
Параметр активирует передачу данных между файловыми дескрипторами средствами ядра ОС. Это ускоряет процесс и экономит ресурсы.

▪ tcp_nopush on;
tcp_nodelay on;
Параметры ускоряют передачу данных HTTP запросов.

▪ reset_timedout_connection on;
Параметр разрешает сброс соединений по таймауту.

▪ server_tokens off;
Отключите server_tokens, чтобы nginx не показывал свою версию.

▪ ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
Отключите старые версии ssl, а можно и tls1, tls1.1. Сейчас по умолчанию поддерживаются версии tls 1.2 и 1.3. Остальные считаются устаревшими.

▪ log_format
Я обычно добавляю дополнительные поля в стандартный формат логов. Как минимум rt=$request_time и ut=$upstream_response_time. Это позволяет мониторить время ответа бэкендов. Отклонение от стандартных логов приводит к тому, что их перестают парсить стандартные шаблоны различного софта. Так что изменяйте на свой страх и риск. Я это делаю там, где потом и шаблоны редактирую сам.

▪ client_max_body_size 10m;
Задаёт максимально допустимый размер тела запроса клиента. Дефолтное значение в 1m часто недостаточно.

Также я в обязательном порядке меняю дефолтные таймауты, типа proxy_connect_timeout, send_timeout, client_body_timeout и т.д. Но это уже делается под конкретные сайты и ситуации, поэтому не привожу примеры этих значений. В общем случае можно оставить дефолт, а потом изменять по мере необходимости.

📌 В завершении несколько полезных ссылок на мои материалы по теме Nginx:
- Подробная установка и настройка Nginx с примерами
- Автоматическое тестирование конфигурации Nginx
- Правильный redirect 301 для SEO в Nginx
- Nginx в качестве балансировщика нагрузки
- Проксирование запросов в nginx с помощью proxy_pass
- Сборка rpm пакета nginx с дополнительными модулями

 📌 Другие полезные ссылки:
- Генерация конфигов Nginx от DigitalOcen
- SSL Configuration Generator
- Проверка конфигурации Nginx

Пост достоин того, чтобы отправиться в закладки.

#nginx

Хочу поделиться с вами любопытным видео, которое привлекло моё внимание. Оно даёт возможность посмотреть на нашу профессию со стороны людей из другого мира. Видео записал системный администратор из Бостона, США.

5 Reasons to Become a System Administrator
https://www.youtube.com/watch?v=hhQlC4G1PGI

Вот 5 причин, по которым он считает профессию системного администратора хорошим вариантом для занятости:
1️⃣ Это очень прибыльная профессия. При этом он поясняет и ставит работу системного администратора в один ряд с разработчиками. Возможно в США разница действительно небольшая. У нас же между разработкой и поддержкой большая разница в зарплатах.
2️⃣ Низкий порог входа в профессию. Не надо много лет учиться, как, к примеру, на врача или научного сотрудника. Я так понимаю, он взял в пример эти профессии, потому что у них зарплаты сопоставимые. Мне трудно с этим согласиться, так как для получения хороших денег в IT придётся тоже долго учиться, либо работать для получения опыта.
3️⃣ Гибкость профессии. Системные администраторы актуальны практически для всех сфер человеческой деятельности. При этом и формат работы у них может быть очень разный. С этим трудно не согласиться.
4️⃣ Стабильность и уверенность в завтрашнем дне. Спрос на IT специалистов не падает, а только растёт. Это позволяет быть уверенным в том, что не останешься без работы, в том числе из-за остановки бизнеса вследствие каких-нибудь локдаунов или прочих катаклизмов.
5️⃣ Системное администрирование - творческая профессия. Это, кстати, верно подмечено. Я замечал, что многие программисты завидуют сисадминам или девопсам как раз из-за того, что у них много разнообразия в работе. В то время как программист может прийти на какой-то старый проект с одним стеком технологий и 5 лет просидеть на нём. У поддержи же всё время какие-то вызовы, тесты нового ПО или подходов к ведению дел. Гораздо больше разнообразия, и я с этим полностью согласен. Сам люблю свою профессию за это.

Отдельно отмечу комментарии. Во-первых, там много любопытной информации от совершенно других людей. Во-вторых, они все очень дружелюбные и приятные, что необычно. Ты читаешь и получаешь заряд позитива. Этого так не хватает в русскоязычных комментариях, где ментально больные люди пытаются автора обидеть, как-то задеть, оскорбить. Постоянно это замечаю, и это грустная история. Сам всегда по умолчанию вежлив и благосклонно настроен ко всем, кто хоть что-то сделал сам и поделился этим с другими.

#разное

​​Думаю, многие системные администраторы знают и используют сканер сети Nmap. Я сам им постоянно пользуюсь. Делал заметку по основным возможностям программы и писал статью с практическим советом по применению. Если не знакомы с этой программой, то советую изучить. Она регулярно используется. Ярлык всегда на рабочем столе.

Недавно узнал, что существует проект Zmap с похожими возможностями и одним важным отличием. Он в десятки и сотни раз быстрее Nmap. Я так понимаю, что когда речь идёт о сканировании всего интернета, используют именно Zmap. Разработчики обещают просканировать весь диапазон ipv4 адресов за 45 минут, если делать это через гигабитное соединение с интернетом. И за 5 минут, если через 10-ти гигабитное. И для всего этого хватит мощности обычного десктопного железа.

Zmap максимально заточен на быстродействие и судя по всему из-за этого умеет сканировать за раз только конкретный порт. То есть нельзя как у Nmap задать диапазон адресов и найти все открытые порты. Нужно конкретно указать, что ищем порт 80 и задать диапазон, не стесняясь в его размерах. Это существенно снижает область его применения. Я бы хотел получить инструмент с подобным быстродействием для поиска открытых портов конкретного хоста или списка хостов. Если кто-то может что-то посоветовать по этой теме, поделитесь информацией. Nmap очень медленно проверяет весь диапазон портов.

Если хотите быстро просканировать какую-то сеть или набор хостов на открытый порт, то имеет смысл использовать Zmap. Он есть в стандартных репах популярных дистрибутивов, так что ставится через пакетный менеджер в одну команду.
# apt install zmap
# dnf install zmap

По умолчанию он не сканирует диапазоны приватных адресов, типа 192.168.0.0/16, 10.0.0.0/8 и т.д. Так что если будете сканировать локальную сеть, закомментируйте в /etc/zmap/blacklist.conf свой диапазон. И на всякий случай при использовании ограничьте максимальную скорость сканирования примерно так:
# zmap -B 10M -p 80 10.0.0.0/16 -o LANresults.csv

Эта команда выполнит сканирование сети 10.0.0.0/16 на наличие открытого 80-го порта со скоростью 10 Mbps. Результат сохранит в файл LANresults.csv.

#network

Сайт - https://zmap.io/
Исходники - https://github.com/zmap/zmap

Telegram-канал "MikroTik сэнсэй"

Многие знают Дмитрия Скоромнова. Практикующего инженера и официального тренера MikroTik.

У Дмитрия есть Telegram-канал, на котором он пишет про оборудование MikroTik. На канале публикуется много практической информации, которой нет в официальной документации вендора.

Некоторые из постов:

🔥 Мракобесие при настройке файрвола на MikroTik.
▪ Почему 802.1ac Wave 2 работает только на бумаге.
▪ Что делать, если Netinstall не видит устройство MikroTik.
▪ Алгоритм переустановки RouterOS.
▪ Встроенный в RouterOS механизм облачного резервного копирования.
▪ Четыре функции кнопки Reset.
🔥 SFP-модуль на котором можно воду кипятить.

Подписывайтесь на канал реального сертифицированного практика с уникальной информацией, без воды, репостов, домыслов.

❗️Автор читает комментарии и участвует в обсуждениях. У вас есть возможность получить ответ на свой вопрос.

#реклама

⚠ Я знаю, что меня читают владельцы Telegram каналов. Хочу сделать предостережение, так как участились случаи попыток угона каналов. Ко мне в течении недели 2 раза писали мошенники. И я лично знаю как минимум двоих владельцев IT каналов, которые их лишились из-за мошенников.

Схемы везде разные, но главный принцип один, и он актуален для любого вида мошенничества. Вам делают супервыгодное предложение, от которого у вас отключается голова, а в глазах начинают крутиться денежные купюры, как у Скруджа Макдака из Утиных историй.

Палятся мошенники на мелочах, которые сразу видны человеку, который постоянно общается с рекламщиками. В первом случае мне предложили купить сразу 3 поста с публикацией через день для компании Skillbox. И текст рекламы один и тот же. Рекламодатели так никогда не делают. Кстати, именно менеджерами Skillbox почему-то представляются мошенники. Наверно считается, что это какая-то очень надёжная компания, или хз как это понимать. Я вообще им, как и Geekbrains, в рекламе отказываю уже давно, так как на них много негатива. Для оплаты они просят вас заполнить анкету на скам-сайте, через который уводят TG аккаунт.

Другие в обсуждении условий написали, что им способ оплаты не принципиален, что тоже не встречается у реальных рекламодателей. Это важный момент. Он всегда имеет значение и обсуждается заранее. А в завершении вообще прислали какой-то экзешник и указали название программы, для которой надо сделать мини-обзор, за который обещали хорошо заплатить отдельно.

Будьте внимательны. Мошенники всегда и везде действуют примерно одинаково, воздействуя на людские пороки - в первую очередь жажду быстрой наживы и жадность. Так что самая надёжная защита от любых мошенников - не искать лёгких и быстрых денег за чей-то счёт. Вероятность того, что кто-то внезапно захочет резко увеличить ваш доход ничтожна мала, так что лучше вообще не брать это в расчёт.

На эту тему могу порекомендовать книгу специалиста по мошенничеству Сергея Мавроди - Сын Люцифера. Она немного пошловата и читается тяжело, но людские пороки и их эксплуатация разобраны очень детально и на различных примерах. Fb2 легко находится и качается. Для расширения кругозора нормальная книга. Полезно прочитать.

#разное

​​Мне часто приходится поддерживать сайты на популярном в РФ движке Bitrix. Решил написать небольшой список настроек, на которые стоит обратить внимание при настройке рабочего окружения и самого сайта. Список основан на личном опыте и не претендует на истину.

📌 Сбалансируйте потребление оперативной памяти на сервере, чтобы её всегда хватало. Bitrix тяжёлый и неповоротливый движок. Его часто запускают на apache с php в качестве бэкенда. Так что надо как минимум между MySQL и Apache разделить ресурсы, чтобы в пике они не съели их все. У меня есть статья на эту тему.

📌 Обратите внимание на настройки php: max_execution_time и memory_limit. В Bitrix много тяжёлых запросов, особенно если настроены обмены с внешними ресурсами. Часто эти параметры приходится увеличивать до высоких значений, с которыми в других движках вам вряд ли приходилось иметь дело (например max_execution_time = 300 и memory_limit = 512M).

📌 Когда разворачиваете новый сайт, обязательно выбирайте кодировку UTF8. До сих пор можно выбрать CP1251. Много старых сайтов встречал с этой кодировкой. Они нормально работают, но я всё же рекомендую конвертнуть их в UTF8. Вот статья с инструкцией и скриптом.

📌 В настройках Главного модуля есть параметр "Использовать горячие клавиши". Чаще всего их никто не использует, лучше отключить. Под них таблица в базе b_hot_keys может разрастаться до огромных значений.

📌 Иногда разработчики включают логирование SQL запросов и забывают их отключить. Все запросы пишутся в базу. Она растёт с огромной скоростью. Отключить: Настройки ⇨ Настройки продукта ⇨ Настройки модулей ⇨ Монитор производительности ⇨ Вести журнал SQL запросов ⇨ Галочку снять.

📌 Если разворачиваете копию сайта для теста, обязательно пометьте её как версию для разработки в настройках Главного модуля, на вкладке с обновлениями. И отключите все кроны, особенно если там есть какие-то обмены. Всё, что вам надо, потом либо отдельно включите, либо запустите вручную. И про почту не забудьте, если есть какие-то рассылки, оповещения для пользователей.

📌 Все кроны сайта запускайте через системный cron, а не на хитах. При создании сайта установщик спрашивает об этом, но по дефолту вроде бы хиты предлагает. Надо не упустить этот момент, иначе под нагрузкой сайт будет сильно тормозить.

📌 Битрикс очень медленный движок, так что надо кэшировать всё, что можно. Обязательно делайте на этом акцент, когда будете беседовать с разработчиками. Если они не понимают и не хотят нормально настраивать кэширование, обращайтесь к руководству. В его интересах, чтобы сайт работал быстро, а без кэширования это невозможно.

📌 Никогда не обновляйте Bitrix сразу на проде. Всегда тестируйте обновления. Очень часто что-то ломается. Особенно если есть интеграции и обмены.

📌 Внимательно заполните gitignore. На сайте очень много того, что в git грузить не надо. Тут нет универсальных советов, так как зависит от конкретного сайта. В поиске много информации по этой теме, по аналогии не проблема сделать. Главное не забыть.

📌 Отправку почты битриксом можно настроить через утилиту msmtp (быстрее и проще, идёт в комплекте с bitrixenv), либо через postfix (чуть сложнее и дольше настройка). Если использовать postfix, то проще работать с логами, делать мониторинг, подсчёт статистики и т.д., так как это стандартное решение.

📌 Хороший CI/CD для Bitrix сделать трудно. Я не умею, так как не работал с большими проектами, а на маленьких всё по понятиям разработчиков делается. Один из вариантов, с которым работал, описывал в статье. Вот ещё пример с сайта самого битрикса.

📌 Bitrix успешно запускают в Kubernetes, хотя это не очень просто. Я видел выступление на конференции по этой теме. В общих чертах, как это может выглядеть описано в обзорной заметке от southbridge (аутсорсер).

В целом, всё, из того, что вспомнил, когда писал заметку. Тому, кто не работает с Битриксом, она не нужна. А если работаете или планируете, имеет смысл сохранить.

#bitrix

Как построить карьеру в IT и не выгореть? А что вообще происходит в индустрии?

Об этом пишет Outlines Tech — это тг-канал одноименной IT-компании, где эксперты делятся лайфхаками, новостями и личным опытом.

Подборка постов:
🔸Отделения будущего с Face ID: что такое «умный» банковский офис

🔸Лайфхаки по контролю задач в условиях неопределённости

🔸Как IT-специалисту составить резюме и не облажаться

🔸Что делать, если работа раздражает, а силы на исходе

🔸Как отказаться от работы мечты и стать счастливее: история тестировщика

А ещё в Outlines Tech найдете классные вакансии! Подписывайтесь: @outlines_tech

#реклама

У меня ситуация на днях возникла, когда подвис одиночный гипервизор у клиента. Причём подвис очень странно. На нём отвалился zabbix-agent и не устанавливается соединение по SSH, хотя порт открыт и принимает запросы, но не отвечает. Подключение отваливается по таймауту. При этом все виртуалки нормально работают. Частично работает веб интерфейс proxmox, но некоторые разделы ничего не показывают.

Сбор логов в данном случае не настроен и его очень не хватает. Вообще, без сбора логов невозможно считать мониторинг полноценным. Расследовать инциденты неудобно, а некоторые и невозможно. Тут теперь какие варианты - либо какая-то софтовая проблема и поможет перезагрузка. Либо с железом какие-то проблемы и сервер из ребута уже не выйдет. Доступа к консоли нет, надо KVM заказывать.

Нужно в обязательном порядке проверять бэкапы и планировать время для перезагрузки, держа в уме, что возможен простой, связанный с переносом виртуалок на другой сервер. Если бы был настроен сбор логов, была бы вероятность увидеть проблему по системным логам или логам работающих служб. Хотя и не обязательно, но шанс есть. Можно было бы подготовиться получше.

Пока разбирался с этой темой, параллельно давно открыта вкладка в браузере на тему сопоставления событий Zabbix и логов различных служб. Прочитал её и понял, что там описывается продукт MONQ, про который я не так давно писал. В самом обзоре я не сделал акцента на том, что система умеет сопоставлять события из мониторинга с событиями из логов. А это очень полезный функционал. И не так много софта, на базе которого это можно сделать.

У кого-то есть подобные связки? На базе чего всё настроено? У меня стандартно логи собирает ELK, мониторинг в Zabbix. Так что никакого сопоставления нет, хожу руками туда-сюда и сопоставляю.

#мониторинг

​​В одной из заметок затрагивал тему создания скриншотов сайтов через консоль сервера. Мне посоветовали для этого готовый Docker контейнерна базе Google Puppeteer - Screenshoter. Я его попробовал. Сделано очень удобно и функционально.

Идея инструмента следующая - запускаете в Docker контейнере софт, который слушает tcp порт. Шлём к нему на API запросы с параметрами и получаем результат. Самый простой случай выглядит вот так:
# docker run -d --restart always \
-p 8080:8080 \
--name screenshoter \
mingalevme/screenshoter

После запуска, можно сделать запрос к сервису:
# curl "https://localhost:8080/screenshot?url=https://ya.ru" > ~/scrshot.png
Скриншот сайта будет в файле ~/scrshot.png.

Сервис может принимать множество параметров. Все они описаны в репозитории. Вот пример с указанием расширения экрана:
# curl "https://localhost:8080/screenshot?url=https://ya.ru&viewport-width=1920&viewport-height=1080" > ~/scrshot.png

В таком режиме можно запустить где-то контейнер и обращаться к нему по мере необходимости. Очень просто всё это связать с любой системой мониторинга на базе обычных вебхуков.

Я немного покопался в репозитории и увидел там docker-compose.yml, где в составе помимо контейнера с Screenshoter есть Nginx со своим конфигом, который все запросы проксирует скриншотеру. Не сразу понял, зачем это вообще нужно, но в итоге запустил всё у себя и разобрался. Можно поднять эти контейнеры и обращаясь к nginx через браузер, видеть скриншот сразу в нём же.

Запустил вот такой compose:

version: "3.1"

services:

 screenshoter-app:
  image: mingalevme/screenshoter
  restart: always

 screenshoter-nginx:
  image: nginx:alpine
  ports:
   - "80:80"
  volumes:
   - ./screenshoter.nginx.conf:/etc/nginx/conf.d/default.conf
   - "/var/log/nginx:/var/log/nginx"
   - "/var/cache/nginx:/var/cache/nginx"
   - "/dev/null:/var/cache/screenshoter"
  depends_on:
   - screenshoter-app

После этого в браузере перешёл по url:
https://10.20.1.16/screenshot?url=https://ya.ru&viewport-width=1920&viewport-height=1080
и получил в браузере скриншот сайта.

У Screenshoter много параметров. Он умеет в том числе и скролить. Можно упростить и автоматизировать создание скриншотов. Сервис очень понравился и показался полезным, так что решил рассказать вам о нём. Запустив его у себя, можно упростить и какое-то личное применение. Например, настроить шаблон для скриншотов сайтов и использовать его - какую-то статью заскриншотил, перевёл в pdf и сохранил в директории, которая с Яндекс.Диском синхронизируется.

Исходники - https://github.com/mingalevme/screenshoter
DockerHub - https://hub.docker.com/r/mingalevme/screenshoter/

#разное

За что люблю почтовый сервер Postfix, так это за его гибкость в настройках. Если хорошенько поискать, всегда можно найти решение той или иной задачи с этим почтовым сервером. Я неизменно всегда устанавливаю почтовый сервер на базе Postfix. Если выбираете почтовый сервер, который будете собирать из компонентов и настраивать самостоятельно, то рекомендую в качестве основы взять Postfix.

Вот несколько нестандартных примеров, которые приходилось реализовывать:
- выбор релей сервера для пересылки сообщения в зависимости от адреса отправителя или домена (актуально для веб сервера, где много сайтов и каждый использует свой внешний сервер для отправки);
- запрет отправки почты на внешние домены, разрешена только локальная отправка внутри собственных доменов;
- автоматическое изменение темы письма или адреса отправителя для всей или выборочной почты;
- автоматическое удаление определённых писем при достижении ими разрешённого времени хранения.

Это то, что вспомнил, пока писал заметку. Недавно появилась задача, ограничить максимально возможное количество отправленных писем в течении некоторого промежутка времени, то есть запретить почтовому ящику отправлять более 50 писем в час. Живой человек в обычном рабочем режиме вряд ли сможет отправить больше.

Начал искать решение и очень быстро нашёл - postfwd. Очень гибкое решение с возможностью писать свои правила для отправки. В Debian пакет есть в стандартном репозитории. Указанная задача решается очень просто:
1. Устанавливаем postfwd:
# apt install postfwd
2. Включаем автозапуск в /etc/default/postfwd, рисуем простой конфиг с единственным правилом в /etc/postfix/postfwd.cf:
id=R01; action=rcpt(sender/50/3600/REJECT sorry, max 50 emails per hour for sender $$sender exceeded)
При желании можно добавить предупреждение при совершённых 30-ти отправках в час:
id=R02; action=rate(sender/30/3600/WARN limit of 30 email per hour exceeded [$$ratecount hits])
Показал для примера, как выглядят правила. Большое количество примеров приведены в документации. По аналогии не трудно для себя писать правила. Возможности очень широкие.
3. Добавляем интеграцию в postfix через его механизм restrictions:
smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040
permit_mynetworks
permit_sasl_authenticated
...........................................
4. Запускаем postfwd, перечитываем конфиг postfix.

Сайт - https://postfwd.org
Исходники - https://github.com/postfwd/postfwd

Cсылки на мои материалы по postfix:
- Настройка postfix + dovecot + mysql база + postfixadmin + roundcube + dkim
- Настройка SSL/TLS сертификатов Let's Encrypt в postfix и dovecot
- Защита почтового сервера postfix + dovecot с помощью fail2ban
- Перенос почтового сервера postfix
- Очистка и обслуживание почтовой базы postfix
- Мониторинг postfix в zabbix         

#postfix #mailserver

Анализ дисковой активности в Linux

Расскажу кратко, с помощью каких консольных инструментов можно всесторонне рассмотреть дисковую активность на сервере под управлением Linux.

Начнём издалека и посмотрим общую дисковую активность отдельного устройства. Для этого можно воспользоваться утилитой btrace из пакета blktrace (есть в стандартных репах)
# btrace -w 60 -a write /dev/mapper/rhel-root
В течении 60 секунд утилита будет анализировать дисковую активность процессов и потоков ядра. В завершении покажет сводную статистику.

Наглядный вывод статистики по дисковым устройствам в режиме реального времени есть у iostat из пакета sysstat (есть в репозиториях). Я предпочитаю вот такое отображение с использованием watch:
# watch -n 1 iostat -xk

Более детально в режиме реального времени нагрузку на диск отдельных приложений можно посмотреть с помощью iotop (есть в репозиториях). Простой запуск без параметров похож на обычный top, только про диски. Более наглядную информацию можно получить, запустив iotop с ключами:
# iotop -obPat

Ещё один вариант отображения активности процессов в режиме реального времени - pidstat. Она тоже из пакета sysstat. Запускаем с обновлением раз в секунду:
# pidstat -d 1
Видим активность всех процессов. Можем конкретизировать, указав один из них по его pid:
# pidstat -p PID -d 1

Двигаемся дальше и смотрим, в какие файлы производится запись с помощью fatrace (в deb дистрибутивах есть в репозиториях). Проверка очень простая и быстрая через анализ обращений к inotify.
# fatrace -f W
Можно записать всю файловую активность в лог файл и потом спокойно посмотреть:
# fatrace -t -s 60 -o ~/fatrace.log

Более детально разобраться с тем, что пишет процесс на диск можно с помощью strace, указав ему в качестве параметра PID процесса:
# strace -e trace=write -p PID

Напомню, что PID процесса или процессов можно узнать, например, вот так:
# pgrep mariadb
или так:
# ps ax | grep mariadb

Смотрим список открытых файлов в конкретной директории с помощью lsof:
# lsof +D /var/log

Приведённых стандартных инструментов достаточно, чтобы провести основной анализ. Я перечислю ещё несколько удобных инструментов, но их скорее всего придётся ставить вручную, минуя пакетный менеджер, что не очень удобно.
◽ утилита iosnoop из пакета perf-tools, показывает много полезной информации, в том числе latency, чего не делают перечисленные выше утилиты
◽ утилита biosnoop из пакета BPF Tools, показывает активность процессов, в том числе используемые сектора дисков и latency, в этом же пакете к дискам имеют отношения утилиты: biolatency, biotop, bitesize, ext4slower и подобные для других файловых систем.

#bash #perfomance