Перейти до

Freebsd 8.3 проблемы с NAT'ом


Рекомендованные сообщения

Интересно какую нужно будет машину если все это на нее поставить + NAT и дофига пользователей.

Ну почему же. Сам по себе snmpd не жрет нифига, cacti - тоже не так прожорлив как zabbix скажем, monit - тоже ресурсонежрущая вещь, практически объязательная для оперативного мониторинга падения сервисов и принятия при этом соответствующих действий.

На настоящих объемах абонентов/трафика держать связку netflow/shape/nat/bandwidthd на том же тазике, что и биллинг - изначально нездоровая затея.

Благо практически бесконечное масштабирование по горизонтали более-менее продумано и ненапряжно. stargazer со своим бесподобным rscriptd на ниве человекообразной кластеризации дичайше жжет.

На практике же тазик-NAS ценовой категории <$1k , уверенно справляется с окологиговыми потоками трафика при скажем ~1500 абонентов на тарифах 5-100Мбит на рыло. С минимальнейшим тюнингом есно. При росте абонбазы абсолютно ненапряжно в пару кликов добавлять новые сервера доступа в любых количествах. Именно поэтому таки stargazer.

 

А для /usr/local/www/apache22/data стоит AllowOverride All

Моя ошибся, просит прощения :(

 

Не фанат конечно с .htaccess возится по древу папочек вебки, вот и захотелось все в кучу в один конфиг.

ну у большинства папочек с чувствительными данными, такими как /config /content /multinet либо теми, откуда не желателен вызов скриптов напрямую, типа /modules натыкано хтакессов с банальным deny from all. Поэтому так и переживаю за AllowOverride.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Сегодня кстати прочувствовал на себе причины почему по дефолту стоит SAFE_REGMODE=1 в alter.ini. :facepalm:

Благо шлюз еще в тесте был и легко поправил косяк через phpMyAdmin.

 

Однако стремает что уникальное поле таблички есть логин а не какойнить замысловато сгенерированный из /dev/random набор хеш сумм.

 

При таком раскладе уж лучше пусть сам биллинг их генерирует и не будет давать их изменять.

 

Хотя и получаются этакие черезмерно замысловатые логины которые по сути сложнее сгенериных паролей.

 

Может прикрутить опцию метода генерации логинов?

По мне так пусть логин и пароль генерется через pwgen like код чем то как оно сейчас генерит основываясь на адресах и рандоме.

 

UPD. Ветку пора переименовать во Флейм :D

Відредаговано Ghost_1987
Ссылка на сообщение
Поделиться на других сайтах
Сегодня кстати прочувствовал на себе причины почему по дефолту стоит SAFE_REGMODE=1 в alter.ini. :facepalm:

Ключевое слово в названии опции SAFE.

 

Благо шлюз еще в тесте был и легко поправил косяк через phpMyAdmin.

Все изменения в табличках users, tariffs и admins - при вмешательстве извне, при запущенном stargazer будут затерты. Все изменения в них происходят при помощи внутренних вызовов конфигураторов старгейзера описанных в опции baseconf конфига billing.ini. sgconfxml к слову тоже по дефолту изза того, что наиболее стабилен на данном этапе.

 

Однако стремает что уникальное поле таблички есть логин а не какойнить замысловато сгенерированный из /dev/random набор хеш сумм.

Модуль store_mysql писал не я - так что вопросы точно не ко мне.

Я бы тоже организовал связывание по банальному автоинкрементному id лучше. Там и пассворды плейнтекстом к слову.

 

При таком раскладе уж лучше пусть сам биллинг их генерирует и не будет давать их изменять.

Он кстати их и генерирует и не дает менять. Именно поэтому и SAFE_REGMODE. Генерация для единообразия происходит так:

[алиас города]+[алиас улицы]+[номер дома]+ap+[номер квартиры]+_(немного рандома, надеемся на отсутствие коллизий)

 

 

Хотя и получаются этакие черезмерно замысловатые логины которые по сути сложнее сгенериных паролей.

В сегодняшних реалиях тотального IPoE вид логина не имеет концептуального значения. Пользователи в 99% случаев и не узнают, что они у них есть.

Основными критериями идентификации пользователей в Ubilling исторически являются адресные данные и возможно ФИО. Оттуда и удобные выбиралки с уличками-домиками и прочие заточки, ориентированные на то, чтобы что пользователи, что персонал на кассах по возможности не особо задумывался о том, что у пользователя есть еще что-то кроме "где вы живете?" и "как вас зовут?".

Адресоориентированность генерации логинов, тоже чисто историческая - для удобства разбора полетов по логам, постоянно не гоняя неизвестно куда, чтобы посмотреть "а что же это за юзер?".

 

По мне так пусть логин и пароль генерется через pwgen like код чем то как оно сейчас генерит основываясь на адресах и рандоме.

Можно, че. Мне рандома не жалко - забирайте сколько хотите :)

 

