Wapr-Old

В новой версии не нашлось места для механизма удаления неактуальных сообщений. Жаль. Будем подождать ещё...

Как обычно, я хочу предусмотреть всё :argh: Но на эту мысль меня навёл Ваш-же скриншот, на котором можно увидеть список с повторяющимися IP адресами. Очевидно, что порты при этом разные, но их в списке не видно. Всё, аллес капут На самом деле у меня была ситуация, когда я запускал 2 биллинга на одном сервере, правда с целью отладки, но всё равно не хочется из за ерунды, не предусмотренной сегодня, влететь на проблемы завтра

Щас будем вместе въезжать =) ИМХО в профайле каждая запись соответствует одному экземпляру биллинга, а по сути сокету TCP/IP, но в списке, который вываливается, не сокеты, а только хосты. И поскольку имён у записей видимо не предусмотрено, по этой информации опознать конкретный экземпляр биллинга в общем случае невозможно. Либо надо показывать в списке и порт (10.10.0.1:5895) либо предусмотреть имя и выводить его.

Неувязочка с профайлами. Судя по картинке профайл соответствует не хосту, а именно экземпляру биллинга, но по списку их не отличить, т.к. виден только адрес хоста. Исправляйте скорей

Можно

При первом же запуске 2 получается или только при запуске с предварительно упавшим предыдущим старгазером? Что-то попадает при этом в stgkrash.log? И замени ps awxu |grep stargazer|awk '{print $2;}' на ps ax |grep stargazer | cut -f1 -d" " Так ведь проще пид получить и быстрее. Зачем с awk связываться?

Думаю, что повремёнка в 2006 году - это из разряда патефона, если только Вы не имеете такого "продвинутого" провайдера := А галочка в авторизаторе это вообще на грани фола... почему бы тогда не дать там полный список тарифов и пусть юзер их переключает как хочет =)

Респект! По пункту С14: Сейчас пишу особоизвращённую систему скриптов управления нетфильтром и всё больше убеждаюсь в его необходимости, т.к. я думал влепить необходимые изменения в OnChange, но есть 2 проблемы - этот скрипт не получает IP изменяемого юзера (что естественно, т.к. он может быть офлайн) и неизвестность в смысле того, а не может ли этот скрипт оказаться запущеннным одновременно с каким-либо другим из OnConnect/OnDisconnect другого юзера. Чревато конфликтом. PS: Доработал скрипты для чернового решения проблемы смены тарифа. Кроме того добавил оптимизацию. тут

Макс, ты в веб технологиях рулишь? Нет? Тогда воспользуйся добрым советом чтоб народ не мучать К тому-же ты мог ошибиться в именах, а как страничку нарисуешь, это сразу заметно станет.

Даже если картинки реально выложены, так давать ссылки на народ нельзя. Они блокируют прямые обращения к файлам. Надо положить там хтмл и в нём дать эти ссылки.

эээ... ну... а, ну да.... шелла нет... убили значить а дальше? всё равно без шелла не запустить. хм... интересная ситуация должно быть

Всегда хотел спросить по пункту К4, но не решался :-(=) Зачем нужен релоад, я понимаю, а вот зачем нужен стоп и как его применить можно... не понимаю Ведь после этого старт будет давать некому. Ещё... К6.а: Да, этого давно ждали и мне лично большего не надо, но ведь если клиентов не 2 3 десятка, а 2 3 сотни, такой механизм теряет практический смысл. Ближе к идеалу было бы выделение клиентов прямо в главном окне (это ведь тоже список, причём сортируемый. Главное, чтобы при изменении сортировки текущее выделение не сбрасывалось, хотя как это сделать, я не скажу), а если мечтать о несбы

Это можно реалиховать в скриптах управления файрволом А это я бы делать не стал, т.к. если трафик может считаться в минус, его можно накачать сколько угодно и не заплатить потом. Проще кредит поставить... ВО! ИДЕЯ!! =:-/ future request: Если юзер перешёл к использованию кредита, он должен (при нахождении онлайн) периодически получать от сервера автоматические сообщения о необходимости его погашения. Например раз в час или около того. Например параметр CreditReminder=<кол-во секунд между повторами> если=0, не напоминать. Точнее напомнить 1 раз, при авторизации.

Продвинутая версия управления через iptables OnConnect: #!/bin/sh #Этот скрипт вызывается в момент, когда пользователь #успешно прошел авторизацию на сервере. Задача скрипта - перестроить #файрвол так, что бы пользователь получил доступ в интернет # ©2003-2006 Wapr Old. Ver 3.0 #Умолчания: При запуске сервера должна быть создана цепочка BILL # с последним правилом -j DROP и в неё должны отправляться все пакеты # для которых необходимо управление доступом. (как минимум из FORWARD) # например так: # iptables -A FORWARD -i $WAN -o $LAN -j BILL # iptables -A FORWARD -i $LAN -o $WAN -j BILL

2 Max Да, конечно опцией, т.к. надо только при привязке параметров нетфильтра к параметрам тарифа юзера. Мне вот впервые за более чем 3 года понадобилось 2 Sonnar По неудалению правил: давай зададимся вопросом - что более надёжно работает - netfilter+iptables или stargazer? Ответ имхо очевиден. Поэтому описанная ситуация может возникнуть только при ошибках в установке системы или сбоях в железе, а тогда как можно вообще это эксплуатировать? С 2003 года у меня стоят простые правила добавления/удаления, без всяких циклических проверок и сбои такого рода возникли всего 1 раз именно при гл

