[Nag]

#279. Софт в Сети

[_Jet]

Смешная статья. Понравилось. Чего только не собирают на коленке, лишь-бы не учить матчасть...

[uropek]

А что можно использовать, что не собирать "на коленке"? И где можно изучить матчасть?

 

А понравилась веб-управлялка управляемыми свичами, интересно есть в что-нибудь такое Open-Source, чтоб с базой можно было интегрировать?.

Изменено 11 августа, 2006 пользователем uropek

[cae]

Ужас какой... Строить на винде немасштабируемое решение...

odbc... access... файловое хранилище...

Занимаюсь билингом с 1995 года и прошёл путь от провайдера с двумя пользователями диалапа до провайдера с немерянным трафиком.

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

В остальных случаях себя не оправдывает.

Удивила фраза

"Запланировали сменить сервер авторизации. Железо старится, а на новом нужно переустановить Windows... Но как поменять пароли нескольким тысячам клиентов?"

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

Лично дважды переносил базы из самописного билинга в купленный и ещё один.

Объединял базы пользователей двух провайдеров с тысячами accounts, но таких проблем не испытывал, ввиду правильной архитектуры систем, даже самописных. Пароли, разумеется, были не в открытом виде, а в crypt(3).

 

В общем, правильно сказал _Jet: учите матчасть, пока не поздно.

 

Что же касается веб-управлялки... NetDisco

[orca]

А мне YOURNetwork Installer понравился, надо будет вспомнить VisualStudio и себе такое написать. Единственное научить его данные по сети вытягивать а не из памятки пользователя!:)

[Terol]

нет, я конечно понимаю все в далеком 97 году были просто гуру Unix и биллинг систем тогда было просто море. Я начинал так же и скажу что даже сейчас RAE до сих пор успешно работает и учитывает клиентов. Из багов только Переполнение счетчика входящего трафика (после 2 с чем то гб сбрасывается) да при ограничении по входящему, он считает вместа трафика в одну сторону - суммарный трафик. Из минусов функционала - нельзя зарезать скорость. Но этому научились биллинговые системы всего 2 года назад.

Не понимаю недовольства к решению на windows. Ставится и настраивается просто, писать логи может в любой ODBC источник, понимает внешние команды (практически можно все сделать), т.е. связка RAE + MSDE или MS SQL 2005 Express + RRAS позволяет решать практически любую задачу.(C MySQL возожностей меньше - там нет ни триггеров не хранимых процедур) Статистика берется из базы и можно не городить огород с PHP, а написать на ASP (да хоть на ASP.NET). Работает как под Windows NT так и под Windows 2003. Для миграции пользователей с машины можно не переставлять, а апдейтить железо (ядро в стандартный режим, запуск на новом железе, ядро обратно ACPI) или есть куча программ миграции (как в reskit так и сторонних производителей). По соединениям ограничен только самим windows, на NT это 256 одновременных было, в Windows 2003 уже 4000. Принимать может как PPTP так и PPPоE. Для маленького провайдера вообще идеальное решение - Celeron 400|512Мб (Менял только винт (тупо перезаливал на новый))- работает уже с 2000 года, без нареканий в среднем больше 100 абонентов онлайн. Мало? ну так и городок маленький.

А по поводу unix биллинга. Если честно НЕ ВИДЕл я пока достойного под unix. Так что бы заплатил и горя не знал. Везде нужен рашпиль и долгая обработка. Даже в платных. Несомненно тут много людей, которые скажут - "самим написать слабо". Не слабо. Вопрос - ЗАЧЕМ, если уже есть.

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

 

Предвижу кучу флейма - что де все отцы и все сами написали или мыслят масштабами циски. МОЛОДЦЫ скажу я вам. МОЛОДЦЫ. Но тот вариант что был описан - имеет право жить. А в новоиbенево где unix специалиста днем с огнем не сыщешь - тем более имеет полное право. Всем удачи. Никого не хотел обидеть, если невольно обидел - извините.

 