Но не раньше 0.3.4 точно. Не хочется ничего более-менее критичного (таким считается работа с баблом, регистрациями, сетями) трогать на фоне уже на 90% готового релиза.

 

UPD. Ветку пора переименовать во Флейм :D

Да мне без разницы под каким заголовком оправдываться за свою лень ;)

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Все изменения в табличках users, tariffs и admins - при вмешательстве извне, при запущенном stargazer будут затерты. Все изменения в них происходят при помощи внутренних вызовов конфигураторов старгейзера описанных в опции baseconf конфига billing.ini. sgconfxml к слову тоже по дефолту изза того, что наиболее стабилен на данном этапе.

 

Ну вот не скажите, буквально за пол часа до поста менял логин через phpMyAdmin вручную минуя stg.

Есественно после этого билинг сыпанул ошибку, но как то не очень навязчиво, пролечилось это все простым рестартом stg.

В логи старгейзера не заглядывал так как уже не впервой так изменяю табличные данные и все работает, пока :D.

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

Что на самом деле очень удачно получается на вашем творении, после основным телодвижений в настройке

даже домохозяйка сможет регистрировать абонентов.

 

Там и пассворды плейнтекстом к слову.

 

Еще один повод фаерволить все и вся :). Благо конфиг у ipfw не сильно замороченный.

А по хорошему вообще админку прокинуть по внутренней сети без выхода во вне.

На LAN только кабинет пользователя ну и др. плюшки а на WAN вообще все рубануть ну или оставить модуль заявок на подключение.

 

Генерация для единообразия происходит так:

[алиас города]+[алиас улицы]+[номер дома]+ap+[номер квартиры]+_(немного рандома, надеемся на отсутствие коллизий)

 

Лично на мой вкус так бы было лучше (логины были бы короче и если вдруг хотелка захочет авторизацию по логинам сделать, не нужно будет абоненту логин-простыню диктовать)

(немного рандома)

 

При чем рандом генерировать исходя из текущей даты, времени на серваке, ну и еще так чегонить подкинуть. И всю это ересь привести в читаемый вид, не больше 8-12 символов.

 

В сегодняшних реалиях тотального IPoE вид логина не имеет концептуального значения. Пользователи в 99% случаев и не узнают, что они у них есть.

Основными критериями идентификации пользователей в Ubilling исторически являются адресные данные и возможно ФИО. Оттуда и удобные выбиралки с уличками-домиками и прочие заточки, ориентированные на то, чтобы что пользователи, что персонал на кассах по возможности не особо задумывался о том, что у пользователя есть еще что-то кроме "где вы живете?" и "как вас зовут?".

Адресоориентированность генерации логинов, тоже чисто историческая - для удобства разбора полетов по логам, постоянно не гоняя неизвестно куда, чтобы посмотреть "а что же это за юзер?".

[/code]

 

Тут конечно не спорю, но реалии таковы что не каждый оператор может себе позволить ставить управляемые свичи, некоторые даже и не слышали о таких. А по мне IPoE без возможности контроля на уровне магистралей как то стремна.

