Посмотрел интересное выступление с HighLoad++ 2021, которое весной выложили в открытый доступ - Есть ли жизнь без ELK? Как снизить стоимость Log Management:

https://www.youtube.com/watch?v=BOVuwr43ZTE

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

Они решили для экономии денег и ресурсов собрать систему сбора логов самостоятельно на базе сборщика логов Vector (по их тестам он оказался быстрее FluentD), парсинг делают им же, обработка с помощью Kafka, данные хранят в ClickHouse, визуализируют с помощью Grafana.

Если вам интересная данная тема, то рекомендую. Я, например, про Vector вообще впервые услышал. Всегда думал, что оптимальный парсер и доставщик логов это FluentD. Обычно его рекомендуют вместо тормозного Filebeat.

#видео #elk #logs

Ранее мне уже приходилось рассказывать о различных неожиданностях, которые можно получить от хостера при управлении виртуальной машиной. Сейчас расскажу ещё один пример, с которым столкнулся впервые.

На одной из VM случайно обнаружил, что нет моих правил в iptables. Остались только цепочки, что добавляет fail2ban, а остальных правил нет. Стал разбираться и выяснил, в чём дело.

На VM через панель управления был добавлен дополнительный внешний IP. А у хостера каким-то образом реализовано автоматическое применение сетевых настроек. Мало того, что они сразу же на VM применились, был отредактирован файл /etc/network/interfaces. В Debian там по умолчанию хранятся сетевые настройки. Мой файл был заменён на новый с дополнительным IP.

У меня давняя привычка применять правила iptables при поднятии сетевого интерфейса. Реализовано это так:
allow-hotplug eth0
iface eth0 inet dhcp
pre-up iptables-restore < /etc/iptables_rules

После добавления адреса я вручную отредактировал firewall, добавил новые правила, связанные с изменениями, применил их. Перезагрузка не потребовалась. А через какое-то время я VM перезагрузил. Стартанула она уже с новыми сетевыми настройками, где в interfaces моей настройки с загрузкой правил iptables уже не было.

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

Вот похожая история на тему управления VM со стороны хостера при добавлении и удалении диска через панель управления:
https://t.me/srv_admin/371
Чуть не остался без подмонтированного диска и всех данных.

Попадали в похожие истории?

#хостинг

​​📍Есть большое количество поводов подписаться на канал сети дата-центров 3data и вот парочка из них: 

 ✅ Рассказывают самые интересные новости из мира дата-центра!
Как работают дата-центры в период санкций, есть ли вероятность того, что ЦОДы вообще перестанут работать, и мы больше не сможем хранить все наши воспоминания в компьютерах и телефонах?

✅ Занимаются исследованием актуальных отраслевых вопросов.
Например, об изменениях спроса и предложения на услуги colocation, проведенное совместно с iKS-Consulting.

 ✅ Делятся интересными фактами о дата-центрах и их работе. 
О ЦОДе на Луне, дата-центрах как объектах искусства и самых крупных сделках отрасли.

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

И это далеко не всё!😉

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

Какой системный администратор Linux не любит хорошенько грепнуть? Это очень полезный навык, который осваиваешь практически сразу, как начинаешь работать в консоли и тем более писать какие-то скрипты. Но есть формат json, который бессмысленно грепать, потому что с большой вероятностью получишь не то, что тебе надо, так как там все данные либо в одной строке, либо построчно иерархически разбиты.

Какой-то добрый человек решил спасти системных администраторов из прошлого и придумал утилиту, которая позволяет успешно грепать json - gron. Лозунг программы - Make JSON greppable!

