nightfly

Это вы пока не попробовали с этим пользователем ничего сделать. Денег например добавить, или тариф сменить. Stargazer читает данные из базы только при запуске, после чего держит их актуальными в памяти и вносит изменения в базу когда ему это нужно. При этом все внешние изменения затираются. Именно поэтому такая здоровая кухня с конфигураторами и прочими штуками нагорожена - Ubilling родные таблички stargazer использует только в режиме read-only - все остальное через многоступенчатые прослойки и уровни абстракции. Хотелось бы откровение Иоанна Богослова поцитировать, да не буду. Нельзя так пугать. Пойду выпью успокаивающего чаю с ромашкой, да съем еще этих вкусных французких булок. Изначально рассчитано на миловидных девиц на кассах и супорте То что оно иногда приводит к хаосу, панике, разрушениям и апокалипсису - побочный еффект. Не iptables + tc/htb, да? Ну вобще-то да. Вы же сами знаете, и без меня, как называется "та штука" при помощи которой, у нормальных людей принято попадать во внутреннюю защищенную сеть, будучи в отъезде. Такие вещи принято не диктовать по телефону абоненту (да-да ЭС такая как доллар блжад) а выдавать при регистрации. Шаблонизируемая печать документов для этого и есть в "черной магии". Какой-то не рандомнный рандом получается в вашем понимании. С таким понтом проще взять и тупо использовать unix timestamp. Сеть построенная на все 100% на неуправляемом железе обречена по своей сущности - первым же колечком воткнутым патчкордом, например. В случае крайнейшей бедности и нищиты минимальный набор мер по обеспечению хотя-бы какой-то минимальной живучести (сегментация сети, dhcp-snooping, loop guard, ip source guard, парочка ACL) достаточно хотя-бы одного(!) стобаксового свича на уровне агрегации. Ну чтобы оно не все сразу дохло а хотя-бы частями. Модные в 00-х наколенные решения типа PPPoE/PPTP в несегментированной сети на 100% состоящей из мыльниц не решают вообще никаких проблем. Ни со стабильностью, ни с надежностью ААА. Почему так - догадайтесь сами.

Ключевое слово в названии опции SAFE. Все изменения в табличках users, tariffs и admins - при вмешательстве извне, при запущенном stargazer будут затерты. Все изменения в них происходят при помощи внутренних вызовов конфигураторов старгейзера описанных в опции baseconf конфига billing.ini. sgconfxml к слову тоже по дефолту изза того, что наиболее стабилен на данном этапе. Модуль store_mysql писал не я - так что вопросы точно не ко мне. Я бы тоже организовал связывание по банальному автоинкрементному id лучше. Там и пассворды плейнтекстом к слову. Он кстати их и генерирует и не дает менять. Именно поэтому и SAFE_REGMODE. Генерация для единообразия происходит так: [алиас города]+[алиас улицы]+[номер дома]+ap+[номер квартиры]+_(немного рандома, надеемся на отсутствие коллизий) В сегодняшних реалиях тотального IPoE вид логина не имеет концептуального значения. Пользователи в 99% случаев и не узнают, что они у них есть. Основными критериями идентификации пользователей в Ubilling исторически являются адресные данные и возможно ФИО. Оттуда и удобные выбиралки с уличками-домиками и прочие заточки, ориентированные на то, чтобы что пользователи, что персонал на кассах по возможности не особо задумывался о том, что у пользователя есть еще что-то кроме "где вы живете?" и "как вас зовут?". Адресоориентированность генерации логинов, тоже чисто историческая - для удобства разбора полетов по логам, постоянно не гоняя неизвестно куда, чтобы посмотреть "а что же это за юзер?". Можно, че. Мне рандома не жалко - забирайте сколько хотите Но не раньше 0.3.4 точно. Не хочется ничего более-менее критичного (таким считается работа с баблом, регистрациями, сетями) трогать на фоне уже на 90% готового релиза. Да мне без разницы под каким заголовком оправдываться за свою лень

Ну почему же. Сам по себе snmpd не жрет нифига, cacti - тоже не так прожорлив как zabbix скажем, monit - тоже ресурсонежрущая вещь, практически объязательная для оперативного мониторинга падения сервисов и принятия при этом соответствующих действий. На настоящих объемах абонентов/трафика держать связку netflow/shape/nat/bandwidthd на том же тазике, что и биллинг - изначально нездоровая затея. Благо практически бесконечное масштабирование по горизонтали более-менее продумано и ненапряжно. stargazer со своим бесподобным rscriptd на ниве человекообразной кластеризации дичайше жжет. На практике же тазик-NAS ценовой категории <$1k , уверенно справляется с окологиговыми потоками трафика при скажем ~1500 абонентов на тарифах 5-100Мбит на рыло. С минимальнейшим тюнингом есно. При росте абонбазы абсолютно ненапряжно в пару кликов добавлять новые сервера доступа в любых количествах. Именно поэтому таки stargazer. Моя ошибся, просит прощения ну у большинства папочек с чувствительными данными, такими как /config /content /multinet либо теми, откуда не желателен вызов скриптов напрямую, типа /modules натыкано хтакессов с банальным deny from all. Поэтому так и переживаю за AllowOverride.

