Wapr-Old

Решил таки выложить обновлённую версию скрипта, но посмотрев на объём :-0 , решил ограничиться заголовком и ссылкой. #!/bin/sh #Этот скрипт вызывается в момент, когда пользователь #успешно прошел авторизацию в биллинге. Задача скрипта - перестроить #файрволлы так, чтобы пользователь получил доступ в интернет # ©2003-2008 Wapr Old. Ver 3.3 (04.2008) #0. Умолчания: До запуска биллинга должна быть создана цепочка BILL # с последним правилом -j DROP и в неё должны отправляться все пакеты # для которых необходимо управление доступом. (как минимум из FORWARD) # и запрос на прокси. # например т

И вообще, есть прекрасная книга от О'Релли, называется "Юзинь самба" Там всё настолько разжёвано и по шагам расписано, что даже я понял, настроил и всё работает уже который год. :tongue:

Не "всех", а "у всех". Почувствуйте разницу (с) -

Дать доступ и обеспечить видимость ресурса - это две большие разницы. Первую задачу решает smbd, вторую nmbd. Делаешь самбу мастербраузером в локалке, у всех юзверей прописываешь wins и с этого моменты сетевое окружение работает как часы. # Domain Logon Services domain master = yes preferred master = yes local master = yes domain logons = no os level = 255 # WINS & DNS service wins support = yes ...

Правильно говорит пословица: обещанного 3 года ждут. Только Вы EvgeniyS чуть поторопились, до 3х лет ещё неделя осталась

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

ftp-data 20/tcp File Transfer [Default Data] ftp-data 20/udp File Transfer [Default Data] ftp 21/tcp File Transfer [Control] ftp 21/udp File Transfer [Control]

на ID надеяться нельзя, т.к. это дело не было ни разу специфицировано. Видимо сугубо внутренняя служебная переменная. Запуска OnDisconnect-OnConnect при смене тарифа мне добиться от авторов не удалось Скоро выложу ещё более продвинутую версию с DNAT

Наверное лучше будет так разрешить $IPTABLES -t nat -A POSTROUTING -i $iface_lan -o $iface_wan -j SNAT --to-source $ip_wan Или хочется для каждого юзера отдельно писать такое правило? А смысл? Набери route -n и посмотри дефолт гейтвей, я не вижу, где это прописывается. Да и не только дефолт... А вообще посмотри сюда http://local.com.ua/forum/index.php?showtopic=2020

Всё это хорошо, но где правила, пускающие клиента в инет? (и потом, я мож не совсем копенгаген в iptables, но для маскарада я бы указал конкретный входной и выходной интерфейсы, а не все подряд адреса)

Если уж делать такое, то в цикл надо обязательно влепить команду записи в лог, т.к. срабатываение этого цикла однозначно свидетельствует об ошибке в настройке системы.

Ну почему? Мы тут обсуждали это дело, но к чему это приведёт, мне неведомо...

В общем случае - никак. Если я не подключаюсь, у меня может быть любой IP, в том числе тот, которого вообще нет в биллинге. Даже если есть, при наличии клиентов с несколькими разрешёнными IP, поиск по базе может не дать однозначного соответствия. И только если все клиенты имеют строго по одному IP, возможен поиск по базе. (но тогда это тривиальный парсинг файлов /var/stargazer/users/*/conf, или вопрос не об этом?)

Что есть неактуальное сообщение? Сообщение которому больше чем N дней? Если так, то сделать можно. Не совсем так, это сообщение, в котором просрочен срок его отправки клиенту, а не просто Н-ное количество дней. Срок должен содержаться в виде структуры данных в служебных полях самого сообщения чтоб можно было при отправке задать например: это сообщение действительно ближайшие (X часов|сутки|неделю|и т.п.), потом уже неактуально и отправлять его клиенту не надо, или - это сообщение клиент получит в любом случае, как бы поздно он не подключился.

Например у юзера нет денег... упс... опередили

Может он имел в виду ширину канала после зажатия шейпером? ...впрочем всё равно это к биллингу не относится.

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

Ага, плюнь, только вот потом деньги в никуда уйдут или ещё чего нибудь случится...

Для этого у администратора есть почта (ИМХО). А вот передача хотя-бы одного текстового параметра при авторизации действительно вещь стоящая. Ничего с ним не делать, просто транслировать в OnConnect, а там пусть скрипт разбирается.

Уже было. Ждём-с...

Ну если посмотреть, что я писал ранее, можно заметить, что я упоминал и красивое решение Т.е. дополнить профайл именем и в списке выводить именно его. Красивей не бывает :tongue:

Это тянет на future request, но в примерно такой формулировке: Ввести в сервер понятие "событие" (если его там ещё нет) и сделать вызов скрипта например OnEvent с передачей ему параметров события. А под событием в частности понимать достижение отдельно установленного(ых) порога(ов) трафика по каждому из направлений. Возможно ещё какие-то критерии, которые сервером проверяются, но сейчас не выводятся наружу.

В логах биллинга? Не дай Бог!

Странно это всё... сейчас посмотрел прошлогодние логи, когда мою сетку подобные вирусы мучали, отмечалось до 20000 запросов в 10-минутный интервал и свыше 100000 за сутки, но ничего не падало и жалоб на тормоза не припоминаю. Правда лог юзера при этом достигает 10Мб :rrr: Может Ваш сервер перегружен посторонней работой или неаккуратно сконфигурирован? -> 23.50.00 - 00.00.00 2.69.92.90 0 0 96 0.000000 2.82.82.154 0 0 48 0.000000 4.79.62.232 0

Всё упирается в "направления", описанные в файле rules. Сумеете написать набор адресов, привязанный например к DIR1 и покрывающий все подсети на eth1 - можно будет и тариф сделать с подсчётом только DIR1. Аналогично и для остальных интерфейсов. А вот привязаться непосредственно к устройству к сожалению нельзя. (ver 2.xx)