Так и живем еще в 2000 -х :facepalm:

 

Можно, че. Мне рандома не жалко - забирайте сколько хотите :)

 

Но не раньше 0.3.4 точно. Не хочется ничего более-менее критичного (таким считается работа с баблом, регистрациями, сетями) трогать на фоне уже на 90% готового релиза.

 

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

 

А большего от халявы и не требуется :)

Відредаговано Ghost_1987
Ссылка на сообщение
Поделиться на других сайтах
Ну вот не скажите, буквально за пол часа до поста менял логин через phpMyAdmin вручную минуя stg.

Это вы пока не попробовали с этим пользователем ничего сделать. Денег например добавить, или тариф сменить.

Stargazer читает данные из базы только при запуске, после чего держит их актуальными в памяти и вносит изменения в базу когда ему это нужно. При этом все внешние изменения затираются.

Именно поэтому такая здоровая кухня с конфигураторами и прочими штуками нагорожена - Ubilling родные таблички stargazer использует только в режиме read-only - все остальное через многоступенчатые прослойки и уровни абстракции.

 

В логи старгейзера не заглядывал так как уже не впервой так изменяю табличные данные и все работает, пока

Хотелось бы откровение Иоанна Богослова поцитировать, да не буду. :facepalm:

 

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

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

 

даже домохозяйка сможет регистрировать абонентов.

Изначально рассчитано на миловидных девиц на кассах и супорте :)

 

То что оно иногда приводит к хаосу, панике, разрушениям и апокалипсису - побочный еффект.

 

Благо конфиг у ipfw не сильно замороченный.

Не iptables + tc/htb, да? ;)

 

А по хорошему вообще админку прокинуть по внутренней сети без выхода во вне.

Ну вобще-то да.

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

 

Лично на мой вкус так бы было лучше (логины были бы короче и если вдруг хотелка захочет авторизацию по логинам сделать, не нужно будет абоненту логин-простыню диктовать)

Такие вещи принято не диктовать по телефону абоненту (да-да ЭС такая как доллар блжад) а выдавать при регистрации. Шаблонизируемая печать документов для этого и есть в "черной магии".

 

При чем рандом генерировать исходя из текущей даты, времени на серваке, ну и еще так чегонить подкинуть. И всю это ересь привести в читаемый вид, не больше 8-12 символов.

Какой-то не рандомнный рандом получается в вашем понимании. С таким понтом проще взять и тупо использовать unix timestamp.

 

Тут конечно не спорю, но реалии таковы что не каждый оператор может себе позволить ставить управляемые свичи, некоторые даже и не слышали о таких. А по мне IPoE без возможности контроля на уровне магистралей как то стремна.

Сеть построенная на все 100% на неуправляемом железе обречена по своей сущности - первым же колечком воткнутым патчкордом, например. В случае крайнейшей бедности и нищиты минимальный набор мер по обеспечению хотя-бы какой-то минимальной живучести (сегментация сети, dhcp-snooping, loop guard, ip source guard, парочка ACL) достаточно хотя-бы одного(!) стобаксового свича на уровне агрегации. Ну чтобы оно не все сразу дохло а хотя-бы частями.

Модные в 00-х наколенные решения типа PPPoE/PPTP в несегментированной сети на 100% состоящей из мыльниц не решают вообще никаких проблем. Ни со стабильностью, ни с надежностью ААА. Почему так - догадайтесь сами.

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

Значит еще слабо ознакомились. Это один большой такой... не не так.... здоровенный... не, опять не то.... громадный, во! костыль на ~200k строк. :lol:

 

А большего от халявы и не требуется :)