и кстати решение - масштабируемое load balancer (встроенный в windows) и ставьте хоть 1000 таких машин.

Изменено 11 августа, 2006 пользователем Terol

[cae]

Из багов только Переполнение счетчика входящего трафика (после 2 с чем то гб сбрасывается) да при ограничении по входящему, он считает вместа трафика в одну сторону - суммарный трафик.

Переполнение счётчика - ситуация стандартная. Это не вызывает проблем. Исправьте алгоритм, перекомпилите, тип проверки на прокрутку, а не на падение точки учёта поставьте, например, по sysUpTime или аналогичному oid (смотря, что у Вас используется в качестве точек учёта).

Тут есть немного подводных камней, если оборудование не cisco.

Не нравится алгоритм рисовать - читайте 64-битные счётчики (ifHCInOctets ifHCOutOctets).

Тут потребуется все лишь oid-ы исправить и скомпилить заново.

 

Из минусов функционала - нельзя зарезать скорость. Но этому научились биллинговые системы всего 2 года назад.

Вообще-то дело билинговой системы байты считать, ограничение скорости либо ставится выделенщику один раз на порту, либо на точке терминации радиусом. Радиус умел отдавать доп.атрибуты как бы не от рождения. Обращаться в SQL за атрибутами радиусы тоже умеют давно, лет пять, наверное, если не больше. Соединить в SQL таблицы радиуса и билинга дело лёгкое.

 

Не понимаю недовольства к решению на windows.

Будете расти - увидите сами. Никто насильно в рай не тянет ;)

 

(C MySQL возожностей меньше - там нет ни триггеров не хранимых процедур)

Есть postgresql и Oracle.

 

А по поводу unix биллинга. Если честно НЕ ВИДЕл я пока достойного под unix.

Жаль. Зайдите на opennet и поищите, там есть и халявные и ссылки на сертифицированные.

 

Везде нужен рашпиль и долгая обработка. Даже в платных.

Не знаю, не знаю. Внедрёж Билл-мастера прошёл на ура. Да, дотачивали с разработчиками некоторые фичи, пока старые точки жили на старом билинге, но на то они и разработчики, чтобы желание заказчика выполнять.

 

Несомненно тут много людей, которые скажут - "самим написать слабо". Не слабо. Вопрос - ЗАЧЕМ, если уже есть.

Вас устраивает - замечательно. Я высказал MHO и показал ограничения.

 

А в новоиbенево где unix специалиста днем с огнем не сыщешь - тем более имеет полное право.

Вы знаете, сейчас на рынке труда заметна обратная тенденция - unix админа, спикающего на perl или php, найти гораздо проще, чем квалифицированного админа виндов. В провинции тоже.

К сожалению. Все ставили винду, но как только чуть в сторону от меню - голяк...

Вам повезло, скажу честно.

 

и кстати решение - масштабируемое load balancer (встроенный в windows) и ставьте хоть 1000 таких машин.

;))) Спасибо, я уж лучше sparc поставлю один раз и забуду о существовании билинга на ближайшие лет пять. А там он себя уже десять раз отобьёт и заменим на новый sparc. Миграция будет tar c + tar x

[GateKeeper]

Уважаемый Андрей Волк, не будете ли любезны пояснить, почему клиентский веб-интерфейс на выдачу статистики в локалке 1000- пользователей (соседняя с Вашей, кстати, на их форуме можете мат по этому поводу почитать) тратит 1 минуту в среднем? Что ж там за скрипт такой на php хитрый!?

[AndyWolk]

Уважаемый Андрей Волк, не будете ли любезны пояснить, почему клиентский веб-интерфейс на выдачу статистики в локалке 1000- пользователей (соседняя с Вашей, кстати, на их форуме можете мат по этому поводу почитать) тратит 1 минуту в среднем? Что ж там за скрипт такой на php хитрый!?

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

Есть в скрипте несколько sql-запросов "простеньких". Сам скрипт работает быстро, а вот запросы к ODBC-драйверу Access и занимают такое огромное время. Помнится, мы с их шефом перепробовали все способы повлиять на Access - бестолку, жутко тормозно работает.

