dimmons
Тип контенту
Профили
Форум
Календарь
Сообщения додав dimmons
-
-
Давно ждал расширенного управления пулами адресов, но так как ранее ничего такого не было пришлось навешивать по 4 учетки для сетей /30 в групповые пользователи, чтобы был нормальный учет используемых адресов. В свзи с некоторыми особенностями распределения насов по сети и ограниченным количеством адресов используем и для ппп и для подсетей одни и теже пулы. Типы сетей соответственно у всех пулов other. И вот беда теперь в том что есть сети выделенные в расширенном управлении пулами, но при выделении из техже подсетей адресов для ппп, адреса занятые в пулах не учитываются как зантые. И наоборот, в пулах могут выбираться адреса занятые ппп учетками. Можно ли както объеденить эти механизмы? чтобы при выделении новых адресов учитывалась занятость и там и там?
-
UPD: Судя по всему вы решили использовать паспорта домов, банально не заполнив типы владельцев. Итого, либо отключите нафиг BUILD_EXTENDED либо адекватно заполните BUILD_OWNERS.
Да, оно самое!!! Как всегда очень оперативно ) Спасибо.
-
После нескольких обновлений пропала возможность добавлять дома. На каком обновлении произошло сказать трудно, долго домов новых не было. Сейчас при открытии справочника "Дома", в нем нет формы добавления нового дома. А при создании абонента если нажать кнопочку дома на этапе выбора дома выскакивает страница с вот этим содержимым:
Fatal error: Uncaught exception 'Exception' with message 'EMPTY_OWNERS_PARAM' in /usr/local/www/apache22/data/billing/api/libs/api.address.php:869 Stack trace: #0 /usr/local/www/apache22/data/billing/api/libs/api.address.php(835): BuildPassport->loadConfig() #1 /usr/local/www/apache22/data/billing/api/libs/api.address.php(561): BuildPassport->__construct() #2 /usr/local/www/apache22/data/billing/modules/general/builds/index.php(35): web_BuildLister('56') #3 /usr/local/www/apache22/data/billing/index.php(67): include_once('/usr/local/www/...') #4 {main} thrown in /usr/local/www/apache22/data/billing/api/libs/api.address.php on line 869
-
Хмм.. вопрос снят... Не меняется адрес при установленном сервисе текущий, выбрать его надо обязательно.
-
Вот 3 кликовым способом и пытался, после нажатия сохранить страница перезагружается и у абона тотже ип адрес.
Уже закралась крамольная мысль сделать запрос апдейта для записей... Но не уверен в полном понимании связей в таблицах по ип адресам, все что до подсети и сервиса вполне очевидно, а вот что за обработчики не понял.
Но всетаки хочется разобраться с штатным способом смены ип адресов. Оператор мы небольшой, рубить 2000 адресов на куски особой возможности нет, поэтому адреса белых стыков для оборудования тоже заносятся в биллинг на технологические учетные записи (чтобы манагер не занял адрес при заведении нового абона), а стыки в сетях дело такое, седня есть завтра нет.. короче ип адреса на учетках менять потребность есть..
-
Текущая версия 0.5.2 rev 3426.
CRM_MODE=1
SAFE_REGMODE=0
Но при попытке сменить адрес, через редактирование експресс карточки, просто оставляет старый адрес. Или, если завести новую сеть-услугу, вставляет первый свободный адрес из этой сети.
P.S. Понимаю позицию создателей, но надо занести абонента который ранее обрабатывался в другом биллинге, менять ему ип нельзя.
-
Редиректите не на страницу блокировки а на сервер squid или webproxy микротика (прямо в фаерволе микротика), далее в сквиде или микротике генерите список ссылок на подмену страницей блокировки, остальное пропускать. На выходе получите бюджетный блокировщик http/https для squid и http для микротика.
P.S. Есть рекомендации роскомнадзора, в документе рекомендован следующий порядок действий:
1. разрешение адресов по доменам в ссылках (именно самостоятельное разрешение)
2. Вывод трафика на эти адреса через PBR
3. Фильтрация ответвленного трафика
Но тут есть нюанс, TTL DNS записей гугла например не превышает 5 минут. Раз в 5 минут обновлять карту PBR не есть айс, так что придется агрегировать ип адреса для доменов своим скриптом за несколько дней и фильтровать по всем ип адресам.
Если кто-то думает что достаточно ПБРить адреса указанные в реестре, увы это не так, они там массово неправильные (процентов эдак 50), а судебным органам на это плевать.
-
Появилась надобность размазать одну подсеть на несколько NAS через redistribute connected. Пользователи заводятся на nas -ы статически, самописными скриптами onConnect, onDisconnect, идентификация наса для прописывания пользователя ранее была по его ip адресу и подсети из таблицы nas. Теперь мне необходимо заводить одну подсеть на несколько насов, возможность идентификации наса по адресу отпадает. Планирую завести дополнительное поле пользователя для привязки его к NAS.
Суть вопроса такова, уже есть много юзеров в биллинге, руками прописывать всем nas это долго, муторно и чревато ошибками. Хочу прописать в таблицу cfitems все запросом. Имеются ли связи у записей в других таблицах с полями таблици cfitems?
-
Еще вопрос выплыл, в разделе http://wiki.ubilling.net.ua/doku.php?id=switchmap указана немного другая команда API для работы "машины времени":
/usr/local/bin/curl -o /dev/null "http://127.0.0.1/billing/?module=switches&cronping=ваш_серийник"
Есть принципиальная разница какую ставить в крон?
-
Да как то хватало ручного опроса.. Но проще добавить в крон походу ))). Спасибо.
-
Спасибо, добрый человек!!
Скопипастил с генератора шаблонов неполностью.
-
Сделал новый шаблон SNMP для нового свича, залил в папку, дал права всем читать-писать. При выборе в поле шаблона из падающего меню в списке шаблонов появляется просто пустая строка. Что я делаю не так?
-
При недоступности свичей, если нажать кнопку "свичи", все подвисает на пару минут, я так понимаю пингается. Никаких задач опроса через API в крон не ставил.
В каких случаях происходит опрос добавленных в базу коммутаторов?
-
Кстати, если кому интересно, на Ubiquiti тоже читает данные нормально.
-
Да действительно, спасибо.
-
Если ни одного устройства для мониторинга не заведено, выдает страничку с надписью "Не найдено устройств для мониторинга сигнала". При заведении микротика выдает девственно белый лист без единой строчки кода.
Ubilling 0.4.7 rev 3042.
-
- То же самое что первый, но на дочерних пользователях раскиданы какие то деньги.
Ну и?
Как будут списываться деньги с разных дочерних пользователей?
И вопрос про групповые операции не в том, что не положились деньги родительскому, а сколько в результате денег окажется на счету групового пользователя (я ложу 500 рублей и они попадают каждому дочернему и родительскому)?
В документации не нашел описания логики работы с лицевыми счетами групповых пользователей.
-
Доброго времени суток коллеги.
Кто нибудь может просветить порядок снятия добавления денег для групповых пользователей (или ткнуть где почитать), возникли следующие вопросы:
- Есть родительский пользователь (на нам стоит фейковый тариф, не снимающий денег), все деньги лежат на нем, на дочерних денег нет, но стоят тарифы снимающие их (тарифы разные). Как будут сниматься деньги?
- То же самое что первый, но на дочерних пользователях раскиданы какие то деньги.
- При включенных групповых операциях деньги кладутся всем дочерним (каждому одна и та же сумма), но не кладутся родительскому. Это значит что общая сумма на счету умножается на количество дочерних юзеров (3 дочерних юзера, кладу 500 рублей, падает по 500 каждому, всего 1500?)? Или это отображение состояния одного лицевого счета?
Мне в принципе не понятно, что происходит с лицевыми счетами родительского и дочерних юзеров при образовании группы. По каким принципам и с каких счетов происходит списание денег по лицевому счету (или нескольким лицевым счетам, если у каждого пользователя остается свой) тарифами каждого из пользователей в группе.
P.S. Еще вспомнилась такая вещь как теги, как они списываются при назначении пользователям в группе?
-
Я тут смотрел исходники динамического шейпера, и как я понял он работает только если NAS сделан локально на сервере биллинга. А есть какой то вариант реализующий его на удаленных NAS?
Отлично работает на NAS под управлением rscriptd и FreeBSD. Остальное мне слабоинтересно.
И еще вопрос про rscriptd, я с ним раньше не сталкивался никогда, у него какието преимущества перед ssh c ключами есть?
Да. Преимуществ ровно два:
1. ssh на ключах - нерабочее говнище с кончающимися сокетами и прочими детскими болезнями.
2. rscriptd - божественен.
Может ли rscriptd что то чего не может ssh?
Да. Он просто выполняет на удаленных серверах все те же OnConnect/OnDisconnect. Делает это вовремя, гарантированно, сплошным потоком и в общем хорошо.
Настройка таких штук вполне себе отработана и работает уже не на одной сотне серверов доступа.
З.Ы. Хотя возможно у вас слишком много свободного времени, вам хочется странного и вы мечтаете о написании чего-то с использованием telnet+expect либо наворотить какой-то комбайн на Node.js для того чтобы дергать удаленно все те же OnConnect/OnDisconnect - это чисто ваш выбор.
Ничего странного не хочется, кроме как пересадить на новый биллинг разношерстный зверинец действующих NAS-ов (привязанных сейчас к другим разным биллингам) постепенно сведя все это к однотипным микротикам. Так что без написать что нибудь не обойтись, но написать хочется, чтобы потом оно меня не трогало, ибо времени нет.
З.Ы. С rscriptd разобрался, но с ним синхронизация пользователей на NAS в том виде в котором она мне нужна, неосуществима. А telnet+expect+Node.js это совсем не мой выбор )), просто python...
-
При наличии Mikrotik API смысла в ssh думаю нет, да и за эти дни библиотеку под API полностью допилил. А удаление все таки сделаю в OnDisconnect, ip адрес мне старгейзер дает, остается NAS по ip адресу в базе найти, что не есть проблема.
Почасовой синхронизатор всех юзеров NAS все равно на днях сделаю, хочу раз и навсегда забыть про ручные правки появляющиеся по причине того что где то например отключили свет и сеанс связи с NAS не удался и т.п. У меня NAS по регионам распиханы, часто это просто поселки, там что связь, что питание - полное гавно.
Я тут смотрел исходники динамического шейпера, и как я понял он работает только если NAS сделан локально на сервере биллинга. А есть какой то вариант реализующий его на удаленных NAS?
И еще вопрос про rscriptd, я с ним раньше не сталкивался никогда, у него какието преимущества перед ssh c ключами есть? Просто у меня уже есть ранее написанная обвязка под другой биллинг для управления ipfw работающая через ssh или локально, переделать под этот билинг, буквально запросы адаптировать и все. Может ли rscriptd что то чего не может ssh?
-
Тогда проще сделать синхронизацию кроном раз в час.
-
Ваша оперативность меня вдохновляет )), вы дадите фору многим платным биллингам.
У меня еще появилась мысль о массовом ресете. Каков механизм работы после нажатия кнопки? Хочу по нажатию этой кнопки запускать синхронизацию по насам (чтобы всех юзеров не удалять-добавлять, а выявлять только то что надо поправить).
Я предполагаю что сейчас дается какаято команда старгейзеру и тот пологинно делает дисконнект-коннект.
-
Имею некоторый предрассудок в использовании логинов как якорей для идентификации пользователей в конфигах железок, но это дело хозяйское, кому как удобней (на некоторых насах с логинами вообще проблема, на каком нибудь ериксоне например)
Обвязку скриптов я переписал по своему, она теперь юзеров и очереди удаляет по запуску OnConnect/OnDisconnect (OnUserAdd/OnUserDel я не трогал). Все работает замечательно, за исключением 1 нюанса. При удалении юзера из биллинга, он исправно запускает скрипты, но в данных уже нет. При этом в интерфейсе биллинга, в пользователях онлайн, удаленный юзер есть (из этого делаю вывод что гдето в базе есть и данные о юзере). Использую запрос вида:
select nh.netid, n.nasip, n.nastype, rsp.speed, u.tariff, sp.speedup, sp.speeddown, u.ip from nethosts as nhjoin nas as n on n.netid = nh.netidjoin users as u on u.login = 'ttt'join userspeeds as rsp on rsp.login = u.loginjoin speeds as sp on sp.tariff = u.tariffwhere nh.ip = u.ipВ принципе вывернуться из ситуации можно просто:
- Для удаления юзера можно вообще в базу не обращаться, скорости мне чтобы удалить данные с наса не нужны. Достаточно того что получает скрипт (собственно обращение к базе в OnDisconnect остались из-за того, что он был быстро вылеплен из OnConnect и отличается только коммандами в API)
- Сказать манагеру чтобы перед удалением юзера он его приостанавливал (пока так и делают ))))
Но все таки мне просто интересно, откуда берутся в юзерах онлайн данные о пользователе после его удаления?? Есть знатоки которые могут прояснить как это все происходит?
-
Я начинаю понимать jcomm )). Stargazer передает при запуске UserAdd и UserDel довольно бесполезные для создания и удаления юзера параметры: логин, тариф и т.п., ни IP адреса, ни скорости.. Так что для управления микротиком эти два скрипта бесполезны. Надо переделывать скрипты OnConnect/OnDisconnect на удаление/добавление адреса и очереди... Попробую расковырять сам, если не получится побегу за пачкой ))).
Перенос биллинга на новый сервер
в Stargazer Ubilling
Опубликовано:
Здравствуйте, встала задача по перносу Ubilling на новый физический сервер. Хотелось бы уточнить правильный порядок переноса базы и конфигов с учетом нескольких нюансов. Нюансы такие, в моем случае биллинг работает просто как биллинг, считает деньги и получает трафик по нетфло от брасов, вся автоматика управления брасами это самописные запускаемые по крону скрипты, никаких задач терминации абонентов этот сервер не выполняет. Исходя из нюансов возникло несколько вопросов: