Данная механика появилась начиная с релиза 0.9.0 и представляет собой удобный уровень абстракции и автоматизации для работы с любыми NAS поддерживающими работу с FreeRADIUS. Тащемто умеет генерировать кучу всякого под видом кастомных per-NAS атрибутов. Да, каких угодно, нет - без привязки к какому либо фиксированному типу NAS.

Начиная с FreeBSD 12.1 достаточно только включить (и запустить) FreeRADIUS в /etc/rc.conf и можно переходить к Включение поддержки в Ubilling.
Для всех более старых версий нужно проделать шаги ниже:

Мы надеемся, что вы устанавливали Ubilling при помощи инсталлятора, и все нужное у вас уже есть. Для начала включаем Free Radius в /etc/rc.conf
Важно: пресеты в /docs/multigen/raddb/ для версии freeradius2 и в docs/multigen/raddb3/ для freeradius3.

radiusd_enable="YES"

После чего разворачиваем пресеты конфигурации FreeRADIUS и базовую структуру БД.

# cd /usr/local/www/apache24/data/billing
# cp -R ./docs/multigen/raddb/* /usr/local/etc/raddb/
# mysql -u root -p stg < ./docs/multigen/dump.sql
# mysql -u root -p stg < ./docs/multigen/radius2_fix.sql

Конфигурация FreeRADIUS3 (идет с бинарными пакетами для FreeBSD >=11.2):

# cd /usr/local/www/apache24/data/billing
# cp -R ./docs/multigen/raddb3/* /usr/local/etc/raddb/
# setenv RADVER `radiusd -v | grep "radiusd: FreeRADIUS Version" | awk '{print $4}' | tr -d ,`
# sed -i.bak "s/\/usr\/local\/lib\/freeradius-3.0.16/\/usr\/local\/lib\/freeradius-$RADVER/" /usr/local/etc/raddb/radiusd.conf
# mysql -u root -p stg < ./docs/multigen/dump.sql
# mysql -u root -p stg < ./docs/multigen/radius3_fix.sql

Потом приступаем к конфигурированию соединения FreeRADIUS с БД Ubilling, редактируя следующие параметры в /usr/local/etc/raddb/sql.conf

Если все закончили, можно попробовать запустить FreeRADIUS, но пока в debug-режиме:

# radiusd -X

И если вы увидели нечто похожее на код ниже - можно продолжать дальше.

... adding new socket proxy address * port 10049
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on command file /var/run/radiusd/radiusd.sock
Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel
Listening on proxy address * port 1814
Ready to process requests.

Включаем соответствующую опцию в alter.ini

;Включена ли поддержка КучаГен-а?
MULTIGEN_ENABLED=1
;Эта опция не обязательна и включает логирование multigen. Возможные значения 0 - disabled, 1 - enabled, 2 - debug, 3 - paranoid, 4 - nani?!. 
;Может уменьшить быстродействие. Радикально. Рекомендуется включать только на время отладки или конфигурации новых NAS.
;MULTIGEN_LOGGING=1
;Путь и опции по-умолчанию radclient для КучаГен-а. Необязательная опция.
;MULTIGEN_RADCLIENT="/usr/local/bin/radclient -r 3 -t 1"
;Используется только для баз использующих innodb и должно решать проблемы с быстродействием,
;посредством вырубания автокоммита и ручной работы с транзакциями.
;MULTIGEN_MAKE_INNODB_GREAT_AGAIN=1
;Показывать только незавершенные сессии по-умолчанию
;MULTIGEN_UNFACCT=1
;Количество дней, используемых для показа статистики аккаунтинга по-умолчанию
;MULTIGEN_DAYSACCT=30
;Дополнительные поля аккаунтинга для показа
;MULTIGEN_FIELDSACCT="acctuniqueid,acctupdatetime"
;Включен ли планетарный потрошитель Ишимура?
ISHIMURA_ENABLED=0
;Включает и устанавливает таймаут кэширования юзернеймов. Может улучшить быстродействие отчетов по аккаунтингу.
;Да, циферка в секундах. Отсутствующая либо равная 0 опция отключает кэширование вообще.
;MULTIGEN_UNTIMEOUT=3600
;Отправлять PoD при смене IP адреса у пользователя? Может принимать значения 0,1,2. При 1 отправляем PoD с новыми данными. При 2 отправляем 2 PoD с новыми и старыми данными. Актуально, например, для статических адресов или radius login=ip.
MULTIGEN_POD_ON_IP_CHANGE=0
;Отправлять PoD при смене MAC адреса у пользователя? Может принимать значения 0,1,2. При 1 отправляем PoD с новыми данными. При 2 отправляем 2 PoD с новыми и старыми данными. Актуально, например, для статических адресов или radius login=mac.
MULTIGEN_POD_ON_MAC_CHANGE=0

