Мысли про..

[suxer]

Началось у меня очередное обостренние по подщету трафика и управлению юзверями, и начал я значится искать нечто новое..

Что имею:

1. Циска на входе, нат, нетфлов, аккаунтинг присутствуют.

2. Фря с интерфейсом на циску и вланами на втором(чтобы клиенты друг другу вирусов не пускали).

3. Кучка управляемых 3комов с вланами.

4. Отдельно стоит сервачек с линухом для биллинга с УТМ5.10(чеснотыреная), статистика принимается по нетфлоу, отключение юзеров на циске через rsh.

5. Юзеры как единичные, так и целые подсетки до 20 компов.

 

 

Чего значит захотелось:

1. авторизацию юзеров через утилитку в которой присутствует отображение трафика на данный момент и остаток денег.

2. перемещающиеся профиля для отдельных юзеров (как в подсетке так и по всем клиентским машинам).

 

Чего НЕ хочется - переходить на различные варианты впн, потому что:

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

 

Почему это нельзя реализовать на УТМ:

авторизатор чесно говоря там кривой и нового как я понял не придвидется или за бабло(причем немаленькое). В принципе можно написать свой, но это отдельный гемор. Перемещающиеся юзеры невозможны в принципе(вариант впн как я уже говорил не рассматривается).

 

На СТГ я наталкивался 2 года назад, но тогда небыло mysql в качестве базы, небыло вебморды. И вот сейчас опять наткнулся значит.

 

Что понравилось:

АФИГЕННЫЙ авторизатор, как раз то что я и хотел. Перемещающиеся юзеры.

Появился модуль нетфлова. Вебморда. Наконецто Мускл в качестве базы.

 

Всякие мысли:

Мускл поддерживается не нативно. Господа, забейте вы на файловую базу. Невижу ни одного плюса при ее использовании.

В качестве коллектора хотелось бы увидеть циско аккаунтинг, в принципе он несложен в реализации.

Хотелось бы чтобы сбор первичной статистики скидывался в какойнить осязаемый дамп. Причем желательно чтобы он предварительно парсился по временным промежуткам (чтото коряво я написал), вобщем если взять к примеру дамп "детальной статистики" в нетапе, там тупо записаны ип сессии. Я незнаю кому это нужно, но когда на 400 метров юзерского трафа получается 300-400 метров "детальной статистики" это слишком(можнобыло поминутно отпарсить). В принципе у вас как раз упрощеная деталька есть, но хотелось бы ее лицезреть в файле и иметь возможность в любой момент ее перенакатить в рабочую базу.

 

Что-то нужно придумать про работу с подсетями. Как сейчас сделано у вас не совсем красиво, например мне нужно чтобы считался трафик с диапазона, мне придется сделать на каждый адрес логин с привязкой к ип и выставить "всегда онлайн" или идти раздавать всем юзерам пароли. А в конце месяца суммировать трафик сьеденый всеми из этой подсети(насколько я понял группировка в группы у вас не работает, или вернее сказать ее нет). Это плохо по тому что я не могу ткнуть носом человека, что у него в подсетке начинается перерасход трафика. Опять же это плохо тем, что например на подсетку хотят 2 гига трафика на 5 человек, из которых 2 используют от 100до 300 метров, 2 по 500 и 1 все остальное. И эти значения всегда плавающие. Получается что если ограничивать каждого в отдельности, кому нибудь нехватит, а у второго останется. Я в принципе согласен что вопрос муторный, и в часности снимается организационными воздействиями. Но всеравно группы нужны, хотябы для банального суммирования наработаного трафика для отображения юзерам из этой группы.

 

Далее. Я не совсем понял в чем заключается модульность вашей системы, если каждый модуль для работы требует перекомпиляции основной системы. Почему не придти к некоторым знаменателям и поделить систему на некоторое число модульных конструкций. Например в УТМ и ланбиллинге сделано как, все коллекторы приводят входящую статистику к некоторому единому формату который потом употребляется основным ядром. Это например убирает надобность перекомпиляции ядра при каждом новом модуле коллектора. и т.д. и т.п.

 

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

 

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

 

Респекты:

Молоцы, что не бросаете начатое, правда за 2 года можнобыло и побольше написать

 

Алферову РЕСПЕКТИЩЕ. Когда я увидел что он написал, да еще и забесплатно, я чесно говоря был в шоке. Незнаю чем он на работе занимается но тот обьем работы который я вижу, у меня бы занял полгода. Кстати вопрос ты часом не из Барабинска?.

 

Мысли закончились, извините что так много и сразу.

[Колян]

В общем, насчет подсетей уже реализовано модульность? хм... Я без перекомпиляции ядра на мускуль спрыгнул Как обстоит с другими модулями, не знаю, не юзел..

[madf]

...

