madf

"Самая совершенная технология это та, которой не видно а все происходит само собой" (с) вроде бы А. Кларка. Никто не предлагает создавать невозможное. Все говорят о минимизации. Но почему-то друг друга не понимают

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

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

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

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

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

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

MySQL? MySQL...

MySQL...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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