Непонятки в NoDeny...

[evp]

Александр (AleksHr),
я бы попросил вас не говорить от имени автора о том на что биллинг рассчитан, а на что нет. Напишите свой и тогда отвечайте на вопросы, адресованные вам. А я свой вопрос задавал не вам. Прекращайте бессмысленный флуд. Давайте подождем, что скажет автор. ОК?

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

И, вообще, без ответа автора, думаю бесполезно продолжать разговор на эту тему. Так что подождем.

[versus]

Дело в том, что для того что бы сервер доступа разрешил пользователю выход в интернет, он от ядра должен получить событие, что этому айпи открыть доступ. Ядро в свою очередь эту информацию получает либо от радиуса либо от сервера авторизации. Если вы сможете каким либо другим способом передавать такое событие при связке мак+ай пи, то ждем предложений. В противном случае, вы переводите биллинг в режим авторизации Всегда онлайн и самостоятельно решаете все связанные с этим проблемы. Конечно ядро будет отключать должников, но и только.
Другого пути пока не придумали.

[Aivanzipper]

IEEE 802.1X ?..

[versus]

IEEE 802.1X ?..

а тупые мыльницы уже умеют ?

[evp]

versus,
не надо никаких сигналов. Достаточно, чтобы логика пакета "Заблокирован" с нулевым предоплаченным трафиком и нулевой переработкой совпадала в случае с авторизацией и без нее. А лучше всего, поскольку логика работы этого пакета без авторизации более верна (в самом деле, зачем отключать доступ по переработке, если стоимость переработки равна 0?), сделать автоматическое переведение состояния доступа клиента в "Запрещен" при установленной галке в пакете "Доступ должен быть заблокирован всегда". Неужели это сложно сделать? За эти несколько дней, что мы тут обсуждаем, вполне можно было такое реализовать. Не хотите менять что-то в ядре - я вас понимаю, новая версия и все такое - оформите в виде дополнительного модуля.

[versus]

versus,
не надо никаких сигналов. Достаточно, чтобы логика пакета "Заблокирован" с нулевым предоплаченным трафиком и нулевой переработкой совпадала в случае с авторизацией и без нее. А лучше всего, поскольку логика работы этого пакета без авторизации более верна (в самом деле, зачем отключать доступ по переработке, если стоимость переработки равна 0?), сделать автоматическое переведение состояния доступа клиента в "Запрещен" при установленной галке в пакете "Доступ должен быть заблокирован всегда". Неужели это сложно сделать? За эти несколько дней, что мы тут обсуждаем, вполне можно было такое реализовать. Не хотите менять что-то в ядре - я вас понимаю, новая версия и все такое - оформите в виде дополнительного модуля.

Эм... а что ж делать с алиасами ?

[evp]

Не совсем понял, а что с ними надо делать? Предоставлять такие же права, как и основной записи. Если у основной записи блокирующий пакет, то ясен пень, что и у алиасов тоже этот пакет. Разве не так? Или с некоторых пор в nodeny появилась возможность алиасам давать отдельные пакеты?

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

И так далее в том же русле

[mefer]

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

[smallcms]

Или с некоторых пор в nodeny появилась возможность алиасам давать отдельные пакеты?

Не замечал такое... 

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

И так далее в том же русле

Абсолютно то же самое делаю. Фактически мои руки - это такой биомодуль "перемещение в грппу клиентов с минусом, чтобы у них не тикала абонка на каком-то сумасшедшем автопилоте"...

Пробовал пофиксить самостоятельно, но пока война... 

[Efendy]

Подчеркиваю: логика биллинга в 50(49) версиях меняться не будет - мы хотим выпустить стабильный (не совершенный, а стабильный) релиз и все силы кинуть на реализацию замыслов в новой версии. Поэтому в 50(49) версиях будут фиксится исключительно баги, несмотря на то, что может казаться, что дополнение ничего не изменит, однако потом кто-то обнаружит, что в каком-то модуле было предположение именно о первоначальном поведении NoDeny. Мы не хотим иметь проблемы в прошлом. Мы хотим поставить точку. Андестенд?

[versus]

В аттаче внешний костыль для автоматизации блокировки клиентов, запускать можно в ручную можно в крон прописать. Скрипт простой, правда написан на питоне, сегодня перестроится с питона на перл не смог.
Конечно не правильно костыли плодить, но объективный ответ дан выше...
Кому надо забирайте

ЗЫ требует модуля MySQLdb
cd /usr/ports/databases/py-MySQLdb/ && make install clean

[smallcms]

Не, версус конечно молодец, спору нет, но думается у него много работы и ему задурили голову.
Дело в том, что у заблокированного (с отрицательным балансом) пользователя алиас блокируется. Это вы написали в биллинге и оно отрабатывает.
Дело в другом. Заблокированному пользователю всё равно начисляется абонка по тарифу.
И вот что мы придумали тут в сетке:
создали группу "Заморозка".
пометили группу флагом "При переходе на новый месяц не производить снятие денежных средств".
Думаю делать выборку из БД будет не так трудно. Труднее если групп несколько. Тогда нужна ещё одна таблица, где нужно хранить id группы, в которой был пользователь до заморозки.
Более проблемный момент - как не производить снятие посуточной абонплаты. Ведь здесь немного иная логика, чем отработка раз в месяц по крону...
 

UPD по поводу лишней группы: понял. "самдурак". есть же тариф "Заблокирован"

[Eugene]

Честно признаться, первый раз вижу такой разговор разработчика и клиента. Неужели такое бывает...

Спасибо огромное, что хоть как то вопрос решили. Будем пробывать. Конечно, с авторизацией доступ это действительно прошлый век.

Чисто поинтересоваться, нет более удобного решения на эту тему и по данному вопросу "Добровольной блокировки"? Очень актуально, поскольку сейчас тенденция: клиенты данного биллинга уходят в Радио-Доступ, а там клиент зачастую живёт в частном секторе и пользуется услугами не ритмично от месяца к месяцу, но нельзя открывать доступ по времени или траффику, только безлимит и месячная абонентка. Я сам лично веду несколько проектов по этой теме и принципиальна именно реализация добровольной блокировки на не авторизированном доступе (авторизация выполняется на уровне железа и с безопасностью и надёжностью там всё замечательно). Кстати, дополнительная авторизация на стороне клиента на 30% удорожает оборудование и обслуживание тех. поддержки, именно это ещё одна причина не использовать такой доступ.

[0xbad0c0d3]

А я себе сделал модуль для заморозки.
Указываешь период скакого по какое число не считать абонплату и соответственно не пускать в инет и все.

[Aivanzipper]

А я себе сделал модуль для заморозки.
Указываешь период скакого по какое число не считать абонплату и соответственно не пускать в инет и все.

Ну так выкладуй сюда. Бесплатно или за деньги это уже как считаешь нужным.