Мускл поддерживается не нативно. Господа, забейте вы на файловую базу. Невижу ни одного плюса при ее использовании.

...

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

От файлового хранилища отказываться вплоть до 3 версии не будем (да и там - еще не факт). Большой плюс Stargazer всегда был в том, что его практически не нужно настраивать. Для маленькой сетки нету смысла утанавливать СУБД - файлы и так все нормально хранят и их не нужно никак настраивать. Запустил - и оно работает.

 

Что Вы имеете в виду под "первичной статистикой" и какой смысл делать ее дамп?

По поводу подсетей - было много обсуждений тут на форуме - поищите, почитайте.

Модульность системы в ее модульности. Перекомпиляции ядра не требуется для подключения модуля.

За проверкой состояния ядра может следить какой-нибуть watchdog. Для этого несложно накатать простенький скрипт и засунуть его в cron.

"Заморозка" и отключение пользователя не влияет на его авторизацию в системе. Человек должен сам откючиться (авторизатором, например). Но в любом случае - проверю.

 

К сожалению, практически нету времени заниматься проектом. По этому разработка и багофиксы проходят так медленно.

[Колян]

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

Файлы... А что в мускуле настраивать надо? Доступ к базе? Модуль сам создаст базу данных и таблицы

[suxer]

Если несложно, опишите пожалуйста принцип работы ether_cap модуля.

Вот например я сейчас для проверки работоспособности стг прокинул со свитча трафик между серваком и циской на интерфейс сервера статистики, завел пользователей с включеной галкой "всегда онлайн". На интерфейсе весь этот трафик tcpdump ом видится, но попадают только какието случайные пакеты. Насколько помню netacct (и еще несколько трафикосчиталок ) такой трафик обрабатывает, а вот mod_cap_ether похоже нехочет.

 

Или он считает только что прошло через интерфейс?

Я нигде не смог найти описание логики его работы.

[vovksextra]

Могу порекомендовать модуль для Firebird - это полностью наша разработка и он поддерживается нами.

Поддерживаю выбор такой СУДБ )).

[madf]

Если несложно, опишите пожалуйста принцип работы ether_cap модуля.

Вот например я сейчас для проверки работоспособности стг прокинул со свитча трафик между серваком и циской на интерфейс сервера статистики, завел пользователей с включеной галкой "всегда онлайн". На интерфейсе весь этот  трафик tcpdump ом видится, но попадают только какието случайные пакеты. Насколько помню netacct (и еще несколько трафикосчиталок ) такой трафик обрабатывает, а вот mod_cap_ether похоже нехочет.

 

Или он считает только что прошло через интерфейс?

Я нигде не смог найти описание логики его работы.

ether_cap работает по принципу перехвата всех пакетов, которые успеет. Он создает пакетный сокет:

capSock = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));

и принимает все пакеты, которые только успевает. По этому при интенсивном трафике или большой загрузке сервера он может пропускать пакеты.

[Колян]

Могу порекомендовать модуль для Firebird - это полностью наша разработка и он поддерживается нами.

Поддерживаю выбор такой СУДБ )).

А чем вам мускуль собсно не угодил?

[madf]

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

Файлы... А что в мускуле настраивать надо? Доступ к базе? Модуль сам создаст базу данных и таблицы

MySQL не всегда хорошее решение. И настраивать его надо - например, юзера создать. Права ему прописать.

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

Сейчас это неплохое решение при сетке в пару сотен юзеров, где админу лениво ставить и настраивать дополнительный софт.

[suxer]

ether_cap работает по принципу перехвата всех пакетов, которые успеет. Он создает пакетный сокет:

Тоесть НЕ по принципу pcap - tcpdump... Понятно. Придется настраивать пропускание трафика через сервер биллинга, хотя не очень этого хочется.

[Колян]

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

Файлы... А что в мускуле настраивать надо? Доступ к базе? Модуль сам создаст базу данных и таблицы

MySQL не всегда хорошее решение. И настраивать его надо - например, юзера создать. Права ему прописать.

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

Сейчас это неплохое решение при сетке в пару сотен юзеров, где админу лениво ставить и настраивать дополнительный софт.

Две сотни? Хм... у меня на сотне никакой нагрузки на сервер бд нету, 120 юзеров.

[BECHA]

мне кажется что субд старгейзеру не нужна - без нее он практически единственный биллинг под *nix способный работать на слабой машинке.

[madf]

мне кажется что субд старгейзеру не нужна - без нее он практически единственный биллинг под *nix способный работать на слабой машинке.

СУБД старгейзеру нужна (собсно, она есть), но выкидывать поддержку файловой базы мы именно по этому поводу не собираемся.

[madf]

Две сотни? Хм... у меня на сотне никакой нагрузки на сервер бд нету, 120 юзеров.

Раз на раз не приходится. У всех разные ситуации.