Пусть они, если захотят, со мной свяжутся, есть способ перенести все на MySQL. По скорости будет земля и небо. Кажется, я уже предлагал им такое решение.

Изменено 11 августа, 2006 пользователем AndyWolk

[GateKeeper]

Тогда прошу поправить статью:

Тормоза в Access-версии начинаются от 200+ пользователей (примерно, может, порог и меньше, а, может, чуть больше)

[AndyWolk]

Тогда прошу поправить статью:

Тормоза в Access-версии начинаются от 200+ пользователей (примерно, может, порог и меньше, а, может, чуть больше)

Статья ни причем.

В том то и дело, что проблема в конкретной конторе, в редакции виндов, софта, драйверов и железа на сервере той локалки.

У нас клиентов больше. Работает быстрее. Мы у себя, конечно, уже чувствуем, что с притоком клиентов от тормознутого Access'a пора избавиться, но нас такая мощная болезнь как у них пока не трогала.

Плюс тормозить должно пропорционально кол-ву клиентов, а не так, что как только 200 юзеров - сразу висюк.

Изменено 11 августа, 2006 пользователем AndyWolk

[Gorbushka]

Статья ни причем.

В том то и дело, что проблема в конкретной конторе, в редакции виндов, софта, драйверов и железа на сервере той локалки.

У нас клиентов больше. Работает быстрее. Мы у себя, конечно, уже чувствуем, что с притоком клиентов от тормознутого Access'a пора избавиться, но нас такая мощная болезнь как у них пока не трогала.

Плюс тормозить должно пропорционально кол-ву клиентов, а не так, что как только 200 юзеров - сразу висюк.

ммм... я не знаю какое железо нужно этой статистике, но на P4 1800Mhz RAM 512 под Win 2k3 она тормозит :)

[Terol]

Переведите на MS SQL - MSDE или MS SQL 2005 Express - они бесплатные. Для примера на Celeron 400/512 статистика отдается не больше 2 секунд. в базе история событий с 2000 года.

Изменено 11 августа, 2006 пользователем Terol

[Terol]

Из багов только Переполнение счетчика входящего трафика (после 2 с чем то гб сбрасывается) да при ограничении по входящему, он считает вместа трафика в одну сторону - суммарный трафик.

Переполнение счётчика - ситуация стандартная. Это не вызывает проблем. Исправьте алгоритм, перекомпилите, тип проверки на прокрутку, а не на падение точки учёта поставьте, например, по sysUpTime или аналогичному oid (смотря, что у Вас используется в качестве точек учёта).

Тут есть немного подводных камней, если оборудование не cisco.

Не нравится алгоритм рисовать - читайте 64-битные счётчики (ifHCInOctets ifHCOutOctets).

Тут потребуется все лишь oid-ы исправить и скомпилить заново.

к сожалению у меня только бинарник.

Из минусов функционала - нельзя зарезать скорость. Но этому научились биллинговые системы всего 2 года назад.

Вообще-то дело билинговой системы байты считать, ограничение скорости либо ставится выделенщику один раз на порту, либо на точке терминации радиусом. Радиус умел отдавать доп.атрибуты как бы не от рождения. Обращаться в SQL за атрибутами радиусы тоже умеют давно, лет пять, наверное, если не больше. Соединить в SQL таблицы радиуса и билинга дело лёгкое.

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

Не понимаю недовольства к решению на windows.

Будете расти - увидите сами. Никто насильно в рай не тянет ;)

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

 

(C MySQL возожностей меньше - там нет ни триггеров не хранимых процедур)

Есть postgresql и Oracle.

а зачем? postgresql только недавно стал найтивный под Windows, с триггерами у них есть заморочки, ваккум каждые Н-цать часов делать не прикольно. А оракл - вариант, но у них только только появился Express. А за деньги - шибко дорого :)

