Комментарии к статье «Шлюз с авторизацией и динамическим распределением канала на базе pf+altq и authpf»
| ОЛОЛО | мфынф |
|---|---|
| Статья полнейший бред | |
| Евгений Загородний | |
|
Крон не устраивал, потому что он запускает что-либо не чаще, чем раз в минуту. А заставлять пользователя ждать в среднем по полминуты, прежде чем его запрос на авторизацию обработается, неприемлемо. На всякий случай: описанной здесь методикой я уже не пользуюсь, и развивать ее не намерен. Так что статью лучше рассматривать, как одну историю про то, как бывает, если никем-не-реализовано-но-очень-хочется :) |
|
| Alexander | |
|
Зачем на Си писать тулзу с setuid? Чем вам не нравится крон? |
|
| Евгений Загородний | |
|
Да, действительно, — нетиражируемо, это серьезный недостаток. Вопрос решался «здесь и сейчас», о возможной необходимости проделать аналогичное на других узлах не задумывался :) Заведение нового пользователя требует ровно двух действий: обычный useradd + запись в authpf.allow. Функциональность htb, судя по (увы, проглянутой по диагонали) документации, практически не отличается от таковой у altq. По крайней мере, как с помощью простого конфигурирования, без «костылей», добиться справедливого разделения пропускной способности без фиксированных ограничений скорости — непонятно. Специфика рассматриваемой сети заключается в том, что она маленькая (8–16 клиентов), соответственно, скорость связи с внешним миром – тоже, и не использовать ее в полной мере — непозволительно. Если можно, — подскажите, где узнать про стандартизованные решения, учитывая эту специфику. (В сторону PPPoE и Radius непременно гляну.) |
|
| набор костылей, нетиражируемо. | Andrew Degtiariov |
|
набор костылей, нетиражируемо. – плюс заведение нового пользователя дофига действий требует – htb в линуксе проще гораздо А авторизацию лучше делать другими путями (PPPoE например) Лучше использовать стандартизированые решения, чтобы был маневр при смене платформы Понятно, что это не этот случай, но при росте количества клиентов, можно поставить какую-то коммерческую платформу и если при проектировании на это закладывались (использование стандартных вещей PPPoE + Radius) то все это происходит более-менее незаметно для клиентов ну и на клиентских интерфейсах ограничивать максимальную скорость, а на внешнем роутере (когда все в одном флаконе это конечно сложно сделать) включить WFQ для нескольких конечных групп трафика. То есть, шейпинг на клиентских интерфейсах, приоритезация – на аплинке. Если сеть большая, то во всей сети (именно поэтому должно быть конечное число классов трафика) |
|