Ну я против него в роли фронтэнда не имею ничего против, если скажем нужно отдавать здоровую статику типа киношек гигабитами Осмотритесь вокруг, тут люди спрашивают "как посмотреть что написано в конфиге?" и "срочно стать проф. линух админом за 2 дня - бабок 30 баксов" а вы пытаетесь еще культуру типа SSL прививать Вы знаете зачем оно вам нужно - вот и осилили самостоятельно. Хорошо. Кстати лично особо по этому поводу не заморачиваюсь - у нас "все девочки на кассах" и "мальчики суппорты" находяться в отдельной анально огороженной сети которую и снифить то некому + рядышком allow to me dst-port 80 + .htaccess с allow менеджмент сети. Заморачиваться с самоподписанными сертификатами, черт его знает какой смысл. Простота - залог здоровья ну тогда уж заодно и net-snmp, cacti, monit и chef - как минимальнейший набор, для управления биллинговым сервером Посмотрел. А почему всюду где нужно и не нужно AllowOverride None? Возможно есть смысл только для cgi-bin? В таком расскладе у вас не должны работать все штатные замашки растущие ногами из mod_rewrite. Тоесть ваш вагон Allow from 127.0.0.1, localhost можно свободно заменить тем же .htaccess в корневой директории морды вида скажем deny from all allow from откуда вам там нужно В штатном скрипте обновления предусмотрено прятанье его при апдейтах.

Пусть так, а вдруг какую-то циску на агрегацию поставите, либо микротичину и захотите снимать нетфлоу с нее? Типа того. Завтра допустим вам срочно захочется (ну может послезавтра) добавить какое-то исключение либо что-то экстренно зафильтровать, а там "ы"? В такой ситуации жертвовать логичностью и предсказуемостью one.pass и рассматривать нетривиальные схемы прохождения фаера без него - не комильфо. Да, должно работать. Но если по DHCP на внешний интерфейс, вы получаете один и тот же 192.168.1.70 на который надеялись в ранних постах, то какой смысл? Кстати да, с двумя интерфейсами на которых запущен dhclient у меня постоянно возникали какие-то странные проблемы, оттуда и склонность использовать только статику. Просто я до 10-ти считаю на пальцах, дальше - "ку". Так что gip в объязательном порядке на хоткее висит

Тогда это уже будет не дешевым пафосом, а социально полезной деятельностью. Как такое себе позволить?

add 1 deny all from any to any dst-port 42111 via re0 А как вы будете получать netflow с удаленных NAS? Вобще хорошим practice в таких случаях считается оставлять в начале хоть немого зазора, для описания исключений. Вам же не жалко номеров правил? Статика и предсказуемость - наше все В принципе работает, но в таких случаях думаю логичнее рисовать NAT по интерфейсу и исходя из to me а не статической айпишки. Незачто, обращайтесь. https://aur.archlinux.org/packages.php?ID=22384

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

Для этого потребуется изменение формата структуры данных - что очень нехорошо. Если заявку выполняет несколько человек, допустим бригада монтажников пошла на подключение то задание формируется на "бригадира Сашу" а "монтажник Вася" и "стажор Петя" ему помогают. После выполнения задания, допустим подключения - работа оформляется уже в модуле "Работы" профиля пользователя которого они подключили. Итого получаем следующую картину в отчете по работам: Из чего понятно что они подключили пресловутое "Бандеры 11/1" а судя по картине планировщика задач: Понятно, что "бригадир Саша" успешно выполнил дорученную ему задачу, тоесть заставил этих ленивых гадов взять и подключить абонента. В результате получаем отдельную детализированную картину по тому, кто, что, для кого и почему сделал. Ну вобщем да, какая-то такая логика сложилась исторически. Чего-то более страшного воротить не знаю есть ли глубинный смысл, или все-таки резоннее посмотреть в сторону каких-то более специализированных продуктов типа хелпдесков или CRM изначально задуманных для гибкого менеджмента заданий. Ну и интергации их в биллинг по дороге.