Покажу на примере, зачем она может понадобиться. У меня есть статья по мониторингу посещаемости сайтов, где данные берутся из Яндекс.Метрики в формате json. Беру обрезанный кусок json, для наглядного примера:
{
 "query" : {
  "ids" : [ 23506456 ],
  "dimensions" : [ "ym:s:searchEngine" ],
  "metrics" : [ "ym:s:users", "ym:s:visits", "ym:s:pageviews" ],
  "sort" : [ "-ym:s:users" ],
},
"data" : [ {
  "dimensions" : [ "ym:s:searchEngine" ],
  "metrics" : [ 2117.0, 2450.0, 3211.0 ]
 } ]
}

Вам надо выхватить все значения из data Так просто их не грепнешь в один присест. А через gron очень просто:
# curl ....... | gron | grep data
json.data = [];
json.data[0] = {};
json.data[0].dimensions = ["ym:s:searchEngine"];
json.data[0].metrics = [];
json.data[0].metrics[0] = 2147.0;
json.data[0].metrics[1] = 2489.0;
json.data[0].metrics[2] = 3271.0;
json.data_lag = 0;

Получили список всех значений data в построчном формате. При желании грепается любое конкретное значение (не забываем про экранирование):
# curl ....... | gron | grep "data\[0\].metrics\[2\]"
json.data[0].metrics[2] = 3271.0;

Эта утилита для тех, кто по какой-то причине не может или не хочет использовать jsonpath в jq. С его помощью какое-то одно конкретное значение вытащить гораздо проще:

# curl ....... | jq '.data[].metrics[2]'
3271.0

Конкретно в данном примере gron не особо нужен. Это просто первое, что в голову пришло. Им будет удобно грепнуть очень большую лапшу json, которая прилетит к вам в терминал. А это обычное дело. Например, когда я настраивал мониторинг ZONT, мне в консоль вываливалась такая лапша, что на экран не помещалась.

Также с помощью gron удобно сравнить два json:
# diff <(gron first.json) <(gron second.json)
7c3
< json.data[0].metrics[2] = 3271.0;
---
> json.data[0].metrics[2] = 3531.0;

Исходники - https://github.com/tomnomnom/gron

#json

Есть много способов защитить подключение из интернета к Windows серверу по RDP. Приведу наиболее известные:

1️⃣ Самое надёжное и очевидное - настроить клиентам VPN, а доступ к серверу разрешить только через этот тоннель. Самый главный минус тут один - клиентам надо у себя на компьютерах настраивать VPN соединение. Где-то оно может блокироваться или работать ненадёжно.

2️⃣ Настроить шлюз Remote Desktop Gateway на базе Windows Server и осуществлять подключение через него. Это простое и удобное для пользователей решение, так как им не нужно делать никаких дополнительных настроек у себя, кроме добавления лишнего параметра в настройки RDP соединения. Я не знаю точно, насколько это безопасное решение. Не припоминаю, чтобы у RDG находили какие-то серьезные уязвимости.

3️⃣ Настроить подключение по RDP через браузер с помощью Apache Guacamole. С одной стороны удобно работать через браузер, так как не надо вообще ничего настраивать на клиенте, но с другой стороны при работе через браузер есть много нюансов с пробросом горячих клавиш, буфера обмена, с подключением принтеров. Подходит не всегда и не всем, но лично я настраивал подобные подключения и людей устраивало. Подобные подключения можно проксировать через Nginx, анализировать логи подключений с помощью fail2ban, добавлять basic auth и т.д.

4️⃣ Первые три способа я пробовал лично. Расскажу про ещё один, о котором узнал от знакомого. Есть софт, похожий на Apache Guacamole, только под Windows - Myrtille (open source). Настраивать сильно проще, чем AG (с этим есть объективные сложности, надо немного разбираться в теме). Обычный виндовый инсталлятор «Далее - Далее - ОК». Затем открываем браузер, заходим по адресу приложения и настраиваем. Поддерживает RDP, SSH и доступ к виртуальным машинам под Hyper-V. Веб клиент реализован на базе HTML5. Подключения можно также проксировать через Nginx, подключить сертификат, добавить basic auth и т.д. Myrtille поддерживает и печать, и передачу файлов.

