SlackER писал(а):Гонял на тестовой машинке 5.2.6 с FreeBSD + mpd 5.2. Связка "Передача IP - трафика" и "Коммутируемый доступ" с динамическими айпишниками прекрасно работала. Иногда rfw загонялся, отключал инет произвольно, если в учетке больше 1 услуги коммутируемого доступа было. В 5.2.7 это поправили. Поставил новую версию, база только как то с ошибками обновилось, но проблема исправилась. Перед финальным тестом залил чистую базу, сделал все как в прошлый раз - mpd выдает айпишник. Только принимаемые пакеты не идут, а исходящие есть. Выдал айпишник без радиуса из mpd.secret - работает. В логах ничего внятного нет, все работает.
Хм, у нас ппроблема несколького иного плана. Обкатывал переход с 006 на 007, связка такая же как у вас. В 006 не было проблем, правиля для фаервола биллинг при включении отдавал, клиент включался. Перешел на 007 по инструкции производителя, пофиксил правила фаера утилиткой, включил биллинг, несколько офигел от искусственного разума-оно добавило разрешающее правило при удалении юзверя (уже бодрит). Ладно поправил, законнектился пользователем- ипшник в биллинге появился, в фаервол пытается добавиться правило с 0.0.0.0 ипишником. Ладно, прибил базу, поставил с нуля 007, эфект аналогичный.
Господа, у многих работает "коммутируемый доступ" + "ип" с динамическими адресами на 7.2 фрешке? Ткните, где ковырять.
При удалении пользователя (через новую админку, последовательность - удаляем услуги, затем тариф, затем пользователя) выполняется правило на включение интернета с ip 0.0.0.0.
А скажите, какие открытые известные баги остались у 007? А то сейчас выкручивают руки, приходится переходить на неё в ближайшее время, хочется знать, к чему быть готовым.
И сразу вдогонку, пользует ли кто-нибудь 007 в 64-битном линуксе? Сейчас комбайн из всего разносится на отдельный NAS и отдельно БД, вероятно ядро биллинга будет крутиться на сервере с БД, а там хотелось бы воткнуть 64-битную систему, чтобы мускулу дать "широкий" доступ к памяти. Чем оно чревато?
В общем, не дождавшись ответов, поставил на тест.
Первое, что бросилось в глаза: ядро грузится ужаааааасно долго. Минут 15 он занимается тем, что извлекает id из blocks_info where account = с первого по последний. Только после этого ядро начинает слушать порты 11758/12758.
Неужели нельзя это как-то поменять/оптимизировать?
Витька писал(а):А скажите, какие открытые известные баги остались у 007? А то сейчас выкручивают руки, приходится переходить на неё в ближайшее время, хочется знать, к чему быть готовым.
И сразу вдогонку, пользует ли кто-нибудь 007 в 64-битном линуксе? Сейчас комбайн из всего разносится на отдельный NAS и отдельно БД, вероятно ядро биллинга будет крутиться на сервере с БД, а там хотелось бы воткнуть 64-битную систему, чтобы мускулу дать "широкий" доступ к памяти. Чем оно чревато?
Видимо это тайна покрытая мраком ).
Нахрен платить за багнутый софт?! Поставил бы 006 и радовался жизни.
Витька писал(а):А скажите, какие открытые известные баги остались у 007? А то сейчас выкручивают руки, приходится переходить на неё в ближайшее время, хочется знать, к чему быть готовым.
И сразу вдогонку, пользует ли кто-нибудь 007 в 64-битном линуксе? Сейчас комбайн из всего разносится на отдельный NAS и отдельно БД, вероятно ядро биллинга будет крутиться на сервере с БД, а там хотелось бы воткнуть 64-битную систему, чтобы мускулу дать "широкий" доступ к памяти. Чем оно чревато?
Видимо это тайна покрытая мраком ).
Нахрен платить за багнутый софт?! Поставил бы 006 и радовался жизни.
006 у меня почти год верой и правдой отпахала. До этого 004 была.
Сегодня обновил-таки продакшн-сервер до 007. Пока, тьфу-тьфу, полёт нормальный...
Витька писал(а):А скажите, какие открытые известные баги остались у 007? А то сейчас выкручивают руки, приходится переходить на неё в ближайшее время, хочется знать, к чему быть готовым.
И сразу вдогонку, пользует ли кто-нибудь 007 в 64-битном линуксе? Сейчас комбайн из всего разносится на отдельный NAS и отдельно БД, вероятно ядро биллинга будет крутиться на сервере с БД, а там хотелось бы воткнуть 64-битную систему, чтобы мускулу дать "широкий" доступ к памяти. Чем оно чревато?
Видимо это тайна покрытая мраком ).
Нахрен платить за багнутый софт?! Поставил бы 006 и радовался жизни.
006 у меня почти год верой и правдой отпахала. До этого 004 была.
Сегодня обновил-таки продакшн-сервер до 007. Пока, тьфу-тьфу, полёт нормальный...
(голос за кадром)
Обновляя биллинг до версии 007, он ещё не знал, что его ожидает в будущем. А пока, у него всё работает стабильно и он радуется жизни.
И вдруг в один прекрасный день....
Витька писал(а):В общем, не дождавшись ответов, поставил на тест.
Первое, что бросилось в глаза: ядро грузится ужаааааасно долго. Минут 15 он занимается тем, что извлекает id из blocks_info where account = с первого по последний. Только после этого ядро начинает слушать порты 11758/12758.
Неужели нельзя это как-то поменять/оптимизировать?
Витька писал(а):В общем, не дождавшись ответов, поставил на тест.
Первое, что бросилось в глаза: ядро грузится ужаааааасно долго. Минут 15 он занимается тем, что извлекает id из blocks_info where account = с первого по последний. Только после этого ядро начинает слушать порты 11758/12758.
Неужели нельзя это как-то поменять/оптимизировать?
индекс создайте в blocks_info
Тут пока ответа дождёшься, сам догадаешься It works, ага.
Витька писал(а):В общем, не дождавшись ответов, поставил на тест.
Первое, что бросилось в глаза: ядро грузится ужаааааасно долго. Минут 15 он занимается тем, что извлекает id из blocks_info where account = с первого по последний. Только после этого ядро начинает слушать порты 11758/12758.
Неужели нельзя это как-то поменять/оптимизировать?
индекс создайте в blocks_info
Тут пока ответа дождёшься, сам догадаешься It works, ага.
Сами себе тех. поддержка )
Хотя в таких случаях тех поддержка должна официально извещать на сайте
Витька писал(а):В общем, не дождавшись ответов, поставил на тест.
Первое, что бросилось в глаза: ядро грузится ужаааааасно долго. Минут 15 он занимается тем, что извлекает id из blocks_info where account = с первого по последний. Только после этого ядро начинает слушать порты 11758/12758.
Неужели нельзя это как-то поменять/оптимизировать?
индекс создайте в blocks_info
Тут пока ответа дождёшься, сам догадаешься It works, ага.
Сами себе тех. поддержка )
Хотя в таких случаях тех поддержка должна официально извещать на сайте
Да индекс мало помогает на большом кол-ве абоентов
Витька писал(а):В общем, не дождавшись ответов, поставил на тест.
Первое, что бросилось в глаза: ядро грузится ужаааааасно долго. Минут 15 он занимается тем, что извлекает id из blocks_info where account = с первого по последний. Только после этого ядро начинает слушать порты 11758/12758.
Неужели нельзя это как-то поменять/оптимизировать?
индекс создайте в blocks_info
Тут пока ответа дождёшься, сам догадаешься It works, ага.
Сами себе тех. поддержка )
Хотя в таких случаях тех поддержка должна официально извещать на сайте
Да индекс мало помогает на большом кол-ве абоентов
кто ставил 5.2.1-007 update 8 какие впечатления? разработчики не могли бы вы сообщить какие баги были исправлены) ещё странно что такой резкий скачок с update 4 на update 8...
).