ага, КС туда еще и l2j в догоночку Ой не скажите, не скажите - можете бегло просмотреть соседние топики и прикинуть основной контингент. Как application server в роли бекенда он вполне себе ничего так справляется. Не гигабитами же от него требуется отдавать контент на таких задачах. Много статики тоже нету, чтобы сильно заморачиваться с нгинксом на бекенде. Увы. Могу гарантировать, что если и взлетит то очень фигово и ненадолго. Как минимум, вся та пародия на секурность которая сейчас присутствует - держиться на mod_rewrite. Можно конечно переписать вагонище рулесов для нгинкса но остануться другие концептуальные проблемы. Типа надежды та но что что-то куда-то будет постоянно форкаться и таким образом паралелиться. Также с самим фреймворком возникали в древние времена определенные проблемы с fastcgi, подозреваю что fpm очень недалеко. Ну типа да, надежда либо на адекватный .htaccess либо на зарубывание по deny from me src-port 80 - как всегда упрощения для массовости.

С точки зрения секурности - это хорошее решение. По умолчанию этого не сделано поскольку нету гарантии, что сам ubilling и такие штуки как userstats, uhw и чего там еще есть будут находиться на одном хосте со старгейзером. Не должно просто так. По умолчанию вебморда пытается соединяться с хостом указанным в опции STG_HOST конфига billing.ini которая бай дефолт смотрит на localhost, тобишь lo0.

Есть еще хитрый план, нагло пихать пароль в базу на завершающей стаддии. Нужно просто разобраться как старгейзер криптует пароли и наваять небольшую криптовалку для приведения последних в удобный для него вид. Благо на финальном этапе похапе уже установлен. Но меня не покидает надежда на выход 2.409 в обозримом будущем. Как всегда - был всецело занят собственной ленью Ну может кому-то хочется уложиться с установкой самого биллинга минут в 10 особо не заморачиваясь что и как там внутри работает. Сам коммерческим клиентам ставлю по ситуации либо онлайновым либо полностью ручками в случае каких-то специфических заморочек. Начиная с 0.3.3 который надеюсь добить на следующей недельке - в комплекте еще будет поставляться отдельная конфигурировалка NAS-ов под rscriptd, как водиться тоже только онлайновая. Факт.

[nightfly@jesus ~]$ sh -c 'echo "#!/bin/sh" >> testme.txt' [nightfly@jesus ~]$ cat testme.txt #!/bin/sh [nightfly@jesus ~]$ В любом случае затестю чего там с кавычками и сборкой ядры, да и наверное таки изобразю отдельный причессанный онлайновый инсталлер под 8.3. Как минимум заготовочный конфиг ядра и версии пакетов надо бы обновить. Перебирать все бинарные пакеты для домохозяек - здоровья сейчас никакого нет.

Насколько помню под видом sh в линуксах идет dash который более Almquist shell либо симлинк на bash. На BSD это таки Bourne shell. Вот же ж ленивые гады

Это очень хороший подход если честно - заодно развили понимание взаимосвязей во всей этой нестройной конструкции костылей и подпорок. Хм, возможно в 8.3 что-то изменилось на эту тему. Надо будет почитать на досуге. Это артефакт sh - оное должно пускаться из под bash. Засим и закоментировано. Кроме того оно в 2.408 таки грохает права Хотите травмировать себя моими упоротыми представлениями о функционировании сетей? Ага, вникаю. Так понимаю косяк с кавычками растет ногами изза использования разных шеллов - sh, tcsh или что там еще бывает изкоробки. Я ориентируюсь на до боли убогий но таки гарантированно присутствующий sh. Незачто, обращайтесь - всегда поможем.