Вызов RemoteAPI

ubapi "multigen" -  регенерация данных всех пользователей, естественно только изменившихся либо отсутствующих.

Куда это засовывать?

crontab -e

*/2 * * * *  /bin/ubapi "multigen"

Все предельно прозрачно и тривиально

Каждый NAS может иметь свои собственные механики работы, выполняемые сервисы и наборы атрибутов а также правила их обработки а также, трансформировать имена пользователей (username) в требуемые вам форматы.

Следует также отметить, что при включении режима NAS-а “Только активные пользователи” все модификаторы единичных атрибутов “Пользователи” будут проигнорированы и атрибуты будут сгенерированы собственно только для активных пользователей. При попадании пользователя в категорию неактивных, все его атрибуты будут удалятся. Для NAS-ов не имеющих этого статуса вся работа с атрибутами будет происходить на основании их модификаторов “Пользователи”, которые могут принимать следующие значения: “Все”, “Активный”, “Неактивный”, что в свою очередь порождает возможность городить логику работы с пользовательскими атрибутами какой угодно сложности.

Не забываем, что в продакшне следует перезапускать ваш радиус-сервер скажем при помощи service radiusd restart при добавлении новых NAS. FreeRADIUS читает radius clients только на своем же старте.

Не забываем №2, что при всяких ваших экспериментах с набором аттрибутов (типо удаление,добавление,изменение имени аттрибутов) стоит сделать полную очистку и генерацию аттрибутов заново. Удаление аттрибута из справочника NAS-а не удалит аттрибуты из табличек mlg_check/mlg_reply.

Также, начиная с Ubilling 1.2.8, появилась возможность напрямую заполнять либо переназначать параметры серверов доступа КучаГен. Сделать это можно воспользовавшись “Кастомными настройками NAS”. Например вот так, можно добавить резервные сервера доступа не вешая на них какие-либо подсети, а также переопределить имя и RADIUS secret существующих серверов доступа:

Лишнехромосомные NAS имеют приоритет перед нормальными

Собственно вот результат

И конечно же не забываем, что любые из этих изменений также требуют перезапуска FreeRADIUS.

При запущенном в одном окне

# radiusd -X 

делаем в соседнем что-то вроде

# radtest testlogin testpassword 127.0.0.1 0 dec0071981b1

Где testlogin и testpassword как несложно догадаться - логин/пароль существующего пользователя которого мы проверяем на авторизуемость, а dec0071981b1 это Radius secret нашего локального сервера доступа.

Что мы должны увидеть в результате? А вот что-то такое:

root@test11_1x64:~ # radtest testlogin testpassword 127.0.0.1 0 dec0071981b1
Sending Access-Request of id 252 to 127.0.0.1 port 1812
	User-Name = "testlogin"
	User-Password = "testpassword"
	NAS-IP-Address = 127.0.0.1
	NAS-Port = 0
	Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=252, length=32
	Framed-IP-Address = 172.16.0.2
	Framed-IP-Netmask = 255.255.255.0

В случае если мы увидим что-то вроде

root@test11_1x64:~ # radtest testlogin testpassword 127.0.0.1 0 dec0071981b1
radclient:: Failed to find IP address for test11_1x64
radclient: Nothing to send.

стоит обратить внимание как минимум на /etc/hosts на тему добавления туда нашего хостнейма в виде

127.0.0.1   test11_1x64 test11_1x64.localdomain

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

Следует также заметить, что в целях улучшения быстродействия, архитектурой КучаГен-а не предусмотрено существование двух атрибутов с одинаковыми именами в рамках одного сценария. В этом случае, последний из описанных шаблонов атрибутов будет затирать все предыдущие. Для обхода этого ограничения, вы можете использовать другой сценарий для атрибутов с дублирующимися именами. Например, если вам требуется отдавать в reply какой-то одинаковый атрибут два раза скажем mpd-limit вы можете сделать это при помощи сценария groupreply как-то так:

