В пятничной подборке видео был ролик с open source системой для ведения заметок, которую можно развернуть на своём сервере. То есть это полностью бесплатная система пока без каких-то намёков на монетизацию. Речь идёт о Blinko. Я сначала прохладно к ней отнёсся, но зацепил внешний вид. Смотрится легковесно и аккуратно. Решил всё же попробовать.

Развернул у себя и немного поработал с ней. Функциональности пока немного. Проект ушёл в первый релиз только в конце октября этого года. Развивается очень активно. Судя по всему, это какая-то китайская компания ведёт разработку. Есть демо:

🌐 https://blinko-demo.vercel.app
👨‍💻 blinko / blinko

Из-за обилия китайского текста смотрится не очень, поэтому проще развернуть у себя чистую установку и попробовать. Там буквально 2 контейнера: веб интерфейс и субд postgresql.

# curl -s https://raw.githubusercontent.com/blinko-space/blinko/main/install.sh | bash

Дальше мои замечания по Blinko.

🔹Сервис полностью работает через браузер. Интерфейс адаптивный, отлично смотрится на смартфонах. Отдельно отмечу, что интерфейс очень лёгкий. Комфортно пользоваться, мгновенный отклик, быстро работает поиск. Красивое оформление. Мне понравилась больше светлая тема. Есть русский язык, но мне привычнее английский.

🔹У программы своя идея организации работы с заметками. На первом экране одноимённый с программой раздел Blinko. Это что-то вроде свалки идей. В течении дня вы быстро добавляете туда какие-то записи или файлы. Потом переходите в раздел Daily Review и поочереди просматриваете все добавленные и ещё не обработанные записи. Соответственно обрабатываете их и превращаете в Заметки (Notes). При желании можно сразу Notes создавать, минуя обработку и раздел Blinko.

🔹Данные могут храниться локально в директории на запущенном сервере или в S3. Можно загружать картинки и видео. Есть встроенный плеер для просмотра своих видео.

🔹Программа позволяет регистрироваться и работать разным пользователям. Совместной работы пока нет, но думаю, что появится. Это было бы логично. Не знаю, насколько безопасно выставлять окно с аутентификацией в публичный доступ. Я бы не стал это делать.

🔹Поддерживаются следующие типы заметок: список, нумерованный список, чек-лист, таблица, код, картинка, видео. Со смартфона можно сразу фотки прикреплять. Я попробовал, нормально работает.

🔹У Blinko удобный механизм для предоставления публичного доступа к заметкам, картинкам и видео. Просто жмёте на кнопку Copy share link и отправляете скопированную публичную ссылку. Человек сможет посмотреть видео через встроенный плеер, а не просто загрузить файл.

🔹Каталогизация заметок происходит на основе тэгов. При этом поддерживается вложенная иерархия. Выглядит почти так же, как и деление по проектам, папкам и блокнотам. Тэги появляются в левом меню, по ним можно быстро перемещаться.

🔹Поддерживается Markdown. Можно переносить записи с сохранением разметки. Импорта нет, перенос только вручную.

🔹Авторы делают акцент на интеграцию с ИИ. Поддерживаются провайдеры OpenAI и Ollama. С их помощью можно задавать человекоподобные запросы к своему хранилищу. Я не пробовал, как это работает, ничего сказать не могу.

В целом мне программа понравилась. Особенно будет актуально, если вам нужен сервис для нескольких человек. С такой функциональностью бесплатных self-hosted аналогов уже не так много. Подозреваю, что в скором будущем Blinko обзаведётся командной работой и облачной версией. И будет продаваться с сохранением open source в каком-то виде.

⇨ 🌐 Исходники

#заметки

Популярный open source продукт, который можно развернуть на своём оборудовании, Gitlab требует для своей работы приличное количество ресурсов. Для того, чтобы он в установке по умолчанию работал бодрячком лучше всего начать с 4 CPU и 8 GB оперативной памяти. Можно выделить 4 GB, но будет заметно тормозить, иногда 500-е ошибки выдавать.

Для того, чтобы иметь возможность использовать Gitlab для единоличного использования, либо очень небольшого коллектива, многие из стандартных компонентов и настроек программного комплекса можно безболезненно отключить. В документации есть отдельная статья на этот счёт:

⇨ Running GitLab in a memory-constrained environment (Запуск GitLab в среде с ограниченным объемом памяти)

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

