madf

Это скорее концепт а не фича какого-либо биллинга. Т.к. имеется информация о связках MAC-Абонент то ее можно использовать для восстановления (или изменения) связок MAC-Port. Не столько важно как это сделать (средствами биллинга или скриптами), сколько важно что это возможно.

Я бы даже сказал "по установке переменных в tcsh".

Это разве не Аутентификация? По идее то что он еще может аутентифицироваться со своими учетными данными нифига не означает что он будет авторизован для доступа к интернетам. Не? В контексте AAA - да, аутентификация. В контексте Stargazer - авторизация

Хм, надо поглядеть...

Я бы сказал что этого не может быть.

Поправочка. Абонент не сможет авторизоваться только если он отключен или "заморожен". Баланс на авторизацию никак не влияет. Правильнее было сказать так что клиент не сможет получить доступ в интерент при указанных выше условиях. Авторизация и получение доступа - разные вещи.

MySQL? MySQL...

MySQL...

В случае подхода "управляемый порт на абонента" в ящике должен быть порядок, а в базе должна быть точная информация о том кто в каком порту сидит. Не использовать эту информацию для авторизации как минимум глупо, как и задалбывать абонента дурацкими паролями. Что значит дурацкими?!) а как вы авторизуете абонента в личном кабинете, тоже по порту, а если он хочет зайти не со своего порта, а вообще с другой сети? Лично для меня проще выдать пользователю логинпароль который везде подходит. А вести базу кто где весит как-то громоздко что-ли... И ничего сложно в том что бы запустить подключения перед браузером, не слышал о такой проблеме от пользователя. Если абонент находится в своем порту - запрашивать у него авторизацию как минимум глупо. Да, если он хочет попасть в "личный кабинет" извне то авторизация по логину/паролю все-же необходима. Но пока он "дома" нужно максимально облегчить его взаимодействие с сетью.

Подход который предлагает NiTr0 даже еще лучше - информация о mac-адресах осталась и ее можно использовать для актуализации данных. Ввод логина и пароля в таком случае понадобится только если абонент совсем-совсем "потерялся" - информации о его MAC'ах нет, куда он включен тоже никто не знает. Очень редкая ситуация, возможна только если абона подключили и тут-же вырезали все кабели.

Конечно же она, эта информация, должна быть и использоваться ее надо. Без сомненья. Но согласитесь, что нужно иметь простой, быстрый и главное дешевый способ актуализировать эту информацию, в случае если по обстоятельствам непреодолимой силы она потеряла свою актуальность. - В случае массового вандализма (а это отнюдь не редкость) бригада из двух специалистов может восстановить повреждения за пару часов (без трассировки кабелей), а может мудохаться целый рабочий день (с трассировкой кабелей). Как Вы думаете, от чего абонент будет испытывать большие страдания: 1. если если услуга не будет оказываться 8 часов, но зато потом он воткнет вилку в розетку и доступ в Интернет появится без вопросов; 2. или же если доступ в Интернет возобновится через 2 часа, но при этом система задаст абоненту вопрос - логин и пароль (причем с определенной долей вероятности ему их вводить не придется - попали таки в правильный порт). Лично мне кажется, что за 8 часов простоя хуями укроют гораздо сильнее чем за 2. И это мы еще не говорим о производительности труда, ведь если специалисты справились за 2 часа, вместо 8, то оставшиеся 6 часов они могут еще много чего полезного сделать. Авторизация по порту не исключает возможности авторизации по логину/паролю в исключительных случаях. Вот только PPPoE тут не нужен.

Эта информация все равно должна быть в базе (иначе как тогда будет работать авторизация?), не вижу проблемы.

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

Stargazer с UBilling может общаться через XMLRPC (Nightfly почему-то его не любит и использует другие, более узкоспециализированные механизмы, но XMLRPC все-таки поддерживает).