А по поводу unix биллинга. Если честно НЕ ВИДЕл я пока достойного под unix.

 

Жаль. Зайдите на opennet и поищите, там есть и халявные и ссылки на сертифицированные.

Не поверите изъелозил весь опеннет. Но опеннет вообще странный какой то. Напоминает мне журнал моделист конструктор. Все пишут только о том какие они молодцы и как изобрели очередной велосипед или решили пролему патчем, получить же помощь на опеннет - большая проблема. Я тогда пытался понять как работает QoS и как правильно работать с htb, ответ получил только в fido.

Изменено 11 августа, 2006 пользователем Terol

[AlexWolf]

Хочу выразить респект автору биллинга, т.к. в свое время сами начинали с его некоммерческой версии. К сожалению, из-за того, что он прекратил поддержку и развитие своего проекта, пришлось перейти на юниксовый биллинг. Мне до сих пор не хватает некоторых фич из того биллинга, хотя, возможно, минусы у него вскрылись бы с увеличением абонентской базы. Сам я так и не смог тогда разыскать Данилова Евгения (aka Doomer). Если бы удалось связаться, возможно мы бы продолжали пользоваться его разработкой и сейчас (если бы смогли, конечно, доработать некоторые моменты сами, раз он уже не продолжал разработки)

Изменено 11 августа, 2006 пользователем AlexWolf

[VitMain]

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

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

[sauron]

Не понимаю недовольства к решению на windows. Ставится и настраивается просто, писать логи может в любой ODBC источник, понимает внешние команды (практически можно все сделать), т.е. связка RAE + MSDE или MS SQL 2005 Express + RRAS позволяет решать практически любую задачу.

ODBC работает очень медленно. По большей части скорость работы зависит от самих ODBC драйверов. Нормальные бесплатные драйвера видел только для MS продуктов. Как сервер для биллинга windows не слишком хорош. В *nix я могу выключить практически все не нужные мне сервисы. В windows это проблематично. Так же не забываем про стратегию работы с памятью. Она там не слишком удачна. Памяти там должно быть всегда больше чем надо иначе может начаться процесс свопинга. Ну собственно и т.п. и т.д.

 

(C MySQL возожностей меньше - там нет ни триггеров не хранимых процедур)

PostgreSQL, Oracle, Firebird список можно продолжить.

 

Статистика берется из базы и можно не городить огород с PHP, а написать на ASP (да хоть на ASP.NET). Работает как под Windows NT так и под Windows 2003. Для миграции пользователей с машины можно не переставлять, а апдейтить железо (ядро в стандартный режим, запуск на новом железе, ядро обратно ACPI) или есть куча программ миграции (как в reskit так и сторонних производителей).

:] В *nix такой проблемы вообще нет. Можно апдейтится до упора. Перенос с одного железа на другое вообще не представляет сложности (самолично переносил биллинг с двух машин причем с заменой версии СУБД на major).

 

По соединениям ограничен только самим windows, на NT это 256 одновременных было, в Windows 2003 уже 4000. Принимать может как PPTP так и PPPоE. Для маленького провайдера вообще идеальное решение - Celeron 400|512Мб (Менял только винт (тупо перезаливал на новый))- работает уже с 2000 года, без нареканий в среднем больше 100 абонентов онлайн. Мало? ну так и городок маленький.

*nix решение будет работать на том же, но памяти ему будет надо в два раза меньше.

 

А по поводу unix биллинга. Если честно НЕ ВИДЕл я пока достойного под unix.

гляньте хоть вот это Cake. Вещь под GPL лицензией. Функционал маловат, но использовать концепцию и написать свое с большим функционалом или расширить никто не мешает.

 

Так что бы заплатил и горя не знал. Везде нужен рашпиль и долгая обработка. Даже в платных.

Универсальные биллинги есть... но захочется ли вам платить бешенные деньги за них?

 

Несомненно тут много людей, которые скажут - "самим написать слабо". Не слабо. Вопрос - ЗАЧЕМ, если уже есть.

