nightfly

Есть такая класная штука, называется документацией.

MASSSEND_ENABLED=1 MASSSEND_SAFE=0

..либо [!] с последующей экскомуникацией ноды. У нас тут борзая эха

Опция SP_URL своим существованием, как бы намекает на то, что там должен быть указан линк на локальный speedtest mini Самоочевидно же - до появления paymentscorr им небыло куда писаться. Откуда они должны были взяться? Из под подушки? В принципе можно елементарно выпарсить из логов - но думаю вы бы не озвучивали такие "багрепорты" если бы это сделали.

ubilling - от слова "Убивать".... наверное. Изначально оно разрабатывалось как zaebilling (загадка на сообразительность - от какого слова), из чего растут ноги у префиксов методов zb_ В смысли деньги не добавились? Или чего с этим "одним" не случилось? Думаю это уже проблемы самого NAS - и нет, я ничерта в микротике не понимаю. Mikrotik direct писан под заказ по спецификации клиента. В целом по ощущениям еффект очень похож, на тот который возникает в некоторых ситуациях при использовании rscriptd - на удаленных NAS, иногда может не дергаться событие reset() когда оно происходит слишком быстро. Это исправлено в stargazer-е который лежит в git. Обходной и малокровный путь для временного исправления нынче такой: 1. скачать сей архивчик 2. заменить его содержимым api/sgconfxml Если же вы не используете rscriptd - тогда чесно говоря, очень сомневаюсь, что проблема в этом. Еще не видел, чтобы локальные OnConnect/OnDisconnect "не успевали" выполняться. Тут более попахивает тем, что микротику не нравиться когда его очень быстро пинают - такое при тестировании видел на 411 либо 433 и на 750-м. С 2011 все хорошо. Для "более медленных" помогло растыкивание слипов между mk_push.

2 madf Еще не привык к неожиданным вопросам? 2 nlo nameserver? На каждого пользователя? В ppp.secrets? Шутите? Такие вещи описываются один раз, глобально в /etc/ppp/ppp.conf.

Ubilling физиологически не дает возможности использовать для абонента айпишку "*", поскольку это работает только при использовании mod_auth_ia и полностью исключает нормальное функционирование mod_auth_ao, на работу с которым в основном заточена вся имеющаяся бизнеслогика.

Во всех браузерах? 1. вас либо отключены кукизы или яваскрипт 2. либо левая дата на сервере 3. либо левая таймзона у PHP В FAQ тоже давно в FAQ и этот вопрос я слышу минимум раза три в неделю - тоже в FAQ Так

Ну дык явственно и з куска кода выше следует откуда оно - если СУБД настолько чем-то взволнована, что манала отвечать на соединения - это уже проблема. Да. У себя такое помниться видел только когда мускуль тупо грохнулся по количеству коннектов от кривого цикла.

