VM.center

Самое не гибкое в Billmanager — это навигация услуг.




Все что вы можете сделать — это вот этот список.
Пытаться создать новые типы продукта — все перестает работать там.

А так же — даже фраза «виртуальный хостинг» не переименовывается.
Если ее переименовать на что-то более современное, типо как Мощный Хостинг, или ISPmanager хостинг — хуй там, все равно Billmanager так и оставит по шаблоны 200х годов :))

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

Просто тупо скопировать раздел. И сделать еще 4 точно таких же.
Но переименовать их по разному.
Например
Lowcost Серверы
HighLoad Серверы
BackUp Серверы
и тд, категорий и подходов к делению просто уйма
А может быть я захочу по континентам рассортировать.
Дата-центры Африки
Дата-центры Америки
Дата-центры Азии
Дата-центры Евпропы

И уже потом создавать обработчики и кучу разных дата-центров в нужном континенте.
Но продаваться да будет один и тот же товар — Выделенные серверы. А значит никакого нового типа продукта делать не нужно, нужно просто скопировать уже существующую настройку. Но панель так не умеет.

Вот основная убогость короче этой панели в том, что она абсолютно не гибкая.

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

Чисто для истории такой публикую.

• Начальный топик с раздачей тут
• Бесплатный ISPmanager Business FAQ описано тут

Так, с Корпорейтом все сложнее.
Во первых там слишком много общего. И просто так взять и создать «реселлера» — не вариант.

Поэтому сначала вы пишите мне в личное сообщение. alice2k
Я заношу вас в график, чтобы не запутаться потом кто есть кто.
И так же заводите заодно логин на проекте vm.center, чтобы потом через личные сообщения мне писать, чтобы я потом добавлял какие-то возможности которые только через меня делаются, в целях безопасности.

Кстати да, вы можете в нем создавать не только 1 хостинг проект. А хоть 100 лепите! Никто и слова не скажет :)
Можно делать разные проекты с разными валютами.


Собственно я вам создаю сотрудника, но с ограниченными правами.
Кнопка «права».
Пока что еще в стадии тестирования что именно отключено.
Но точно отключено — резервное копирование, глобальные настройки, настройки системы, логирования. Это все нужно для того, чтобы биллинг сам по себе работал — и за этим следим только я и Vova1234 . Остальным портить эти настройки никчему.


Далее методы оплаты получаются доступные для всех сотрудников, если это не отключено.
Как бы человек начала создает себе Компанию, создает себе Проект.
А потом создает методы оплаты для проекта.


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




Тоже самое касается и обработчиков услуг.
Сами серверы шареда, сами ноды VPS допустим. И доступы до них. Когда автоматически все это создается.
Обработчики услуг — будут отключены. И добавляются через меня, через переписку в личных сообщениях уже, тут на портале.



Чем может быть вам полезен Billmanager ?
Например вы хостер типичный — хотите продавать шаред хостинг. Не вопрос, направляете домен, делаем вам сертификат, настраиваем методы оплаты. Создаем отдел поддержки, назначаем в него ваш проект и ваших сотрудников.
Кидаете мне доступы от обработчика — добавляю его в список. Далее вы сами создаете тарифы. И назначаете им тот обработчик, который я создал.
Тоже самое если вы продаете VPS.
А может быть вы захотите продавать выделенные серверы и попробовать как оно? Не каждому дано создать хостинг. И многие не имеют денег на старт. Как раз — за счет моей раздачи вы можете попробовать свои силы, вдруг у вас получится. А если не получится, то вы не подарите денег цензорным панелям ISPsystem.

Далее, еще Billmanager вам может быть полезен.
Если вы хотите по API что-то распространять.
Во первых можно просто создать проект для перепродажи из десятков и сотен различных Billmanager.
Пример такого www.ihor.ru/reselling