5️⃣ Для полноты картины упомяну еще пару способов, которые сам не использовал, но знаю, что так можно. Проксировать RDP соединения напрямую умеет Nginx с помощью stream. Также шлюзом для RDP соединений может выступать HAProxy. Причём он умеет идентифицировать RDP, парсить rdp_cookie. Например, для запоминания связки "имя пользователя - сервер" и подключать пользователя к одному и тому же серверу. Актуально, если у вас HAProxy балансирует подключения на несколько RDP серверов.

А вы какой способ используете для защиты RDP? Может есть ещё что-то простое и удобное?

#windows #rdp #security

Есть одна вещь, которая мне не нравится в Debian. Я всегда выполняю одну и ту же настройку сразу после установки системы. Не понимаю, кто придумал по умолчанию логи cron писать в общий системный лог /var/log/syslog. Это при том, что настройка для отдельного ведения журнала cron уже есть в конфиге rsyslog, но почему-то закомментирована. И настройка для логирования файла /var/log/cron.log уже есть в logrotate.

Если вы так же, как и я, любите, когда логи cron хранятся в отдельном файле, то сделайте следующее. Открываете на редактирование /etc/rsyslog.conf и раскомментируете строку:
cron.*                 /var/log/cron.log
Далее отключаем запись логов в общий файл. Добавляем cron.none в следующую строку:
*.*;auth,authpriv.none,cron.none    -/var/log/syslog
Перезапускаем rsyslog и cron:
# systemctl restart rsyslog cron

Проверяем, появился ли файл с логом.
# ls -l /var/log/cron.log

На всякий случай проверьте файл /etc/logrotate.d/rsyslog. Есть ли там строка с упоминанием файла /var/log/cron.log. Вроде должна быть. Не помню, чтобы я руками добавлял.

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

Я подзабыл, а в Ubuntu тоже логи cron в наследство от Debian пишутся в общий syslog? Кто-то делает подобную настройку или это мой бзик? Я после Centos никак не могу привыкнуть, что по дефолту нет этого лога.

#debian

​​Продолжу вчерашнюю тему про RDP. Судя по комментариям, есть немало людей, которые просто ставят аналог fail2ban, только под Windows. Я ранее рассказывал про подобные решения:

▪ RDP Defender - https://t.me/srv_admin/1168
▪ EvlWatcher - https://t.me/srv_admin/1680
▪ IP Ban - https://t.me/srv_admin/1657

Мне лично RDP Defender больше всего нравится. Но есть ещё один бесплатный продукт, который раньше был популярен - Cyberarms IDDS. А сейчас у него даже сайт не открывается. Тем не менее, на github хранятся исходники и скомпилированная версия - https://github.com/EFTEC/Cyberarms Обновлений не было 5 лет. Я решил проверить, он вообще рабочий или уже нет.

Установил на Windows Server 2019, без проблем запустился. Всё работает. По функционалу и удобству он лучше всех перечисленных выше. У него настроек больше, они гибче, плюс уведомления по smtp отправлять умеет. Помимо подключений по RDP, может следить за виндовыми службами: ftp, smtp, sql server и некоторыми другими. Для каждой службы свой агент.

Принцип работы у Cyberarms IDDS примерно такой же, как у всех. Устанавливает свою службу, создаёт правило во встроенном брандмауэре, заполняет правило ip адресами. Перед установкой надо поставить в систему пакет Microsoft Visual C++ 2010 x64. Без него не установится. И агент, отвечающий за авторизацию по RDP называется Windows Base Security Agent. Во всех инструкциях в сети почему-то запускают другого агента - TLS/SSL Security Agent. С ним у меня ничего не работало.

Хочу напоминать, что подобного рода защита от перебора учёток решает только одну задачу. На моей памяти было как минимум две уязвимости в протоколе RDP, которые позволяли получить доступ к серверу в обход механизма аутентификации. То есть подобного рода программы никак вас от этого не защитят. Так что смотрящий напрямую в интернет RDP порт это очень небезопасно. До очередной найденной уязвимости. Сначала прокатится волна взломов, потом будет выяснено, через какую уязвимость они прошли. И только потом выпустят обновление, закрывающее эту уязвимость.

