Решил собрать в одну кучку все известные мне способы попадать на свой(или чужой) сервер, который находится за NAT.
Егор Вершинин @Dorlas
IT специалист
Backup and Restore — виртуальные машины в облаках/хостингах
Medium
6 min
Tutorial
Постановка задачи — есть виртуальная машина в облаке — мы хотим решить две задачи:
1. Резервировать ее по расписанию на наш сервер(а), находящиеся под нашим полным контролем.
2. Иметь возможность в любой момент сконвертировать нужную версию из резервной копии в виртуальную машину (в любом формате) и запустить ее на нашем оборудовании (т. е. приземлить виртуальную машину из облака на грешную...).
И так, поехали!
Поднимаем мониторинг на базе Icinga2/Web/Director/Grafana за 5 минут
Easy
21 min
Tutorial
Свое знакомство с мониторингом Icinga2 я начал в 2018-м году, со статей IT-KB, за что им огромная благодарность. Статьи были подробные, под Debian 8. В то время я активно использовал FreeBSD и за несколько дней изучения мне удалось запустить мониторинг в CBSD JAIL. В 2020-м все это было мною опробовано на Debian 10. Естественно с подробным документированием и составлением статей в личной WiKi. Мониторинг интересный, легкий, возможности широкие, мобильный клиент под Android приличный и удобный. Но есть проблема - даже по своим заметкам в WiKi установка в новой локации каждый раз занимает от часа до двух (на данный момент в телефоне уже с 10-к штук инстансов).
Год назад мне все это надоело и я потратил пару дней, чтобы написать ряд Ansible Playbook-ов, которые большую часть шагов сделают автоматически. Подробности ниже.
Почтовый сервер на Debian / ALT / Astra / RedOS — опыт портирования Ansible Playbook
Medium
5 min
Tutorial
История начинается в 2017-м году - когда мне потребовался самодельный почтовый сервер на связке Postfix + Dovecot + Roundcube + LDAP-каталог (AD на тот момент). Сказано - сделано - времени ушло прилично (делалось для FreeBSD), но зато много в чем получилось досконально разобраться. И естественно была составлена приличная статья-портянка в личной DokuWiki.
В 2021-м году адаптировали под Debian 11. В 2022-м был написан Ansible Playbook, который все делал автоматически, экономя пару часов времени ))) и нервов тоже изрядно экономил.
И вот наконец, неделю назад, была поставлена задача попробовать адаптировать данный Playbook к отечественным ОС (к 3-м самым распространенным, как видно из темы).
Если не хочется читать и погружаться в детали - все результаты выложены по ссылке (текущая версия Wiki + 4 архива Ansible Playbook): https://github.com/Dorlas/mailserver-ansible/
Установка Outline WiKi на Debian/Ubuntu с KeyCloak
Easy
12 min
Tutorial
Очередная статья про настройку Outline + KeyCloak. С одной стороны, статьи в сети есть. С другой стороны - начинаешь по ним делать и выплывают подводные камни, которые в статьях почему то не приведены. После полугода периодического мучения с установкой данного продукта решил собрать в кучу все мысли и приемы.
Первоисточник: Основной алгоритм был взят из статьи: https://wenkdth.org/posts/keycloak-outline-setup/.
Изменение настроек программ с сохранением персональных параметров
5 min
Предыстория
В одной медицинской организации внедряли решения на базе PACS-серверов Orthanc и DICOM-клиента Radiant. В ходе настройки выяснили, что каждый DICOM-клиент должен быть описан в PACS-серверах следующим образом:
- Имя клиента
- AE-имя (должно быть уникально)
- TCP-порт, который автоматически открывается на стороне клиента и принимает DICOM-обследования от PACS-сервера (т.е. сервер как бы толкает их в сторону клиента – инициируя соединение первым)
- IP-адрес
После настройки Radiant клиентов получили следующую информацию к размышлению – у каждого клиента настройка ПО с указанными выше параметрами приводила к заполнению файла pacs.xml, который располагался в профиле пользователя (путь: %APPDATA%\RadiantViewer\pacs.xml). При этом конфиг одного клиента от другого отличался минимум двумя параметрами (AE-имя у всех разное, а порт в основном одинаковый, кроме терминальных клиентов, работающих на одном и том же сервере – там порты тоже приходилось назначать разными).
Пример файла pacs.xml по ссылке:
Примерно полгода все было хорошо, система заработала…и тут до нас дошли «подводные камни»:
- Нам нужно ввести в строй несколько новых PACS-серверов, которые подменят старые (где стало заканчиваться место на дисках). PACS сервера в виртуальных машинах, но речь не об этом;
- Нам нужно как-то централизованно изменить уникальные конфигурации (двумя отличающимися параметрами) на 200 машинах (их количество регулярно увеличивалось);
- Учитывая темпы роста объемов обследований, решение нужно не разовое, а тиражируемое и регулярное (например, 1 раз в 3-5 месяцев).
Решение ниже.
Mikrotik – сбор и анализ NetFlow трафика
5 min
Предисловие
Когда-то давно, в далекой далекой галактике… Хотя если подумать, это было всего то 15 лет назад.
В общем были времена, когда в качестве центрального шлюза в сеть Интернет использовались решения на базе FreeBSD и Linux. И были эти решения любовно настроены, и обвешивались они всеми возможными и невозможными функциями (от межсетевого экрана и VPN серверов до TFTP+PXE-сервисов бездисковой загрузки)… и не было беды, и все было хорошо…
Но времена меняются, появляются новые решения, появляются компании, которые «дешево и сердито» готовят ядро Linux, обвешивают необходимым функционалом и продают это за весьма скромные деньги (сопоставимые со стоимостью аппаратной части).
Примером таких решения является компания Mikrotik и ее одноименные решения.
Старые технологии на новый лад. FreeBSD Jails + CBSD Project
7 min
Предисловие
Примерно 9 лет назад, когда в моем городе появились первые безлимитные тарифы (что-то вроде 128 кбит/сек за 500 руб.), я принял решение держать в квартире собственный «сервер» для решения различных задач. Одной из первых идей было поднятие зеркала для проекта FreeBSD.org. Проработало оно где-то 2 года. Далее в этом уже не было смысла, ввиду расширения каналов и других причин.
Помимо этого, сервер принимал на себя в разные периоды времени и другие задачи:
- Хранение резервный копий данных, документов и дистрибутивов;
- Закачка торрентов;
- Раздача торрентов по DLNA и SMB на различные устройства;
- VPN-клиент к провайдеру (был даже период, когда сервер держал два PPTP соединения через MPD – для работы локального трафика и медленного безлимита);
- VPN-сервер и подключение до офисного шлюза (канал до работы);
- Asterisk сервер для IP-телефонии (в дальнейшем в доме появились всякие SPA-3112, радио-трубки и т.д.);
- FTP-служба для получения данных с IP-камеры, для сброса бекапов с Mikrotik-ов скриптами;
- И т.д. и т.п.
Общая мысль – в руках был конструктор с кучей разноцветных деталей и большое желание прикрутить еще что-нибудь эдакое. В общем то обычная ситуация для большинства системных администраторов, знающих и любящих *nix-системы.
Многоступенчатая организация хранения резервных копий для самых маленьких
5 min
Совсем недавно по планете прокатились волны WannaCry и его клонов. А сама проблема шифровальщиков стоит перед системными администраторами уже более 10 лет. Рано или поздно – но все внедренные и реализованные меры по защите от шифровальщиков не помогают и все-таки находится пользователь, который открывает письмо, вложение и получает полный «букет». Также много «приятных и увлекательных» часов получает системный администратор.
И тут то все четко начинают понимать, что нужны резервные копии (много, разных, в разных местах). Т.е. правило 3-2-1, придуманное и описанное Peter-ом Krogh-ом, весьма желательно выполнять. Данная статья – пример, который помогает сделать реальным выполнение данного правила на «коленке» — без покупки дорогостоящего оборудования (в условиях жесткой экономии).
И тут то все четко начинают понимать, что нужны резервные копии (много, разных, в разных местах). Т.е. правило 3-2-1, придуманное и описанное Peter-ом Krogh-ом, весьма желательно выполнять. Данная статья – пример, который помогает сделать реальным выполнение данного правила на «коленке» — без покупки дорогостоящего оборудования (в условиях жесткой экономии).