SPB.Ryzen9-9950X-192ram [noda3] [russia.network]

Итак.

Итак, добавлена noda3 [Selectel-SPB2]
IP — 24 штук.

Доля/Тариф на 1 долю (можно соединять)
  • Ryzen9-9950X [32vCore] / 8 ddr5 / 100 ГБ NVME / 1 IP
  • Старт 11-2024 год — цена 2000р
  • С 11-2025 цена — далее 2000р (так как больше нету понятия «вечная лицензия и с второго года уже не дешевле»)

Автоматически можно заказать

Биллинг панели где доступно
cp.aofy.ru/ — тут выбирать Selectel
bill.yacolo.net/billmgr
На этом проекте поддержки нет. Но у других хостеров на портале vm.center — будет, но и цены там будут другие и анонсы тоже ;)

SPB.Ryzen9-9950X-192ram [noda2] [russia.network]

Итак.

Итак, добавлена noda2 [Selectel-SPB2]
IP — 24 штук.

Доля/Тариф на 1 долю (можно соединять)
  • Ryzen9-9950X [32vCore] / 8 ddr5 / 100 ГБ NVME / 1 IP
  • Старт 11-2024 год — цена 2000р
  • С 11-2025 цена — далее 2000р (так как больше нету понятия «вечная лицензия и с второго года уже не дешевле»)

Автоматически можно заказать

Биллинг панели где доступно
cp.aofy.ru/ — тут выбирать Selectel
bill.yacolo.net/billmgr
На этом проекте поддержки нет. Но у других хостеров на портале vm.center — будет, но и цены там будут другие и анонсы тоже ;)

Perm.Ryzen9-9950X-192ram [noda1] [russia.network]

Итак.

Итак, добавлена noda1 [PermDC-COLO-1]
IP — 24 штук.

Доля/Тариф на 1 долю (можно соединять)
  • Ryzen9-9950X [32vCore] / 8 ddr5 / 100 ГБ NVME / 1 IP
  • Старт 10-2024 год — цена 2000р
  • С 10-2025 цена — далее 2000р (так как больше нету понятия «вечная лицензия и с второго года уже не дешевле»)

Автоматически можно заказать


Биллинг панели где доступно
bill.yacolo.net/billmgr
На этом проекте поддержки нет. Но у других хостеров на портале vm.center — будет, но и цены там будут другие и анонсы тоже ;)

Changelog 2023 virtfusion