Я взял виртуальную машину с 1 CPU и 2 GB памяти и попробовал на ней запустить Gitlab. Что для этого нужно сделать?

1️⃣ Подключаем 1 GB свопа.

# dd if=/dev/zero of=/swap bs=1024 count=1000000
# mkswap /swap
# chmod 0600 /swap
# swapon /swap

Добавляем в /etc/fstab:

/swap swap swap defaults 0 0

2️⃣ Меняем параметр swappiness:

# sysctl vm.swappiness=10

Добавляем в /etc/sysctl.conf:

vm.swappiness=10

3️⃣ Устанавливаем Gitlab.

# curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash
# EXTERNAL_URL="https://10.20.1.36" apt-get install gitlab-ce

4️⃣ Отключаем службу puma, которая помогает обрабатывает конкурентные запросы. Без большой нагрузки можно обойтись без неё. В /etc/gitlab/gitlab.rb добавляем:

puma['worker_processes'] = 0

5️⃣ Уменьшаем число фоновых процессов Sidekiq:

sidekiq['concurrency'] = 10

6️⃣ Оптимизируем Gitaly. Туда же в конфиг добавляем:

gitaly['configuration'] = {
  concurrency: [
   {
    'rpc' => "/gitaly.SmartHTTPService/PostReceivePack",
    'max_per_repo' => 3,
   }, {
    'rpc' => "/gitaly.SSHService/SSHUploadPack",
    'max_per_repo' => 3,
   },
  ],
}

gitaly['env'] = {
 'GITALY_COMMAND_SPAWN_MAX_PARALLEL' => '2'
}

❗️Обращаю ваше внимание, что я убрал из этого раздела настройки, касающиеся cgroups. В инструкции судя по всему какая-то ошибка. Если их оставить, то сокет gitaly не поднимается. А в интерфейсе при создании каких-либо сущностей, например, нового проекта, вылетает 502 ошибка. И это не зависит от выделенных ресурсов.

7️⃣ Отключаем мониторинг:

prometheus_monitoring['enable'] = false

8️⃣ Уменьшаем потребление памяти процессам GitLab:

gitlab_rails['env'] = {
 'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}

gitaly['env'] = {
 'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000'
}

9️⃣ Перезапускаем Gitlab:

# gitlab-ctl reconfigure

🔟 Идём в веб интерфейс и отключаем в настройках мониторинга метрики Prometheus: Admin Area ⇨ Settings ⇨ Metrics and profiling ⇨ Metrics - Prometheus ⇨ отключаем Enable Prometheus Metrics.

После перезапуска Gitlab будет очень долго подниматься. Но в итоге заработает. Смотрим потребление памяти и проверяем, как всё работает:

# free -h

Более подробно всё это описано по ссылке в статье из начала заметки. Для комфортной работы лучше всё же добавить до 2CPU и 3GB памяти. Тогда всё это будет бодро работать с предложенными параметрами. Если этого не сделать, то иногда будете видеть 500-е ошибки.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#gitlab #devops #cicd

Нашёл на github простой скрипт, который делает одну вещь - следит за конкретным лог файлом или набором файлов на предмет появления там заданных строк. Как только их видит, отправляет уведомление в Telegram.

https://github.com/dobanov/mon_log_and_send_keywords_to_telegram

Я проверил версию на python. Работает очень просто. Копируем репу:

# git clone https://github.com/dobanov/mon_log_and_send_keywords_to_telegram
# cd mon_log_and_send_keywords_to_telegram

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

# apt install python3-pip python3-watchdog

Запускаем скрипт без параметров:

# python3 tg_mon.py

Он ругнётся, что не переданы параметры и нет файла конфигурации. Создаст пустой ~/.config/tg_log.ini. Заполняем его:

filename=/var/log/auth.log
keyword=Accepted password,session opened
n=100
bot_id=5731668668:AAFxcwvp8XjvepZzDMIAN87l1D_MuiI1Ve9
chat_id=210856265
debug=true

В этом примере я указал две строки из файла auth.log, куда записывается вся информация об SSH сессиях. В данном случае в Telegram прилетят две строки:

2024-12-04T18:35:23.679324+03:00 debian12-vm sshd[4282]: Accepted password for root from 10.8.2.2 port 9669 ssh2
2024-12-04T18:35:23.680422+03:00 debian12-vm sshd[4282]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)

