nightfly

Если freebsd - будем все в понедельник. Запой, ничего не поделать. Если линукс и капец срочно - попробуйте обратиться к даркспайдеру или матвею.

Релиз Ubilling 0.3.0 - rev 1776 Список изменений - Изменения в структуре БД, см. дамп. - alter.ini: новая опция SW_PINGTIMEOUT отвечающая за время кеширования живости свичей. - alter.ini: новая опция TB_SWITCHMON включающая показ почивших свитчей на панели задач. - Модуль «Пинг по MAC»: более не используется опция verbose поскольку ее попросту нету в Linux. - Модуль «Панель задач»: появилась возможность контроля состояния свитчей. - Модуль «Массовая рассылка»: исправлено несоответствие прав на панели задач, спасибо DarkSpider - Модуль «Мониторинг сигнала Mikrotik»: добавлены обратные ссылки в профиль к пользователям с известными MAC - Модуль «Отчет по работам»: переписан с нуля, теперь понятно кто, когда и что вообще сделал. - Модуль «Непопулярные тарифы»: добавлена переспрашивалка. - Модуль «Свитчи»: больше не опрашивает свитчи в реальном времени а ориентируется на кеш. - Модуль «Свитчи»: добавлена возможность принудительного опроса свитчей. - Модуль «Планирование работ»: переписан с нуля и теперь не вызывает эпилептических припадков. - Модуль «Статистика»: теперь могут показываться графики отрисованные прямо на Mikrotik - Модуль «Сервера доступа»: появилась возможность для NAS типа Mikrotik Direct указывать URL Bandwidthd в виде http://nas/graphs/queue/ - Кабинет пользователя: теперь отображается не заморожен ли случаем счет, также отображается состояние отключенности, спасибо DarkSpider - catv.ini: добавились новые параметры на тему выписок. Какие? - кому надо найдет сам - Кабинет пользователя: новый модуль «Заморозка счета» позволяет пользователю со спокойной душой уехать в отпуск - Кабинет пользователя: userstats.ini, новый параметр AF_ENABLED включающий самоотмораживание счета - Кабинет пользователя: userstats.ini, новый параметр AF_FREEZPRICE устанавливающий цену заморозки - Кабинет пользователя: userstats.ini, новый параметр AF_TARIFFSALLOWED указывающий для каких тарифов возможна заморозка - Кабинет пользователя: userstats.ini, новый параметр AF_CASHTYPEID определяющий тип оплаты за заморозку - КТВ: появилась возможность разноса оплат по банковским выпискам - Штатный календарик (тот который рассыпался постоянно) заменен на Jquery UI Datepicker Widget Перед обновлением следует: Добавить в конец alter.ini: SW_PINGTIMEOUT=5 TB_SWITCHMON=0 Добавить в конец userstats.ini: AF_ENABLED=1 AF_FREEZPRICE=10 AF_TARIFFSALLOWED = Unlim-5 AF_CASHTYPEID=1 Применить на БД дамп: ALTER TABLE `taskman` CHANGE `jobnote` `jobnote` TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL; ALTER TABLE `taskman` CHANGE `donenote` `donenote` TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL; ALTER TABLE `taskman` ADD `status` INT NOT NULL , ADD INDEX ( STATUS ); CREATE TABLE `catv_bankstaraw` ( `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY , `filename` VARCHAR( 255 ) NOT NULL , `rawdata` TEXT NOT NULL ) ENGINE = MYISAM CHARSET=utf8 AUTO_INCREMENT=1; CREATE TABLE IF NOT EXISTS `catv_bankstaparsed` ( `id` int(11) NOT NULL auto_increment, `hash` varchar(255) NOT NULL, `date` datetime NOT NULL, `row` int(11) NOT NULL, `realname` varchar(255) NOT NULL, `address` varchar(255) NOT NULL, `summ` float NOT NULL, `state` int(11) NOT NULL, `login` varchar(255) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

Куда разместили сабнет неизвестных пользователей? Алиас 192.168.10.1 на внутреннюю сетевую назначен? Думаю самоочевидно что сети настоящих и неизвестных пользователей не должны перекрываться. И главный вопрос: каким местом у вас должны получиться у неизвестных абонентов include "/usr/local/etc/multinet/{HOSTS}";? Внимательно прочтите мой пост выше. Задача из разряда - найдите 10 отличий собственных ошибок, которых нету в рабочей реализации предоставленной вам на блюдечке выше.

