nightfly

Потому, что пользователь stargazer на самом деле не зарегистрировался. Это происходит вызовами родных старгейзеровых конфигураторов. Все остальное, типа адресов, мобилочек, и прочего добавляется уже самим убиллингом напрямую в базу. Либо неверно указаны логин, пароль администратора старгейзера, либо не верен путь к конфигуратору sgconf_xml либо последний вообще не собран. Внимательно смотрите, что у вас нарисовано в config/billing.ini и насколько это соответствует реальности.

До 9.2? Юзать в продакшне? Думаю - самобичевание.

Ну дык посмотрите глазами - проверьте фаер, позырьте по логам (для умолчальных OnConnect/OnDisconnect это /var/stargazer/allconnect.log) На это забейте - по словам абонента вы и христианских младенцев ночами едите. Всегда проверяйте все лично - см. выше. Вот это точно не хорошо, вынужден согласиться. Вдумчивым логированием выполнения OnConnect/OnDisconnect, и только. Если проблема не становиться видимой - значит это волшебная проблема из разряда невозможных и несуществующих в природе. Хотя... если вы используете rscriptd для удаленных NAS серверов, может проявляться одна

Ну, не взирая на этимологию, там чуть другие семантические свойства присутствуют

слон с укором смотрит на вас красными глазами

Это штука рисующая иконку на таскбаре, ту которая с черепашкой. Для особых ценителей старины оригинальный vservices.php валяется в docs/vservices_cli, его можно положить на место при желании - только смысла никакого в этом не вижу. Все вот такие вот внешние подпорки теперь выносяться в remote API - там хоть какая-то пародия на авторизацию есть. вы чо, /tmp пропили? wget "http://billing.isp/index.php?.... ни на что не намекает?

Вам виднее. Всеравно потрудитесь оформить эту свою "вручную" до состояния скрипта - будет веселее

Да, плюс в большинстве своем еще и "вкати патч на БД на ходу", просто в последнем как-то обошлось без этого. Вот такой вот занятный деплоймент Кроме того, я даю гарантию что при реальном использовании у вас начнут воротиться какие-то свои примочки-дописки-довески-обвески требующие развертывания поверх новых релизов. Это к слову, что придется обновлялку под свои нужды править.

Знаете анекдот про "с мягким знаком"? Дык вот - с мягким знаком потом обновляться. Оно уже в продакшне с обеда у десятка сетей. Багфиксы там достаточно критичных вещей.

Это кажется бич любого продукта Пздц комплимент Вы того, осторожнее, а то madf сейчас обидиться и интегрирует в stargazer самоуничтожение при одном виде StoreModule store_mysql. Его и так уже морально добивают расплодившиеся "инсталлерные" пользователи. P.S. имеете возможность еще поискать баги в обновляторе, вкатив себе каррент релиз.

Релиз Ubilling 0.3.3 rev 1979 - alter.ini: новая опция CREATETASK_IN_PROFILE включающая интерфейс создания задач в профиле - alter.ini: новая опция SUSP_PAYMENTS_NOTIFY описывающая порог срабатывания уведомления о подозрительных оплатах - Модуль «Производитель оборудования»: теперь асинхронно подгружается в модальном диалоге - Модуль «Тарифы»: теперь при создании по умолчанию тип подсчета трафика up+down - Модуль «Классы трафика»: теперь есть проверка на заполненность названия правила - Модуль «Работники»: теперь проверяется как минимум заполненность имени и типа работы - Модуль «Тег

да комментируется - в FAQ про это есть

Нет Ключевой момент "после рестарта". Допустим есть себе запущенный старгейзер - вы исправляете поле cash юзера на ручнике с 50, до скажем на 100. Всюду отображается что у него таки 50 денег на балансе. После чего добавляете ему 20 денег и оппа - у него на счету 70 денег. Старгейзер перечитывает базу только на старте, после чего просто ее "помнит". Так есть и так было всегда.

Значит еще слабо ознакомились. Это один большой такой... не не так.... здоровенный... не, опять не то.... громадный, во! костыль на ~200k строк. Это не халява - THIS IS SPARTA OPENSOURCE!!!1

Это вы пока не попробовали с этим пользователем ничего сделать. Денег например добавить, или тариф сменить. Stargazer читает данные из базы только при запуске, после чего держит их актуальными в памяти и вносит изменения в базу когда ему это нужно. При этом все внешние изменения затираются. Именно поэтому такая здоровая кухня с конфигураторами и прочими штуками нагорожена - Ubilling родные таблички stargazer использует только в режиме read-only - все остальное через многоступенчатые прослойки и уровни абстракции. Хотелось бы откровение Иоанна Богослова поцитировать, да не буду.

