​​Для редактирования и совместной работы с документами через браузер есть два наиболее популярных движка с открытым исходным кодом:

▪️ OnlyOffice
▪️ Collabora Online

Про #OnlyOffice я регулярно пишу, можно посмотреть материалы под соответствующим тэгом. Там же есть инструкции по быстрому запуску продукта. Решил то же самое подготовить по Collabora Online, чтобы можно было быстро их сравнить и выбрать то, что больше понравится.

Движок для редактирования документов работает в связке с каким-то другим продуктом по управлению файлами. Проще всего потестировать его в связке с ownCloud. Запускаем его:

# docker run -d -p 80:80 owncloud

Идём по IP адресу сервера https://10.20.1.36, создаём учётку админа и логинимся. В левом верхнем углу нажимаем на 3 полоски, раскрывая меню и переходим в раздел Market. Ставим приложение Collabora Online.

Переходим опять в консоль сервера и запускаем сервер collabora:

# docker run -t -d -p 9980:9980 -e "extra_params=--o:ssl.enable=false" collabora/code

Возвращаемся в веб интерфейс owncloud, переходим в Настройки ⇨ Администрирование ⇨ Дополнительно. В качестве адреса сервера Collabora Online указываем https://10.20.1.36:9980. На этом всё. Можно загружать документы и открывать их с помощью Collabora Online. У меня без каких-либо проблем сразу всё заработало по этой инструкции. Работает, кстати, эта связка довольно шустро. Мне понравилось. Погонял там с десяток своих документов и таблиц.

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

Интерфейс Onlyoffice больше похож на Excel, интуитивно с ним проще работать. Основные форматы - .docx, .xlsx, .pptx. Соответственно и совместимость с ними лучше. Collabora построена на базе LibreOffice, а он заметно отличается от Excel, так что переход будет более болезненный. Основные форматы - .odt, .ods, .odp. Майкрософтовские документы открывает хуже.

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

#docs #fileserver

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

⇨ Свой распределённый S3 на базе MinIO — практический опыт наступания на грабли / Алексей Плетнёв

Выступление двухгодичной давности, но я его посмотрел только на днях. У крупной компании возникла потребность в большом файловом хранилище (100 TБ данных и 100 ТБ трафика в месяц). Готовые решения отбросили из-за дороговизны. Решили строить своё на базе известного сервера MinIO.

📌 Причины, почему выбрали MinIO:

◽Open Source
◽Производительный
◽Распределённая архитектура
◽Легко масштабируется и разворачивается
◽Сжатие файлов на лету
◽Общая популярность проекта

📌 Проблемы, с которыми столкнулись при внедрении и эксплуатации:

▪️ Не очень информативная документация
▪️ По умолчанию модель отказоустойчивости такова, что при неудачном стечении обстоятельств выход из строя буквально нескольких дисков на одном сервере может привести к потере информации, хотя на первый взгляд кажется, что чуть ли не потеря половины кластера не приведёт к этому
▪️ Нельзя расширить существующий кластер. Можно только создать новый и присоединить его к текущему.
▪️ При обновлении нельзя перезапускать ноды по очереди. Рестартить надо разом весь кластер, так что без простоя сервиса не обойтись.
▪️ Вылезла куча критических багов, когда пропадали все пользователи и политики, бились сжатые файлы, неверно работало кэширование и т.д.
▪️ Реальный срок восстановления после замены диска непрогнозируемый. Нагрузка при этом на диски сопоставима с эксплуатацией RAID5.
▪️ Нет мониторинга производительности дисков. Если один диск жёстко тормозит, тормозит весь кластер. Эту проблему ты должен решать самостоятельно.

Для полноценного теста отказоустойчивого распределённого хранилища достаточно следующего железа. 3 одинаковые ноды:

- 8 CPU
- 16G RAM
- SSD NVME для горячих данных
- HDD для холодных

MinIO поверх ZFS работает значительно лучше, чем на обычной файловой системе, хотя разработчики это не рекомендуют. При расширении ZFS пулов, MinIO адекватно это переваривает и расширяется сам. Это позволяет решать вопрос с расширением кластера налету. Для дополнительной отказоустойчивости и возможности обновления без даунтайма автор к каждой ноде MinIO поставил кэш на базе Nginx. Пока сервер перезапускается, кэши отдают горячие данные.

В итоге автор делает следующий вывод. Minio неплохое локальное решение в рамках одной стойки или дата центра, но для большого распределённого кластера он плохо подходит из-за архитектуры и багов.

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

#S3

▶️ Пока ещё Youtube худо-бедно работает, продолжаем впитывать информацию. Тормозить стал уже и на мобильном интернете. Вчера явно заметил разницу. Пришлось пустить траф на ноуте через внешнюю прокси, чтобы нормально смотреть видео.

Как обычно, ниже те видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне показались интересными и полезными.

⇨ Настройка роутера MikroTik с BGP для просмотра видео дома
Автор рассказал, как решить вопрос со скоростью ютуб с помощью динамической маршрутизации на роутерах Mikrotik.

⇨ Proxmox CLUSTER. Что это и зачем? Создание кластера из 3 узлов (nodes)
Описание работы кластера Proxmox и пример настройки кластера из трёх нод. Автор настраивает сеть, объединяет узлы в кластер, показывает на практике, как работает миграция виртуальных машин между узлами кластера, настраивает HA.

⇨ RocketChat - Powerful, Chat and Communications platform. Rivals Slack, Teams, and more!
Обзор бесплатного self-hosted чат-сервера. У меня было много заметок по нему на канале, можно найти через поиск. Я сам постоянно обслуживаю и немного использую Rocket.Chat. Знаю его неплохо. Не могу сказать, что он мне нравится, но из бесплатного ничего лучше не знаю. В целом, работает нормально. Если у кого-то есть по нему вопросы, можно задавать.

⇨ Подробное описание начальной настройки OPNsense с нуля
Огромное (1,5 часа) видео по настройке программного шлюза OPNsense. Автор разобрал настройки файрвола, vlan, управляемого свитча.