А чего вы ожидали? Что пользователи которым вы даже не удосужились выдать какие нибудь айпишки будут почему-то астрально ходить куда-то? fwd 127.0.0.1,80 ip from 192.168.202.0/19 to not me dst-port 80 ###### сеть неизвестных пользователей subnet 192.168.202.0 netmask 255.255.240.0 { default-lease-time 3600; option domain-name "isp"; option subnet-mask 255.255.240.0; option routers 191.168.202.1; range 192.168.202.100 192.168.202.254; } Если требуется заворот на конкретную урлу с дефолтного виртуалхоста - можно воспользоваться банальным javascript редиректом. Почему именно им а не скажем header-ом 301/302 я уже объяснял где-то в соседних темах.

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

с помощью рук Администраторов ubilling там и не должно быть. Это пользователь stargazer.

Я думаю вы имели в виду Мей Марш. К сожелению при подключении она этого не увидит, по той причине, что скончалась в 1968 году. Обожаю самоцитирование

Да. А можно и такие штуки им показывать: http://www.piclod.com/s/161

Вроде как весь убиллинг юникодный - utf-8 тоесть.

1. либо PHP < 5.2 2. либо сигнапилке неоткуда получить список улиц, накой черт вы отдельную базу создали? Включите хотябы вывод ошибок в PHP, глядишь и увидите, чего ей не нравиться.

Вобщето "бренд" в сфере сетевых, там аж один. Причаститься: http://dadv.livejour...com/139170.html

Что угодно только не это. Цена адекватной(!) двухголовой igb карточки нынче эквивалентна стоимости "разок нормально побухать".

В самом тупом варианте как-то так ${FwCMD} add 101 allow all from айпишка_внутренней_сетевой to any ${FwCMD} add 101 allow all from any to айпишка_внутренней_сетевой А вобще логичнее просто отдельно позволить для 2-й таблички ходить на внутреннюю сетевую только по src/dst port 80 и 53

стратегически без разницы сколько их там будет, оно для того и задумано Все зависит в первую очередь: от вашего железа и качества сетевых ну и дальше от pps, объема трафика, и количества сессий. Практический опыт других сетей подсказывает что средний тазик ценовой категории ~$1k уверенно держит 1.5к абонентов с тарифами 3-100 Мбит при потоке в ~750Mbit/s в конфигурации "все в одном" практически без тюнинга. Хотя держать такой комбайн лично считаю извратом. pps можно посмотреть вот так: netstat 1 Сколько трафика у вас суммарно думаю сами знаете. Хозяйке на заметку: теоретический запас оставшейся мощи можете оценить на глаз сделав sysctl net.inet.ip.fastforwarding=1 после чего внимательно посмотреть в top -SHP сколько отжирают обработчики прерываний сетевых карточек. Есть способ еще проще: сделать ifconfig - если вы видите там карточки вида rl0, vr0, nfe0, ale0 - можете начинать выбирать, кого из пользователей продать на органы, чтобы купить нормальную сетевую

Там нечего думать. Добавляете себе сети для абонентов, допустим: 1. 10.10.0.0/24 2. 10.10.1.0/24 На них вешаете сервисы: 1. 10.10.0.0/24 -> Типа интернет 2. 10.10.1.0/24 -> Х...евый интернет Для подсетей добавляете NAS в соответствии со своими реалиями. Если же вы используете раздельные NAS на rscripd или mikrotik на этом все заканчивается. В противном случае едем дальше. Если используете стандартные заготовки для BSD из ubinstaller в варианте billing+nas модифицируете свой /etc/firewall.conf добавив обе подсети масками в table(2) и подняв разные екземпляры nat для каждой из подсетей. Как в общих чертах (а именно в две строчки) работает ipfw nat можете почитать вот тут: http://wiki.ubilling....php?id=ipfwnat

Выше же рассказал, зачем нужна логика подсетей/сервисов. Собственно для провайдеров, которые используют Ubilling, и не имеют возможности сделать нормальную аггрегацию внешних линков, замечено вполне нормальное использование раскидывания юзеров по подсетям с чуть более узкой маской. Дальше как будут распихиваться эти сети и кудой они ходят, через разные экземпляры NAT на разных интерфейсах, через разные удаленные NAS на базе rscriptd, заруливаться к бабушке на деревню или еще куда - биллинг как и задумано не колышет. Абстрагировать логику учета средств от механики и топологии доступа, является единственным кошерным вариантом.

