VM.center

Был такой проект ispsystem.it, я хотел делать FAQ в 2015 году. Но сейчас уже 2020, руки так и не дошли. Домен стал не нужен, продлять его не буду.
Сохраняю те топики для Истории.

Как-то в статьях про dns зону я писал, что очень упрощает работу — технический домен или поддомен.

Например.
Сервер шаред хостинга №1
s1.hosting.123.ru — скажем так метится к примеру.
и мы создаем техничную запись *.s1.hosting.123.ru

А при создании заказа — пользователю — автоматически создается технический поддомен user100.s1.hosting.123.ru

ну, нумерация, как домены/поддомены могут меняться, тут на ваше усмотрение.

Но биллинг ISP не позволяет такое провернуть.
Т.к. при создании тарифа — указывается шаблон.

т.е. этот один и тот же шаблон пойдет на 1ый, на 2ой и последующие сервера.


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

По сути этот изврат убивает саму суть — когда одному тарифу можно включить хоть 50 серверов в настройках.
Тупо, я считаю.

Шаблон доменного имени должен указываться в «Серверы» — когда добавляешь сервер и ему прописываешь этот шаблон.

Был такой проект ispsystem.it, я хотел делать FAQ в 2015 году. Но сейчас уже 2020, руки так и не дошли. Домен стал не нужен, продлять его не буду.
Сохраняю те топики для Истории.

Неправильно


Правильно

Был такой проект ispsystem.it, я хотел делать FAQ в 2015 году. Но сейчас уже 2020, руки так и не дошли. Домен стал не нужен, продлять его не буду.
Сохраняю те топики для Истории.

А теперь давайте я расскажу основные проблемы с тарифами.

Во первых. Важное значение это метод списания.
Например вы хотите создать тариф, где при оплате за год — сразу списывалась бы сумма с лицевого счета аналогичная стоимости за год.
У вас созданы все цены и периоды.
НО вдруг оказывается, что когда человек выбирает «за 1 год» — все равно списание происходит только за первый месяц, да еще и со скидкой, если вы делали за 1 год цену дешевле. Получается такой вот прямой убыток. Вместо 100р/мес, получается 70р/мес(70р берется из цены если на 1 год )
Большинство людей не врубает в чем дело.

А сейчас я вам расскажу в чем.
Существует такая настройка, как "тип учета"

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

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


Но нет. Это не будет работать, если у вас выставлен тип учета — месячный. Согласитесь какая-то тупость в логике.

В итоге — если вы хотите чтобы периоды работали — нужно ставить тип учета — «по периодам».
Не забывать это! И нигде об этом не написано, при создании тарифа. В всплывающих подсказках ничего такого нет.

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


Находится это вот где.


А настройка внутри редактирования этих типов.


Когда ты впервые настраиваешь биллинг — хуй ты это заметишь.
Все FAQ должны быть в самом биллинге — всплывающими подсказками. Притом нормальными подсказками со скриншотами, чтобы можно было понять, о чем идет речь в подсказке.!

Так же стоит сразу сказать. Что когда вы создаете новый тип продукта. Писем приходящих на email клиенту — не будет.!
Нужно так же создать шаблоны писем. Но почему-то биллинг не сообщает в процессе создания нового типа продукта, что вам нужно не забыть настроить шаблоны писем. Так что не забудьте сделать это.

Далее.
Проблема с «обрабатывается».

Как я уже писал в первоначальной статье — нужно было ставить галочку «требуется сервер», чтобы лицензии заработали.
Но это далеко не единственная проблема с «обрабатывается».
Полно косяков. И самый большой косяк — зависимые элеметы.
Глючные заказы — невозможно удалить.

А еще, многие, кто не осиливал биллинг — зарастали глючным спамом.
Есть такая херня — как «уведомлять об ошибках»
Находится это тут



Вот короче — все ставят эту галочку! Потому что не знают что это такое. Думают, авось пригодится.
И потом начинается чистый голимый спам. И люди не понимают где это отключить.


Я как-то раз видел биллинг, который примерно год был в запасе. Ну человек купил, хотел настроить, но не осилил. И вот короче подобный спам так срал каждый час. Представляете сколько за год тикетов «удаления» или «обработки» там насрало ?? Это был настоящий жесткачь.
Еще полно людей, которые так и работают с этим спамом. Они не знают как это отключить, но им не вломы каждый день отправлять в архив этот спам. Когда я подсказал им как это отключается, как будто бог с небес пришел.

Еще я хотел бы сказать, что есть такая полезная вещь, как Соглашения.