#windows #rdp #security

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

◽ обзорная статья по работе с json в zabbix
◽ jq - утилита для преобразования однострочных json в удобочитаемый вид, а также для получения значений через jsonpath
◽ онлайн сервис JSONLint для проверки синтаксиса
◽ форматирование json в удобочитаемый вид с помощью python
◽ онлайн сервис hcl2json для конвертации форматов json, yaml и hcl друг в друга
◽ jo - консольная утилита, создаёт json из поданных в неё данных. Умеет, к примеру, список файлов в директории оборачивать в json или вывод какой-нибудь консольной команды, типа ps.
◽ онлайн сервис JSONPath для извлечения данных из json
◽ gron - консольная утилита, которая превращает json в текст, к которому можно эффективно применить утилиту grep. То есть делает json грепабельным. 

#json

​​Постоянно пользуюсь утилитой rclone для загрузки данных в S3 хранилище. Вспомнил, что ни разу не писал про неё отдельно. Решил исправить. Думаю, многие знают про неё, так как программа старая, удобная, популярная. Она есть под все известные ОС: Windows, macOS, Linux, FreeBSD, NetBSD, OpenBSD, Plan9, Solaris.

Я использую её исключительно в консоли Linux. Она есть в базовых репозиториях, так что ставится стандартно:
# apt install rclone
# dnf install rclone
Самую свежую версию можно поставить вот так:
# curl https://rclone.org/install.sh | bash

Далее рисуем простой конфиг в файле ~/.config/rclone/rclone.conf:
[selectel]
type = swift
user = 79167_username
key = uO6GdPZ97
auth = https://api.selcdn.ru/v3
tenant = 79167_username
auth_version = 3
endpoint_type = public

Это пример для S3 хранилища от Selectel. Все учётные данные получите в ЛК. Я давно им пользуюсь. Когда выбирал, он был самым дешёвым. Сейчас не знаю как, не сравнивал. Для объёмов до 100 Гб там цены небольшие. За этот объём заплатите рублей 300 примерно (стандартное хранилище, холодное ещё дешевле), так что не критично. Рекомендую дублировать бэкапы сайтов, магазинов в S3. У меня это всегда второе, холодное хранилище, куда уезжают полные архивы с определённой периодичностью.

Бэкап директории /mnt/backup/day делается следующим образом:
# /usr/bin/rclone copy /mnt/backup/day selectel:websrv-day

Я обычно делаю 3 контейнера: day, week, month с настройкой хранения копий 7, 30 дней и бессрочно. Контейнер с месячными архивами чищу вручную время от времени, либо вообще не чищу. А первые два очищаются самостоятельно в соответствии со своими настройками. Следить самому за этим не надо. Если у вас это будет единственное хранилище, то очистку лучше настроить не по времени, а по количеству файлов в контейнере. Иначе если не уследите за бэкапами и они по какой-то причине не будут выполняться, через какое-то время все старые будут удалены, а новые не приедут.

В S3 от Selectel данные заходят очень быстро. Скорость до Гигабита в секунду. Скачивать редко приходится, так что не знаю, какая там реальная скорость, но проблем никогда не было. Думаю тоже что-то в районе гигабита, обычно сам интернет медленнее, куда грузить будете. Можно через панель управления зайти и открыть веб доступ к какому-нибудь файлу, сделать одноразовую ссылку. Также доступ к файлам есть через личный кабинет напрямую в браузере, либо по FTP. Я для визуального контроля и загрузки файлов обычно по FTP захожу.

Сайт - https://rclone.org

#backup #s3