⇨ Установка Next Generation FireWall Zenarmor в OPNsense
Установка и настройка бесплатного NGFW (Next Generation Firewall) Zenarmor в софтовый файрвол OPNsense. Интересное решение, раньше не слышал о нём.

⇨ Proxmox: LXC контейнер показывает ерунду по CPU
Небольшой баг с LXC контейнерами в Proxmox, когда они показывают нагрузку не за себя, а по всему хосту. Я с этим, кстати, тоже сталкивался, но думал, что так и надо. Просто забивал. Решение очень простое, в видео приведено.

⇨ Synology BACKUP! Active Backup for Business. Обзор функий, настройка. Windows и Linux backup. VM
Встроенная в Synology система бэкапа для компьютеров и серверов под управлением Windows и Linux, а так же сетевых дисков и некоторых систем виртуализации. Автор на конкретных примерах показал, как это работает. Весьма функциональная, удобная и простая в настройке штука.

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

#видео

​​Для быстрого доступа к СУБД Mysql очень удобно использовать небольшой скрипт Adminer, который представляет из себя ровно один php файл и запускается на любом хостинге. Я бы не писал о нём в очередной раз, если бы не столкнулся на днях с некоторыми нюансами при его использовании, так что решил оформить в заметку, чтобы самому потом не забыть.

С помощью Adminer можно создать пользователя и базу данных, назначить или изменить права, посмотреть содержимое таблиц, выгрузить или загрузить дамп. Лично мне для административных целей больше ничего и не надо. Разработчики, работая над сайтом, обычно просят phpmyadmin. Я не очень его люблю, потому что он монструозный, для него надо ставить дополнительные расширения php, поддерживать это дело.

Если я пользуюсь сам, то обычно просто закидываю adminer на сайт, делаю, что мне надо и потом сразу удаляю. В этот раз решил оставить на некоторое время и закрыть через basic_auth в Nginx (на самом деле в Angie). Вроде бы нет ничего проще:

# wget https://github.com/vrana/adminer/releases/download/v4.8.1/adminer-4.8.1-mysql-en.php
# mv adminer-4.8.1-mysql-en.php /var/www/html/adminer.php

Закрываем паролем. Создаём файл с учёткой:

# htpasswd -c /etc/nginx/.htpasswd admineruser21

Добавляем в Nginx:

location /adminer.php {
auth_basic "Administrator’s Area";
  auth_basic_user_file /etc/nginx/.htpasswd;
}

Перезапускаю Nginx, проверяю. Пароль не спрашивает, доступ прямой. Всё внимательно проверяю, ошибок нет. Я 100 раз это проделывал. Тут нет никаких нюансов. Но не работает.

Быстро догадался, в чём тут дело. В Nginx есть определённые правила обработки locations. Я с этой темой когда-то разбирался подробно и кое-что в памяти осело. Ниже для php файлов уже есть location:

location ~ \.php$ {
....
}

Он с регулярным выражением, поэтому обрабатывается раньше и при первом же совпадении поиск прекращается. Так что до моего location с паролем очередь просто не доходит. Сделать надо так:

location ~ adminer.php {
  auth_basic "Administrator’s Area";
  auth_basic_user_file /etc/nginx/.htpasswd;
.......................  
}

Тут надо указать все те же настройки, что у вас стоят для всех остальных php файлов в location ~ \.php$. И расположить location с adminer выше location для остальных php файлов. Это важно, так как судя по документации:

Затем nginx проверяет location’ы, заданные регулярными выражениями, в порядке их следования в конфигурационном файле. При первом же совпадении поиск прекращается и nginx использует совпавший location.

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

#webserver #nginx #mysql

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

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

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

#железо

​​Существует несколько наиболее популярных систем управления конфигурациями:

▪️ Saltstack 
▪️ Chef
▪️ Puppet
▪️ Ansible

Что интересно, наиболее молодая из них стала самой популярной на сегодняшний день. Расскажу кратко о них для общего образования.

🔹Saltstack - написана на Python, для работы на хосты устанавливается агент, хотя есть и безагентный режим работы с ограниченными возможностями. Проект стартовал в 2011 году. Работает по модели pull, где сервер публикует задачу, а агенты принимают ее и асинхронно выполняют практически в режиме реального времени. Архитектурно система разработана для поддержки огромных инфраструктур с тысячами и десятками тысяч серверов.

🔹Chef - написан на Ruby, также использует клиент-серверную архитектуру с агентами на хостах. Стартовал в 2009 году. Имеет большое сообщество и как следствие обширный набор "рецептов" по установке и настройки различного оборудования и софта. Например, Gitlab использует Chef для установки и управления self-hosted версии своего сервера.

🔹Puppet - написан на Ruby, также использует клиент-серверную архитектуру с агентами на хостах. Стартовал в 2005 году. Агенты периодически обращаются к серверу и забирают изменения настроек. Язык конфигурации довольно сложен, но и возможностей там очень много. Будет актуален для больших и сложных систем. Из того, что я помню, Foreman использует Puppet.

🔹Ansible - написан на Python, не требует установки агентов. Работает по модели push. В качестве транспорта использует SSH соединения. Проект стартовал в 2012 году, в 2015 его купил Red Hat и начался стремительный рост популярности. По факту сейчас это наиболее распространённая система управления конфигурациями. Её отличает простота настройки и запуска в работу. Будет актуальна даже на малых масштабах инфраструктуры. Есть ряд проблем на больших проектах с тысячами серверов. Возможно там это будет не самое подходящее решение. Язык разметки конфигураций YAML. Читается и пишется относительно легко. За счёт этого и отсутствия агентов для взаимодействия и стал так популярен. Есть хорошая документация, которой достаточно для эксплуатации.

