ServerAdmin.ru
31K subscribers
573 photos
46 videos
22 files
2.83K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru

Регистрация в РКН: https://vk.cc/cG1Urj
Download Telegram
​​Часто возникают ситуации, когда хочется вести контроль версий конфигурационных файлов в системе 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
После запуска идём на http://$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
This media is not supported in your browser
VIEW IN TELEGRAM
Как построить карьеру в 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 "http://localhost:8080/screenshot?url=https://ya.ru" > ~/scrshot.png
Скриншот сайта будет в файле ~/scrshot.png.

Сервис может принимать множество параметров. Все они описаны в репозитории. Вот пример с указанием расширения экрана:
# curl "http://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:
http://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
​​Хочу познакомить вас с интересным проектом, у которого вряд ли есть какое-то промышленное применение. Это скорее просто прикол или интересная фишка. Речь пойдёт о проекте Sampler, который условно можно назвать консольным дашбордом простой системы мониторинга. Работает всё исключительно в консоли, внешний вид которой вы оформляете с помощью виджетов.

Sampler представляет из себя один бинарник, к которому нужно подготовить конфигурационный файл в формате yaml. Настраивается всё очень просто и быстро. Описание виджетов есть в репозитории. Вот пример виджета для мониторинга за временем отклика нескольких сайтов:

runcharts:
 - title: Search engine response time
  rate-ms: 500
  scale: 2
  legend:
   enabled: true 
   details: false
  items:
   - label: GOOGLE
    sample: curl -o /dev/null -s -w '%{time_total}' https://www.google.com
   - label: YAHOO
    sample: curl -o /dev/null -s -w '%{time_total}' https://search.yahoo.com
   - label: BING
    sample: curl -o /dev/null -s -w '%{time_total}' https://www.bing.com

Виджет будет рисовать 3 графика с временем отклика трёх указанных сайтов. Виджетов много: различные диаграммы, текстовые значения, текст в формате ASCII. На картинке во вложении пример заполненного дашборда.

У меня на канале было много разных заметок на тему консольных утилит. Помню про календарь рассказывал, кто-то ссылку на сервисы погоды давал, курсы валют. Всё это можно вывести на Sampler. Пример консольного прогноза погоды:
# curl wttr.in

В Sampler есть простенькие триггеры, которые сработают при выходе за заданные значения метрики. Он может вывести что-то на экран, или воспроизвести звук. С помощью SSH он умеет ходить на удалённые хосты и забирать оттуда какие-то метрики. Пример вывода top с удалённого хоста:
variables:
 sshconnection: ssh -i ~/.ssh/id_rsa.pub user@10.10.1.1
textboxes:
 - title: SSH
  pty: true
  init: $sshconnection
  sample: top

Можно ходить в mysql базы и выполнять какой-то запрос:
variables:
 mysql_connection: mysql -u root -s --database mysql --skip-column-names
sparklines:  
 - title: MySQL (random number example)
  pty: true
  init: $mysql_connection
  sample: select rand();

Я допускаю, что кому-то может зайти эта тема как простой мониторинг. Настроить его реально просто и быстро. Буквально сходу по примерам из документации. У меня с первого раза всё получилось и заработало.

Мне лично больше всего понравилась идея где-то в IT отделе повесить такой дашборд на стену. Выглядит необычно и атмосферно. Захотелось домой себе вывести такой с полезной информацией типа той же погоды, температуры в доме, влажности и т.д. Может это и состоится. Изначально планировал на Grafana собрать.

Исходники - https://github.com/sqshq/sampler

#мониторинг
Подсистема инициализации и управления службами в Linux под названием Systemd плотно вошла в нашу повседневную рутину по управлению серверами. Есть в ней отдельный компонент Timers, который служит заменой классического планировщика мира Unix - cron.

Хочешь не хочешь, но с Timers работать придётся. В том же Debian 11 все повторяющиеся действия реализованы через timers и продублированы в старом cron. Список можно посмотреть вот так:
# systemctl list-timers
Увидите там logrotate.timer, man-db.timer, apt-daily.timer, apt-daily-upgrade.timer и т.д. Если установить php, certbot, то они также добавят свои таймеры наравне с записями в классический cron. Я так подозреваю, что в какой-то момент в обычном cron они исчезнут.