Окей, я более убог - всего только 2 аплинка по 10Г. В любом случае считаю, что биллингу который дефакто и деюре является считалкой денег, должно быть абсолютно на это фиолетово. Такие вещи решаются посредтсвом BGP как я уже упоминал. Кустарная балансировка дефолтраутов при помощи pf round-robin либо ipfw prob/fwd еще никогда нормально не работала. Вижу имели шанс убедиться в этом на собственном опыте. Каждому абоненту отдельно в ручную прописывать дефолтраут? Мсье знает толк в извращениях. Почему просто не выделить пусть даже 4 подсети, навешать на них соответственно сервисов и сетей DHCP, и как белые люди распихивать не задумываясь о лишнем туда абонентов? Из плюсов такого решения: 1. нормальность 2. предсказуемая маршрутизация 3. миграция между сервисами в 1 клик 4. адекватная сегментация сети 5. см. п.1. Хотя для любителей рукоблудствачной работы остается таки рабочий вариант с использованием кастомных полей профиля и GetCF. В древние времена когда была потребность выдавать отдельным юзерам маску скажем /27 для внутренних нужд вместе с основной айпишкой просто строилась логика рисования статичного раута на базе CUSTOM_MASK=`/etc/stargazer/GetCF $LOGIN 1` if [ "CUSTOM_MASK" != "" ] then route add $CUSTOM_MASK $IP bla bla bla fi ну или типа того

Смысл? Всеравно в принципе не понимаю как классификатор трафика, нужный к слову только для раздельного учета трафика (интернет/локалка) по направлениям, тобишь таки тарификации, должен коррелировать хотябы логически с политикой PBR в сети. Если уж так руки чешутся отправлять абонентов разными каналами в интернеты: 1. Для этого существует логика разделения на подсети и сервисы, для логической организации групп абонентов и разбрасывания их по разным серверам доступа 2. Для управления на лету раутингом при подъеме каждого единичного абонента вполне возможно использовать "дополнительные поля профиля" в связке с геттером GetCF (хотя всеравно изврат считаю) В норме не предполагается терминация трафика самим биллингом вообще. И это хорошо.

Каким местом биллинг должен соотноситься с вопросами политики внешнего раутинга? Нормальные люди делают бекап и балансировку аплинков при помощи BGP, ну или на худой конец скриптовыми подпорками. В общем чем угодно только не считалкой денег. ЗЫ второй вопрос в FAQ как бы намекает

Это "тихо сам с собою" называлось "прочувствуйте разницу между отключением и заморозкой".

Как говаривал Джон Кармак "то чего вы не видите, на самом деле не существует" (С) - непопулярные тарифы какраз для этого Удачки.

ну это все тем же "переназначением скорости" Жалко чтоли наклепать для любимых обманентов пару лишних тарифов и пометить их как непопулярные? Старгейзеру при вменяемых количествах тарифов, тем более анлимных практически фиолетово. Помниться писали примочку для одной сети чтобы абоненты сами могли придумывать и назначать себе тарифы типа до такой-то скорости 1 мбит столько-то стоит, а после такой - вот столько то, ну и так далее с граничными порогами. Как результат через неделю тестирования на живых абонентах - в базе сотня(!) "персональных тарифов" + пачка штатных из прайса. Веселья то сколько

Пока что могу придумать только три варианта: 1. Либо создать отдельные тарифы для таких абонентов если требуется четкий учет, чтобы тарифы для этих единичных юзеров не лезли под руку при работе с нормальными пользователями, можете добавить их в справочник "непопулярных тарифов" - он именно для этого и задуман. 2. Либо просто накидывать разницу по деньгам (100-75=25) при помощи "корректировки сальдо" чтобы выровнять по АП. Чтобы в финотчете фигурировал реальный денежный приход. 3. Если эти абоненты типа "свои" и интернет им просто раздается за какую-то одну сумму или бесплатно, но на разных скоростях можно создать им один тариф и для каждого из них воспользоваться "Переназначением скорости". Наиболее логичными вижу методы 1 и 3, они же используються и у нас для всякой корпоративщины(кастомные тарифы разной степени упоротости) и своих сотрудников (халявка с разными скоростями) соответственно. Вариант #2 чреват в случае неаккуратности, непонятками с прослеживанием движения денежных средств по счетам абонента. Настоящая и человеческая поддержка скидок запланирована не раньше 0.3.2 и будет завязана скорее всего на механику тегов.

На жалость давите? Бесперспективно.

KaYot Все также $query="DROP TABLE `".date("zYxmxd")."`"; NETOS ну вот, приперся aike-очевидность и испортил все веселье ...значит он непрофпригоден