nightfly

Релиз Ubilling 0.3.7 rev 2339 Список изменений: - Изменения в структуре БД, см дамп. - alter.ini: новая опция TB_UBIM включающая уведомления о новых сообщениях - alter.ini: новая опция TB_UBIM_REFRESH вечающая за таймаут AJAX проверки новых сообщений - alter.ini: новая опция UBIM_REFRESH отвечающая за таймаут AJAX проверки поступления новых сообщений - alter.ini: новая опция GRAVATAR_DEFAULT указывающая модель генерации аватар по умолчанию. - Модуль «Профиль пользователя»: исправлена проблема с отображением паспортных данных - Модуль «Работы»: бессовестно рефакторнут - Модуль «Работы»: больше не получится воспользоваться при отсутствии сотрудников либо типов задач - Модуль «Сети и услуги»: косметическая чистка - Модуль «Статистика по трафику»: безжалостно переписан - Модуль «Статистика по трафику»: исправлено отображение графичков с NAS типа mtdirect - Модуль «Статистика по трафику»: теперь графики с NAS типа mtdirect в меньшем окне - Модуль «Редактирование ВсегдаОнлайн»: улучшено логирование - Модуль «Карта оборудования»: в «поиске координат» теперь возможно визуально расставлять свитчи по карте - Модуль «Хелпдеск»: теперь использует gravatar для отображения администраторов - Новый модуль «Сервис мгновенных сообщений»: позволяет общаться администраторам между собой - Модуль «Панель задач»: теперь умеет уведомлять о новых входящих сообщениях - Модуль «Бекап БД»: появился функционал для очистки БД от ставших ненужными данных - КТВ: теперь есть «Корректировка сальдо» - КТВ: теперь есть «Фиктивный платеж» - КТВ: теперь есть «Установить счет» - КТВ: немного причесана формочка добавления денег - КТВ: теперь отображаются оплаты не только за текущий год - КТВ: теперь возможна шаблонизация при печати должников в catv_debtors.tpl - КТВ: новый отчет «Текущие должники для разноса, по адресам» - API удаленного вызова: новый вызов autocleandb предназначенный для периодической зачистки БД - OpenPayz: появился фронтенд работы с платежной системой "Новоплат" Перед обновлением следует Вкатить вот такой дампик на БД: CREATE TABLE IF NOT EXISTS `catv_paymentscorr` ( `id` int(11) NOT NULL auto_increment, `date` datetime NOT NULL, `userid` int(11) NOT NULL, `summ` float NOT NULL, `from_month` int(11) NOT NULL, `from_year` int(11) NOT NULL, `to_month` int(11) NOT NULL, `to_year` int(11) NOT NULL, `notes` varchar(255) default NULL, `admin` varchar(255) default NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1; CREATE TABLE IF NOT EXISTS `ub_im` ( `id` int(11) NOT NULL AUTO_INCREMENT, `date` datetime NOT NULL, `from` varchar(255) NOT NULL, `to` varchar(255) NOT NULL, `text` text NOT NULL, `read` tinyint(4) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1; В alter.ini добавить следующие опции: TB_UBIM=1 TB_UBIM_REFRESH=0 UBIM_REFRESH=60 GRAVATAR_DEFAULT="monsterid" Как водиться живая демка тут.

Одного не можу зрозуміти - звідки звичка реплікувати на себе загальнодержавні проблеми? В себе їх категорично простіше вирішити і забути ніж в глобальних масштабах. З того і варто починати - за звичай більшість проблем криється тяжкому наслідді. Памятаю "проблема" була 7к юзерів в московії перетягнути з з самопала і pppoe на ubilling з dhcp - а це я навіть не знаю як називається, але точно не "проблемою". От бачите - самі собі і визначили шлях до подальшого розвитку, що якраз добре.

Ага, коли провайдери з пятизначними кількостями абонентів мігрують на якусь біллінгову систему, вони точно не "бігають по селі" а спочатку думають про конвертацію абонбази. Благо простих як дошка засобів для цього передбачено цілу купу - від прямої роботи з базою до зручної "консолі розробника". Якщо в провайдера нема відповідних фахівців здатних просто зробити з одної БД іншу - вони просто звертаються до розробника. Є підозра що останній точно знає як в фіналі має виглядати цілістна сконвертована БД. В нормі перехід в продакшні займає рівно стільки часу аби переткнути кабель з одного тазіка в інший. Так здогадуюсь процес "міграції" ви розумієте як "сісти і нареєструвати руками Х абонентів клікаючи мишою". Ок. Ні, просто хоч трохи орієнтуюсь в термінології. То сабнети. Думаю перекладете самостійно. Хвилини 4 часу на таке потрібно. Можете назвати хоч одну причину навіщо це може бути потрібним хочаб одному адекватному провайдеру? Ключове слово - провайдеру.

Свиню в селі "забивають" - а юзеру присвоюється відповідна основна IP адреса ассоційована до конкретного "nethost" З якого NMLEASES "його видно"? Козу під деревом "привязують" а конкретний nethost ассоціюється до мережі крізь політику сервісів Значить про нього не має бути згадок в dhcpd.log як мінімум поняття не маю що за "пули" - в Ubilling такого немає Також в сусідньому селі "забивається" котрась інша свиня, а в таблички 3 та 4 зі скриптів ініціалізації користувача потрапляє саме та адреса, яка присвоєна йому в Ubilling. А, це така опція про яку в трьох місцях в документації сказано, що вона є категорично небезпечною? Є доречі, ще одна така цікава опція - CRM_MODE=1 - вона теж настільки ж небезпечна і дозволяє вручну налажати де тільки можна - з айпішками в тому ж числі. В FAQ чітко сказано, що ми думаємо про "фігурне" вигадування айпішок.

1. не создан nethost для IP какого-то пользователя 2. нету NAS для подсети какого-то пользователя Подозреваю, что 192.168.1.1 это останки изначального тестового пользователя, который остается сразу после установки - удалите его нафиг.

Молодець, візьміть з полички печеньку

Для начала включаем net.inet.ip.fastforwarding=1 и вдумчиво смотрим не выжрано ли обработчиком прерывания карточки в потолок CPU. em карточки вполне себе при таких раскладах отстреливаться. Если рядом с timeout resetting вы наблюдаете throttling interrupt - это уже плохо и похоже на болезнь матери и интеррапт сторм. Также очень даже помогает для начала поменять шнурок / переткнуть порт. Искренне надеюсь что никаких dev.em.Х. вы не крутили, что очень любят пионеры - em карточки тюнить таким образом бесперспективно, их следует менять на igb коли хочется shape/nat гигабитами.

NAT подымается на внешней сетевой - мы ее вроде как не трогаем дык ifconfig -a - не нужно ощущений Oo В общем случае, для тестирования на ходу, вам следует менять только /etc/firewall.conf после чего: 1. останавливать stargazer (killall stargazer) 2. перезапускать ipfw (/etc/rc.d/ipfw restart) 3. запускать stargazer (stargazer) Все остальное можно поправить при уверености в рабочести и контрольно ребутнуться. Что за сетевые, такие волшебные то? А да, и покажите ipfw show.

А чего не работает?

Незачто. Орите если чего.

В таком случае интерфейс шейпа крутиться только в /etc/firewall.conf ${FwCMD} add 12001 pipe tablearg ip from any to table\(4\) via интерфейс out ${FwCMD} add 12000 pipe tablearg ip from table\(3\) to any via интерфейс in

Если шейпера старые без tablearg - то да, там тоже указывается на каком интерфейсе подымается шейп. В любом случае полностью имеет смысл посмотреть в сторону перехода на новые - прирост производительности в таком варианте около 45%. После 0.3.5 шейп подымается только двумя правилами в firewall.conf

ok напомните в личку последних 4 цифры-буквы серийника это было-бы наглядной демонстрацией влияния тяжелых наркотиков На вскидку допускаю, что если после замены сетевой смениться имя интерфейса, стоит его изменить в следующих конфигах: /etc/rc.conf /etc/firewall.conf /etc/rc.d/billing /usr/local/bandwidthd/etc/bandwidthd.conf /usr/local/www/apache22/data/billing/config/alter.ini Это в случае если у вас используется модель шейпинга из 0.3.5 и выше. Если шейп остался более ранний (хотя и не рекомендуется) - стоит заглянуть еще в /etc/stargazer/OnConnect

не возможно Ставили инсталлятором? Меняли смотрящую в интернет или на пользователей? Если моделька та же - то скорее всего ничего менять не придется. Если отличается - придется исправить от двух до "чуть больше" конфигов в зависимости от того куда смотрит сетевая.

Как минимум отсутствие понимания того, как работает tablearg. Сравните ipfw table 111 show с тем что у вас, например находиться в table 4.

Вчимось читати разом: DirectoryIndex ще ніхто не відміняв.

фігово прикрутили уміляюсь, обгрунтуйте фігово прикрутили точно фігово фігово прочитали доку хотів би побачити того мудлана, який підмережу "невідомих абонентів" мало того, що не зробить deny via ifaceout а щей своїми ж руками в табличку під NAT додасть. я ж казав шо фігово прикрутили "Фігово прикрутили" - залишається в силі. Звідки блін взявся index.html? Відки ці всі збочення? Чому замість того аби прочитати уважно пів екрана детального мануала, виходячи з якого це рішення працює вже в кількох сотень нормальних провайдерів вас тягне на якісь не зрозумілі збочення? Чому я це все запитую? P.S. Наступила неделя кентавра "забили на чтение документации" - все юниты получили +14 к "фигово прикрутитили".

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

Так, все вірно. Худ думок в правильному напрямку. Хоча є ше така штука - досить спрощує життя.

Так і є. Тільки я не розумію яким місцем у вас співвідносяться блокування 172.16.0.0/24 і невідомих-відомих MAC фаєром(!).

пробігають інколи п-ф-ф-ф, головне цього більше ні при кому в голос не кажіть. Зирніть в arp -a краще.

а шо, фист видко? яке відношення фаєр має до виловлювання MACів? Хінт. В кінець /etc/syslog.conf вписуємо в кінець !dhcpd *.* /var/log/dhcpd.log після чого робимо # touch /var/log/dhcpd.log # /usr/local/etc/rc.d/isc-dhcpd restart # /etc/rc.d/syslogd restart і в alter.ini виставляємо NMLEASES так; NMLEASES=/var/log/dhcpd.log Зручна вибиралка і виловлювалка MAC для того і існує. А чому б і ні? Ну хіба б самі собі налаштували dhcp snooping.

Хецнер не?

mc? п-ф-ф-ф Там в депенденсах, чорт зна шо може підтягуватись - тому да, вже нечестива. Ви її осквернили. Зараз откровення Іоана Богослова почну цитувати. Підоймати NAT по імені інтерфейсу і масці з пулу аплінка - нє? Можу дати хорошу безкоштовну пораду - розглядати мікротіки просто як L2 транспорт рівня доступу, а не як NAS. Це ліквідує порядку 95% концептуальних проблем в подальшому.