А потом в тарифе указывается это соглашение.


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

Был такой проект ispsystem.it, я хотел делать FAQ в 2015 году. Но сейчас уже 2020, руки так и не дошли. Домен стал не нужен, продлять его не буду.
Сохраняю те топики для Истории.

Когда вы создаете свои типы продуктов.
Есть некоторые замечания, о которых ВЫ НЕ ЗНАЕТЕ при установке. И знание этого доходит совершенно случайно, копаясь в логике этого биллинга.

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

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

Был такой проект ispsystem.it, я хотел делать FAQ в 2015 году. Но сейчас уже 2020, руки так и не дошли. Домен стал не нужен, продлять его не буду.
Сохраняю те топики для Истории.

Оказывается. Внезапно я спустя 3 месяца обнаружил. Внезапно нашел где это.

Видите галочку? ДАДА, нужно ставить эту галочку. По умолчанию она почему-то не включена.


Из-за того, что этой галочки не было — группы тарифов не работали.
Хотя когда ты создаешь Группу — там нету не слова про галочки.

Был такой проект ispsystem.it, я хотел делать FAQ в 2015 году. Но сейчас уже 2020, руки так и не дошли. Домен стал не нужен, продлять его не буду.
Сохраняю те топики для Истории.

Нужно установить BILLmanager на новый сервер, после залить базу данных биллинга со старого сервера. Дополнительно нужно перенести файл конфигурации billmgr.conf со старого сервера на новый, потому что туда записываются различные опции и включенные возможности. Учтите, что в файле конфигурации указываются данные для подключения к mysql, нужно будет указать в файле верные данные для подключения.
Если никаких специфических изменений BILLmanager не производилось, то этого достаточно.

Если есть плагины

• Нужно перенести xml плагинов, они лежат в директории /usr/local/ispmgr/etc/ и называются billmgr_mod_your-plagin.xml
• Нужно перенести обработчики плагинов. Они лежат в директории /usr/local/ispmgr/addon/
• Если используются cgi скрипты для плагинов, то следует перенести и их. Расположение — /usr/local/ispmgr/cgi/
• Если есть собственные модули платежных систем или регистраторов, то переносим их из /usr/local/ispmgr/sbin/

Если

• Если есть собственные шаблоны уведомлений следует перенести /usr/local/ispmgr/etc/notify/
• Если есть собственные шаблоны документов следует перенести /usr/local/ispmgr/etc/docs/
• Если изменялись настройки бренда следует перенести /usr/local/ispmgr/skins/sirius/local/
• Если используются аватары и собственные шаблоны печати переносим /usr/local/ispmgr/skins/sirius/local/
• Чтобы перенести вложения в тикетах, нужно перенести /usr/local/ispmgr/var/mailattach/
• Чтобы перенести конфиги пользователей, нужно перенести /usr/local/ispmgr/var/userconf/

Для начала работы с уже установленной панелью, вам понадобится:

• Настроить домен и почту
• Добавить токены Hetzner
• Добавить пользователей

Опциональные шаги:

• Настроить внешний вид и домен панели
• Настроить параметры панели

Идем сюда
hetzner.highload.cloud/billmgr
Заказываем тариф за 300р
Потом заказываем панель

ЖДЕМ минут 10 пока панель установится сама, это вам не быстрый Дебиан от хетзнера который за 5 сек делается.

Потом идем сюда
accounts.hetzner.com/signUp
Регистриуемся.
По умолчанию дается 10 штук облака, как заполнится — просите через поддержку расширить и тд
Так же можно регистрироваться много раз. Лучше делать это раза 3 в неделю, уж точно не в один день кучу аккаунтов. Иначе подумают спам и могут отклонить.
Чтобы убрать НДС — попросите друга с украины зарегаться. На форумах полно украинйцев, вместе с ними можете свои хостинги открывать. Как раз партнера найдете.

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

Настраиваем почту.
Например тут www.mailgun.com
Даже и 1 бакс не потратится.

Настраиваем логотип, бренд.

И в настройках — добавляем аккаунты Hetzner которые вы зарегали.

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

Чтобы создать токен, заходим в пустой проект на hetzner.cloud. После этого, выбираем «Access > API tokens»


После чего, жмём «Generate API token», вводим любое название и получаем наш первый токен

и копируем сгенерированный токен (его невозможно будет посмотреть снова, после нажатия «ОК»)

Добавлять в панель несколько токенов от одного и того же проекта не имеет смысла. Это негативно скажется на качестве распределения клиентов по аккаунтам.