Версия 3.1.0 Stable Released
5 декабря 2023 г.
Добавлена ​​поддержка централизованного хранилища Ceph RBD. docs.virtfusion.com/next/installation/storage/ceph-rbd
Добавлена ​​поддержка хранилища Remote Filesystem. docs.virtfusion.com/next/installation/storage/remote-filesystem
Добавлена ​​возможность разрешить пользователям указывать пользовательский ISO docs.virtfusion.com/next/guides/custom-iso
Добавлена ​​возможность указывать список серверов для резервного копирования с помощью Disaster Recovery docs.virtfusion.com/next/guides/disaster-recovery#backup-only-specific-servers
Добавлены controlDomain и controlName в тело запроса webhook (https://docs.virtfusion.com/next/guides/webhooks#body) для использования с docs.virtfusion.com/next/integrations/webhook-proxy
Добавлен инструмент CLI для принудительной очистки резервных копий из хранилища. docs.virtfusion.com/next/reference/cli#force-flush-backups-based-on-storage-id
Добавлены простые сведения о приложении и статистика кэша (Система -> Здоровье -> Приложение).
Добавлена ​​необязательная промежуточная подсеть CIDR для блоков маршрутов IPv6.
Добавлена ​​возможность задать шлюз и первый IPv6 для промежуточных подсетей маршрутов /126.
Добавлен журнал DNS (Ведение журнала -> DNS).
Добавлена ​​возможность очистки записи резервной копии сервера.
Добавлены параметры по умолчанию для отчетов о свободной странице Memory Ballooning и Auto Deflate (Настройки -> Виртуализация).
Количество назначенных, зарезервированных, свободных и общих IPv4 теперь отображается в списке заблокированных IP-адресов.
Динамические миграции теперь выполняют полную проверку на предмет несоответствия дискового устройства и пути/имени.
Все задачи миграции теперь отображаются для конечных пользователей как «Обслуживание системы» и никогда не будут показывать состояние сбоя.
Исправлена ​​проблема с отображением использования самообслуживания при удалении пакета.
Исправлена ​​проблема, при которой при добавлении дополнительных дисков кнопки отображались как отключенные.
Перестроение зоны DNS теперь будет объединять данные из всех назначенных блоков IP.
Сведения о блоке маршрутов IPv6 теперь отображаются конечному пользователю для промежуточных распределений /126.
Добавлено несколько новых столбцов (RDNS, блок маршрутов IPv6) в таблицы IP (Сервер -> Сеть).
Мониторы работоспособности теперь используют льготный период перед уведомлением выбранных администраторов о потенциальных проблемах.
Исправлена ​​проблема с собственными фильтрами при использовании настраиваемой MAC-адресации.
Читать дальше
,

Changelog 2021-2022 virtfusion

Выпущена версия 2.0.0 Testing Build 2
20 декабря 2022 г.
Исправлена ​​проблема с сохранением настроек пакета сервера.
Добавлены итоговые значения токенов и часов в конечную точку API самообслуживания.
Добавлена ​​возможность для конечных пользователей просматривать базовую ежемесячную разбивку использования самообслуживаемых виртуальных машин.
Читать дальше
,

NL-1.Ryzen9-7950X-192ram [noda72] [fucking-martin-htznr.cloud]

Итак.

Итак, добавлена noda72 [Serverius-COLO-1]
IP — 24 штук.

Доля/Тариф на 1 долю (можно соединять)
  • Ryzen9-7950X [32vCore] / 8 ddr5 / 100 ГБ NVME / 1 IP
  • Старт 08-2024 год — цена 2000р
  • С 08-2025 цена — далее 2000р (так как больше нету понятия «вечная лицензия и с второго года уже не дешевле»)

Автоматически можно заказать


Биллинг панели где доступно
asuka.onl/billmgr
panel.skladchik.ovh/billmgr
На этом проекте поддержки нет. Но у других хостеров на портале vm.center — будет, но и цены там будут другие и анонсы тоже ;)

NL-1.Ryzen9-7950X-192ram [noda71] [fucking-martin-htznr.cloud]

Итак.

Итак, добавлена noda71 [Serverius-COLO-1]
IP — 24 штук.

Доля/Тариф на 1 долю (можно соединять)
  • Ryzen9-7950X [32vCore] / 8 ddr5 / 100 ГБ NVME / 1 IP
  • Старт 08-2024 год — цена 2000р
  • С 08-2025 цена — далее 2000р (так как больше нету понятия «вечная лицензия и с второго года уже не дешевле»)

Автоматически можно заказать


Биллинг панели где доступно
asuka.onl/billmgr
panel.skladchik.ovh/billmgr
На этом проекте поддержки нет. Но у других хостеров на портале vm.center — будет, но и цены там будут другие и анонсы тоже ;)

Как настроить тунель на Hetzner по GRE ?

Сама статья
1. Настройка на сервере роутере. (Тут должны быть непосредственно прикреплены подсети и AlmaLinux (На момент тестов – 8.9))

1.1 Включаем ip forward в файле “/etc/sysctl.conf”
Для этого выполняем команду:
nano /etc/sysctl.conf
Добавляем в файл значение “net.ipv4.ip_forward=1”
Сохраняем файл, выполняем команду:
sysctl -p
ВАЖНО! Если пропустите хоть один шаг, в дальнейшем туннель может рассыпаться.

1.2 Устанавливаем пакеты “net-tools, iptables, iproute2” (Вместо iproute2 может быть iproute) (Здесь он нам нужен для iptunnel и роутов)
Для этого выполняем команду:
apt install net-tools iptables iproute2