​​Когда у вас много независимых друг от друга мониторингов, возникает проблема за контролем всего этого хозяйства. Лично я для Zabbix использую интеграцию с Grafana и делаю на последней дашборд с выводом триггеров с нескольких Zabbix серверов. Меня вполне устраивает такое решение для быстрого просмотра состояния нескольких (у меня 6) серверов мониторинга.

Подозреваю, что для Prometheus и его Alertmanager тоже должно быть что-то похоже на базе Grafana, но я сегодня хочу вам рассказать про другой дашборд, который может объединять в себе события от нескольких Alertmanager. Это программа под названием Karma - https://github.com/prymitive/karma, которая как раз представляет из себя Alert dashboard для Prometheus Alertmanager.

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

Конфиг у Karma, как не трудно догадаться, в формате yaml и в общем случае довольно простой. В репозитории есть пример с подключением локального alertmanager. Для удалённых просто uri будет отличаться и их будет несколько. Для самой простой настройки достаточно их подключить в режиме readonly:

servers:
  - name: prod
   uri: https://user:password@prod.alert.example.com
   timeout: 20s
   proxy: false
   readonly: true
  - name: dev
   uri: https://user:password@dev.alert.example.com
   timeout: 20s
   proxy: false
   readonly: true

Для аутентификации в Karma есть 2 способа: basic auth или передача учётных данных через header в запросе. А для авторизации - ACL списки. То есть этот продукт подходит для работы различных команд с разграничением доступа к поступающим оповещениям. Ограничение доступа работает не на просмотр, а на возможность подавления оповещения.

Demo - https://karma-demo.herokuapp.com
Исходники - https://github.com/prymitive/karma
Обзор и пример настройки - https://www.youtube.com/watch?v=pLI8-gHgedA

#prometheus #мониторинг #devops

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

В статье автор предлагает использовать фреймворк Selenium для создания скриншота сайта. Для его использования он написал небольшой скрипт на Python и опубликовал его в виде картинки 🤦

Дальше он предлагает добавить этот скрипт в Zabbix и использовать в каких-то действиях. Например, в триггере для мониторинга сайта. Если получаем ошибку мониторинга, то делаем автоматом скриншот. Скрипту url сайта передаём через макрос триггера {TRIGGER.URL}, так что не забудьте этот url указать в триггере.

Идея мне понравилась, только не захотелось возиться с Selenium. Я его вообще никогда не использовал. А ещё и скрипт набирать бы пришлось с картинки. В комментариях один человек посоветовал использовать утилиту cutycapt. И тут началось...

У меня тестовый Zabbix Server работает на базе Oracle Linux 8. Cutycapt старая утилита и для 8-й версии её вообще нет. Попытался собрать из исходников, не получилось, так как для сборки надо qt4, а он давно снят с поддержки и в репах его нет. Есть только qt5, но под ним не собирается. Долго я мучался со сборкой и установкой пакетов. Потом плюнул и просто установил пакет от 7-й версии, который взял в epel7. И на удивление, всё получилось. В зависимостях там qt5, которые подтянулись из epel8.

Также понадобился пакет Xvfb для запуска Cutycapt на сервере без графического окружения. В итоге скриншот сайта делается вот так:
# xvfb-run CutyCapt --url=https://serveradmin.ru --out=serveradmin.png

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

Помимо привязки к триггеру, можно сделать ручной запуск скрипта через веб интерфейс. А скриншот добавить на дашборд в виджет. Я так понял, что подобный виджет появился в версии 6.2, так как в 6.0 у себя не нашёл его.

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

#zabbix #website

▶️ За время ведения канала накопилось много пятничных юморных видосиков. Не хочется повторять публикации, хотя некоторые вещи можно с удовольствием пересматривать. Плюс аудитория постоянно меняется и увеличивается, а старые посты редко кто читает. Решил периодически делать тематические подборки, чтобы захватывать материал из прошлых статей.