Когда у вас возникнут проблемы с масштабированием решения тогда поймете.

 

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

Мне abills не понравился реализацией. Реализация будет загибаться при средней нагрузке.

 

и кстати решение - масштабируемое load balancer (встроенный в windows) и ставьте хоть 1000 таких машин.

Какова будет устойчивость решения и его масштабируемость?

[sauron]

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

Хм у FreeRADIUS все вполне работает. Но к нему мозги надо. Т.к. летающая тарелка еще та.

 

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

В зависимости, что понимать под промышленными решениями. В нише средних нагрузок как раз распрастранен windows. Дальше больше... чаще SUN.

 

а зачем? postgresql только недавно стал найтивный под Windows, с триггерами у них есть заморочки, ваккум каждые Н-цать часов делать не прикольно.

Какие заморочки с триггерами ? Вот сколько пишу на различных диалектах триггеры, почти везде одно и тоже, различается слегка деталями и не более. Хотелось бы узнать про заморочки поподробнее. Про вакуум забудьте. Поставьте PostgreSQL 8.1 включите autovacuum и будет вам счастье.

 

 

Не поверите изъелозил весь опеннет. Но опеннет вообще странный какой то. Напоминает мне журнал моделист конструктор. Все пишут только о том какие они молодцы и как изобрели очередной велосипед или решили пролему патчем, получить же помощь на опеннет - большая проблема. Я тогда пытался понять как работает QoS и как правильно работать с htb, ответ получил только в fido.

Странно именно через opennet находил довольно много биллингов. Правда не все понравились.

[Shiva]

А есть ещё компания T-Soft Биллин и технологии :)

Вот они тоже ламеры под винды пишут... :)

[jab]

У пионеров почему-то сложилось мнение, что биллинг - это нечто

сложное и недоступное. Хотя любой возьми - десяток табличек,

пяток скриптов да двадцать формочек к ним.

[GateKeeper]

jab прав. В одном из тредов в софте писал, что без особого напряга ваяется билинг на посгресе, радиусе и mpd под фряхой. Пару раз поразмыслить - и вуаля, не такой уж и бедный функционал на коленке. При 8-часовой занятости проектом один человек максимум в месяц уложится.

[jab]

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

 

Особенно если кросплатформенный, да с разными DB-backends,

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

заказчиков поначалу "желающих странного" а после "забивающих

гвозди микроскопом", да еще и с техподдержкой всего этого

барахла в течении десятков лет... брр...

[Saper]

Вы забываете, что кроме биллинга в статье ещё описана такая замечательная фишка как управление сетью и юзерами с помощью умного оборудования и всё это интегрировано с биллингом через веб-интерфейс.

 

Судя по скриншотам замечательная штука. Автору респект. Такое наверное есть только у вас и нечто подобное я сделал для себя в нашей сети, и тоже на Виндах с помощью ASP.NET.

 

А у линуксоидов такого нет, бе-бе-бе. :-)

 

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

 

Так что биллинг-биллингом, а веб-управлялка всей сетью рулит по любому.

[AndyWolk]

To Saper: Спасибо. Если интересно, можем обменяться тут опытом.

 

А вот про "программу для тех. поддержки", настраивающую сеть, что-то все в форуме молчат.

Сегодня, кстати, включил в нее поддержку PPPoE. Если нужно, она установит драйвер PPPoE, вшитый к ней внутрь. А если драйвер, установлен, то включит bind на нужном интерфейсе. Создаст ярлычок на рабочем столе.

Изменено 16 августа, 2006 пользователем AndyWolk

[Piyoz]

Затеяли реорганизацию сети, понадобилась программка для автоматической настройки сети. Нашли такую у автора статьи, обратились и получили программку уже под собственные настройки. Программа самое то для пользователей, которым сложно объяснить, что такое настройки сети и где их искать. Здесь же - ввёл логин и IP адрес, и всё настроено. Пользователи остались довольны.

 

Среди недостатков - работает не со всеми сетевыми адаптерами, к примеру не все nForce опознавала.