То есть полная информация о подключении - IP адрес и пользователь.

Запускаем скрипт:

# python3 tg_mon.py

Открываем новую SSH сессию и наблюдаем уведомление в телеге. В данном случае обе строки не нужны, сделал так для примера.

Всё очень просто и быстро. Код скрипта можете сами посмотреть, он небольшой. В репе лежит простенький шаблон для создания systemd службы, чтобы запускать скрипт в фоне.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#script #logs

Прочитал интересную статью про Linux IOWait в блоге компании Percona. У автора оказались подозрительно русские имя и фамилия - Peter Zaitsev. Навёл справки. Оказалось, что это Пётр Зайцев - сооснователь компании Percona. Я и не знал, что эта компания основана русскими, хотя пользуюсь её бесплатными продуктами много лет.

⇨ Understanding Linux IOWait

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

# sysbench --threads=8 --time=0 --max-requests=0 fileio --file-num=1 --file-total-size=10G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run

Используется утилита sysbench. Я, кстати, писал про неё. У неё есть встроенные тесты для СУБД. Приведённая выше команда жёстко нагрузит метрику cpu iowait. Проверить можно через vmstat, колонка wa.

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

# sysbench --threads=8 --time=0 cpu run

Снова смотрим на vmstat и видим, что нагрузка IOWait куда-то пропала. Как так? Первый тест продолжает нагружать диски, но мы уже этого не видим в привычной метрике.

Смысл тут вот в чём. Когда мы долго ждём ответа от дисков, процессор простаивает. Растёт метрика cpu idle. Простой процессора из-за ожидания I/O засчитывается в метрику IOWait. Но как только мы нагружаем процессор другой работой, метрика idle падает, а за ней и IOWait. Это особенность подсчёта этих метрик.

Теперь вместо первого теста в 8 потоков, запустим только один на виртуалке с 4-мя ядрами:

# sysbench --threads=1 --time=0 --max-requests=0 fileio --file-num=1 --file-total-size=10G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run

Несмотря на то, что этот тест тоже полностью нагрузит дисковую подсистему, мы увидим IOWait в районе 20-25%. А на виртуальных машинах с большим числом ядер (32-64) цифра будет настолько незначительна, что мы можем вообще не заметить её. Но при этом дисковая подсистема будет полностью загружена.

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

Как же узнать, что у нас есть проблемы с нагрузкой по I/O? Можно посмотреть на столбец b в vmstat. Он показывает количество процессов, которые заблокированы в ожидании I/O для завершения. Соседний столбец r покажет суммарное число запущенных процессов.

В продукте Percona Monitoring and Management есть плагин, который в том числе показывает статистику по процессам. Там будут видны процессы, ожидающие I/O. Указанный мониторинг бесплатен, это open source.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #perfomance

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

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

☝️ Бэкап, кстати, почти всю ночь восстанавливался. И это очень долго. Поэтому я всегда делаю отдельно бэкапы данных внутри виртуалок. Систему можно поднять быстро, залить основные данные, нужные для запуска сервиса, а остальное копировать по ходу дела. Это если архитектура сервиса и данных позволяет.

Виртуалку я восстановил, запустил, убедился, что она работает и выключил. Позже появилось время с ней поработать более внимательно. Настроил там сеть, подключился и стал смотреть. Каково же было моё удивление, когда этой ошибки я там не обнаружил. СУБД работает нормально, CHECK TABLE отрабатывает нормально, дамп делается.

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

2024-11-23T20:22:17.678755+03:00 mariadbd[738]: 2024-11-23 20:22:17 7451105 [Note] InnoDB: You can use CHECK TABLE to scan your table for 
corruption. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2024-11-23T20:22:17.678779+03:00 mariadbd[738]: 2024-11-23 20:22:17 7451105 [ERROR] InnoDB: We detected index corruption in an InnoDB type table. You have to dump + drop + reimport the table or, in a case of widespread corruption, dump all InnoDB tables and recreate the whole tablespace. If the mariadbd server crashes after the startup or when you dump the tables. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2024-11-23T20:22:17.678805+03:00 mariadbd[738]: 2024-11-23 20:22:17 7451105 [ERROR] Got error 126 when reading table 'b_stat_session_data'
2024-11-23T20:22:17.678833+03:00 mariadbd[738]: 2024-11-23 20:22:17 7451105 [ERROR] mariadbd: Index for table 'b_stat_session_data' is corrupt; try to repair it

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