🔥 Нестареющая классика - веселенький денек у сисадмина. Вряд ли нужны какие-то комментарии к этому видео. У автора ролика есть ещё несколько похожих творений. Мне понравилось вот это - The Website is Down #3: Remain Calm.
▪ Цикл качественного профессионального американского юмора на тему техподдержки - Nick Burns, Your Company's Computer Guy. Для восприятия юмора надо хорошо понимать английский на слух. Я несколько раз пересматривал данный цикл. Очень нравится.
🔥 Классная переозвучка фрагментов фильма Волк с Уолл-стрит - трудовые будни техподдержки. Лично я считаю это лучшей тематической переозвучкой из тех, что я видел.
▪ Хороший тематический видеоряд к песне от Научно-технического рэпа - Надо было ставить линукс. Нравится этот исполнитель, частенько слушаю под настроение.
▪ Нестандартный саркастически-юмористический ролик на тему работы тех. поддержки - The Expert: IT Support. От авторов известных скетчей на тему современного крупного бизнеса. Я все смотрел, понравилось.
▪ Эффективный способ решения проблем с вентилятором в системном блоке.
▪ Хороший юмор на тему Kubernetes - Hitler uses Kubernetes.
🔥 Как на самом деле пишется и проверяется код в больших технологичных компаниях? Ответ в ролике - how we write/review code in big tech companies.
▪ Забавный фрагмент из фильма Кремниевая Долина "Silicon Valley" - Удаление данных. К сожалению, сериал так и не посмотрел. Всегда находится что-то другое (иногда смотрю стримы Voodoosh перед сном по третьим героям).

В завершении поста анекдот:

Умер системный администратор, и попал на небо к Богу. Бог посмотрел на него и говорит, мол ты себя при жизни вел хорошо, грехов немного и поэтому сам выберешь, куда тебе отправляться, в рай или ад. Админ выбирает рай.

Заводит Бог сисадмина в одно помещение, а там стоят крутые сервера, навороченные рабочие станции, быстрая сетка, и говорит: "Это рай, здесь ты будешь жить и развлекаться в свое довольствие, и будешь ты простым пользователем". 

У админа глаза заблестели, но из любопытства он все равно просит Бога показать и ад. Бог отвечает: "Ад - это тоже здесь, только тогда ты будешь системным администраторoм".

#юмор #подборка

​​Давно слышал про бесплатную и открытую configuration and management database (CMDB) i-doit (не idiot, как хочется прочитать с первого взгляда 😁). Это база данных для хранения всей инфорvации об IT. Есть open source версия и платная. Основное отличие - в бесплатной можно только руками всё вводить и нет управления пользователями и ролями.

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

📌 I-doit умеет хранить и организовывать любую информацию, имеющую отношение к IT:
◽ оборудование, в том числе сервера, стойки, облачные ресурсы;
◽ общую информацию, документацию, контакты;
◽ программное обеспечение, лицензии, службы;
◽ сетевую информацию, в том числе с помощью встроенной системы управления IP адресами;
◽ географическое расположение объектов и группировку на основе этого.

Всё это удобно организовано. Проверить можно в Demo. Я там все разделы просмотрел, оценил. Полезной особенностью I-doit является встроенная интеграция с helpdesk системой Zammad. Она тоже open source, так что можно получить функциональную бесплатную связку из двух продуктов. В итоге i-doit будет показывать все тикеты, связанные с объектом, а в Zammad можно будет выбирать объект во время заведения тикета. Как это выглядит на практике можно посмотреть в документации к Zammad.

Если кто-то использует I-doit, дайте обратную связь по ней. Мне показалась эта система очень удобной и информативной. Работает на базе стандартного веб сервера php + mysql.

Сайт - https://www.i-doit.org
Исходники - https://sourceforge.net/projects/i-doit/files/i-doit
Demo - https://demo.i-doit.org

#управление #ITSM

Когда, как не в выходной день поговорить об играх. Если у вас есть желание установить и настроить свой игровой сервер какой-нибудь популярной игры, можно воспользоваться 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