Это не халява - THIS IS SPARTA OPENSOURCE!!!1

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Это вы пока не попробовали с этим пользователем ничего сделать. Денег например добавить, или тариф сменить. Stargazer читает данные из базы только при запуске, после чего держит их актуальными в памяти и вносит изменения в базу когда ему это нужно. При этом все внешние изменения затираются. Именно поэтому такая здоровая кухня с конфигураторами и прочими штуками нагорожена - Ubilling родные таблички stargazer использует только в режиме read-only - все остальное через многоступенчатые прослойки и уровни абстракции.

 

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

Заглянул в логи старгейзера, подтверждаю что после ручной правки старгейзер отсыпал ошибку, но после его рестарта в тех же логах нет никаких ошибок и все действия с пользователем логируются в соответствии с его новым логином.

 

Вот такие дела. Возможно такая ситуация наблюдается со старой версией старгейзера?

 

Какой-то не рандомнный рандом получается в вашем понимании. С таким понтом проще взять и тупо использовать unix timestamp.

 

Имел ввиду как то так (ниже питонокод):

import hashlib
import time
hash = hashlib.sha1()
hash.update(str(time.time()))
print hash.hexdigest()
print hash.hexdigest()[:10]

 

По поводу наколенных решений типа PPPoE/PPTP и присутствия хотя бы одного управляемого свича на месте схода всех магистральных линий, полностью согласен :) .

Відредаговано Ghost_1987
Ссылка на сообщение
Поделиться на других сайтах
Вот такие дела. Возможно такая ситуация наблюдается со старой версией старгейзера?

Нет

 

но после его рестарта в тех же логах нет никаких ошибок и все действия с пользователем логируются в соответствии с его новым логином.

Ключевой момент "после рестарта".

 

Допустим есть себе запущенный старгейзер - вы исправляете поле cash юзера на ручнике с 50, до скажем на 100. Всюду отображается что у него таки 50 денег на балансе. После чего добавляете ему 20 денег и оппа - у него на счету 70 денег.

Старгейзер перечитывает базу только на старте, после чего просто ее "помнит". Так есть и так было всегда.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
но после его рестарта в тех же логах нет никаких ошибок и все действия с пользователем логируются в соответствии с его новым логином.

Ключевой момент "после рестарта".

 

Допустим есть себе запущенный старгейзер - вы исправляете поле cash юзера на ручнике с 50, до скажем на 100. Всюду отображается что у него таки 50 денег на балансе. После чего добавляете ему 20 денег и оппа - у него на счету 70 денег.

Старгейзер перечитывает базу только на старте, после чего просто ее "помнит". Так есть и так было всегда.

 

Я так изначально и понимал :). Теперь еще более уверен.

 

Подводя итог, если не дай бог появится необходимость править базу в ручную, тушим старгейзер, правим, стартуем.

Но это есть ересь по отношению к биллингу, этот акт не рекомендуется к воспроизводство и вообще ни как не комментируется разработчиком. ;)

Відредаговано Ghost_1987
Ссылка на сообщение
Поделиться на других сайтах
Подводя итог, если не дай бог появится необходимость править базу в ручную, тушим старгейзер, правим, стартуем.

да

 

Но это есть ересь по отношению к биллингу, этот акт не рекомендуется к воспроизводство и вообще ни как не комментируется разработчиком. ;)

комментируется - в FAQ про это есть ;)

Ссылка на сообщение
Поделиться на других сайтах

...

Но это есть ересь по отношению к биллингу, этот акт не рекомендуется к воспроизводство и вообще ни как не комментируется разработчиком. ;)

Я об этом уже столько раз говорил что, скорее всего, просто забыл описать в документации.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

...

Но это есть ересь по отношению к биллингу, этот акт не рекомендуется к воспроизводство и вообще ни как не комментируется разработчиком. ;)

Я об этом уже столько раз говорил что, скорее всего, просто забыл описать в документации.

 

Подозреваю что ее никто не читает. А учитывая что есть такой няшечный веб морда к stg, к нему (stg) будут вообще относиться как к еще одной фигне которую нужно поставить чтобы это все заработало :) .

 

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

 