На основном сервере саму виртуалку я не перезагружал, но службу mariadb перезапускал. Мне тогда это не помогло.

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

Как сказал один читатель к заметке про проблемы с СУБД. В базе иногда происходит какая-то неведомая хрень. Сразу понятен уровень специалиста. Знает, о чём говорит. Теперь я тоже знаю.

#mysql

Ко мне недавно обратился заказчик, которому я почти 3 года назад настроил небольшую инфраструктуру для работы с файловыми базами 1С. Надо было кое-что изменить. Что самое удивительное, всё это время её никто не обслуживал от слова совсем. Только базы добавляли. Я подключился по SSH к серверам и увидел, что с начала 22-го года туда никто не подключался, кроме меня. Всё это время с базами работали через интернет без VPN. Кратко расскажу, что я там настроил с упором на безопасную работу без VPN.

Был арендован бюджетный выделенный сервер, на нём установлен Proxmox на raid1 mdadm. На нём настроены 3 виртуальные машины:

◽️Windows Server, где будет работать 1С
◽️Debian для Nginx и Apache Guacamole
◽️Debian для локальных бэкапов

На Proxmox настроен файрвол. Входящий доступ закрыт на всё. Исключение - ssh и web доступ к гипервизору по белым спискам IP. Сделано как резерв, основное подключение организовано по-другому. Настроены пробросы 80 и 443 портов в виртуалку с Nginx. На ней обязательно включен автозапуск.

На сервере с Nginx настроено проксирование запросов на Windows Server с 1С. Доступ к базам через доменное имя, слеш, имя базы. Доступ закрыт паролем через basic_auth. На этой же виртуалке поднят Apache Guacamole, а через него настроен доступ ко всем виртуалкам по SSH или RDP через браузер. Guacamole не стал закрывать через basic_auth, смотрит напрямую в инет. Можно было закрыть для большей безопасности.

На Windows сервере устанавливается как обычно платформа 1С и веб сервер Apache. Делается публикация баз. Всё стандартно. Пользователи этой системы работают только с ним. Точнее администратор 1С. Пользователи только через браузер работают с 1С. Порты RDP не пробрасываются. Сервер напрямую из интернета недоступен.

На третьем сервере настраивается Samba, создаётся сетевой диск с доступом только на чтение. Этот диск подключается к Windows машине. В этот сетевой диск ежедневно делаются бэкапы файловых баз, старые удаляются. Работает скрипт на самом сервере с бэкапами. Монтирует папку с Windows сервера и забирает файлы к себе, а отдаёт их уже только в режиме чтения. Это сделано, чтобы был оперативный доступ к бэкапам с Windows машины, но при этом их нельзя было удалить с неё. С самого бэкап сервера базы копируются куда-то во вне.

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

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

#1С

В моих заметках про self-hosted сервера GIT постоянно возникали упоминания Gogs. Это тоже легковесный open source сервис GIT от китайских разработчиков. Причём упоминаемая несколько раз ранее Gitea является форком Gogs, который случился довольно давно. С тех пор Gitea развивается намного активнее, обросла дополнительной функциональностью, была приобретена коммерческой компанией и получила какие-то проблемы с лицензией, так что и её уже форкнули в новый проект Forgejo.

Если вам нужно простое хранилище кода с различной функциональностью только вокруг него, то Gogs будет оптимальным выбором с точки зрения потребления ресурсов. Там нет ни своего registry, ни инструментов для CI/CD, ни учёта времени, ни многих других возможностей, которые есть в той же Gitea.

При этом базовые возможности для совместной работы с кодом там будут:

- привычные профили пользователей, дашборды с активностью и т.д.;
- доступ к репам по ssh и https;
- веб редактор для работы с кодом и записями в wiki;
- аутентификация по паролям, через LDAP или SMTP (!) сервер
- управление пользователями, организациями, репозиториями.

В общем, тут только GIT и ничего больше. В качестве хранилища состояния могут использоваться PostgreSQL, MySQL, SQLite3 и TiDB. При использовании SQLite3 для запуска службы не нужно ничего, кроме самого бинарника gogs и установленного в системе git:

# apt update && apt install git -y
# wget https://dl.gogs.io/0.13.0/gogs_0.13.0_linux_amd64.tar.gz
# tar xzvf gogs_0.13.0_linux_amd64.tar.gz
# cd gogs
# ./gogs web