Ключевое слово в названии опции SAFE. Все изменения в табличках users, tariffs и admins - при вмешательстве извне, при запущенном stargazer будут затерты. Все изменения в них происходят при помощи внутренних вызовов конфигураторов старгейзера описанных в опции baseconf конфига billing.ini. sgconfxml к слову тоже по дефолту изза того, что наиболее стабилен на данном этапе. Модуль store_mysql писал не я - так что вопросы точно не ко мне. Я бы тоже организовал связывание по банальному автоинкрементному id лучше. Там и пассворды плейнтекстом к слову. Он кстати их и генерирует и

Ну почему же. Сам по себе snmpd не жрет нифига, cacti - тоже не так прожорлив как zabbix скажем, monit - тоже ресурсонежрущая вещь, практически объязательная для оперативного мониторинга падения сервисов и принятия при этом соответствующих действий. На настоящих объемах абонентов/трафика держать связку netflow/shape/nat/bandwidthd на том же тазике, что и биллинг - изначально нездоровая затея. Благо практически бесконечное масштабирование по горизонтали более-менее продумано и ненапряжно. stargazer со своим бесподобным rscriptd на ниве человекообразной кластеризации дичайше жжет. На практик

Ну я против него в роли фронтэнда не имею ничего против, если скажем нужно отдавать здоровую статику типа киношек гигабитами Осмотритесь вокруг, тут люди спрашивают "как посмотреть что написано в конфиге?" и "срочно стать проф. линух админом за 2 дня - бабок 30 баксов" а вы пытаетесь еще культуру типа SSL прививать Вы знаете зачем оно вам нужно - вот и осилили самостоятельно. Хорошо. Кстати лично особо по этому поводу не заморачиваюсь - у нас "все девочки на кассах" и "мальчики суппорты" находяться в отдельной анально огороженной сети которую и снифить то некому + рядышком allow t

Пусть так, а вдруг какую-то циску на агрегацию поставите, либо микротичину и захотите снимать нетфлоу с нее? Типа того. Завтра допустим вам срочно захочется (ну может послезавтра) добавить какое-то исключение либо что-то экстренно зафильтровать, а там "ы"? В такой ситуации жертвовать логичностью и предсказуемостью one.pass и рассматривать нетривиальные схемы прохождения фаера без него - не комильфо. Да, должно работать. Но если по DHCP на внешний интерфейс, вы получаете один и тот же 192.168.1.70 на который надеялись в ранних постах, то какой смысл? Кстати да, с двумя интерфейс

Тогда это уже будет не дешевым пафосом, а социально полезной деятельностью. Как такое себе позволить?

add 1 deny all from any to any dst-port 42111 via re0 А как вы будете получать netflow с удаленных NAS? Вобще хорошим practice в таких случаях считается оставлять в начале хоть немого зазора, для описания исключений. Вам же не жалко номеров правил? Статика и предсказуемость - наше все В принципе работает, но в таких случаях думаю логичнее рисовать NAT по интерфейсу и исходя из to me а не статической айпишки. Незачто, обращайтесь. https://aur.archlinux.org/packages.php?ID=22384

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

Для этого потребуется изменение формата структуры данных - что очень нехорошо. Если заявку выполняет несколько человек, допустим бригада монтажников пошла на подключение то задание формируется на "бригадира Сашу" а "монтажник Вася" и "стажор Петя" ему помогают. После выполнения задания, допустим подключения - работа оформляется уже в модуле "Работы" профиля пользователя которого они подключили. Итого получаем следующую картину в отчете по работам: Из чего понятно что они подключили пресловутое "Бандеры 11/1" а судя по картине планировщика задач: Понятно, что "бригадир Саша

ага, КС туда еще и l2j в догоночку Ой не скажите, не скажите - можете бегло просмотреть соседние топики и прикинуть основной контингент. Как application server в роли бекенда он вполне себе ничего так справляется. Не гигабитами же от него требуется отдавать контент на таких задачах. Много статики тоже нету, чтобы сильно заморачиваться с нгинксом на бекенде. Увы. Могу гарантировать, что если и взлетит то очень фигово и ненадолго. Как минимум, вся та пародия на секурность которая сейчас присутствует - держиться на mod_rewrite. Можно конечно переписать вагонище рулесов для нги

С точки зрения секурности - это хорошее решение. По умолчанию этого не сделано поскольку нету гарантии, что сам ubilling и такие штуки как userstats, uhw и чего там еще есть будут находиться на одном хосте со старгейзером. Не должно просто так. По умолчанию вебморда пытается соединяться с хостом указанным в опции STG_HOST конфига billing.ini которая бай дефолт смотрит на localhost, тобишь lo0.