vop

Что ж так не везет этой фре Все ж таки, какой способ счета трафика для фри лучше?

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

Я считаю Ну я сижу в сети с несколькими шлюзами. Но если мне какая-нить программка начнет прописывать шлюз... я пойду надаю по лицу автору такой программки Ну, спамиться никогда не вредно

Давно тут не был. Надеюсь, тебе уже где-нибдуь ответили на вопрос: man pwconv

Критическое число?

До чего людей дядя билли доводит Тебе надо: 1. Примонтировать новый винт, предварительно его разбив так, как ебе надо. 2. Скопировать содержимое старого диска на ковый, например, при помощи команды "/bin/cp -av" 3. Установить на новый диск загрузчик, который у тебя используется. 4. Пометить загрузочный раздел нового диска активным. 5. Поставить новый диск мастером.

Ну под линуксом, в принципе, тот же arp -s IP MAC pub Но в любом случае, это не панацея. Панацея одна - отключение порта на свиче. Любым способом, включая монтера

А в чем особенности подсчета трафика ВПН? В чем отличие от подсчета другого трафика?

Вот это действительно нада.... или хотябы полноценного подсчета на divert'e Давно бы было пора разнести коллектор трафика и подсчет денег в разные модули/подсистемы. Просто попытка все слить в один флакон оборачивается сильными ограничениями и потерей гибкости конфигурирования.

А мы своим собственным пользуемся Пока никто не жалуется

Либо настроить SNAT, либо у провайдера настроить роутинг твоей сетки на твой сервер.

А что, STG разве не блокирует неплательщиков? Я думал, что блокирует. Ну по поводу самого скрипта. Совершенно зря ты все делаешь в корневой цепочке INPUT. Это iptables, а не ipchains. Лучше сделать селектор в INPUT, FORWARD, из которого вызывать отдельную цепочку. Тогда будет и проще работать, и меньше нагрузки на фильтр, и управлять проще. Например, если есть список тех, кому разрешено работать, то при изменении статуса платежа какого-либо клиента, простой скрипт сносит цепочку нафик, и тупо строит заново, возвращая разрешенных клиентов, и запрещая всех остальных. У меня, например, для этих целей служит такой скрит на шелле: #!/bin/sh ############################################################################## # TopolA MS, Copyright © 2006, Oleg Vlasenko ############################################################################## # User configuration data CLI_NET="172.16.0.0/24" # SYS_ADR1="172.16.1.25" # SYS_ADR2="172.16.1.26" # SYS_ADR3="172.16.1.27" ############################################################################## # Filenames of allow list RESLISTDIR=/usr/local/accnt/conf ALLOWLIST=$RESLISTDIR"/internet.allow" ############################################################################## # Bocking chain name ACT_CHAIN="active" ############################################################################## # Set iptables variable IPT=${IPT:-`which iptables`} if [ $? != 0 ]; then echo Can not find iptables command exit 1 fi ############################################################################## # Check if we have "allow list" file. if [ ! -f ${ALLOWLIST} ]; then exit 0 fi ############################################################################## # Let's check if chain "active" exists. If so, flush it, else create a new one $IPT -F $ACT_CHAIN >/dev/null 2>&1 if [ $? = 1 ]; then $IPT -N $ACT_CHAIN $IPT -I FORWARD -s ${CLI_NET} -j $ACT_CHAIN fi ############################################################################## # System addresses - should work always # $IPT -A $ACT_CHAIN -s $SYS_ADR1 -j RETURN # $IPT -A $ACT_CHAIN -s $SYS_ADR2 -j RETURN # $IPT -A $ACT_CHAIN -s $SYS_ADR3 -j RETURN # Add allowed addresses from accnt /bin/cat $ALLOWLIST | while read Res; do $IPT -A $ACT_CHAIN -s $Res -j RETURN done # Rest of customer IP should be rejected $IPT -A $ACT_CHAIN -j REJECT --reject-with icmp-host-unreachable ############################################################################## Файл internet.allow содержит список IP клиентов, которым разрешено работать. Скрипт запускается регулярно из крона раз минут в 5. Список создает специальная тулзовина. В принципе, не сложно написать такую тулзовну и под старгейзер.

Здасте Вася я снялася, здрасте елка новый год. Или блондин или латыш. Мдя... Вроде как вы предлагаете мне, как потенциальному клиенту, коммерческую услугу. И вроде как я нахожусь практически в зоне обслуживания. Захожу на сайт, и что я вижу? Snake Oil signed сertificates Вот теперь сижу, и думаю, а стоит ли? Может и к остальному такое же отношение?

Идея гарантированного сохранения данных была описана еще в 70-х, если я не ошибаюсь. На то она и гарантированная, что бы данные не пропадали. Хоть и примитивная по сути. Даже на ассинхронной системе после сбоя ты либо получишь новые данные, либо у тебя останутся старые. Но в любом случае не файл нулевой длины.

Господа, а не проще ли попросить автора переписать процедурку записи данных, добавив туда... эээ.... 4-5 строчек, что бы получить запись с гарантированным сохранением данных, вместо того, что бы устраивать массовые танцы с бубном по постоянному спасению стата?

Пользуемся встроенными в кернелы.

Разумеется возможен. И более того, девочке кассиру не надо пакет выбирать для клиента - он сам выбирает. К тому же некоторые провы уже и девочку-кассира ликвидировали - просто карты продают в магазинах и киосках района. Клиенты сами платят картами, сами себе пакеты выбирают. Только настройкой серверов доступа вам придется заниматься самостоятельно. В данном случае, шейпером. Биллинг будет выдавать любые эвенты серверу доступа, и любую необходимую информацию, достаточную для управления сервером доступа. Вся обвязка двется в виде сырцов. Но сам я лезть туда не хочу. Настройка серверов остается за админом.

Вопрос не в том, можно ли так сделать, или нет. Сделать можно, и не обязательно через финансовые евенты. Можно использовать и ресурсные евенты, такие-как количество трафика, время суток и т.д. Вопрос в другом - это единственная цель топикстартера, которую он преследует? Если единственно, что ему требуется, сделать квотированную безлимитку, то биллинг тут вообще не причем. Можно и забор запорожцем подпирать - но нужно ли для этого покупать запорожец? А вот если вопрос стоит немного по другому - как сделать, что бы, наряду со всеми стандартными, была возможность учитывать и такую услугу тоже - то это уже вопрос биллинга, который способен учитывать разный тип услуг.

Давай разберемся. Биллинг не занимается тем, что делает клинту услугу. Услугу клиенту делает администратор. Роль любого биллинга - учет предоставляемых услуг. Причем учет производится путем перевода количественных показателей услуги в финансовый эквивалент. Вторая задача биллинга - выдача управляющих сигналов внешнему окружению, как результат финансовых евенов (событий). Т.е. изменение баланса на какую-либо величину, преодоление порога и т.д. Давай посмотрим твой случай. Ну во первых, тебе самому придется решать вопрос, при помощи каких именно средств ты будешь устанавливать клиенту ограничение скорости (имеется ввиду шейпер). Во вторых, как я понял, в ствоем случае финансовый эвент не наступает. Т.е. клиент заплатил денег, и все - 2 гига потрачено, но на счету у клиента нет никаких изменений и шевелений. Так-что в принципе, можно добавить фиктивный финансовый евент, типа, считать трафик в деньгах, добавляя одновременно эти же деньги клиенту. Это уже похоже на двойную бухгалтерию какую-то Сделать можно, но значем? Что тебе надо для решения твой задачи? Во первых, коллектор трафика (в любом виде его реализации). Во второых - монитор трафика с функциями контроля и шедуллинга. Вот при помощи этого ты и решишь эту задачу. Ну если еще при этом тебе надо будет подсчитать денежку, вот тут уже тебе биллинг и подойдет. Но биллинг - это подсчет денег. Это не программа, которая заменит администратора

Я его пользую. Но я, вроде как, лицо заинтересованное. Задавай вопросы - отвечу.

Все-таки, не спора ради, но мне хочется разобраться, что именно происходит в наши времена. Поэтому хочется уточнить два вопросика: 1. О каких именно сторонних приложениях идет речь? 2. В чем заключатеся простота доступа к мускулю с неизвестной структурой данных, в отличие от сложности доступа к данным старгейзера с полностью прозрачной структурой данных? Пока я знаю один ответ на этот вопрос - полная неквалифицированность программера, который наивно верит, что единственный язык программирования- это ПХП, а единственный способ хранения данных - это мускуль (ну как в книжке про "ПХП за 5 минут"). Возможно есть какие-либо другие аргументы, которые мне не известны? Очень бы хотелось их понять.

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

Я не совсем понимаю, откуда такое требование может возникнуть, хотя догадываюсь (дилетанство + книжка "ПХП за 5 минут"). В чем проблема поставить биллинг, который хранит данные в мускуле? Тут уж выбирать надо требования к биллингу - либо фичи биллинга, либо "хочется, что бы хранил данные, как мне надо".

Я никак не могу уловить одну ускользающую от меня деталь. А именно, почему и каким боком авторизация должна быть связана со статистикой? А что мешает сделать ЦЖИ-скриптик, который будет открывать и закрывать доступ клиента? Какая проблема? При чем тут биллинг? Пусть биллинг считает байты, а скрип открывает доступ.

Хммм... Ну ты уж выбирай, что тебе надо, старгейзер или мускуль