Но только в Корпорейт версии — есть возможность пойти еще дальше.
Знаете таких как icplicense ? Их аккаунт, их биллинга все хостеры связывают себе в биллинги, как обработчик. И перепродают лицензнии.
Вот — вы можете сами стать точно такими же.
Допустим у вас есть аккаунт где-то, у хостера, или у тех же ISPsystem оригинальный с 50% скидкой. И вы хотите чтобы и 50 хостеров так же покупали у вас с этой скидкой.
Добавляете этот аккаунт в корпоративном биллинге, в обработчики, через меня.
А потом все кто заводит аккаунт в вашем проекте, внутри корпоратива, могут потом тот аккаунт, что они завели добавлять себе в свои собственные Billmanager уже, в обработчики и продавать своим клиентам по API. Тем самым аккаунт с 50% скидкой начинает продаваться чуть ли не по всему рынку хостеров. Как раз то, чем занимается icplicense.

Ах, да, каждый проект кроме SSL сертификата собственного домена.

Когда вы просите у меня Биллинг — я вношу вас в график и записываю на какой IP адрес вы садитесь. Можно купить выделенный чистый IP.

Должен еще завести ящик на pdd.yandex.ru на свой домен.
Как настраивается написано в этом FAQ


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


Так же в Корпорейте есть фичи, которых нет в обычном Billmanager
Например рекламные баннеры.


И например подсказки сопутствующие товары.
Это что-то вроде, как тут у меня в блоге — похожие топики :)


Так же есть документооборот.
Хотя думаю — большинству он не нужен.


Про основные возможности Billmanager думаю нет смысла рассказывать. Например группы тарифов, группы пользователей. Можно делать тарифы доступные только при определенных условиях или для определенных групп клиентов. Короче все вопросы — на этот проект, раздел и создан «вопросы» :)

Не удалось расшифровать данные error:0407109F:rsa routines:RSA_padding_check_PKCS1_type_2:pkcs decoding error

Во время биллинга услуги с Id произошла ошибка: 'An error occurred while working with keys or certificates. Failed to decrypt the data error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check failed '.

Решение проблемы
Перенесите со старого сервера /usr/local/mgr5/etc/billmgr.pem.

Billmanager v5 примерно стабильный стал с 2016 года.
Ну в 2015 он был так себе, а в 2014 вообще адище.

Так вот, пошел процесс переноса v4 на v5 примерно с 2016 года.

И вот, в 2018 вскрылась одна проблема.
Засирается место.


Решается проблема сначала командой

du -h --max-depth 1

например

du -h --max-depth 1 / 
du -h --max-depth 1 /usr
du -h --max-depth 1 /usr/local
du -h --max-depth 1 /usr/local/mgr5
du -h --max-depth 1 /usr/local/mgr5/var

итого срется сюда
/usr/local/mgr5/var/usageinfo
и еще нада смотреть
/usr/local/mgr5/var/logs

только вот в настройках есть только папка /logs


А вот папка usageinfo пишется с момента запуска биллинга и вообще не чистится похоже
Теперь я знаю даты старта каждого биллинга :)


Если вдруг у кого-то будет подобное.
Теперь вы знаете, что нужно чистить.

Миграция с ОС 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.

Уровень логирования определяет насколько детально будет отображена информация в логах. Чем выше значение, тем более подробная информация записывается в лог.

Уровни логирования:
1 — замечания;
2 — критические ошибки;
3 — ошибки;
4 — предупреждения;
5 — информация о запросах;
6 — расширенная информация;
7 — сообщения удалённых сервисов;
8 — трассировка кода;
9 — отладочная информация.

"https://<ip-адрес/доменное имя>/billmgr?theme=client" — новый клиентский интерфейс. 
"https://<ip-адрес/доменное имя>/billmgr?theme=orion" — старый клиентский интерфейс.

Полный тикет

В 2018 году Вечных панелей — снова не стало.

Q: Как перенести лицензию, купленную на стороне, на мой аккаунт в ISPsystem?

A: Перенос лицензий между любыми типами аккаунтов (партнерским и простым) запрещен!

для справки, это произошло осенью 2013