На сегодняшний день системному администратору или девопсу обязательно надо знать Ansible, даже если вы сами не собираетесь описывать инфраструктуру с его помощью. Большое количество софта описано с помощью ролей Ansible. Это может сильно упростить установку и эксплуатацию. Например, через Ansible можно быстро развернуть Ceph, Kubernetes, кластер Patrony и т.д. Также под весь популярный софт попроще есть наборы плейбуков для установки, обновления. Тот же Zabbix агент обновлять или ставить с нуля на группу хостов. У меня была подборка обучающих материалов по Ansible.

Насчёт популярности остальных могу только субъективно погадать. Saltstack точно менее популярен остальных, а вот Puppet и Chef могут рядом идти, хотя Chef всё же наверное популярнее. Не знаю, кто из них лучше. Я только в общих чертах о них слышал, сам никогда не работал с ними. Не приходилось сталкиваться. А вот с Ansible постоянно.

В этот список, по идее, можно было бы добавить и Terraform, но он как-будто инструмент более высокого порядка для разворачивания инфраструктуры на уровне серверов и виртуальных машин облачных провайдеров, когда надо подучить набор серверов с заданными характеристиками и сетями. А не для того, чтобы потом добавлять SSH ключи, пользователей на сервера и устанавливать софт.

#ansible

​​Полезной возможностью Tmux является расширение функциональности за счёт плагинов. Для тех, кто не знает, поясню, что с помощью Tmux можно не переживать за разрыв SSH сессии. Исполнение всех команд продолжится даже после вашего отключения. Потом можно подключиться заново и попасть в свою сессию. Я в обязательном порядке все более-менее долгосрочные операции делаю в подобных программах. Раньше использовал Screen для этого, но последнее время перехожу на Tmux, так как он удобнее и функциональнее.

Особенно важно выполнять обновление систем в Tmux или Screen, так как обрыв соединения в этот момент может привести к реальным проблемам. Я и сам сталкивался, и читатели присылали свои проблемы по этой же части. У меня были заметки на этот счёт.

Для Tmux есть плагин Tmux Resurrect, который позволяет сохранить состояние Tmux со всеми панелями и окнами и порядком их размещения. Вы сможете подключиться в свою настроенную сессию не только в случае отключения, но и перезагрузки Tmux или всего сервера. То есть вы можете настроить в первом окне несколько панелей, к примеру, с htop, tail каких-то логов, переход в какую-то директорию. Во втором окне что-то ещё. Потом сохранить эту сессию. Даже если сервер будет перезагружен, вы сможете восстановить всё окружение.

Демонстрация, как это работает:
▶️  https://vimeo.com/104763018

Установить Tmux Resurrect можно либо через Tmux Plugin Manager, либо напрямую:

# git clone https://github.com/tmux-plugins/tmux-resurrect

Добавляем в ~/.tmux.conf в самое начало:

run-shell ~/tmux-resurrect/resurrect.tmux

Заходим в сессию Tmux и сохраняем её состояние через prefix + Ctrl-s, по умолчанию префикс это Ctrl-b, то есть жмём Ctrl-b потом сразу Ctrl-s. Внизу будет информационное сообщение, что сессия сохранена. Восстановить её можно будет через комбинацию Ctrl-b потом сразу Ctrl-r.

Интересная возможность, которая позволяет завершать сессию, сохраняя её состояние. У меня привычка не оставлять запущенные сессии в фоне. Если их оставлять, то они накапливаются, забываются и могут месяцами висеть. Я обычно поработаю и все сессии после себя завершаю.

#linux #terminal

​​Вчера очень внимательно читал статью на хабре про расследование паразитного чтения диска, когда не было понятно, кто и почему его постоянно читает и таким образом нагружает:

⇨ Расследуем фантомные чтения с диска в Linux

Я люблю такие материалы, так как обычно конспектирую, если нахожу что-то новое. Записываю себе в свою базу знаний. Частично из неё потом получаются заметки здесь.

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

1️⃣ Через iostat смотрим нагрузку на диск и убеждаемся, что кто-то его активно читает. Сейчас уже не обязательно iostat ставить, так как htop может показать то же самое.

2️⃣ Запускаем blktrace в режиме наблюдения за операциями чтения с выводом результата в консоль:

# blktrace -d /dev/sda1 -a read -o - | blkparse -i -

Вывод примерно такой:

259,0  7   4618   5.943408644 425548 Q RA 536514808 + 8 [questdb-ilpwrit]

В данном случае RA 536514808 это событие чтения с диска начиная с блока 536514808.

3️⃣ Смотрим, что это за блок:

# debugfs -R 'icheck 536514808 ' /dev/sda1

debugfs 1.46.5 (30-Dec-2021)
Block Inode number
536514808 8270377

То есть этот блок имеет номер айноды 8270377.

4️⃣ Смотрим, что это за файл:

debugfs -R 'ncheck 8270377' /dev/sda1
Inode Pathname
8270377 /home/ubuntu/.questdb/db/table_name/2022-10-04/symbol_col9.d.1092

Нашли файл, который активно читает процесс questdb-ilpwrit.

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

Был уверен, что это можно сделать проще, так как я уже занимался подобными вопросами. Вспомнил про утилиту fatrace. Она заменяет более сложные strace или blktrace в простых случаях.

# apt install fatrace

Просто запускаем её и наблюдаем

# fatrace

В соседней консоли откроем лог:

# tail -n 10 /var/log/syslog

Смотрим в консоль fatrace:

bash(2143): RO /usr/bin/tail
tail(2143): RO /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
tail(2143): O  /etc/ld.so.cache
tail(2143): RO /usr/lib/x86_64-linux-gnu/libc.so.6
tail(2143): C  /etc/ld.so.cache
tail(2143): O  /usr/lib/locale/locale-archive
tail(2143): RCO /etc/locale.alias
tail(2143): O  /var/log/syslog
tail(2143): R  /var/log/syslog

Результат тот же самый, что и выше с blktrace, только намного проще. В fatrace можно сразу отфильтровать вывод по типам операций. Например, только чтение или запись:

# fatrace -f R
# fatrace -f W