Future request: Можно ли сделать так, чтобы перед переводом юзера с тарифа на тариф, биллинг сначала его отключал принудительно, а затем подключал уже по новому тарифу? Сейчас возился с новыми анлимными тарифами и столкнулся с неприятной особенностью, которая раньше у меня не проявлялась и с которой вообще мало кто видимо сталкивался. Я ввёл несколько тарифов по образцу: anlim_50, anlim_70 и т.п. При этом число в имени тарифа используется при задании параметров netfilter для ограничения скорости. И всё вроде работает за исключением того, что перевод с тарифа на тариф тех, кто online, вызы

Фантазии... Допустим я имею 2 канала в инет для целей надёжности и хочу как то распределить трафик чтобы резерв не простаивал. В медленный резервный канал я пущу например аську и почту, а остальное в основной. При этом я даю юзерам тариф, в котором имеется сколько то БМ (в общем). Ещё я хочу разделить подсчёт аськи и почты по разным направлениям. И ещё хочу (помня о том, что по аське можно и файлы гнать без ограничения), чтобы резервный канал не был забит трафиком вусмерть. И ещё поскольку почтовый сервис - отдельная (теоретически) услуга, хочу дать на него некое гарантированное количеств

Спасибо :tongue: На самом деле я исхожу из того, что сделать схему, которая разрешит только нужные комбинации и при этом будут разрешены все нужные и запрещены ненужные гораздо сложнее, чем схему, просто разрешающую всё необходимое. А если при этом образуются бесполезные на первый взгляд комбинации, так ведь можно их просто не использовать. Правда? Тем более, что эти комбинации не являются чем то неправильным, багами или бэкдорами с точки зрения логики рассчёта трафика. Ох не люблю я этот виндовозный принцип, когда элемент управления в гуях не соответствует его логической сущности

Ну вот пошёл предметный разговор. Это приятно. 2 XoRe Конфиги как раз фигня, это самое простое и последнее в нашей проблеме. А зачем БМ считать как деньги если они именно Бесплатные Мегабайты? 2 Max На мой взгляд было внесено лишнее усложнение в виде верхних вентилей. Поясню на примере среднего канала вашей схемы: есть 3 параметра управления - верхний вентиль, размер бачка и нижний вентиль. При указанном положении верхнего вентиля размер бачка никак не влияет на работу канала и => его можно принять = 0. При переключении верхнего вентиля и размере бачка = 0, работа канала

Ну ладно, Вот моя последняя отчаяная папытка

Так я бы может и поспорил, но не вижу с чем. Нет внятного описания Вашей модели. Может они нормальная, но я её не видел

а чуть ранее... Вы там как нибудь договоритесь между собой, чего же он все таки хочет :argh: Я отвечал на поставленный вопрос, а не на подразумеваемый. Если он хочет просто 25 на все направления оптом, то это тривиальный случай, реализованный в текущем биллинге. Не понимаю, зачем тогда напрягать программера? Это да, но если так сделать, мало кто сумеет заюзать полученную гибкость. Ибо не все тут программисты. Так рассуждать неправильно, т.к. понятие "тариф" в существующей версии отличается от того, о чём мы говорим. А понятие "направление" вообще имеет 2 смысла даже сейчас: 1. DIR в

Ладно, попытаюсь объяснить моё видение процесса (но писанины будет много). Умолчания: 1. Под направлениями биллинга я понимаю именно то, что забито в биллинге. Т.е. совокупность правил фильтрации пакетов. Всё. 2. Под направлением тарифа я понимаю совокупность правил, флагов и полей, привязанных к конкретному направлению биллинга. 3. Когда я говорю о направлении, я всегда говорю о п.2 Теперь ответы: а. В данном случае я не буду делить ничего. Просто при создании тарифа "Эконом" будет указано, что его абонплата=80руб. , а на направлении 1 имеется 25Мб БМ. Это всё записано в определ

Я заметил Честно говоря не вижу принципиальных отличий от моего предложения, за исключением того, что моё гибче. Или гибчее Почему наличие глобальных БМ должно отключать локальные БМ? И если хочется реализовать подобную логику, по моей системе достаточно не задавать локальные БМ. Результат будет аналогичный. Единственный вариант, который у меня не реализуется, такой: есть 3 направления А Б В. Направление А - суть отдельный канал, а Б и В - другой канал, но например http и ftp. И мы хотим, чтобы при наличии глобальных БМ и всех локальных БМ, при окончании БМ из направления А глобальные

Не понял. Честно. Как можно задать глобально и несколько? Тоже как то не вполне врубился... В общем есть преложение, подкупающее своей простотой. -) Всё решается путём ещё большего упрощения алгоритма. Что мы имеем по структуре объектов? Базовая единица - объект "направление", от него порождаются объекты "тариф", от которого объект "биллинг". Т.е. надо породить одно из другого и в базовом объекте заложить поле БМ. Тогда БМ будет в всех объектах, а метод, вычитающий трафик из поля БМ будет просто передавать наверх остаток трафика, который образовался при обнулении счётчика БМ объек