В 2020 решил провести эксперимент


До этого все ноды были просто тупо разделены методом честности. Например 16 долей — значит 16 виртуальных ядер.
Купил 1 долю — 1 ядро получил в тариф
Купил 5 долей — 5 ядер получил в тариф
Все честно было. Никаких настроек не ставил я сроду.

НО в 2020 решил испытать фичу.
В VMmanager есть некий приоритет, который я никогда не использовал. Раньше хоть у 10 долей и у 1 доли приоритет был одинаковый.

Теперь же так.
Каждому тарифу — ставится одинаковое кол-во ядер. Например у процессора Ryzen-7 это 8 ядер процессора и 16 потоков. Поэтому короче я ставлю в тариф 16 vCore. В абсолютно каждый, хоть на 8 озу, хоть на 64 озу.
Но у тарифа с 8 озу будет самый низкий приоритет. У тарифа на 16 озу будет выше в два раза. У тарифа на 24 озу будет выше в 3 раза, у тарифа на 64 озу будет выше в 8 раз.

т.е. каждая VM может использовать 100% CPU, но когда CPU забивается по пизде, то срабатывает приоритет и мощность отдается тем, у кого он выше, а остальные ждут очереди процессора после. Вот такая честность на этом тарифе. Попробуем как оно работает :) Например когда CPU прохлождается или возможно никогда до 100% даже и не доходило, значит даже самый слабый приоритет может юзать все ядра.

В 2012 году так делал tinyvds.ru я еще тогда был нубом.
Вот теперь я решил попробовать в чем фишка.

Итак, конфиг

• Ryzen-7 [8c-16t]
• 128 DDR4 ECC
• 4x 1 ТБ NVME raid0
• 16 IP

1 доля равна

• Ryzen-7 16vCore / 8 ddr4 / 200 NVME — 1000р

Так же было куплено 4 диска чтобы сделать в raid0 и максимально много места.
Для любителей делать кучу говно сайтов которые хотят 100 ГБ и выше.

• Ryzen-7 16vCore / 8 ddr4 / 200 ГБ NVME — 1000р
• Ryzen-7 16vCore / 16 ddr4 / 400 ГБ NVME — 2000р
• Ryzen-7 16vCore / 24 ddr4 / 600 ГБ NVME — 3000р
• Ryzen-7 16vCore / 32 ddr4 / 800 ГБ NVME — 4000р
• Ryzen-7 16vCore / 40 ddr4 / 1 ТБ NVME — 5000р
• Ryzen-7 16vCore / 48 ddr4 / 1200 ГБ NVME — 6000р
• Ryzen-7 16vCore / 56 ddr4 / 1400 ГБ NVME — 7000р
• Ryzen-7 16vCore / 64 ddr4 / 1600 ГБ NVME — 8000р

Для заказа написать тикет тут, жду 50% предзаказов и покупаю.
panel.skladchik.ovh/billmgr

DNS сервис может видеть когда заканчиваются домены добавленные в нем.


И при желании присылать напоминание что можно переехать к «нему» и продлять домен у «него» :)
Правильный маркетинг.

Прошлая нода №9 — была уничтожена от старости.
На нее место куплен новый сервер.

Раньше все серверы, шареды, ноды анонсировались на проект складчин
И оплаты и графики шли именно так. Шаред обычно доли раздал, все пользуются, мало кто уходит. Текучки нету. У шареда текучка только если это именно шаред хостинг модель. А если это складчина, то все кто поверил в честную складчину точно не уходят.
С VPS же наоборот — текучки очень много.
Поэтому нужен только BILLmanager за копейку.
Итак. Заодно согласно правилам проекта VM.center — показываю, как аносируется нода. В будущем все хостеры смогут так анонсировать. С мини рассказом о себе, кто они и характеристики ноды и ее цены, локации и особенности ;)

Итак.

• Добавлено на узел rbx3.1245.ovh/vmmgr
• Добавлена в честную Историю — list.skladchik.ovh (2017-2018 год узлы смотреть)

Итак, добавлена noda9 [RBX3]
IP — 16 штук.


Доля/Тариф на 1 долю (можно соединять)

• E3-1245v2 / 2 ddr3 / 25 SSD / 1 IP

• Старт 10-2019 год — цена 200р
• С 10-2020 цена — далее 200р (так как больше нету понятия «вечная лицензия и с второго года уже не дешевле»)

travaux.ovh.net/vms/
travaux.ovh.net/vms/index_rbx3.html

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