Собираем все события в течении 30 секунд с записью в текстовый лог:

# fatrace -s -t 30 -o /tmp/fatrace.log

Не хватает только наблюдения за конкретным процессом. Почему-то ключ -p позволяет не задать конкретный пид процесса для наблюдения, а исключить из результатов операции процесса с этим pid:

# fatrace -p 697

Можно исключить, к примеру bash или sshd. Они обычно не нужны для расследований.

Рекомендую заметку сохранить, особенно про fatrace. Я себе отдельно записал ещё вот это:

# debugfs -R 'icheck 536514808 ' /dev/sda1
# debugfs -R 'ncheck 8270377' /dev/sda1

#linux #perfomance

​​Развернул и потестировал очень любопытный бесплатный продукт - JumpServer. Сразу скажу на что он похож - Apache Guacamole, Trasa (проект умер) или Myrtille, но более функциональный и простой в настройке. Из минусов - есть баги и он китайский. Но в целом работает. У меня получилось очень быстро развернуть и настроить для простых подключений по SSH и RDP.

📌 JumpServer позволяет:

◽Вести локальную базу пользователей с различными методами аутентификации с логированием их действий.
◽Организовывать этим пользователям удалённый доступ к другим хостам по SSH, RDP или веб. То есть можно настроить в том числе доступ к веб интерфейсу различных устройств. Отдельно поддерживается доступ к различным СУБД.
◽Использовать в качестве клиента для подключения браузер или отдельный SSH и RDP клиент от самого JumpServer.
◽Настраивать разветвлённую структуру групп хостов и пользователей с различными правами доступа.

Установка и настройка выглядят следующим образом:

1️⃣ Разворачиваем систему с помощью скрипта. Всё запускается в Docker. Он должен быть самой свежей версии. На более старых возникает баг, не стартует один контейнер. Я с этим столкнулся на Debian 12. Пришлось подключать репу Docker и ставить самую свежую версию.

# curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

2️⃣ Заходим в веб интерфейс по IP адресу сервера. Учётка по умолчанию: admin / ChangeMe.

3️⃣ В разделе User ⇨ user создаём нового пользователя.

4️⃣ В разделе Assets ⇨ assets добавляем новый хост типа Linux или Windows. Указываете IP адрес хоста и учётную запись для аутентификации.

5️⃣ В разделе Policies ⇨ Authorization создаёте новую политику или изменяете существующую. В ней надо указать учётную запись, которую вы создали и хосты, которые вы добавили. У нас сейчас их по одному, можно соответственно, множественные пересечения делать.

На этом всё. Можно заходить созданным пользователем и пробовать подключаться. Либо тут же попробовать под админом, зайдя в отдельную вкладку Workbench. У меня сразу заработало, но с нюансами. Например, в веб консоли, если запустить mc или htop, то всё виснет. Не работает псевдографика. Я поигрался с настройками и темой, но быстро не смог разобраться, в чём проблема. Альтернатива - использовать отдельный SSH клиент, который интегрируется с JumpServer. Скачать его можно тут же в веб интерфейсе. Подключение по RDP нормально заработало.

В целом, система понравилась. В первую очередь за счёт простоты установки и настройки. Никаких заморочек, всё заработало сразу. Инструкция по быстрому запуску (quickstart) тут.

Что ещё умеет JumpServer:
- Объединять пользователей в группы
- Объединять хосты в группы и делить на зоны
- Каталогизировать хосты по типам платформ, например, Windows, Linux, macOS, BSD и т.д.
- Создавать шаблоны для настроек пользователей
- Автоматически создавать пользователей на управляемых хостах
- Создавать списки ACL с разрешениями или запретами на подключения
- Вести список всех запускаемых в консоли команд

⇨ Сайт / Исходники

#remote

Я ранее делал пару заметок на тему бесплатных инструментов для организации SSO: Keycloak и Authentik. Первый более навороченный и сложный для больших организаций. Второй попроще и больше подходит для небольших инфраструктур, в том числе личных сервисов. По настройке и возможностям мне Authentik понравился больше. Жду подходящий проект, чтобы его внедрить. Уже давно решил, что где-нибудь его попробую.

Тут как раз на днях посмотрел видео про настройку Basic Auth на базе Authentik. Очень востребованная лично для меня функциональность. Я люблю использовать Basic Auth в Nginx для того, чтобы скрыть от посторонних глаз то, что не должно быть в публичном доступе: различные управляющие веб панели, типа postfixadmin или phpmyadmin, веб доступ к 1С и т.д.

▶️ Authentik и basic http аутентификация

Автор по шагам показал, как это сделать на примере Traefik и Nginx. Там ничего особо сложного, но из-за скудной документации по этой теме некоторые вещи неочевидны. С инструкцией всё понятно. Посмотрел наглядно, как это выглядит. Мне понравилось. С учётом того, как часто я использую Basic Auth, точно пригодится. Вот ссылка на документацию по теме. Там реально всего пару предложений и пример конфига.

У автора серия из 3-х публикаций про Authentik:
▶️ Настройка authentik по-быстрому
▶️ OIDC авторизация с помощью Authentik на примере Portainer

Этой информации достаточно для базового внедрения основных возможностей. Материал свежий и пока актуальный.

#sso #nginx

​​В репозиториях популярных дистрибутивов есть маленькая, но в некоторых случаях полезная программа progress. Из названия примерно понятно, что она делает - показывает шкалу в % выполнения различных дисковых операций. Она поддерживает так называемые coreutils - cp, mv, dd, tar, gzip/gunzip, cat и т.д.

Progress по смыслу немного похожа на pv, но принцип работы там совсем другой. Pv берёт информацию из пайпов, соответственно, надо заранее направить поток в неё, чтобы что-то увидеть. А progress сканирует каталог /proc, находит там поддерживаемые утилиты, далее идёт в fd и fdinfo, находит там открытые файлы и следит за их изменениями.