1.3 Поднимаем сам GRE, MTU не трогаем, оно для нас полностью подходит.
Для этого выполняем команды:
sudo modprobe ip_gre
lsmod | grep gre
СВЕРЯЕМСЯ! Вывод после выполнения команд должен быть такой:
ip_gre                          0
gre                               1 ip_gre
Снова необходимо выполнить команды, которые поднимут GRE туннель:
iptunnel add gre1 mode gre local <strong>ROUTER_IP</strong> remote <strong>NODE_IP</strong> ttl 255
ip addr add 192.168.5.1/30 dev gre1
ip link set gre1 up
ВНИМАНИЕ! Здесь необходимо заменить “ROUTER_IP” на IPv4 адрес вашего сервера-роутера, а NODE_IP на IPv4 адрес вашей ноды куда необходимо перенести подсеть.
Выполняем следующую команду:
ip a
СВЕРЯЕМСЯ! Вывод после выполнения команды должен содержать данную информацию:
gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default qlen 1
        link/gre SERVER_IP peer NODE_IP
        inet 192.168.5.1/30 scope global gre1
              valid_lft forever preferred_lft forever
1.4 Добавляем роут подсети и работаем с firewall ОС:
Выполняем следующую команду:
ip route add x.x.x.x/y via 192.168.5.2 dev gre1
ВНИМАНИЕ! Здесь необходимо заменить “x.x.x.x/y” на вашу подсеть, вовсе не обязательно иметь или переносить /24, это может быть любая от /30? например – 1.1.1.168/29.
1.5 Отключаем нахуй все firewall в нашем AlmaLinux, выполняя следующую команду:
systemctl disable --now firewalld
Теперь проверяем через команду ip a, чтобы подсеть x.x.x.x/y не осталась на каком-либо сетевом интерфейсе сервера-роутера. Если IP-Адреса или подсеть осталась на каком-либо интерфейсе удаляем их через команду:
ip a del x.x.x.x/y dev INTERFACE
ВНИМАНИЕ! Здесь необходимо заменить “x.x.x.x/y” на вашу подсеть, например 1.1.1.168/29, а “INTERFACE” на имя сетевого интерфейса, где находятся данные IP-Адреса, например ens3.

КОНЕЦ НАСТРОЙКИ РОУТЕРА + ВАЖНОЕ! Изменения пропадают с рестартом сервера-роутера! Поэтому надо сохранить их либо в etc/network/interfaces, либо в условный rc.local (Не очень рекомендую). Сохранить необходимо данные с пунктов 1.3 и 1.4, остальное делается разово и не требует повторений.
2. Настройка на ноде или узле, кому как привычнее. (Необходима ОС AlmaLinux (На момент тестов – 8.9))
2.1 Включаем ip forward в файле “/etc/sysctl.conf”
Для этого выполняем команду:
nano /etc/sysctl.conf
Добавляем в файл значение “net.ipv4.ip_forward=1”
Сохраняем файл, выполняем команду:
sysctl -p
ВАЖНО! Если пропустите хоть один шаг, в дальнейшем туннель может рассыпаться.

2.2 Устанавливаем пакеты “net-tools, iptables, iproute2” (Вместо iproute2 может быть iproute) (Здесь он нам нужен для iptunnel и роутов)
Для этого выполняем команду:
apt install net-tools iptables iproute2

2.3 Поднимаем сам GRE, MTU не трогаем, оно для нас полностью подходит.
Для этого выполняем команды:
sudo modprobe ip_gre
lsmod | grep gre
СВЕРЯЕМСЯ! Вывод после выполнения команд должен быть такой:
ip_gre                          0
gre                               1 ip_gre
Снова необходимо выполнить команды, которые поднимут GRE туннель:
iptunnel add gre1 mode gre local NODE_IP remote ROUTER_IP ttl 255
ip addr add 192.168.5.2/30 dev gre1
ip link set gre1 up
ВНИМАНИЕ! Здесь необходимо заменить “ROUTER_IP” на IPv4 адрес вашего сервера-роутера, а NODE_IP на IPv4 адрес вашей ноды куда необходимо перенести подсеть.

2.4 Добавляем роуты и айпишники на узел и сам узел в VMmanager 6:
Для этого выполняем команду:
echo 100 vm >> /etc/iproute2/rt_tables
Отлично, теперь добавляем узел/ноду в VMmanager 6 с типом сети – Маршрутизация и айпи адресами из подсети +1 (ЭТО ВАЖНО)
Пример: если у нас подсеть 1.1.1.168/29, тогда в VMmanager 6 мы добавляем адресное пространство 1.1.1.169-1.1.1.175.
После добавления узла переходим в ssh и выполняем команды:
ip rule add from x.x.x.x/y table vm
ip route add 0.0.0.0/0 via 192.168.5.1 dev gre1 table vm
ip route add x.x.x.x/y dev vmbr0 table vm
ip addr add x.x.x.x/y dev vmbr0
ВНИМАНИЕ! Здесь необходимо заменить “x.x.x.x/y” на вашу подсеть, например – 1.1.1.168/29.