В следствии чего, мы получим от FreeRADIUS следующий ответ:

....
	mpd-limit = "in#1=all rate-limit 5242880 655360"
	mpd-limit = "out#1=all rate-limit 1048576 131072"
....

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

На данный момент поддерживаются сервисы PoD (RADIUS Packet of Disconnect) и CoA (RADIUS Change of Authorization). В рамках этих сервисов, вы можете скриптовать, все что вам захочется для обеспечения требуемого вам поведения серверов доступа. Теперь кратко о том, в каких ситуациях будут выполнены данные скрипты:

Соответственно для сервиса POD+CoA при вываливании пользователя в оффлайн правила последовательно те же. Для пользователей, которые ранее не имели какого-либо состояние (читаем новых пользователей) не будет выполнено никаких скриптов в рамках сервисов. Для них будут просто сгенерированы новые атрибуты на общих основаниях.

Никто вас не заставляет вручную кликать всю конфигурацию для каждого вашего NAS сервера. Вы можете сконфигурировать только один и переносить все его опции, шаблоны атрибутов и сервисов на другие просто при помощи “Клонирования” в один клик. Также вы можете копировать, вставлять, и куда-то себе сохранять всю конфигурацию нужного вам NAS сервера, постить ее по форумам или мессенджерам в виде одной единственной строки текста.

Догони меня кирпич

Сам сервер FreeRADIUS вести учёт трафика не будет. Трафик должен учитываться при помощи протокола NetFlow: сенсором будет выступать сам RADIUS-клиент, который будет отправлять статистику на коллектор, в нашем случае модуль cap_nf ядра системы. Как это сделать будет описано отдельно в документации для выбранного вами решения.

Если очень хочется, и вам не страшно - можете попробовать использовать вызов multigentraff из Remote API. Например как-то так:

20 * * * *  /bin/ubapi "multigentraff"

Это будет запихивать данные из аккаунтинга в Stargazer.

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

ISHIMURA_ENABLED=1

в конфигах alter.ini и userstats.ini. Это активирует шоковый двигатель, для обхода всей механики работы с коллекторами Stargazer-а.

В Ubilling 1.3.0 и далее, все это управляется опциями MULTIGEN_AUTOCLEANUP_* конфига alter.ini и происходит автоматически.

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

Например каких-то таких:

$cleanupDays=30;
 
$query="DELETE FROM `mlg_acct` WHERE `acctstarttime` <= NOW() - INTERVAL ".$cleanupDays." DAY AND `acctstoptime` IS NOT NULL";
nr_query($query);
 
$query="DELETE FROM `mlg_postauth` WHERE `authdate` <= NOW() - INTERVAL ".$cleanupDays." DAY";
nr_query($query);

Сохраняем как-то так

После чего оставляем периодический вызов в crontab -e как-то так

4 4 * * *     /bin/ubapi "onepunch&param=mlgclean"

В случае, если вы используете планетарный потрошитель Ишимура, все должно нормально работать само по себе при штатном вызове fullhostscan с параметром traffdiff. Если же вы не желаете опираться на изменения трафика, а скажем только на существование незавершенных сессий Radius, все так же очень просто, One-Punch скриптом. Для коммутируемых соединений типа PPPoE можно например, так:

 $dnPath = DATA_PATH . 'dn/';
    //directory clanup
    $oldDnData = rcms_scandir($dnPath);
    if (!empty($oldDnData)) {
        foreach ($oldDnData as $deleteFile) {
            unlink($dnPath . $deleteFile);
        }
    }
 
    $accounting = new NyanORM(MultiGen::NAS_ACCT);
    $accounting->selectable(array('username', 'framedipaddress', 'acctstarttime'));
    $accounting->where('acctstoptime', 'IS', 'NULL');
    $allSessions = $accounting->getAll();
 
    //saving new DN data
    if (!empty($allSessions)) {
        foreach ($allSessions as $io=>$each) {
            file_put_contents($dnPath.$each['username'], 'alive');
        }
    }

*/20 * * * *     /bin/ubapi "onepunch&param=mlgdn"