Можно по-разному относиться к нововведениям, но лично мне в таком виде они не нравятся. Это как в Windows функции размазались по Настройкам и Панели управления. В итоге приходится тратить больше времени на настройку и проверять всё в двух местах. Если уж переехали на таймеры, то в cron зачем дублировать? Там всё равно стоят проверки и если уже есть таймер для задачи, то cron ничего не делает. Но проверять приходится.

Когда я познакомился с Unix, его cron был одним из тех инструментов, который мне понравился больше всего. Простота и гибкость настройки подкупали. Все задания в одном файле. Просто скопировал и перенёс его на любой другой сервер, то есть очень простой бэкап всех заданий. Я даже на Windows устанавливал порт крона.

Смотрим на таймеры. Из удобств лично я увидел более гибкий планировщик, который может быть не только календарным, как в cron, но и событийным. Например, можно задать интервал на запуск через 10 минут после загрузки системы и потом повторять каждые 3 часа. Вроде удобно, но лично у меня никогда не было задачи, которой бы требовалось такое расписание. Ни разу не возникло ситуации, когда планировщик cron не справился бы. Максимум, иногда в скрипт добавишь sleep, но это редко бывает. Стараюсь так не делать, потому что костыль.

Вторым плюсом можно отметить логирование каждого отдельного таймера. Это удобно, но не сказать, что очень сильно надо. Grep общего лога cron с таким же успехом покажет все события отдельной задачи. В таймерах смотрим лог вот так:
# journalctl -u logrotate.timer

Ещё одним несомненным плюсом таймеров является возможность настройки зависимостей задач от других служб. Это реально удобно и в обычном cron никак не реализуется. Только если закладывать логику проверки в сам скрипт. Также таймеры могут быть присоединены к разным cgroups.

Я решил написать эту заметку, потому что на днях возникла простая задача. Надо было настроить периодический перезапуск службы 1С на Linux сервере. Прикинул, как это можно сделать через Timers. Получилась такая схема:
1. Создаём отдельную службу, которая перезапускает процесс srv1cv83.
2. Создаём таймер, который запускает эту службу.
Второй вариант, в описание самой службы srv1cv83 добавить параметр WatchdogSec, который будет автоматически перезапускать службу через заданный промежуток времени. Но так трудно попасть в конкретное время. Можно рано или поздно в середине рабочего дня перезапуститься.

Мне показалось, что проще просто добавить в crontab:
55 6 * * 7 root /usr/bin/systemctl restart srv1cv83
и перезапускать службу каждое воскресенье в 6:55. На этом решении в итоге и остановился.

А вы используете systemd timers? Какие задачи решаете? Может я туплю и не понимаю, как красиво и просто перезапускать в нужное время существующую работающую службу, управляемую systemd?

#linux #systemd #cron
​​Делюсь с вами простым и полезным сервисом opensource.builders. Это сайт, в на котором в удобном виде собраны Open Source аналоги известных коммерческих решений. Всё это распределено по категориям, так что удобно пользоваться.

Я просмотрел почти всё. Много бесплатных программ я обозревал на своём канале. Например, берём раздел Communication и смотрим бесплатные альтернативы Slack, Teams и Discord: Rocket.Chat, Zulip, Mattermost и т.д. Тут же смотрим аналог Helpdesk системы Zendesk: Zammad, UVDesk, Helpy.

Забрал сайт себе в закладки. Скорее всего буду потихоньку обозревать наиболее популярные и полезные программы. Нашёл много всего интересного. Например, аналог Notion - Appflowy, аналог TeamViewer - Myrtille и т.д. О многих программах вообще никогда не слышал, хотя судя по звёздам на гитхабе, они популярные.

Кстати, недавно писал UCS сервер и назвал его условным заменителем AD. Авторы этого сайта его туда же поместили, как замену AD.

Подобный сайт можно поднять у себя локально. Инструкция в репозитории. Не очень понял, зачем это может пригодиться.

Сайт - https://opensource.builders/
Исходники - https://github.com/junaid33/opensource.builders

#бесплатно