2.5 Добавляем разрешение для форвардов, выполняя следующие команды:
iptables -A FORWARD -i gre1 -o vmbr0 -j ACCEPT
iptables -A FORWARD -i vmbr0 -o gre1 -j ACCEPT

КОНЕЦ НАСТРОЙКИ НОДЫ/УЗЛА + ВАЖНОЕ! Изменения пропадают с рестартом сервера! Поэтому надо сохранить их либо в etc/network/interfaces, либо в условный rc.local (Не очень рекомендую). Сохранить необходимо данные с пунктов 2.3, 2.4 и 2.5, остальное делается разово и не требует повторений. ВАЖНО Х2: выполнять “echo 100 vm >> /etc/iproute2/rt_tables” из пункта 2.4 повторно не надо.

Читать дальше

Миграция с CentOS Linux 7 для платформ DCImanager, VMmanager и BILLmanager

Миграция с ОС CentOS 7 на AlmaLinux 8 для VMmanager
Вам предстоит выполнить ряд действий:

Подготовка
Проверьте совместимость оборудования с ОС AlmaLinux 8, загрузив ОС AlmaLinux в режиме Live Media.
Перенесите виртуальные машины на другой узел кластера при смене ОС на узле кластера. (См. статью «Миграция виртуальных машин» для более подробной информации).
Создайте резервную копию платформы на внешнем хранилище. (Смотри статью «Резервное копирование платформы»).
Смена ОС
Подключитесь к серверу по SSH.
Установите последнее доступное обновление ПО: yum update -y
Перезагрузите сервер: reboot
Установите ПО Elevate:
yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
Установите фреймворк Leapp:
yum install -y leapp-upgrade leapp-data-almalinux
Проверьте готовность системы к смене ОС:
leapp preupgrade
Изучите вывод команды и файл отчёта /var/log/leapp/leapp-report.txt для информации о возможных проблемах при смене ОС.
Настройте фреймворк Leapp:
rmmod pata_acpi
leapp answer --section remove_pam_pkcs11_module_check.confirm=True

Запустите смену ОС:
leapp upgrade

Перезагрузите сервер:
reboot
Проверьте версию ОС:
cat /etc/os-release

Действия после смены ОС на узле кластера
Подключитесь к узлу кластера по SSH.
Удалите старые репозитории:
rm /etc/yum.repos.d/ispsystem-base6.repo
rm /etc/yum.repos.d/CentOS-QEMU-EV.repo


На сервере с платформой измените настройки файрвола:
docker exec -it vm_box bash
cd /opt/ispsystem/vm
/usr/bin/ansible-playbook -i <NODE IP>:22, -e targets=all -e ansible_python_interpreter='auto_silent' -e datacenter_type='common' -e ssh_port='22' -e network_autosetup_enabled='1' -e is_lxd='0' -e dc_ips='' -e dc_ips6='' -e closed_contour='0' etc/playbooks/node/firewall.yml --timeout 60 -b

Готово! По завершении этих шагов ваша платформа будет успешно мигрирована на поддерживаемую ОС AlmaLinux 8, обеспечив стабильную и безопасную работу системы.

Миграция на ОС AlmaLinux 8 без переустановки DCImanager 6
Миграция операционной системы (ОС) представляет собой важный процесс, требующий внимательности и последовательности действий для обеспечения бесперебойной работы платформы. В случае смены операционной системы с CentOS 7 на AlmaLinux 8 без переустановки DCImanager 6, есть особенности и шаги, которые не предусмотрены разработчиками ОС CentOS. Поэтому процедура миграции может привести к неудачному результату, а платформа будет недоступна в процессе смены ОС на сервере с платформой.

Чтобы успешно выполнить миграцию, необходимо следовать инструкциям для обеспечения безопасной и бесперебойной работы платформы. Вот пошаговая инструкция для миграции с ОС CentOS 7 на ОС AlmaLinux 8 с помощью ПО Elevate:

