Доброе время суток.
Имею интересную и вместе с тем, достаточно стандартную проблему - нужно настроить билинг, пусть и кастрированный.
Решено было, что проще всего поставить squid и уже его админить. Существует небезызвестная мордочка к нему - SAMS. Мордочка достаточно хороша, хоть и код страшен. Но есть одно большое "НО"!! Юзверей мне нужно авторизовать из лдапа. А он очень коряво с этим работает, то есть никак. Там товарищь с форума его якобы заводил со лдапом. Но что-то как-то сходу не завелось - ковыряемся, но хотелось бы ещё варианты рассмотреть.
Как ещё один вариант - сарг, но он плох тем, что лопатить логи и это очень медленно, нужно низкое время реакции - то есть самс демоном висит и хавает лог сквидовый, через пайп - это хорошо.
Порывшись в гугл, опеннете создалось впечатление что мордочек к squid'у - единицы. Помогите, добрые люди.
P.S. Просто думается мне, что проще управлялку с сквиду найти, чем настроить squid + биллинг, если есть варианты - колитесь.
GUI для SQUID'а. Предложите варианты.
- SCIF
- Full Member
- Сообщения: 144
- Зарегистрирован: 07 июн 2006 15:50
- Откуда: Владивосток
- Контактная информация:
GUI для SQUID'а. Предложите варианты.
Последний раз редактировалось SCIF 16 апр 2008 11:13, всего редактировалось 1 раз.
- hatred
- Global Moderator
- Сообщения: 1205
- Зарегистрирован: 08 июн 2006 00:32
- Откуда: Владивосток
- Контактная информация:
Re: GUI для SQUID'а. Предложите варианты.
гм, а зачем?
я делал: ulog-acctd + свой парсер на tcl + pppoe + freeradius (пользователи в mysql, но вариант с ldap тоже скорее всего придумать можно) + правила в iptables + прозрачный прокси + небольшой бакенд к радиусу для обработки аккаунтинговой информации и отключения пользователей + самописная мордочка для статистики и управления.
в нашней компании это решение работает сейчас на 12 серверах (в новосибирсе внедрял удаленно, потребовалось только настройка клиентского соединения по pppoe с винды)
ну с парсером ulog данных, время апдейтов 5 минут, сократить можно до 1 минуты (расписание крона) чем чаще, тем быстрее логи обрабатываются, как показывает практика RT логирование траффика мало когда нужно.
я делал: ulog-acctd + свой парсер на tcl + pppoe + freeradius (пользователи в mysql, но вариант с ldap тоже скорее всего придумать можно) + правила в iptables + прозрачный прокси + небольшой бакенд к радиусу для обработки аккаунтинговой информации и отключения пользователей + самописная мордочка для статистики и управления.
в нашней компании это решение работает сейчас на 12 серверах (в новосибирсе внедрял удаленно, потребовалось только настройка клиентского соединения по pppoe с винды)
ну с парсером ulog данных, время апдейтов 5 минут, сократить можно до 1 минуты (расписание крона) чем чаще, тем быстрее логи обрабатываются, как показывает практика RT логирование траффика мало когда нужно.
Прошли времена когда на элементарные вопросы можно было отвечать man <что-то там> (с) из сети
Hatred's Log Place | My GitHub repos | My Gitlab repos
Hatred's Log Place | My GitHub repos | My Gitlab repos