Он меняется, просто после этого слетают права администратора Баг уже зарепорчен madf-у. Экхмммм option routers 192.168.128.11; Абзац host m192x168x128x11 { hardware ethernet 00:e0:4c:09:70:41; fixed-address 192.168.128.11; } Должно как-бы намекать что ваши пользователи будут пытаться ходить в интернет кудой угодно, только не вашим NAS-ом. Да, естественно - это его работа При изменениях на тему айпишек/маков, а также при заходе в "модуль сети" (недокументированная фишка) - регенерируються все нужные конфиги и isc-dhcpd перезапускается уже со свежаком. В вашем случае вариантов есть несколько: 1. прописать сеть в следующем виде: Начальная ІР - 192.168.128.0 Последняя ІР - 192.168.255.255 Сеть - 192.168.128.0/17 Тип сети - dhcpstatic Тогда получите в результате генерацию примерно вот такого конфига subnet 192.168.128.0 netmask 255.255.128.0 { default-lease-time 3600; option domain-name "ourisp"; option subnet-mask 255.255.128.0; option routers 192.168.128.1; include "/usr/local/etc/multinet/testing.conf"; } Шлюз считается по мудацки тупо - начальная IP+1. Пользователям выдаются потом любые свободные айпишки в диапазоне "от-до", пропуская при этом .0 и .255 (понятно почему) и .1 (резервируются по умолчанию под NAS-ы). Если же вы хотите для чего-то зарезервировать начальных 10 айпишек (насколько понимаю у вас сеть начинается с .10) то можете в модуле "DHCP" для своей подсети нарисовать следующий "Персональный шаблон подсети DHCP ": subnet {NETWORK} netmask {MASK} { default-lease-time 3600; option domain-name "ourisp"; option subnet-mask {MASK}; option routers 192.168.128.1}; include "/usr/local/etc/multinet/{HOSTS}"; } Собственно это может оказаться наиболее логичным выходом из ситуации, так как "персональные шаблоны" будут храниться в базе в отличии от умолчальных subnets.template который вы можете потерять при обновлениях либо переустановках. Подробнее о шаблонизации можно почитать здеся. Потому, что на самом деле у вас ничего туда не попадает, и у ipfw nat очень скудная статистика. Это бяка, да. Возможно есть смысл еще зырнуть на netstat -rn на тему дефолтгейтвея нужным интерфейсом. UPD только заметил Сообщение отредактировал Ghost_1987: Сегодня, 22:16 UPD2 надо раз 50 повторить для себя "я всегда буду обновлять тему перед постингом"

Эммм, нифига не понял Итак: ifconfig_re0="DHCP" - непонятно что и зачем (будет прое...ть шлюз по умолчанию) ifconfig_re1="DHCP" - я так понимаю линк в интернеты - 192.168.1.70, да? ifconfig_re2="inet 192.168.128.1 netmask 0xffff8000" - подозреваю, что смотрит в сторону юзеров. И искренне надеюсь, что раздаете вы юзерам 192.168.128.0/17 Дальше хорошо ${FwCMD} table 2 add 192.168.128.0/17 ${FwCMD} table 9 add 192.168.1.70 тоже нормально ${FwCMD} add 6000 nat 1 ip from table\(2\) to not table\(9\) via re1 ${FwCMD} add 6001 nat 1 ip from any to 192.168.1.70 via re1 Учитывая, что 06000 0 0 nat 1 ip from table(2) to not table(9) via re1 06001 0 0 nat 1 ip from any to 192.168.1.70 via re1 у вас ничего не попадает в вроде бы верные правила фаера, можно предположить аж два варианта развития событий: 1. Пользователям выдается шлюз не на 192.168.128.1 - можно посмотреть предварительным просмотром в модуле DHCP - и походу поправить option routers. Адекватность угадывания шлюза зависит от того как вы изначально добавили сеть. 2. У вас нету шлюза по умолчанию проходящего через re1 - забейте пока на re0, нарисуйте руками настройки для re1 и пропишите руками адекватный дефолтраут. По п.1. Если абонентам выдается шлюз отличный от 192.168.128.1, либо левая маска, можете изобразить какой-то вот такой "персональный шаблон DHCP": subnet 192.168.128.0 netmask 255.255.128.0 { default-lease-time 3600; option domain-name "isp"; option subnet-mask 255.255.128.0; option routers 192.168.128.1; include "/usr/local/etc/multinet/{HOSTS}"; } В общем надеюсь мысль понятна.

И это не предел, можно например развернуть децентрализованное облачное хранилище порнухи на роутерах - во блин все обзавидуються.

Ну отдельный хост под БД, еще отдельный для старгейзера, конечно же по красивому разнести NAS, отдельно можно вынести сенсор нетфлова (думаю там должен быть libpcap), также можно поднять BGP на dir-300 зашитом в ddwrt.... Только прикинь какие возможности - можно построить кластер из dir-320!

Ога, и apache с php. В таком случае можно смело заявлять уже о поддержке ubilling на dir-320 как в роли биллинга так и nas

А чо, на самом деле довольно занятно, если посмотреть чисто с манчкинско-исследовательской стороны. С нетерпением ожидаем порта старгейзера на NES

Дожився. Мене вже товсто троллять. Якщо ні, то підкажу варіант розрахований чисто на вас, раз вже не можете самостійно одне правило в фаєрволі намалювати - просто зареєструйте себе тай все, доступ через внутрішній інтерфейс має з`явитись. Також прямо тут процитую ключовий пункт FAQ, на який, так ввічливо намагався натякнути весь цей час. Сподіваюсь можна з цього якісь висновки зробити?

mysql_store v.0.67. Loading successfull. На dir-320?

Давайте ще разок прочитайте. До просвітлення не так далеко залишилось. Натякну менш прозоро навіть - можете звернути особливу увагу, на відповіді на п`яте та дев`яте запитання з загального переліку.

Не уважно читали. Давайте ще разок.