Проверьте совместимость оборудования с ОС AlmaLinux 8. Вы можете загрузить ОС AlmaLinux 8 в режиме Live Media для проведения данной проверки.
Подключитесь к серверу по SSH и сделайте резервную копию платформы для предотвращения потенциальных неполадок во время миграции:
dci backup
Резервная копия будет сохранена в директории /opt/ispsystem/dci/backup/. Сохраните копию на внешнем носителе.
Установите последние доступные обновления ПО и перезагрузите сервер:
yum update -y
reboot
Установите ПО Elevate и фреймворк Leapp:
yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
yum install -y leapp-upgrade leapp-data-almalinux
Проверьте готовность системы к смене ОС:
leapp preupgrade
Изучите вывод команды и файл отчёта /var/log/leapp/leapp-report.txt для выявления возможных проблем при смене ОС.
Настройте фреймворк Leapp и запустите смену ОС:
rmmod pata_acpi
leapp answer --section remove_pam_pkcs11_module_check.confirm=True
leapp upgrade
Перезагрузите сервер и проверьте версию ОС:
reboot
cat /etc/os-release

Миграция через резервное копирование DCImanager 6
В случае миграции с ОС CentOS 7 на любую поддерживаемую ОС, необходимо следовать определенной последовательности действий. Пошаговая инструкция для миграции через резервное копирование DCImanager 6 представлена ниже:

Создайте новое значение токена для вашей лицензии в личном кабинете на my.ispsystem.com или обратившись в техническую поддержку.
Создайте резервную копию платформы:
dci backup
Копия будет сохранена в директории /opt/ispsystem/dci/backup/. Если помимо платформы на сервере находится локация, создайте резервную копию директории /opt/ispsystem/dci/os_templates/. Сохраните резервные копии на внешнем носителе.
Если помимо платформы на сервере находится локация, остановите платформу:
dci down
Установите поддерживаемую ОС и подключитесь к серверу через SSH.
Если в системе не установлен архиватор tar или утилита curl, установите их через соответствующие команды для используемой ОС.
Скачайте установщик и сделайте файл установщика исполняемым:
curl -O https://download.ispsystem.com/6/dci/dcibox/dci
chmod +x dci
Создайте директорию /opt/ispsystem/license/ и скопируйте ранее созданную резервную копию платформы в директорию /opt/ispsystem/dci/backup/.
Запустите восстановление платформы из резервной копии:
./dci restore -b=<backup_file>
Активируйте лицензию в интерфейсе DCImanager 6 и выполните дополнительные шаги, если на сервере находится локация.
Обновите базу данных:
docker exec -it mysql bash -c "mysql_upgrade -u root -p$MYSQL_ROOT_PASSWORD"
Успешное выполнение этих шагов обеспечит безопасную и бесперебойную миграцию вашей платформы на новую ОС.

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

Важно убедиться, что версия BILLmanager на новом сервере не ниже, чем на старом. Миграция возможна между серверами с разными операционными системами.

Подготовка:
  • Подготовьте новый сервер, установите на него BILLmanager, активируйте триальную лицензию через личный кабинет ISPsystem.
  • Включите режим технического обслуживания на старом сервере на время переноса.
  • Импортируйте данные пользователей со старого сервера на новый.
  • Перенесите кастомные XML-файлы, дополнения и плагины на новый сервер. Это можно осуществить с помощью команд scp.
  • Перенесите настройки витрины со старого сервера на новый, скопировав соответствующие директории.
  • Установите отсутствующие пакеты ПО, такие как обработчики услуг, платежные системы и почтовые шлюзы, на новом сервере.
  • Привяжите лицензию BILLmanager к новому серверу, активируя коммерческую лицензию через личный кабинет.
  • Отключите режим технического обслуживания на старом сервере после успешного переноса.
  • После завершения переноса рекомендуется отключить или удалить BILLmanager со старого сервера, чтобы избежать конфликтов из-за одинаковых настроек обработчиков услуг.

Подготовка нового сервера включает установку BILLmanager, активацию триальной лицензии через личный кабинет ISPsystem и вход в BILLmanager через браузер для активации лицензии.

Убедитесь, что на обоих серверах активные лицензии, и после переноса активируйте на новом сервере коммерческую лицензию.