Запускается gogs в режиме веб сервера. Можно идти на 3000-й порт по IP адресу и выполнять настройку. Как я уже сказал, если выбрать в качестве СУБД SQLite3, то установка будет выполнена тут же, а база будет создана в файле data/gogs.db.

Веб интерфейс работает очень быстро и легко. Системные требования минимальны. Запускается на VPS с 512 МБ оперативной памяти. Есть русский язык. По умолчанию выбирается язык браузера. Чтобы его поменять, надо выйти к окну логина и там снизу выбрать. Я сначала долго искал, никак не мог понять, как изменить язык.

Доступа к сайту gogs.io без VPN нет. Как я понял, это блокировка со стороны РФ для хостера DigitalOcean. Сайт живёт на нём.

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#git

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

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

⇨ Безопасная передача файлов с помощью Magic Wormhole
Использование специальной библиотеки для прямой шифрованной передачи файлов между распределенными клиентами. У библиотеки есть как консольная утилита, которую можно использовать вручную, либо в скриптах, так и GUI приложение.

⇨ Запускаем ИИ чат-бот локально. LM Studio
⇨ Запускаем ИИ чат-бот локально. LobeChat
Обзорная информация по запуску языковых моделей на своих серверах.

⇨ Tmux – установка и кастомизация + Nord theme
Подробная статья про установку, настройку и использование популярного терминального мультиплексора tmux.

⇨ Установка Graylog 6.1 на Debian 12
Краткая инструкция по установке и базовой настройке сервера сбора и анализа логов. Это чуть более простой в настройке аналог популярного ELK Stack. Про непосредственно сбор логов будут отдельные статьи.

⇨ Обновления безопасности Exchange Server за ноябрь 2024 г.
Обзор свежих обновлений безопасности почтового сервера Exchange.

⇨ ИТ переезд компании в новый офис
Основные этапы и рекомендации по успешному проведению переезда. К краткой текстовой выжимки прилагается более чем 2-х часовой видеоматериал.

⇨ Как установить Zabbix 7 на Ubuntu 24.04 с использованием веб-сервера Apache и базы данных MySQL
Подробная инструкция по установке перечисленной связки сервисов для запуска Zabbix Server.

⇨ Как установить Zabbix 7 на Ubuntu 24.04 с использованием веб-сервера NGINX, БД PostgreSQL, и расширением TimescaleDB
Другой стек для запуска Zabbix Server.

⇨ Отслеживание утечек секретов при разработке программных решений
Описание двух инструментов для поиска секретов в исходном коде приложений: Gitleaks и gitGrabber.

⇨ Критическая уязвимость в Zabbix: что известно и как защититься
Описание недавней CVE-2024-42327 в Zabbix Server.

Если кто-то хочет присоединиться к этой подборке, то пишите мне в личные сообщения. Пока список выглядит так:

▪️https://r4ven.me/
▪️https://wiki-it.ru/
▪️https://www.gurin.ru/
▪️https://sysadminhub.ru/
▪️https://it-skills.online/
▪️https://devopslife.ru/
▪️https://bite-byte.ru/
▪️https://sysadminium.ru/
▪️https://desoft.ru/
▪️https://www.pc360.ru/
▪️https://bafista.ru/
▪️https://it-experience.ru/
▪️https://blogadminday.ru/
▪️https://marukhin.ru/

#статьи

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

Был почтовый домен mail.example.com с сервером и на него же посадили веб интерфейс, что не очень удобно. Не рекомендую так делать. Делайте для него отдельный домен, типа webmail.example.com или как-то ещё. Я веб интерфейс перекинул на отдельный веб сервер, и для домена mail.example.com в настройках nginx сделал переадресацию на webmail.example.com, а чтобы продолжать обновлять сертификат оставил location /.well-known без переадресации. Сделал и забыл.

Прилетает от мониторинга через пару недель оповещение, что через 10 дней сертификат для mail протухает. А должен обновиться раньше. Иду разбираться и не понимаю, в чём проблема. На вид всё сделано корректно, как я обычно делаю. Смотрю логи ошибок certbot и вижу, что проверка домена mail идёт не по https, а по http. Я честно говоря почему-то думал, что сначала проверка всегда идёт по https, и если там всё ОК, то этого достаточно. Оказывается нет. Не обращал на это внимание.