Там скорее для разработчиков и модуляписателей нежели для простых смертных :) .

 

Ну а ведь всегда же хоца чтобы завелось сразу, с пол пинка. И только апосля, если не завелось, с грустью погружаешься в чтение манов.

Відредаговано Ghost_1987
Ссылка на сообщение
Поделиться на других сайтах
Подозреваю что ее никто не читает.

Это кажется бич любого продукта :(

 

А учитывая что есть такой няшечный веб морда к stg, к нему (stg) будут вообще относиться как к еще одной фигне которую нужно поставить чтобы это все заработало :) .

Пздц комплимент :D

 

Вы того, осторожнее, а то madf сейчас обидиться и интегрирует в stargazer самоуничтожение при одном виде StoreModule store_mysql. Его и так уже морально добивают расплодившиеся "инсталлерные" пользователи. :P

 

P.S. имеете возможность еще поискать баги в обновляторе, вкатив себе каррент релиз.

Ссылка на сообщение
Поделиться на других сайтах
А учитывая что есть такой няшечный веб морда к stg, к нему (stg) будут вообще относиться как к еще одной фигне которую нужно поставить чтобы это все заработало :) .

Пздц комплимент :D

P.S. Вы того, осторожнее, а то madf сейчас обидиться и интегрирует в stargazer самоуничтожение при одном виде StoreModule store_mysql :P

 

Зачем обижаться ведь на самом деле продукт (stg) хороший, просто страшный в плане "Ох ёпт твоюж, сикоко тут всяго, как это фсе конфигить, да еще и через консоль"

 

P.S.2. имеете возможность еще поискать баги в обновляторе, вкатив себе каррент релиз.

Сервак ушел в продакшен, протестирую наверно уже немного папожа, а там гляди еще одну новую версию выкатите. :)

Ссылка на сообщение
Поделиться на других сайтах
Сервак ушел в продакшен, протестирую наверно уже немного папожа, а там гляди еще одну новую версию выкатите. :)

Знаете анекдот про "с мягким знаком"?

Дык вот - с мягким знаком потом обновляться. Оно уже в продакшне с обеда у десятка сетей. Багфиксы там достаточно критичных вещей.

Ссылка на сообщение
Поделиться на других сайтах

Оно уже в продакшне с обеда у десятка сетей. Багфиксы там достаточно критичных вещей.

 

Ну я и не спорю что нужно обновляться дабы пофиксить старые баги и найти новые. :)

 

Но как бэ сервак еще в пути на продакшен, физически не доступен и в полном оффлайне.

Вот как доступ будет, сделаем.

 

P.S. Я так понимаю что обновления не инкриментальные, а тупо накати сверху пачку файлов и ручками поправь основные конфиги.?

Ссылка на сообщение
Поделиться на других сайтах
P.S. Я так понимаю что обновления не инкриментальные, а тупо накати сверху пачку файлов и ручками поправь основные конфиги.?

Да, плюс в большинстве своем еще и "вкати патч на БД на ходу", просто в последнем как-то обошлось без этого. Вот такой вот занятный деплоймент :)

 

Кроме того, я даю гарантию что при реальном использовании у вас начнут воротиться какие-то свои примочки-дописки-довески-обвески требующие развертывания поверх новых релизов. Это к слову, что придется обновлялку под свои нужды править.

Ссылка на сообщение
Поделиться на других сайтах

Кроме того, я даю гарантию что при реальном использовании у вас начнут воротиться какие-то свои примочки-дописки-довески-обвески требующие развертывания поверх новых релизов. Это к слову, что придется обновлялку под свои нужды править.

 

Буду обновлять вручную а обновлялку использовать как шпаргалку.

Не хоца попасть на грабли на продакшене.

Ссылка на сообщение
Поделиться на других сайтах

Буду обновлять вручную а обновлялку использовать как шпаргалку.

Вам виднее. Всеравно потрудитесь оформить эту свою "вручную" до состояния скрипта - будет веселее ;)

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...