nightfly

Дык вот же ж общие рекваеры. Опциональными и полезными могут оказаться еще SNMP & PCRE. А вот вам и весь, вполне достаточный конфиг php.ini из UBinstaller: magic_quotes_gpc = Off magic_quotes_runtime = Off magic_quotes_sybase = Off date.timezone="Europe/Kiev"

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

Естественно. Это - дата осуществления платежа. Можно конечно было бы цеплять к платежам скажем дату окончания ВоВ, но это будет нихрена не дата совершения платежа. Когда там юзер куда-то сходил - имеет к платежу ровно столько же отношения как и дата окончания ВоВ. Дата "реальной оплаты" - какраз очень даже совпадает.До секунды. "Реальной" оплата становиться только тогда, когда она поступает на счет пользователя. До этого момента ее не существует ни для биллинга, ни для бухгалтерии в общем. Откуда такие соображения, если не секрет? Прикиньте какие вы счастливые люди? Мало то

Вы видите меня стоящим у вас за спиной с окровавленным топором? Нет? Вывод - никто вам не запрещает. в FAQ В продолжении фразы должно было быть "который я меняю на соответствующий при помощи удобной выбиралки" а не "аааааамамачтойта!!!1111" Природа не терпит пустоты. Рандом, очевидно же.

Как минимум в /config/billing.ini и в /userstats/config/userstats.ini

Да. И не только.

Ну вот - сами сознались Как не сложно заметить у меня "к этим вашим линуксам" встроенная нелюбовь, только по трем причинам: 1. зубодробительный синтаксис iptables (без комментариев) 2. отсутствие нормального шейпера (ни слова о tc/htb - это полисер а не шейпер по факту. Шейпить им это точно такой же онанизм как полисить при помощи dummynet или шейпить при помощи altq) 3. их много разных И если вопрос с п.1. хоть как-то пытаются решить ребята из Uncomplicated Firewall который ufw, глядишь чего-то и получится такое что не стремно ставить в продакшн. С п.2. на сегодняшний день все до

Думаю разница должна быть только в реализации заворота фаером. Остальное должно быть полностью переносимо. И да - вы и так знаете, что я думаю про эти ваши.... iptables Поддержка 27-ми часов в сутках запланирована и уже находиться в стадии написания, но в релиз попадет не раньше 0.4.2

Эммм... был не прав.... прошу меня извинить - нагрузился, че-то на GOOD_URL/BAD_URL из OpenPayz Редирект на ISP_URL в UHW происходит в случае, если к странице UHW обращается пользователь с уже известным Ubilling и присвоенным кому-то MAC адресом из подсети не принадлежащей к UNKNOWN_MASK. Тоесть поменял себе юзер себе мак, либо нам позвонил и мы ему поменяли "четыре красных буквоцифры", после чего возможны два сценария его последующих действий: 1. либо юзер баран и не переполучил по DHCP свои новые настройки 2. либо юзер умный и скажем умеет страшную технологию "вкл-выкл сетевую либо п

А разрешить трафик по UDP 53 для подсети неизвестных MAC сквозь локальный DNS? Чем они резолвить ISP_URL должны? Тем более в NAT они не попадают и не надо.

Нечего там считать. Если абонент сам себя морозит из кабинета пользователя - снимается сумма указанная в AF_FREEZPRICE а также та сумма которая указана в тарифе в поле "Стоимость заморозки", если она не нулевая. В замороженном состоянии на абонента просто не начисляется АП и не выполняется OnConnect, даже если у абонента достаточно средств. Вот и все.

Жизнь скучна без экстрима Я лучше напложу еще побольше жертв 408, и думаю рано или поздно ты не выдержишь изобразив хотябы предварительное 2.409

"Наверное" не знаю зачем его вы выключали. Вот дефолтный конфиг как он есть, и его работа полностью понятна и четко обозначена в документации: DayFee = 1 ReconnectOnTariffChange=yes DayFeeIsLastDay = no DayResetTraff = 1 SpreadFee = no FreeMbAllowInet = no WriteFreeMbTraffCost = yes FullFee = yes

Это проблема "быстрого reset" на rscriptd а не замены тарифа. ReconnectOnTariffChange у нас нынче бай дефолт. Была попытка включить гитовую версию старгейзера в одну из сборок ubinstaller, но она у меня на то время не собралась, а релиз горел Потому, что это действительно подпорка и стоит ждать 2.409 где это все исправлено "изкаробки".

Вот, как-то так 0.3.6 - rev 2264 billing.ini: новая опция RESET_AO хотфиксящая проблему при использовании rscriptd (включать строго по дикой нужде) Установите RESET_AO=1 и будет вам щастье.

А так, мало не забув. Таблички які не будуть звертатись кліканням по модулю бекапів з вебінтерфейсу - встановлюються опцією NOBACKUPTABLESLIKE=

За замовчуванням в бекап weblogs не потрапляє. Тому я і раджу на продакшні використовувати ось це.

CREATE TABLE IF NOT EXISTS `weblogs` ( `id` int(11) NOT NULL AUTO_INCREMENT, `date` datetime NOT NULL, `admin` varchar(45) DEFAULT NULL, `ip` varchar(64) DEFAULT NULL, `event` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`), KEY `date` (`date`), KEY `date_2` (`date`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

cat ваш_дамп.sql | /usr/local/bin/mysql -u root -p stg --password=newpassword --default_character_set utf8

Кому как. Комутируемые соединения пора бы оставить в прошлом. Если выглянуть через окно, можно заметить - 2013-й год на улице. HP_MODE, как следует из его названия задуман как режим высокой продуктивности, отчасти он вполне себе справляется с пережевыванием абонбаз до 60000 абонентов, полагаясь на фоновую подгрузку данных при помощи ajax в фоне, отчасти используя deffered rendering (отложенную прорисовку?), а от части оно нормально работает с нормальными количествами абонентов изза того, что не производит в цикле тысячами всяких глупых проверок - типа "а исполнился ли OnConnect?". В угоду

Это - сезонное обострение.

Здається - ні, не упустили. Критичними є конфіги: /config/mysql.ini /config/billing.ini /config/alter.ini /config/ymaps.ini /userstats/config/mysql.ini /userstats/config/userstats.ini Все інше затирається навіть при оновленнях обновлятором, після чого вищевказані конфіги повертаються на місце. Можна взагалі бути брутальним і після того як поставились з нуля інсталятором і розгортання бази перелити поверху каталог billing з бекапа (це такий варіант для надто лінивих). У будь якому випадку треба пам'ятати, що заливати дампи БД потрібно при незапущеному stargazer. Він читає та

Страааашно?

Таблички покрашились, при непередбаченій зупинці MySQL. Загалом в таких випадках варто робити наступне: 1. зупиняємо stargazer 2. шукаємо хто поламався з допомогою CHECK TABLE `імя_таблички` 3. рихтуємо її з допомогою REPAIR TABLE `імя_таблички` 4. запускаємо stargazer

Это ONLINE_HP_MODE=1