Для того, чтобы посмотреть прогресс той или иной команды, не обязательно запускать утилиту progress вместе с выполнением. Это можно сделать в любой момент времени. Например, запустили упаковку или распаковку большого архива gz и хотите посмотреть, как она выполняется. Достаточно открыть вторую консоль и там посмотреть. Мне это часто актуально, когда большие дампы sql распаковываю. Иногда это прям очень долго, особенно, когда однопоточный gzip используется.

Покажу сразу на примере. Создадим файл:

# dd if=/dev/urandom of=testfile bs=1M count=2048

За процессом, кстати, тоже можно следить с помощью progress, только не будет отображаться % выполнения, потому что утилита ничего не знает о конечном размере. Будет отображаться только скорость записи в режиме реального времени.

Жмём файл:

# gzip testfile

Открываем вторую консоль и там смотрим за процессом:

# watch -n 1 progress -q
[34209] gzip /tmp/testfile
    6.5% (132.2 MiB / 2 GiB)

Если запустить без watch, то progress выведет только текущую информацию и сразу же закроется. То есть не получится наблюдать в режиме реального времени.

То же самое будет и с распаковкой:

# gunzip testfile.gz

В соседней консоли смотрим:

# watch -n 1 progress -q
[35685] gzip /tmp/testfile.gz
    76.1% (1.5 GiB / 2.0 GiB)

Progress очень маленькая утилитка, написанная на чистом C (вспоминается песня "Папа может в C"). Размер - 31K. Из зависимостей только небольшая библиотека ncurses для вывода информации от сишных программ в терминал. Есть почти под все линуксы:

# apt install progress
# dnf install progress

⇨ Исходники

#terminal #linux

Пока я был в отпуске, пропустил важную для меня новость. Ну как важную. Была важной, а теперь уже не очень. В общем, компания Битрикс наконец-то выпустила обновление своего окружения VMBitrix 9.0.0. И как вы думаете, на базе какой операционной системы? .... Барабанная дробь .... CentOS Stream 9 😱.

Этим они меня удивили. Самый неудачный выбор, который только можно придумать. Напомню, что до этого окружение было на базе Centos 6 и 7. 7-я версия уже EOL, так что они переехали на Stream. Как я понял, просто поленились и пошли по самому простому пути. Я ни разу ни у кого не видел в проде Centos Stream. Соответственно, не понятно, для кого они это выпустили. Ожидал увидеть Debian или Ubuntu, на худой конец Rocky или Alma, но надеялся на Docker образы.

Поясню, что VMBitrix это готовое преднастроенное окружение для запуска сайтов на базе Bitrix, а так же CRM Bitrix24. Сам сайт, в принципе, всё равно на чём запускать. Он заработает практически на любом хостинге на базе Nginx + Apache + PHP. А вот с Bitrix24 посложнее, потому что там пуши. Настраивать самостоятельно хостинг под него утомительно. Не хочется тратить на это время. Готовое окружение эффективно решает эту задачу, плюс некоторые другие типа многосайтовости, получение сертификатов и т.д. В целом, пользоваться удобно, потому что, во-первых, экономит время, а во-вторых, у всех одинаковое окружение. Это упрощает разработку и перенос продукта.

Я для себя эту задачу уже решил и настроил всё в Debian 12 на базе Angie вместо Nginx. Настройки уже обкатаны, веб сервер работает пару месяцев. Планировал статью написать, но не знаю как по времени сложится. Особо некогда. Если вы работаете с Ubuntu, то рекомендую вот этот материал:

⇨ CRM Битрикс-24 на веб-окружении под Ubuntu 24.04, c поддержкой PUSH и многосайтовости

Это сайт хорошего специалиста. Я с ним пересекался на одном проекте. Если вам нужен проект на Битриксе, рекомендую. По стоимости будет недёшево, но и результат будет хороший в отличие от многих других вариантов. Мне есть с чем сравнивать, так как с Битриксами работаю последние лет 10. Сейчас уже сильно меньше, а лет 5 назад постоянно был вовлечён в разработку. Буквально на днях обращался человек, просил посоветовать кого-нибудь для разработки под Битрикс, потому что уже намучался и отчаялся найти хорошего исполнителя. Это типичная история для тех, кто ввязался в разработку на базе Bitrix. Абсолютно (без преувеличения) все, с кем я пересекался по этой теме, просили посоветовать хорошего разработчика.

Вот, кстати, сама новость про VMBitrix 9.0.0:
⇨ https://dev.1c-bitrix.ru/community/forums/forum32/topic159152/
Там есть все технические подробности.

Можно считать, что VMBitrix больше нет. Не знаю, кто будет себе разворачивать его в прод на базе Centos Stream. Для разработки программистам, наверное, сойдёт, но потом встанет вопрос с переносом в прод. Предвижу истории, когда разработчик будет говорить, что у него всё работает, а на проде будут ошибки. Я сам уже сталкивался с такими моментами, потому что много мелких нюансов по настройке веб сервера, прав доступа, хранения сессий, передачи заголовков, IP адресов и т. д. Если разработчики совсем не понимают в администрировании, то они нормально перенести не смогут.

#bitrix

Провёл почти всё лето с семьёй на даче у родителей. Тут у них старый видик есть с кассетами. Подключается к довольно современному телевизору, у которого присутствуют входы для "тюльпанов". Увидел эту картинку и как-то проникся. Тут наверное есть люди, которые никогда не видели эти провода. Я в начале 90-х познакомился с ними, когда купили видеомагнитофон Panasonic.

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

Проблема в том, что дрова от тюнера то ли под XP, то ли Win7, придётся на отдельный хард ставить старую систему, искать дрова, везти видик, подключать. Хлопотный процесс. Проще было бы отдать на оцифровку, но из-за одной кассеты не хочется куда-то ехать.

#разное