У меня получилось так, что по http шла сразу переадресация всех запросов mail -> webmail, а последний хостился на другом сервере, поэтому проверка не проходила. Поправил правила nginx. Оставил location /.well-known и для http, и для https, чтобы в любом случае проверка домена проходила успешно. Что-то типа такого:

server {
    listen 80;
    server_name mail.example.com;

    location /.well-known {
    root /var/www/mail.example.com;
    }

    location / {
    return 301 https://webmail.example.com$request_uri;
    }
}

Для https аналогично.

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

#zabbix #мониторинг

Решил всё же после выхода Zabbix Server 7.2 обновить один из работающих серверов до этой версии. Давно собирался там порядок навести и нарисовать новые дашборды. Имеет смысл это сделать уже на свежей версии.

Сервер был версии 6.0 на ОС Debian 11. Первым делом обновил Debian 11 до 12. Всё прошло гладко. Debian хорошо обновляется с релиза на релиз. Не припоминаю серьёзных проблем с этим. Потом подключил репозиторий от Zabbix 7 и обновил его с 6.0 до 7.0. Процесс обновления в целом прошёл штатно, но на выходе я столкнулся с проблемой.

Это был старый сервер, который обновляется с релиза на релиз, с системы на систему с 4-й версии. А может и того раньше. Не помню точно. Он всегда работал под Apache. После обновления на 7.0 в веб интерфейсе пропал русский язык. В настройках он остался, но если в профиле выбрать русский язык и сохранить настройки, то ничего не менялось. Оставался английский.

Я немного погуглил, решения не нашёл. Несмотря на то, что все необходимые условия для появления русского языка выполнены, он не работал. Я не стал дальше решать вопрос, а просто заменил Apache на Nginx и Php-fpm. Русский язык появился. То есть проблема сидела где-то в настройках Apache и скорее всего php.

Дальше в пару шагов обновил 7.0 до 7.2:

# wget https://repo.zabbix.com/zabbix/7.2/release/debian/pool/main/z/zabbix-release/zabbix-release_latest_7.2+debian12_all.deb
# dpkg -i zabbix-release_latest_7.2+debian12_all.deb
# apt update
# apt upgrade

Тут тоже столкнулся с ошибкой. В 7.2 веб интерфейс вынесли в новую директорию /usr/share/zabbix/ui вместо прошлой /usr/share/zabbix. Нужно поправить это в настройках nginx. Больше ничего менять не надо. Перезапускаем службу и тестируем новую версию 7.2.

❗️С версией сервера 7.2 не будут работать прокси 6.0. Для меня это было сюрпризом, так как в одном сегменте сети до сих пор работают Centos 7 и туда максимум можно поставить версию 6.0. С сервером 7.0 они нормально работали, а с 7.2 уже не хотят. Пришлось решать этот вопрос отдельной установкой туда более свежей системы.

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

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

#zabbix

Для рисования схем существует много различных программ. Причём этот вопрос хорошо закрывается полностью бесплатным ПО. Его можно разделить на 2 категории: ручное рисование и автоматическое на основе текстового описания. Сегодня речь пойдёт про ручное рисование.

Наиболее популярные инструменты - draw.io и excalidraw.com. Оба сервиса представляют собой веб приложение, которое можно в том числе развернуть у себя на веб сервере. Результатом работы в браузере будет обычный файл, который можно сохранить к себе на компьютер. Это удобно. Не нужно ничего устанавливать локально, но при этом все схемы у тебя всегда под рукой. Можно воспользоваться как своим сервисом, так и публичным.

Я одно время пользовался draw.io и думал, что ничего другого и не надо. Вроде всё и так есть. Потом кто-то посоветовал посмотреть excalidraw. Он мне понравился. Там по умолчанию нет специальных иконок и прочих красивостей, но на деле оказалось, что простыми прямоугольниками и прочими геометрическими фигурами со стрелками нарисовать схему быстрее и проще. И выглядит она нагляднее. Так что теперь рисую там. При желании туда тоже можно импортировать готовые наборы иконок, но я без них обхожусь.