... Администратор в той ипостаси что требуется работодателю, обладает объемом знаний намного большим чем любой програмер. ... Не сравнивайте разные профессии.

И что же вы можете такого "затюнить" на $2к в месяц? Это какой-то перманентный тюнинг получается, а когда же все это будет работать? PostgreSQL, например. Даже сами разработчики не рекомендуют использовать дефолтные его конфиги. Ну и да, тюнинг, обычно, как раз и есть перманентный Оооо.... Я дико извиняюсь, а что вы там храните? 10 000 записей о клиентах? И для этого вы тюните PostgreSQL? Лечитесь. У меня БД PostgreSQL размером 10ТБ+ и этим занимается специалист по БД, а не администратор. Да и сам PostgreSQL собственной сборки с изменениями в исходном коде внесенными программистами С/С++. Ну что вы там можете "натюнить"? В лучшем случае - "погулите", потыкаетесь как слепой котенок и все. Стандартные настройки для PostgreSQL подходят разве что "на посмотреть". Их в любом случае надо подгонять под конкретную систему. Об этом написано, между прочим, в официальной документации. И не нужно быть DBA чтобы привести десяток параметров к объему ОЗУ и характеристикам дисковой подсистемы и прописать пару sysctl. И мне как программисту на предыдущей работе приходилось заниматься тюнингом PostgreSQL. База была не 10 Тб а всего 1.5 Тб, но и этого было достаточно чтобы "играться" с индексами и делать принудительный ANALYZE некоторых таблиц. И тоже приходилось патчить - правда, не сам PostgreSQL а всего-лишь pg_migrate. Конечно, хорошо иметь DBA в штате, но стоит он немало и не все его могут себе позволить. Да и не всем он нужен. В большинстве случаев достаточно обычного администратора с минимальными знаниями PostgreSQL почерпнутыми из документации. К чему эти меряния объемами БД и крутостью патчей? Я согласен с вашим утверждением что "тонкая настройка системы" обычно мало кому нужна, но и заявлять что apt-get install ... всегда достаточно не стоит.

И что же вы можете такого "затюнить" на $2к в месяц? Это какой-то перманентный тюнинг получается, а когда же все это будет работать? PostgreSQL, например. Даже сами разработчики не рекомендуют использовать дефолтные его конфиги. Ну и да, тюнинг, обычно, как раз и есть перманентный

Как-то круто для Днепра. Это сетка или какая-нибуть контора?

Я бы ориентировался на $1к-$2к. Хотя в разных городах может по разному быть.

Я бы не сказал что требования очень высоки. Ну разве что оказание техподдержки пользователям и особенно в ночные смены - вот эти требования рекомендую убрать, человек подобного уровня техподдержкой пользователей не занимается а ночные работы оговариваются отдельно по отдельному тарифу. А так я знаю такого человека, сейчас он приблизительно таким всем и занимается за $1,5к в месяц.

Это я уже понял. Но с другой стороны - народ сообщает, что есть странные глюки при работе с PPPoE, а этого мы себе по понятным причинам позволить не можем. А можно узнать примеры этих самых странных глюков? Из личной практики pppoe работает очень даже стабильно. Перестал pppoe сервер справляться с нагрузкой, поставил параллельно второй и работаешь дальше, плюс повысилась отказоустойчивость. У моего провайдера бывает "зависает" сессия. Переподнять не сложно, но неприятно.

К стати да, я уже говорил про 777

Тема поднимается при каждом переводе времени

Чего ж сразу не сказали? А что при этом пишется в stargazer.log? И как вы относитесь к детальному расследованию проблемы (я буду предоставлять патчи, вы будете с ними пересобирать и сообщать о результатах пока проблема не будет решена)?

Не обратил внимание что фря. CFLAGS и CXXFLAGS там устанавливаются как-то по другому (вроде бы через setenv, но могу ошибаться). Можно собирать и без них, просто сборка будет без оптимизации. И вместо make надо давать команду gmake.