Не так давно я делал обзор на свой текущий рюкзак со всем его содержимым. Ещё тогда подумал, что рюкзаку уже много лет (~8-9), выглядит не очень и можно было бы поменять. Но у меня вообще нет свободного времени заниматься подбором рюкзака, так что вечно бы откладывал этот момент. А тут так сложилось, что он сам пришёл мне в руки. Забегая вперёд скажу, что он стал моим основным рюкзаком. Я с ним походил 2 недели, так что могу написать осмысленный отзыв, который написан полностью мной, вообще без редактуры. 

Речь пойдёт про рюкзак Bobby Edge бренда XD Design. Он хорошо подойдёт тем, кто любит носить с собой кучу вещей. Это как раз про меня. Я бывает по 2-3 ноута с зарядками загружаю в рюкзак, когда еду на дачу с семьёй. А вообще, это городской рюкзак среднего объёма – 17 литров.

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

Поначалу показалось это не очень удобно, так как привык, что в прошлом рюкзаке у меня было 4 отделения на молниях. Можно было сразу попасть в любое из них. Но при этом было 8 ходунков по 2 на каждой молнии. Всё это неизменно звенело при ходьбе, что было как-то не очень. В Bobby Edge молния одна, ходунки не звенят вообще. На них есть фиксатор, который предотвращает случайное раскрытие молнии, он же держит ручки бегунков, чтобы они не болтались и не звенели. 

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

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

Могу много про рюкзак рассказывать. Кто меня давно читает, знает, что я люблю длинные тексты, но это не формат Telegram канала. Так что кратко отмечу другие особенности:

◽️Широкие лямки позволяют плотно подтянуть рюкзак к спине. Для меня это актуально, так как со спиной есть проблемы. Прошлый рюкзак специально покупал с разгрузкой на груди и поясе. Я спину подлечил, так что не очень актуально стало. Этот хорошо сидит и без разгрузок. 
◽️На лямке рюкзака есть небольшой карманчик для проездного или карт. 
◽️На спине есть отдельный карман с карабином для ключей. На нём же заявлена RFID-защита. На практике вряд ли она кому-то нужна. 
◽️Помимо отделения для ноута с диагональю до 16″, есть отделение для планшета до 10″.

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

#разное

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

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

Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.iss.one/boost/srv_admin.

📌 Больше всего пересылок:
◽️Список IP адресов Youtube для ускорения (534)
◽️Последовательность действия для проверки сервера на взлом (447)
◽️Подборка тематических видео по IT (336)

📌 Больше всего комментариев:
◽️Список IP адресов Youtube для ускорения (181)
◽️Подборка тематических видео по IT (113)
◽️Мой новый рюкзак (89)

📌 Больше всего реакций:
◽️Моя подготовка к отпуску (276)
◽️Восстановление данных с помощью Scalpel (204)
◽️Список IP адресов Youtube для ускорения (200)

📌 Больше всего просмотров:
◽️Список IP адресов Youtube для ускорения (12570)
◽️Подборка тематических видео по IT (10561)
◽️Установка Collabora Online (10185)

#топ

Собрал в одну заметку замечания по настройке службы SSHD, которая обеспечивает подключение к серверам по SSH. Эта служба присутствует практически во всех серверах. Сказал бы даже, что во всех. Я не припоминаю ни одной виртуалки или железного сервера, куда бы не было доступа по SSH. По возможности, доступ к этой службе лучше закрывать от публичного доступа, но иногда это либо затруднительно, либо вообще невозможно.

Настройки этой службы обычно живут в конфигурационном файле /etc/ssh/sshd_config.

1️⃣ Аутентификация по паролю. Включать или отключать, каждый решает сам для себя. Я лично всегда аутентификацию по паролю оставляю. Просто на всякий случай. Если пароль несловарный, то подобрать его всё равно практически нереально. Проблем с безопасностью это не вызывает.

PasswordAuthentication yes

Если аутентификацию по паролю отключить, то сразу отваливаются все боты, что непрерывно долбятся в службу. Лог будет менее замусорен.

2️⃣ Аутентификация с использованием публичных ключей. По умолчанию она включена и какой-то отдельной настройки не требует. Решил добавить этот пункт, чтобы лишний раз напомнить про ed25519 ключи. Они более надёжны и, что полезно на практике, более короткие. С ними удобнее работать. У меня была отдельная заметка про их использование.

PubkeyAuthentication yes

3️⃣ Разрешение на аутентификацию пользователю root. Тут тоже не буду ничего рекомендовать. Каждый сам решает, разрешает он руту аутентификацию или нет. Если я работаю на сервере один, то обычно аутентификацию разрешаю и работаю всегда под root. Я туда только для этого и захожу, мне не нужны другие пользователи с ограниченными правами. Если же вы работаете не один, то разумнее разделять пользователей, работать через sudo и логировать действия всех пользователей. Так что универсального совета быть не может.

Если вы сами ещё не определились, как вам лучше, то отключите эту возможность. Когда разберётесь, сделаете, как вам надо.

PermitRootLogin no

4️⃣ Ограничение на подключение на уровне группы или пользователей. Только пользователи определённой группы или явно указанные смогут подключаться по SSH. Я на практике именно для SSH не пользуюсь этой возможностью, а вот пользователей, которые подключаются по SFTP, обычно завожу в отдельную группу и разрешаю по SFTP подключаться только им. Но это другая настройка. Будет ниже.

AllowGroups sshgroup
AllowUsers user01 user02

5️⃣ Порт, на котором работает служба. Стандартный - 22. Большого смысла менять его нет. Как только первые боты разузнают, что у вас на каком-то порту работает служба, начнут туда долбиться, так же, как и на 22-й. Да и в shodan скорее всего информация об этом появится. Я по привычке порт меняю, если он доступен публично. Хуже от этого не будет, особенно если вы от сканирования портов тоже закрылись. Если служба закрыта от публичного доступа, то оставляю, как есть.

Port 22

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

MaxAuthTries 3

Пользователь подключился, 3 раза неправильно ввёл пароль, его отключает. После этого нужно устанавливать новое соединение.