Инструкция по переносу BILLmanager на новый сервер:
Шаг 1: Включение режима технического обслуживания
«Режим технического обслуживания» временно останавливает работу модулей обработки и почтовых шлюзов в BILLmanager. Чтобы включить его на старом сервере, создайте пустой файл /usr/local/mgr5/etc/billmgr.DoNothing.

Шаг 2: Импорт данных
На старом сервере:
Создайте резервную копию с веб-интерфейса BILLmanager, перейдя в раздел Инструменты → Резервное копирование и нажав кнопку «Запустить». Сохраните архив с резервной копией.
Сохраните настройки брендирования.
Скопируйте директории на новый сервер с помощью команд scp
scp /usr/local/mgr5/skins/dragon/local_* root@:/usr/local/mgr5/skins/dragon/
scp /usr/local/mgr5/etc/brand_settings.billmgr.xml root@:/usr/local/mgr5/etc/

На новом сервере:
Перейдите в раздел Инструменты → Резервное копирование → кнопка Закачать, выберите архив с резервной копией с предыдущего сервера и нажмите «Восстановить».
После восстановления из резервной копии на новом сервере в конфигурационном файле может быть указан IP-адрес старого сервера. Укажите IP-адрес нового сервера в конфигурационном файле ihttpd /usr/local/mgr5/etc/ihttpd.conf. Перезапустите BILLmanager:
/usr/local/mgr5/sbin/mgrctl -m billmgr exit

Шаг 3: Перенос кастомных XML-файлов, дополнений и плагинов
Если у вас есть кастомные XML-файлы, дополнения и плагины, выполните следующее:
Создайте на новом сервере директорию /usr/local/mgr5/backup/, если такой директории еще нет.
Перенесите существующие кастомные файлы с помощью команд scp
scp -r /usr/local/mgr5/etc/xml/ root@:/usr/local/mgr5/backup/
scp -r /usr/local/mgr5/addon/ root@:/usr/local/mgr5/backup/
scp -r /usr/local/mgr5/src/ root@:/usr/local/mgr5/backup/

Скопируйте содержимое директорий с помощью команд:
cp -n /usr/local/mgr5/backup/xml/* /usr/local/mgr5/etc/xml/
cp -n /usr/local/mgr5/backup/addon/* /usr/local/mgr5/addon/
cp -n /usr/local/mgr5/backup/src/* /usr/local/mgr5/src/

Шаг 4: Перенос файлов витрины
Для переноса витрины со старого сервера на новый, скопируйте на новый сервер следующие директории:
# /usr/local/mgr5/skins/showroom/ — файлы витрины провайдера;
scp -r /usr/local/mgr5/skins/showroom/ root@<IP-адрес_нового_сервера>:/usr/local/mgr5/skins/showroom/
# /usr/local/mgr5/etc/showroom.sample.dragon/ — файлы шаблонов, на основе которых создаются витрины.
scp -r /usr/local/mgr5/etc/showroom.sample.dragon/ root@:/usr/local/mgr5/etc/showroom.sample.dragon/

Шаг 5: Установка отсутствующих пакетов
После переноса базы данных, на новом сервере запустите установку всех отсутствующих пакетов обработчиков услуг, платежных систем и почтовых шлюзов. Для этого выполните команду:
/usr/local/mgr5/sbin/mgrctl -m billmgr fix.modules

Шаг 6: Привязка коммерческой лицензии к новому серверу
После переноса BILLmanager на новый сервер, зайдите в личный кабинет, где заказана лицензия. Удалите триальную лицензию из личного кабинета. В настройках коммерческой лицензии введите IP-адрес нового сервера. Обновите файл лицензии, нажав на кнопку «Обновить лицензию» в веб-интерфейсе BILLmanager, либо загрузив лицензию вручную с помощью команды:
/usr/local/mgr5/sbin/licctl fetch billmgr

Шаг 7: Отключение режима технического обслуживания
Чтобы отключить режим технического обслуживания, удалите файл /usr/local/mgr5/etc/billmgr.DoNothing

Также мы планируем в этом году обеспечить поддержку ОС Alma Linux 9 для продуктов DCImanager и VMmanager, однако обращаем ваше внимание, что инструмент миграции Leapp для OC CentOS 7 предполагают разделения процесса миграции: сначала с OC Centos 7 на AlmaLinux 8, и только с нее уже на AlmaLinux 9.