nightfly

Странно. Насколько помню gateway_enable="YES" эквивалентен net.inet.ip.forwarding=1. Который насильно втыкается в /etc/sysctl.conf.

Учитывая мою встроенную офигительность и доброту, а также количество страждущих - по многочисленным заявкам в 0.5.4 начиная с ревизии 3467 ВНЕЗАПНО материализуется фича "кредитовалка принудительно не чаще одного раза в месяц".

Ну мне вот, например, всегда эскалейд хотелось, а madf-у не знаю....

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

А блин. При ребутах же. Сам процитировал - сам провтыкал. Да - полноценным инитом там и не пахнет.

Это вопли store_mysql о невозможности записать в базу изменения состояния юзера и его статистики. Почему такое происходит, лучше спросить у madf-a. Хотя на установках собранных UBinstaller я такого в принципе не видел.

если этого пользователя действительно не существует в природе, и первая подсеть занята только им - просто сделайте DELETE from `nethosts` WHERE `id`='2' удалите по нормальному сеть и живите себе счастливо. Хотя такой еффект не может не настораживать - при нормальном удалении нормального пользователя нетхосты и прочие такие штуки чистятся в первую же очередь.

ну а кто ж нормальный днем работает?

Это сигнализирует о том, что каких-то пользователей у вас в процесе перекосило и их нетхосты остаются прибитыми к этой сети. а покажите ка SELECT * from `nethosts` из консоли разработчика.

2 DemonidZe Все кто нужно уже видели и используют

Есть конечно же. Любой каприз за ваши деньги. Только проверок там слегка побольше - уже появились еще и плавающие периоды тарификации в stargazer.

Нет. Всякие такие штуки в принципе не предназначены для работы на размазанной АП. (А думаете почему она не рекомендуется, по всей документации?)

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

UPD: А хрен там с утра. Я ж нормально с таким не засну проблема исправлена начиная с 0.5.4 rev 3462. Для резкого фикса следует обновить api/libs/api.userreg.php получив его отсюда: https://github.com/nightflyza/Ubilling/blob/master/api/libs/api.userreg.php (вот в чистом виде)

Хм. Спасибо. Стабильно, дета раз в год исправляю эту проблему с бессмертными юзерами, и стабильно она вылазит опять из самых неожиданных мест. С утра посмотрю чем подпереть на этот раз

и действительно, слишком громоздко всё будет, хотя в необозримом будущем я вернусь к этому вопросу и запилю как надо думал очередь на внешний интерфейс повесить, но входящий траффик там шейпить безсмысленно, а исходящий ничнотжно мал буду локальный ретрекер ставить, чтоб юзеры через друг-друга качали свой дом2, а от вирусов пусть сами избавляются Простота - залог здоровья

Амінь

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

Собственно слегка причесал модуль, начиная с 0.5.4 rev 3456. Если очень спичит затестить - следует утащить себе вот эту либу: https://github.com/nightflyza/Ubilling/blob/master/api/libs/api.compat.php (вот в прямом виде) а также сам обновленный модуль https://github.com/nightflyza/Ubilling/blob/master/modules/general/pl_ipchange/index.php (опять же вот чистый сорс). Результат: 2014.05.12 16:39:18 DISCONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.7;CASH-180.000000 2014.05.12 16:39:19 CONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.5;CASH-180.000000;SPEED-5120;UPSPEED-5120,MAC-14:88:67:87:40:21

как видно из результата - дисконнект вызывается уже с новым ип тоесть биллинг отправляет старгайзеру команду на смену ип, а уже потом вызывает ресет (дисконнект/конеект) а надо другая последовательность: дисконект -> смена ип -> коннект Эммм. Логично. Надо бы посмотреть что можно с этим сделать.

Странно. По идее старгейзер при смене IP пользователя всегда сначала последовательно вызывает для него OnDisconnect после чего OnConnect. В любом случае тыканье по менялке айпишек вызывает следующий результат: /var/stargazer/allconnect.log 2014.05.12 15:32:02 DISCONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.7;CASH-180.000000 2014.05.12 15:32:02 CONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.7;CASH-180.000000;SPEED-5120;UPSPEED-5120,MAC-14:88:67:87:40:21 2014.05.12 15:32:41 DISCONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.5;CASH-180.000000 2014.05.12 15:32:41 CONNECT: ID-10;LOGIN-ap_p3iu;IP-172.30.0.5;

Вы будете смеяться, но тем же zbs_UserDetectIp() производиться и авторизация по паре логин/пароль. Это тоже самоочевидно. Итого просто выставляете при обращении у себя два кукиза ulogin и upassword. Вот и вся авторизация. Опять же, можно в принципе написать все это одним отдельным модулем кабинета пользователя, по дороге разворачивая его при апдейтах автообновлятором. Учитывая наличие у вас на скриншоте таких штук как морозильник, попрошайка, карточки, тарифоменялка и прочих активных вещей, заведомо настраиваемых и общающихся с конфигураторами stargazer-a - в случае использо

1. Я не знаю какое отношение ваш топик имеет к Stargazer. 2. http://wiki.ubilling.net.ua/doku.php?id=userstats - смотрите как работает UBA_ENABLED Хотя, если немного подумать, было бы круто врезать какой-то полноценный ААА + что-то типа xml rpc для таких вещей. Тоже в принципе никаких проблем не вижу.

вот только в старой базе треть маков не заполнена, а треть уже не актуальна такое бывает когда провайдер сделал ставку на впн Да. Вполне себе типичная картина. Так, что скорее всего вас ждет второй вариант. Он наименее травматичен с точки зрения сохранения целостности умолчальной политики доступа.

Да, вполне себе традиционно. Как правило люди следуют одним из двух путей: 1. Конвертируют уже вместе с MAC-ами 2. На этапе конвертации, втыкают всем кредит с просрочкой достаточной для работы юзера некоторое время. Ага