Документация NetAMS

Минимально допустимая величина времени таймаута неактивности, используется при проверке корректности введенного пользователем (оператором) значения. Задается в секундах. По умолчанию значение 60 сек.

max_abs N

Максимально допустимая величина времени абсолютного таймаута, используется при проверке корректности введенного пользователем (оператором) значения. Задается в секундах. По умолчанию значение 1036800 сек = 24*12*60*60.

min_abs N

Минимально допустимая величина времени абсолютного таймаута, используется при проверке корректности введенного пользователем (оператором) значения. Задается в секундах. По умолчанию значение 60 сек.

min_passwd_length N

Минимально допустимая длина пользовательского пароля. По умолчанию равно 3 символом, однако в настоящий момент проверки не производится.

delay N

Интервал времени между периодическими проверками всех юнитов на наступление таймаута. Задается в секундах. По умолчанию значение 10 сек.

relogin {yes|no}

Разрешать ли повторный логин для абонента, который считается уже залогиненным? По умолчанию «да».

set–user–ip

Указывает на необходимость в случае успешной авторизации перезаписать IP–адрес юнита (если он имеет тип user) на текущий; при наступлении таймаута или останове доступа адрес сбрасывается в 0.0.0.0. Принимает значения yes или 1 (делать перезаписывание) или no или 0 (не делать). По умолчанию равно 0.

set {name AAA | oid BBBB}

[password CCCC]

[inact DDDD]

[abs EEEE]

[mac 0a:0b:0c:0d:0e:0f]

[strict|nostrict]

Записывает в структуру данных юнита в памяти и одновременно в SQL–базу параметры юнита (определяется по имени или номеру OID):

• Пароль (password)

• Таймаут неактивности (inact)

• Абсолютный таймаут (abs)

• Установленный привязанный MAC–адрес юнита (mac)

• Параметр безусловной привязки (strict) или его отмена (nostrict)

Все значения таймаутов задаются в секундах. Они должны быть или равны нулю, или быть в рамках между минимальным и максимальным значением. Если какая–то из величин таймаутов (или обе) равны нулю, то проверка этого типа таймаута для данного юнита не производится. Если какая–то из величин не указана, будет взято значение по умолчанию (определенное соответственно или в заголовочном файле src/netams.h или параметрами управления сервисов default–inact или default–abs).

login {name AAA | oid BBBB}

password CCCC

[ip A.B.C.D]

[mac JJ:JJ:JJ:JJ:JJ:JJ]

Служит для авторизации юнита и открытия к нему доступа. Обязательно указывать имя или OID юнита, а также пароль. Значения IP–и MAC–адреса должны подставляться внешним скриптом авторизации.

В случае указания неправильного имени юнита получится:

login:0#login name r546–1a

parse: FAIL: unit with name= r546–1a is not exist

Неправильного пароля:

login:0#login name r546–1 password 123

parse: FAIL: password incorrect

Успешной авторизации:

login:0#login name r546–1 password 123456

parse: OK: login success from ip:0.0.0.0, mac:00:00:00:00:00:00

При этом в лог–файле сервера появится соответствующая запись.

logout {name AAA | oid BBBB}

password CCCC

[ip A.B.C.D]

[mac JJ:JJ:JJ:JJ:JJ:JJ]

Команда отключения пользователя, параметры такие же, как и у login.

[service billing]

NeTAMS разрабатывался изначально не как система биллинга, а как система учета трафика. Вследствие этого основными учетными единицами являются юниты. К сожалению, концепции юнитов, имеющих основным свойством статический IP–адрес, не достаточно для реализации полноценного биллинга. Для решения проблемы был организован новый сервис, service billing, основной целью которого стала «правильная» поддержка других типов учетных единиц — пользовательских аккаунтов.

Как сервис биллинга интегрируется в ядро NeTAMS:

1. Создается и поддерживается структура аккаунтов, где каждый аккаунт представляет собой учетную запись пользователя, имеющую следующие параметры:

а) имя, идентификатор, описание

б) индекс текущего тарифного плана, и того который вступит в действие со след. месяца

в) баланс

г) даты создания, модификации и прочее

д) список ассоциированных юнитов

е) емаил, пароль

ж) статус

2. При создании аккаунта необходимо привязать к нему один или несколько юнитов, по которым будет осуществлен учет трафика (юниты имеют IP–адрес и список политик учета трафика). При необходимости юниты создаются автоматически через веб–интерфейс.

3. Каждый аккаунт, если не включена его добровольная блокировка, имеет активный тарифный план (и план «на будущее»). Тарифный план характеризуется именем, описанием и списком «подпланов». Этим достигается возможность создания «гибких» планов.

4. Каждый подплан характеризуется:

а) политикой учета трафика. Она автоматически выставится для каждого юнита, который принадлежит соответствию «юнит–аккаунт–план–подплан»

б) количеством включенного в абонентскую плату трафика (раздельно входящий/исходящий, значение в мегабайтах или без лимита)

в) месячная абонентская плата: правило съема этой платы (единовременно/ежедневно и др.)

г) плата за превышение трафика, включенного в аб. плату, в у.е. за мегабайт (раздельно входящий/исходящий; «бесплатно»)

Набор скриншотов с веб–интерфейса управления биллингом: