Ошибка при обновлении Zabbix: "Неподдерживаемая кодовая страница"

После очередного обновления в веб-интерфейсе Zabbix появилось сообщение

Неподдерживаемая кодовая страница или тип сравнения для таблиц: < длинный список таблиц >

то же самое на английском

Unsupported charset or collation for tables: < длинный список таблиц >

и в логе

character set name or collation name that is not supported by Zabbix found in 379 column(s) of database "zabbix", only character set "utf8" and collation "utf8_bin" should be used in database

Это происходит из-за того, что в базе данных MySQL используется кодировка отличная от utf-8. Исправляется это буквално за несколько минут.

Миграция Jira с H2 на PostgreSQL

Если при устновке Jira Software была выбрана встроенная СУБД H2, а не внешняя, то со временем увеличение объёма данных может отрицательно сказаться на производительности сервиса. В моём конкретном случаем размер файла /var/atlassian/application-data/jira/database/h2db.mv.db приблизился к 5 Гб, что вызывало огромные задержки при выполнении любых действий. Чтобы решить эту проблему было принято решение перенести данные на полноценную СУБД - PostgreSQL. Ставить PostgreSQL будем на тот же сервер, на котором запущена Jira.

Запись видеоконференций Jitsi Meet с помощью Jibri, запущенного в docker-контейнере

Процесс установки и настройки сервиса видеоконференций Jitsi Meet был описан в одной из предыдущих заметок. Указанная в той заметке конфигурация срвиса была лишена одной немаловажной возможности, а именно возможности вести видеозапись конференции. За наличие этой возможности отвечает сервис Jibri (JItsi BRoadcasting Infrastructure). Его настройка и будет описана далее.

Специфика работы Jibri такова, что один экземпляр этой службы может записывать только одну конференцию. Это происходит из-за того, что при нажатии кнопки "Начать запись" Jibri подключается к конференции как участник и после этого записывает видео. Чтобы решить эту проблему и не плодить при этом серверы с Jibri будем использовать docker-контейнеры.

Использование SSL-сертификатов Let's Encrypt из репозитория GitLab на Zimbra Collaboration OSE

В предыдущей заметке был описан механизм загрузки SSL-сертификатов Let's Encrypt в репозиторий GitLab. Теперь доставим эти сертификаты на сервер Zimbra Collaboration Open Source Edition. Сертификаты и закрытый ключ хранятся в репозитории, так что триггером для запуска процесса обновления сертификатов на почтовом сервере будет служить наличие нового коммита в нём. Скрипт будет запускаться на почтовом сервере и рассчитан на использование в случае, когда один сервер Zimbra обслуживает один почтовый домен.

Ошибка git "fatal: unable to access 'https://...': Peer's Certificate issuer is not recognized."

При выполнениии команды git clone https://адрес репозитория.git появляется ошибка

fatal: unable to access 'https://адрес репозитория.git': Peer's Certificate issuer is not recognized.

или

fatal: unable to access 'https://адрес репозитория.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Это происходит из-за того, что на машине, где выполняется команда, отсутствует доверие к корневому центру сертификации, выдавшему SSL-сертификат, используемый сервером.
Решить это можно 2 путями.

Хранение и автоматическая загрузка сертификатов Let's Encrypt в репозиторий GitLab

Let's Encrypt предоставляет удобный сервис для получения бесплатного SSL-сертификата, но у него есть один нюанс, сертификат выпускается со сроком действия 90 дней. Это не будет вызвать каких-либо неудобств, если сертификат используется на той же машине, на которой происходит его выпуск и обновление. В случае же, если получается wildcard-сертификат, то он будет использоваться и на других машинах, так что нужно его как-то туда доставить.
Первое, что нужно решить, это определить место хранения сертификата, доступное с любой дугой машины. Решено было использовать для этого репозиторй на локальном GitLab. Это даёт возможность контролировать версионность файлов и откатить изменения, в случае ошибки, чего не позволяет использование обычного общего smb-ресурса.

Конвертация образов дисков виртуальных машин

Для переноса виртуальной машины с одного гипервизора на другой может потребоваться конвертация образа диска этой виртуальной машины. С этой задачей на отлично справляется qemu-img. Програма поддерживает форматы дисков для всех распространённых гипервизоров:

• KVM, Xen - qcow2
• VMware - vmdk
• Hyper-V - vhd, vhdx
• VirtualBox - vdi

Так же возможна конвертация образов дисков, созданных с помощью dd.