2 madf Если база небольшая - до 10-20к абонентов, отлично справляется и мускуль при правильном подходе, который называется "не трогать его руками" и "дотянуть индексы". 2 RIt Нет. Как показывает практика на BSD все как правило работает "изкоробки" вполне успешно. До скажем 5к абонентов можно как правило не утруждать себя заглядыванием в my.cnf. Для начала включите slow_query_log - и посмотрите не уходит ли просто ваш мускуль в астрал банально забивая на кверизы от тоже больноватого store_mysql. Возможно стоит посмотреть в каком контексте у вас идут операции с мускулем и добавить индексов по полям которые участвуют в where. Также можно попробовать покрутить на скорую руку key_buffer-ы и его родственников. К сожелению вынужден признать, что store_mysql действительно "слегка больноват" и возможно стоит как-то минимизировать использование конфигураторов stargazer до минимума - тогда точно все будет хорошо в этой жизни. if(MysqlSetQuery(res.c_str())) { errorStr = "Couldn't save user stat:\n"; // errorStr += mysql_error(sock); return -1; } Как бы намекает. В случае если вы действительно массивно пишете детальную статистику и база пухнет гигами то постгря начинает выглядеть единственным адекватным решением. И нет - нормальный DBA тогда таки уже нужен. 2 Alexey Osipov Да, бывают случайности, видел таковые

Почему? Кто-то стоит за спиной с топором и запрещает? По-моему проще уж некуда.

madf как всегда забыл упомянуть, что для руления постгрей нужен адекватный DBA, способный постоянно бороться с вакумом и прочими "особенностями". Давайте угадаю - у вас linux. Очевидно бубунто-дебиано образный. Там изначально больной mysql-client. Лечится пересборкой.

Спать - это для слабаков PS пельмени шлите мылом.

Я подозреваю что имелся в виду корень каталога, в который установлен ubilling?

А-а-а-а мы все умрем!!! опасносте!!!111

Блин, я сам до сих пор не понял. Вспоминается анекдот про "б...дь кто все эти люди?" На самом деле, я это все привел, чисто как вариант использования этих двух разных сущностей. Как несложно заметить изначально в ubilling присутствовали "те работы что негр с киркой" которые выполняются для конкретного абонента. Это писалось для себя - чтобы иметь представление кто же подключал абонента и кто ходил к нему на вызовы. Иногда полезно узнать, что абонента такого-то год назад, подключал Иван Васильевич, который судя из примечаний к подключению был под героином "Планирование задач" (или почему-то "работ", я реально не могу вспомнить когда оно в оное переименовалось) писалось под заказ для конкретного оператора, и там была мотивация "просто чтобы не забывать ходить на вызовы и как-то отмечать выполненные и невыполненные + кто их делал, а также чтобы можно было планировать не привязываясь к конткретному абоненту". Для себя всю эту радость вы можете использовать либо не использовать, как вам удобно благо никакой особой бизнеслогики на это не завязано и носят обе эти сущности более справочную информацию "для себя". На будущее были планы как-то скрестить бульдога с носорогом, чтобы скажем "задачи" могли в случае "выполненности" порождать за собой "работы" на конкретных абонентах, но как это должно выглядеть, чтобы не быть слишком замороченным я к сожелению еще пока слабо для себя представляю.

Ну они типа друг другу не протеворечат. Тем более что никак не связаны. Как вариант использования на практике: бригадиры Саша и Валера за которыми закреплены скажем монтажники Вася, Петя, Сережа и Ворфоломей. Пишем подключение на завтра для бригадира Саши там-то и там-то. На следующий день не забухавший в отличии от Саши бригадир Валера решает сотворить это подключение. После подключения пользователя в работах отмечаются Сережа и Варфоломей которые героически под руководством Валеры осуществили это подключение а задача в планировщике отмечается таки как выполненная Валерой, хотя была запланирована для Саши. Правда через день всплывает факт фигово обжима кабеля у пользователя и к нему направляется монтажник Вася по результатам деятельности мы получаем выполненную по абоненту работу типа "ремонт" с примечанием "когда же эти м@#аки научатся нормально обжимать витую?". Итого имеем 1 выполненное задание и штуки 4 выполненных работы разными людьми, также как и возможность через год "вспомнить" кто же и почему подключал какого-то конкретного пользователя.

возможно вы будете шокированы, но находится он в каталоге /config как и остальные конфиги

Неа, это вообще разные штуки, не имеющие ничего общего. Почему так - не спрашивайте у меня Просто в последних релизах они выглядят идентично - это неожиданная случайность. В отчет по работам попадают "работы" заполненные по конкретным пользователям в "Профиль пользователя -> Работы". Типа так: И как результат: Собственно "работы" удобно использовать для контроля всяких подключений, ремонтов итд конкретно интернет-пользователей. "Планирование задач" на самом деле (я не имею понятия почему оно внезапно стало называться "Планирование работ") удобно использовать таки для планирования допустим всяких работ по КТВ, протяжке кабелей и прочей мути которая к конкретным интернето-пользователям имеет очень опосредованное отношение. И нет - логики в этом всем нету, не ищите Он отображается в "редактировании пользователя" в самом верху при включении CRM_MODE - выше я уже предупредил, там опасносте!!!!11

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

Ну дык нету выполненных работ за текущий месяц. Чего показывать то?

А чего говорит SELECT COUNT(`id`) from `jobs` WHERE YEAR(date) = YEAR(CURDATE()) AND MONTH(date) = MONTH(CURDATE()) ?