несколько вопросов и предложений.
Добавлено: Чт янв 10, 2008 7:17 pm
всем привет. сразу хочу передать привет... то есть поблагодарить автора за сей нелегкий, но полезный труд.
имеется циска 3650 (сорри, наврал, 2851. add 24.01.08), юзается в основном для раздачи впн. подключение к радиусу и биллингу прошло без проблем. отредактировал только ф-ию сброса юзера. тут уже говорили, что rsh больше нагружает машину, чем smtp, но в предложенном варианте сброс по smtp требует запущенного фингера, что не есть хорошо. да и сама операция состоит из большого кол-ва команд. заюзал сброс по айпшнику, который из диапазона циски.
во-первых чуть поменял в nas.pm ф-ию вызова сброса:
elsif ($nas_type eq 'cisco') {
hangup_cisco($NAS, $PORT, { USER => $USER }, $attr);
}
и часть ф-ии hangup_cisco() которая скидывает по snmp:
my $userIP = $attr->{FRAMED_IP_ADDRESS};
$command = "$SNMPGET -v1 -c $SNMP_COM -Ov $NAS->{NAS_IP} .1.3.6.1.2.1.4.21.1.2.$userIP | awk '{print \$2}'";
log_print('LOG_DEBUG', "$command");
my $INTNUM=`$command`;
$INTNUM =~ s/\n//;
$command = "$SNMPSET -v 1 -c \"$SNMP_COM\" $NAS->{NAS_IP} 1.3.6.1.2.1.2.2.1.7.$INTNUM i 2 > /dev/null 2>&1";
log_print('LOG_DEBUG', "$command");
$exec=`$command`;
причем awk '{print \$2}' наверное можно заменить чем-нибудь перловым, но я не обладаю еще такими познаниями ;) в итоге всего 2 вызова snmp утилит.
да, и определение переменных $SNMPSET и $SNMPGET перенес в config.pl, ибо незачем каждый раз определять их месторасположение, да и пути у всех разные.
далее, пытаюсь реализовать довольно простую схему: есть несколько тарифов с ограниченным дневным входящим траффиком. типа 10, 20, 50, 100, 200, 500, 1000 Мб в день. при указании в тарифе только лимитов на объемы столкнулся с тем, что отключения юзеров не происходит при превышении заданного траффика, ни при алайвах, ни при запуске billd.pl. тоже многие сталкивались, однако сброс юзеров с отрицательным балансом происходит безпроблемно, при каждой отработке этого самого billd.pl, который у меня запускается раз в две минуты.
решил пойти по легкому пути ;) а именно: сделал тарифы с ценой входящего траффика 1 руб за метр, создал юзеров, добавил им на счет по 10, 20, 50, и тд рублей, чтобы ограничение происходило на уровне депозита, который хоть и не отображается в реальном времени, но подсчитывается точно (зависит, ессно, от частоты запуска billd.pl). дневные и недельные лимиты по входящему траффику все-таки оставил, ибо по ним происходит удержание черезчур качающих юзеров, которые умудрялись за эти две минуты израсходовать весь недельный запас ;)
однако далее поджидал неприятный сюрприз. ежедневное снятие абонплаты предусмотрено, а вот начисление, увы, нет. то есть задумка была такая: каждую ночь всем юзерам согласно их тарифам капала бы денежка на следующий день, без всяких сохранений оставшегося баланса. но отрицательная абонплата не срабатывала.
немного поковырявшись в базе, изменил значение поля day_fee, чтобы оно могло принимать отрицательные значения, но вот дальше дело не пошло, ибо ф-ию, которая отрабатывает из pereodic daily с наскоку не нашел.
вот теперь вопросы:
1. как можно сотворить такой тарифный план с минимальнвм вмешательством в код? пока что на ум приходит только внешний скрипт, который будет вместо pereodic daily запускаться, брать абонплату у каждого юзера и делать update его депозита.
2. в каких случаях запускается logrotate, который, судя по коду должен вычищать архивируемые записи из таблицы s_details? (видимо для ее разгрузки).
3. очень хотелось бы увидеть сортировку во всех выпадающих списках, ибо пока она работает только при выборе компании.
4. при создании нового юзера привязать его к группе можно сразу, а вот к компании только после нахождения этого юзера в общем списке. причем групповые операции позволяют менять группу, а кампанию нет, что тоже обидно. вобщем, хотелось бы создавать юзера за один заход.
5. при просмотре списка групп при щелчке на кол-ве юзеров попадаем в список юзеров только этой группы, а при аналогичном действии в списке компаний - попадаем в параметры самой компании, и чтобы увидеть всех ее юзеров нужно щелкать еще раз. да и ссылка дублируется, в колонке "пользователи" и в "информация" один и тот же
нашел таки ;) index.cgi, line 695:
$html->button($line->[3], "index=13&COMPANY_ID=$line->[5]&subf=11"),
6. ф-ия sendmail() из Base.pm пытается отработать даже если в config.pl рассылка писем запрещена.
немного сумбурно, но все же.
имеется циска 3650 (сорри, наврал, 2851. add 24.01.08), юзается в основном для раздачи впн. подключение к радиусу и биллингу прошло без проблем. отредактировал только ф-ию сброса юзера. тут уже говорили, что rsh больше нагружает машину, чем smtp, но в предложенном варианте сброс по smtp требует запущенного фингера, что не есть хорошо. да и сама операция состоит из большого кол-ва команд. заюзал сброс по айпшнику, который из диапазона циски.
во-первых чуть поменял в nas.pm ф-ию вызова сброса:
elsif ($nas_type eq 'cisco') {
hangup_cisco($NAS, $PORT, { USER => $USER }, $attr);
}
и часть ф-ии hangup_cisco() которая скидывает по snmp:
my $userIP = $attr->{FRAMED_IP_ADDRESS};
$command = "$SNMPGET -v1 -c $SNMP_COM -Ov $NAS->{NAS_IP} .1.3.6.1.2.1.4.21.1.2.$userIP | awk '{print \$2}'";
log_print('LOG_DEBUG', "$command");
my $INTNUM=`$command`;
$INTNUM =~ s/\n//;
$command = "$SNMPSET -v 1 -c \"$SNMP_COM\" $NAS->{NAS_IP} 1.3.6.1.2.1.2.2.1.7.$INTNUM i 2 > /dev/null 2>&1";
log_print('LOG_DEBUG', "$command");
$exec=`$command`;
причем awk '{print \$2}' наверное можно заменить чем-нибудь перловым, но я не обладаю еще такими познаниями ;) в итоге всего 2 вызова snmp утилит.
да, и определение переменных $SNMPSET и $SNMPGET перенес в config.pl, ибо незачем каждый раз определять их месторасположение, да и пути у всех разные.
далее, пытаюсь реализовать довольно простую схему: есть несколько тарифов с ограниченным дневным входящим траффиком. типа 10, 20, 50, 100, 200, 500, 1000 Мб в день. при указании в тарифе только лимитов на объемы столкнулся с тем, что отключения юзеров не происходит при превышении заданного траффика, ни при алайвах, ни при запуске billd.pl. тоже многие сталкивались, однако сброс юзеров с отрицательным балансом происходит безпроблемно, при каждой отработке этого самого billd.pl, который у меня запускается раз в две минуты.
решил пойти по легкому пути ;) а именно: сделал тарифы с ценой входящего траффика 1 руб за метр, создал юзеров, добавил им на счет по 10, 20, 50, и тд рублей, чтобы ограничение происходило на уровне депозита, который хоть и не отображается в реальном времени, но подсчитывается точно (зависит, ессно, от частоты запуска billd.pl). дневные и недельные лимиты по входящему траффику все-таки оставил, ибо по ним происходит удержание черезчур качающих юзеров, которые умудрялись за эти две минуты израсходовать весь недельный запас ;)
однако далее поджидал неприятный сюрприз. ежедневное снятие абонплаты предусмотрено, а вот начисление, увы, нет. то есть задумка была такая: каждую ночь всем юзерам согласно их тарифам капала бы денежка на следующий день, без всяких сохранений оставшегося баланса. но отрицательная абонплата не срабатывала.
немного поковырявшись в базе, изменил значение поля day_fee, чтобы оно могло принимать отрицательные значения, но вот дальше дело не пошло, ибо ф-ию, которая отрабатывает из pereodic daily с наскоку не нашел.
вот теперь вопросы:
1. как можно сотворить такой тарифный план с минимальнвм вмешательством в код? пока что на ум приходит только внешний скрипт, который будет вместо pereodic daily запускаться, брать абонплату у каждого юзера и делать update его депозита.
2. в каких случаях запускается logrotate, который, судя по коду должен вычищать архивируемые записи из таблицы s_details? (видимо для ее разгрузки).
3. очень хотелось бы увидеть сортировку во всех выпадающих списках, ибо пока она работает только при выборе компании.
4. при создании нового юзера привязать его к группе можно сразу, а вот к компании только после нахождения этого юзера в общем списке. причем групповые операции позволяют менять группу, а кампанию нет, что тоже обидно. вобщем, хотелось бы создавать юзера за один заход.
5. при просмотре списка групп при щелчке на кол-ве юзеров попадаем в список юзеров только этой группы, а при аналогичном действии в списке компаний - попадаем в параметры самой компании, и чтобы увидеть всех ее юзеров нужно щелкать еще раз. да и ссылка дублируется, в колонке "пользователи" и в "информация" один и тот же
нашел таки ;) index.cgi, line 695:
$html->button($line->[3], "index=13&COMPANY_ID=$line->[5]&subf=11"),
6. ф-ия sendmail() из Base.pm пытается отработать даже если в config.pl рассылка писем запрещена.
немного сумбурно, но все же.