7️⃣ Ограничение сессий внутри одного SSH-подключения. Не путать с ограничением на количество параллельных сессий с одного хоста. Этот параметр отвечает не за это. Если вы просто подключаетесь к серверу и его администрируете, то вам хватит и одной сессии.

MaxSessions 1

8️⃣ Принудительный запуск какой-то конкретной команды после регистрации пользователя в системе. Например, запускаем не стандартную оболочку, а прокладку, которая будет логировать все действия пользователей. Вот пример с log-user-session. А вот с принудительным запуском подсистемы sftp. Показываю сразу рабочий пример с подключением по sftp заданной группы пользователей, с chroot в конкретную директорию и с umask 002 для новых файлов.

Subsystem sftp internal-sftp -u 002
Match User sftpusers      
ChrootDirectory /var/www    
ForceCommand internal-sftp -u 002

#linux #security

​​Ранее рассказывал о том, как можно выпустить самоподписанный сертификат, установить его в веб сервер и настроить доверие. В комментариях были замечания, что это неудобно делать вручную для многих серверов. То решение было описано для одного сервера. Ниже рассмотрю вариант, как решить эту же задачу, только для всей внутренней инфраструктуры.

Речь пойдёт про open source центр сертификации от компании SmallStep - step-ca. Его можно развернуть у себя и использовать для различных задач. Я расскажу на примере получения HTTPS-сертификатов X.509 для локальных веб ресурсов с помощью протокола ACME и одноимённой утилиты. Помимо этого на базе step-ca можно организовать:
◽выдачу SSH-сертификатов для пользователей
◽выпуск токенов единого входа OAuth OIDC
◽выпуск клиентских сертификатов X.509 для TLS аутентификации
Всё это описано в документации и в рамках заметки не раскрыть.

Установка step-ca описана в документации. Выглядит она относительно просто, так как есть готовые пакеты. А относительно, потому что юнит systemd и рабочие каталоги придётся делать вручную.

Вот инструкция для установки на Debian/Ubuntu:

# wget https://dl.smallstep.com/cli/docs-ca-install/latest/step-cli_amd64.deb
# dpkg -i step-cli_amd64.deb

# wget https://dl.smallstep.com/certificates/docs-ca-install/latest/step-ca_amd64.deb
# dpkg -i step-ca_amd64.deb

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

# step-cli ca init
✔ Deployment Type: Standalone
✔ (e.g. Smallstep): PrivateCA (можно любое имя использовать)
✔ (e.g. :443 or 127.0.0.1:443): :443
✔ (e.g. [email protected]): [email protected]
✔ [leave empty and we'll generate one]:
✔ Password: E}b;-9DU9UyАВ8TU7$FINl-T8OM

Теперь переносим настройки в /etc/step-ca и запускаем как службу.

# useradd --user-group --system --home /etc/step-ca --shell /bin/false step
# setcap CAP_NET_BIND_SERVICE=+eip $(which step-ca)
# mkdir /etc/step-ca
# mv $(step path)/* /etc/step-ca

# touch /etc/step-ca/password.txt
# chmod 600 /etc/step-ca/password.txt
# mcedit /etc/step-ca/password.txt
# chown -R step:step /etc/step-ca

В файл password.txt записываем пароль от CA, который был создан во время инициализации. В файлах /etc/step-ca/config/ca.json и defaults.json меняем все пути с /root/.step на /etc/step-ca. И создаём юнит для systemd:

# mcedit /etc/systemd/system/step-ca.service

Содержимое не привожу, оно длинное, в заметку не уместится. Взял 1 в 1 из документации, он же в репозитории.

# systemctl daemon-reload
# systemctl enable --now step-ca

Служба должна запуститься на порту 443. Можно браузером зайти. Там будет страница с ошибкой, потому что никакого веб интерфейса нет, но тем не менее будет видно, что сервис работает.

Сразу отмечу важный нюанс. По умолчанию step-ca выпускает сертификаты на 24 часа. Для каких-то задач это, наверное, нормально, но для веб серверов не вижу смысла перевыпускать так часто, даже с учётом того, что это автоматизировано. Можете оставить так, а можете увеличить время. Тут об этом рассказано в доках.

Активируем ACME провизионер в step-ca:

# step ca provisioner add acme --type ACME

Эта команда добавит некоторые настройки в ca.json. Перезапускаем службу:

# systemctl restart step-ca

Теперь можно брать acme.sh или любой другой клиент (certbot и т.д.) и настраивать выпуск сертификатов через свой CA. Для этого надо либо на клиентских системах добавить root_ca.crt в системные, либо при запуске клиента указывать явно:

acme.sh --issue --standalone -d debian12-vm \
    --server https://10.20.1.36/acme/acme/directory \
    --ca-bundle ~/certs/root_ca.crt \
    --fullchain-file debian12-vm.crt \
    --key-file debian12-vm.key

Работаем с этим CA так же, как и с другими: добавляем серты в веб сервера, настраиваем автообновление. И не забываем в клиентские машины добавить CA в доверенные, чтобы в браузерах не было предупреждения.

#security #webserver

Существует отдельный класс файрволов - NGFW (Next Generation Firewall). Они либо работают в связке с IDPS (Intrusion Detection and Prevention System), либо включает её в себе. Если говорить простыми словами, то это файрвол, интегрированный с системой обнаружения и предотвращения вторжения.

Наиболее известный бесплатный представитель этого класса - Suricata. Она интегрирована в софтовые файрволы Pfsense, OPNsense, IPFire и некоторые российские продукты. Если не ошибаюсь, то в IDECO и ИКС тоже она. Но ниже речь пойдёт не о ней, а о Zenarmor. Это коммерческий продукт, у которого есть функциональная бесплатная версия.

Обратил на него внимание, потому что он интегрирован в OPNsense, легко и быстро устанавливается и настраивается. Я сделал это, проверил работу, всё получилось с первого раза. Сразу скажу, какие задачи умеет решать бесплатная версия Zenarmor:

▪️ Просмотр текущей сетевой активности в режиме реального времени. Видно, какой хост куда обращается. Во время просмотра можно настроить различные блокировки на уровне хоста, адреса или домена назначения, tcp портов.
▪️ Сбор сводной статистики по сетевой активности с возможностью экспорта.
▪️ Блокировка доступа по сформированным спискам сайтов или типам трафика. Можно заблокировать весь трафик voip или https. Можем заблокировать конкретный сайт vk.com или применить сразу готовый список с сайтами, относящимся к социальным сетям или другим категориям.
▪️ Zenarmor регулярно обновляет сигнатуры угроз со своих серверов и теоретически может их предотвращать. На практике я это не проверял, потому что не знаю как. По идее, он должен автоматически блокировать вредоносную активность вирусов.

Всю основную функциональность я проверил. Развернул по небольшому руководству из этого видео:

▶️ Установка Next Generation FireWall Zenarmor в OPNsense

Собственно, оно и было отправной точкой в этой теме. Установил OPNsense, далее плагин Zenarmor. Подключил тестовую машину с виндой к шлюзу и погонял трафик с неё. Настройка очень простая. В приведённом видео всё есть. Там же примеры возможностей, дашбордов, отчётов. Если вам нужны красивые картинки со статистикой для руководства, то это будет неплохим решением.

Все возможности бесплатной версии Zenarmor перечислены на странице со сравнением тарифных планов. Для использования у себя не нужны никакие регистрации. Просто ставим OPNsense и соответствующий плагин из интерфейса шлюза. На выходе получается более удобный и эффективный продукт, нежели существующая в pfsense связка на базе snort+suricata.

⇨ Сайт

#gateway #security

​​Я в своё время, когда познакомился с CIS — Center for Internet Security, изучил некоторые их документы по настройке софта, с которым работаю. Вот список заметок:

▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16

На основе документа CIS Docker Benchmark v1.6.0 (доступ только через VPN) создан open source продукт, который проверяет Docker контейнеры и настройки самой службы - Docker Bench for Security. Покажу, как им пользоваться.

Можно просто запустить скрипт на хосте и посмотреть его замечания и рекомендации:

# git clone https://github.com/docker/docker-bench-security.git
# cd docker-bench-security
# sh docker-bench-security.sh

Вот несколько замечаний, которые я получил на тестовом сервере. Это не всё, что там было, показываю просто для примера:

[WARN] 1.1.1 - Ensure a separate partition for containers has been created
[WARN] 1.1.3 - Ensure auditing is configured for the Docker daemon
[WARN] 2.2 - Ensure network traffic is restricted between containers on the default bridge
[WARN] 2.13 - Ensure centralized and remote logging is configured
[WARN] 4.5 - Ensure Content trust for Docker is Enabled

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

Похожую проверку можно запустить через Docker. Это тот же скрипт, но упакованный в контейнер, который тут же будет собран:

# docker-compose run --rm docker-bench-security

Проверки можно разделить и не делать сразу все. К примеру, запускаем только проверки образов и runtime:

# sh docker-bench-security.sh -c container_images,container_runtime

Для проверки конкретного образа, достаточно его указать при запуске скрипта. Образ должен быть скачан. Будут выполнены все проверки, в том числе хоста. При проверке образа это скорее всего не нужно. Имеет смысл сразу указать, что нас интересует только 4-й раздел проверок, относящихся к образам:

# docker image pull nginx
# sh docker-bench-security.sh -i nginx -c container_images

Напомню, что есть похожий инструмент Dockle, писал про него. Он делает примерно то же самое, но только для образов. Саму систему и службу docker не проверяет. Конкретно для образов он удобнее и информативнее, чем Docker Bench for Security, потому что проверяет не только по CIS, но и некоторым другим рекомендациям. Увидеть разницу проверок можно на тестовом образе от Dockle:

# docker run --rm goodwithtech/dockle:latest goodwithtech/dockle-test:v2
# sh docker-bench-security.sh -i dockle-test -c container_images

У Dockle вывод более подробный с большим числом замечаний. Эти проверки имеет смысл использовать в тандеме. Docker Bench for Security для хоста и службы, Docker для образов.

#cis #docker #devops

​​В сервере мониторинга Zabbix есть интересная возможность по отправке регулярных отчётов. К сожалению, у неё несколько громоздкая реализация, поэтому лишний раз её настраивать не хочется. Но в целом, ничего сложного, настройка простая. Реализованы эти отчеты на базе рендеринга pdf файлов из изображения дашборда средствами браузера chrome. В связи с этим, chrome необходимо устанавливать на сервер. Не обязательно именно на тот же сервер, где и мониторинг.

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

Покажу на практике, как выглядит настройка. Использовать буду реальный сервер на базе Oracle Linux Server 8.10. Для любого другого сервера настройка будет выглядеть так же, только команды и ссылки на скачивание будут другие.

Устанавливаем необходимые пакеты:

# dnf install zabbix-web-service
# wget dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
# dnf install google-chrome-stable_current_x86_64.rpm
# systemctl enable --now zabbix-web-service

Добавляем в конфиг zabbix_server.conf:

StartReportWriters=1
WebServiceURL=https://127.0.0.1:10053/report

Службу zabbix-web-service установил на ту же машину, где сам мониторинг, поэтому указал соответствующий адрес. Если будете устанавливать её отдельно, то не забудьте его поменять.

Перезапускаем сервер мониторинга:

# systemctl restart zabbix-server

Идём в веб интерфейс, в раздел Отчёты ⇨ Регулярные отчёты. Настройка там интуитивна, так что рассказывать особо нечего. Нужно будет выбрать панель и период, который будет выбран при формировании отчёта. Если в панели несколько страниц, то в отчёте они будут все по очереди отражены.

Отчёты будут отправляться на e-mail, так что у пользователя, для которого вы их будете отправлять, он должен быть указан. Здесь же можно проверить отправку отчёта.

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

 📌 Ссылки на документацию:
⇨ Scheduled reports
⇨ Setting up scheduled reports

#zabbix