Видел не раз в комментариях упоминание lucidchart. Про него есть подробное видео на ютубе на канале ADV-IT. Автор нарисовал для примера пару схем и показал процесс. Изначально думал, что это наподобие описанных выше программ, где так же есть open source версия, но нет. Lucidchart полностью коммерческий продукт с бесплатным тарифным планом, в котором основное ограничение - 60 объектов на схему. Сайт использует какую-то хитрую блокировку по странам, так что я не смог зарегистрироваться даже через американский VPN. Так что можно смело про него забыть. Lucidchart у меня год в закладках висел, ждал своего часа и вот дождался.

☝️ Вернусь ещё раз к draw и excalidraw и расскажу об одной особенности, которая может быть кому-то незнакома. Для этих сервисов есть плагины для популярной IDE - VSCode. С помощью этих плагинов вы можете хранить схемы в репозиториях и изменять их прямо в редакторе. После изменения схемы автоматически рендерятся в картинки. То есть для вас это редактируемые объекты, которые легко изменяются, а для тех, кто будет смотреть этот репозиторий, это будут статические png картинки. Вот тут подробно показано, как это работает:

▶️ Рисуем документацию прямо внутри IDE - excalidraw

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

◽️Graphviz - ветеран подобных сервисов, очень старый продукт, который развивается и использует по сей день.
◽️Mermaid - более современный сервис, много где имеет встроенную поддержку (GitLab, Gitea, Joplin, Notion и т.д.), наиболее популярный на сегодняшний день.

Таких движков для описания кода очень много. У них довольно высокий порог вхождения. Используется свой язык разметки, так что придётся немного поразбираться.

#схемы

В ОС на базе Linux существуют несколько наиболее популярных программных решений для построения отказоустойчивого дискового хранилища, или по простому - софтовых рейдов:

◽️Mdadm
◽️LVM Raid
◽️ZFS

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

Про ZFS тоже рассказывать большого смысла нет. Известная и проверенная временем технология. Я ещё на Freebsd её использовал и очень радовался, когда корень системы можно было поставить на ZFS. Она спокойно переживала аварийные выключения сервера, в отличие от UFS, которая была файловой системой по умолчанию и постоянно ломалась после аварийных отключений.

А вот про LVM Raid и информации немного, и практического применения я не видел. Мне не очень понятно, почему. Я немного поигрался с этим рейдом на тестах. Выглядит интересно. Сразу скажу, почему я решил обратить на него внимание. LVM Raid поддерживает технологию DM-integrity (device mapper integrity), с помощью которой можно контролировать целостность хранимой информации с помощью дополнительного хранения и проверки метаданных (checksum) файлов. Это то, что ZFS делает по умолчанию. Поясню, зачем это надо.

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

При использовании Mdadm и поверх него ФС EXT4 или XFS, никакой защиты от подобных ошибок у вас не будет. Если не делать регулярное сопоставление записанных файлов с каким-то другим хранилищем таких же файлов, то о битых файлах вы не узнаете, пока явно не наткнётесь на них во время проверки. В LVM Raid с поддержкой DM-integrity часть хранилища выделяется под хранение метаданных файлов. Я не нашёл точно информации, сколько конкретно % от общего объёма тратится. Но там немного, не более 10%.

При использовании LVM Raid + DM-integrity вы узнаете о битых файлах при очередной проверке файлов с тем, что записано ранее в хранилище метаданных. Это происходит как минимум во время чтения. Я так понимаю, что процесс этот может происходить и в фоне, можно и принудительно запускать и смотреть результаты. CLI от LVM даёт такие возможности. При обнаружении повреждённых файлов, они будут автоматически восстановлены с других носителей в рейд массиве.

Хотел сделать заметку с примерами создания и управления LVM Raid, но сделаю это позже отдельной заметкой в виде готовой шпаргалки. Вводная теоретическая часть получилась слишком длинной.

Если кто-то использовал LVM Raid, поделитесь опытом и впечатлениями. Особенно интересно, если дополнительно включали DM-integrity. Без неё я не вижу смысла использовать рейд LVM, а не Mdadm. LVM хоть и даёт бОльшую гибкость в управлении. Например, можно на лету изменить уровень рейда, увеличить или уменьшить тома. Но на практике это не особо нужно. Mdadm проще и более предсказуем, интуитивен в управлении. Технически DM-integrity можно включить и для дисков в составе Mdadm, но там нет нативной поддержки, как в LVM. Битые файлы будут помечаться как ошибки чтения диска и Mdadm будет пытаться их синхронизировать с других дисков. Это тоже рабочий вариант, но не такой удобный в плане управления и отслеживания ошибок.

#lvm #raid