Перейти к содержимому
Калькуляторы

mrlexus

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    27

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем mrlexus

  2. Опубликовано · Жалоба на ответ

    Какие поля в таблице меняете?

     

    created, timefrom, activated время выставляю в 00:00:00

     

    Воспроизвел у себя такую же ситуацию. После изменения времени напрямую в БД в указанных полях на 00:00:00 перерасчет прошел практически мгновенно.

    Вероятно, время перерасчета зависит от параметров блокировки и типа списания в тарифном плане. У меня блокировка - Активная, списание - Комбинированно.

  4. Опубликовано · Изменено пользователем mrlexus · Жалоба на ответ

    Еще лучше вынести это в параметр конфига. Приводим функцию к такому виду:

     

       public function validateVgid() {

       if (!yii::app()->params['vgroup_schedule_blocked']) {
           if ($this->vgroup()->vgroup->blocked) {
               throw new Exception('Account is blocked');
           }
       }

       foreach ($this->tarrasp() as $item) {
           if ($this->byUser($item)) {
               throw new Exception('Please remove allready scheduled tariff change');
           }
       }
   }

     

    И в конфиг ЛК добавить такие строчки:

     

    //Разрешить смену тарифного плана при блокировке УЗ
'vgroup_schedule_blocked' => false,

     

    ЗЫ Просто ради интереса, сколько денег попросили бы разработчики за такую доработку?

  5. Опубликовано · Жалоба на ответ

    А проблема - абонент не может сменить тариф если он заблокирован по балансу. Никто случаем не разбирался? подозреваю что надо всего лишь условие проверки чуть исправить...

    Посмотрел код ЛК. Оказалось все очень просто. Ищем файл client2/client/components/tariff/changing/Tariff_Changing_Helper.php и приводим в нём функцию к такому виду:

     

       public function validateVgid() {
       /*
       if ($this->vgroup()->vgroup->blocked) {
           throw new Exception('Account is blocked');
       }
       */
       foreach ($this->tarrasp() as $item) {
           if ($this->byUser($item)) {
               throw new Exception('Please remove allready scheduled tariff change');
           }
       }
   }

  6. Опубликовано · Жалоба на ответ

    Услуга включается только через УЗ - блокировки - там при включении время включения ставится 00:00

    Не совсем так. В интерфейсе админки в двух местах (Объекты - УЗ и Объекты - Пользователи - нажать +) есть менюшки управления блокировками, которые как раз используют только текущее время при изменении состояния и изменять это поведение разработчики не намерены.

    Поэтому выход: либо выпиливать эти менюшки из интерфейса либо бить по рукам операторов, которые ими пользуются.

     

    а если клиент управляет услугой из лк?

    Пытался допилить в ЛК мастер управления пакетами ТВ, с первого захода не осилил. Но там можно взять за образец мастер смены тарифного плана и в коде вычислять нужную дату и время ставить 00:00.

     

    Ну и крайний вариант - запрашивать доработку у разработчиков.

  7. Опубликовано · Жалоба на ответ

    Любое обновление ЛБ - это боль, страдание и бессонные ночи.

    Лучше уточните, какие платформы используете (Интернет, Телефония/IP телефония, ЦТВ/КТВ и т.д.), могу рассказать более детально.

     

    ЗЫ Учитывая, что сейчас обновление только с пакетом тех. поддержки, то должно быть проще. Но, не уверен.

  8. Опубликовано · Жалоба на ответ

    Сюда бы разработчиков LANBilling.

    Очень хочется узнать их опыт платной поддержки, желательно с аналогичными графиками.

    Особенно интересует процент неоплачиваемого времени техподдержки по причине "DEVBUG".

  9. Опубликовано · Жалоба на ответ

    Где-то с версии 12 появилась возможность списывать доп. услуги не создавая доп. учетку агента usbox. Что очень удобно, я ради этого обновлялся.

    Согласен удобно. Только этом механизм не годен для полноценной замены учетных записей USBOX. Для привязки оборудования к УЗ все равно надо создавать учетку USBOX. Мы так надеялись, что теперь не придется плодить пустые учетки, но, увы...

  10. Опубликовано · Изменено пользователем mrlexus · Жалоба на ответ

    Вы совсем меня неверно поняли в первом абзаце, эскалация не равно суд. Больше того, суд в таких вопросах на моем опыте, всегда тупик.

    Инструменты о которых я говорю - изначально заложенные в договоренности механизмы, когда обоим субъектам отношений не выгодно затягивание решения вопроса. Причем насколько я поняла представителей СР тут, сейчас договора ТП, как и в моем случае, гарантируют не время реакции на инцидент, а время решения инцидента. Это очень разные вещи.

     

    2anichka991

     

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

     

    Уточните еще один важный момент: договоренности или же договора (бумажные) конкретно у Вашей компании с разработчиком? Это две большие разницы. Мне действительно это интересно в свете последних изменений в сервисной политике разработчика.

     

    Гарантированное время решения это хорошо. Только решение решению рознь. Могу рассказать конкретный пример с техническими подробностями, если Вам интересно и Вы готовы дать свои профессиональные комментарии.

  11. Опубликовано · Изменено пользователем mrlexus · Жалоба на ответ

    Даже если предположить, что у известного на рынке поставщика есть «прихоти», во что лично я не верю т.к. у поставщиков решений почти всегда есть есть обоснования для тех или иных изменений (публичные или не публичные вопрос другой), то для меня фраза «50 менеджеров привыкли и потому мой бизнес становится неуправляемым» звучит мягко говоря несерьезно, т.к. даже в моем, как тут выразились, юношестве, уже были известны умные книжки про управление в которых уважаемые люди писали про регламенты, инструкции и пр. – документы, которыми должен руководствоваться, такой механический персонал, как, в частности, менеджеры, в своей повседневной работе. Таких руководящих документов как «привычка» я в этих книжках не видела.

     

    В данном конкретном случае все регламенты и прочие бумажки в одночасье становятся фИговыми листочками, которыми можно лишь прикрыться при разборах полетов. Если под большой красной кнопкой написать "НЕ НАЖИМАТЬ", на неё обязательно нажмут, и, наоборот, если написать "НАЖАТЬ ОБЯЗАТЕЛЬНО" - никто не нажмет. Это человеческий фактор и он не решается только административным воздействием. Поэтому необходимо делать техническую реализацию системы положительной или отрицательной связи для контроля возникновения ошибки а работе штатного (!) функционала системы. На реализацию данной системы требуются ресурсы, как временные, так и человеческие. Итог - система работает, но появился очередной костылик под падающий забор.

     

    Я прекрасно понимаю, что в идеале Вы хотели бы получить от меня рекомендацию, как действовать в конкретной ситуации с которой Вы столкнулись в процессе эксплуатации lanbilling, но этого не получится сделать по разным причинам

     

    Вы мне уже ответили в первом абзаце. Опуская промежуточные ходы и ответвления итог один - "Идите в суд" (с)

    Мне ясна Ваша позиция.

     

    Я с большим уважением отношусь к опенсорсу. Применяю его там, где он уместен. Ключевое слово уместен. Биллинг - не самое уместное, и самое главное, не для всех уместное удовольствие. Нужно быть _способным_ его эксплуатировать.

     

    Если взять конкретный продукт, то без Linux/UNIX, MySQL, Apache, php + extentions, python и умения все это приготовить, LB просто набор байтов. И только в совокупности все это становится БИЛЛИНГОМ. Поэтому Ваше высказывание немного сомнительно.

    Кроме всего, для того, чтобы все это стало по настоящему АСР, требуется дополнительная обвязка для управления оборудованием, и тут без opensource совсем не обойтись. Даже CoA не послать.

     

    К чему я все это.

    Я вижу, что продукт развивается, местами становится лучше, но в эту бочку меда разработчики своими же руками кидают совсем уж неприличные объемы дегтя. Причем, иногда складывается ощущение, что они сознательно выпускают релиз с некоторой долей ошибок, иногда совсем "детских" и от релиза к релизу повторяющихся.

    Мне очень хочется, чтобы это было неправдой и с каждым релизом старые ошибки не повторялись, а новые - не появлялись. А описанные мною выше "нежданчики", и, особенно, реакция на них разработчиков - небольшое недоразумение, которое будет решено до окончания срока подписки на обновления.

    Пока я вижу некоторое улучшение, связанное с приходом нового технического директора в команду СР.

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

  12. Опубликовано · Жалоба на ответ

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

    Разработчик отмалчивается и не принимает разумные доводы.

    Ок. Принято.

    Решение через изменение бизнес-логики - убедить 50 менеджеров (их действия уже доведены практически до автоматизма) делать не так, как они привыкли за 5(!) лет использования системы, а прям вот сейчас делать так, как надо разработчику по его прихоти.

    Ваши действия?

  13. Опубликовано · Жалоба на ответ

    Ну это простой квест - обращусь к разработчику с инцидентом и дождусь хотфикса если гипотеза подтвердится.

    Ок. Принято.

    Разработчик в ТТ отвечает, что это не баг, а фича, и доку мы поправим.

    На неоднократные вопросы о сроках решения проблемы ответа нет несколько месяцев. Доход вашей компании все также теряется...

     

    Оба контрагента - резиденты РФ.

    Ваши действия?

     

    P.S Не читайте советских газет до обеда (с) Ф.Ф. Преображенский

  14. Опубликовано · Жалоба на ответ

    anichka991

     

    Интересно Вас читать. Все смешалось в доме Облонских... Машины, деньги, полствола... :) Невольно вспомнилось детство и мультик про полтора землекопа :)

     

    Однако, хочется узнать Ваше мнение по более конкретному вопросу.

     

    Представьте, что с очередным обновлением ПО (оплаченном), Вы обнаруживаете нештатное поведение системы, которое не описано ни в документации, ни в списке изменений к релизу. Причем это поведение прямо влияет на уменьшение дохода Вашей компании.

    Ваши действия, как лица, ответственного за функционал этого ПО в Вашей компании?

  15. Опубликовано · Жалоба на ответ

    Забавно.. только что приобрели лицензию на обновление. Получили доступ к сборкам 2.0 с 001 по 014, кроме 009 и 011.

     

    Создание тикетов в HD доступно? При покупке лицензии на обновление?

    Доступно. Но решение проблемы не гарантировано. В большинстве случаев проблемы решают, но решение может растянуться на несколько месяцев. Будьте готовы к отпискам со стороны HD.

  16. Опубликовано · Изменено пользователем mrlexus · Жалоба на ответ

    10 блокировка может быть установлена только из админки менеджером вручную. Система автоматически не переводит в это состояние никакие УЗ. Равно как и обратно - не выводит из 10 блокировки.

    Это не может быть глюком.

    Если только не чьи-то шаловливые ручки...

    Смените пароли менеджеров в ЛБ, на доступ по ssh, к mysql и пр. разрешите файерволом доступ к админке только с доверенных хостов, проведите аудит системы на предмет нелегального доступа.

  17. Опубликовано · Жалоба на ответ

    Не все так просто.

    Если УЗ ни разу не была в состоянии "Отключено" (10 блокировка), то это поле в БД имеет значение '0000-00-00 00:00:00',в админке оно отображается прочерком.

    Если УЗ была в 10-й блокировке - то поле имеет значение даты перехода в это состояние. При включении УЗ поле остается неизвенным.

    Переход в состояние "Отключено" влияет на на списания абонплаты. В этом состоянии списания не производятся.

    Вот меня и смущает, откуда такая дата взялась?

     

    Еще вопрос: почему дата изменения состояния УЗ - 19.11.2013? Какие действия с УЗ производились в этот день?

  20. Опубликовано · Жалоба на ответ

    У Ланбиллинга есть статья на эту тему. Там пример для Linux, но для FreeBSD тоже можно сделать.

    Чтобы абоненты не ждали таймаута сброса сессий mpd можно в скриптах обработки carp чистить таблицу sessionradius.

  22. Опубликовано · Жалоба на ответ

    Кусок моего старого скрипта динамического шейпера под utm5. Как один из вариантов управления скоростью:

    	$ebs=floor($speed_shape/8);
$cbs=$ebs/2;
$if_up="/usr/sbin/ngctl msg ".$interface.":inet.1-0-m setconf { upstream={ cbs=".$cbs." ebs=".$ebs." cir=".$speed_shape." greenAction=1 yellowAction=1 redAction=2 mode=3 } downstream={ cbs=".$cbs." ebs=".$ebs." cir=".$speed_shape." greenAction=1 yellowAction=1 redAction=2 mode=3 } }";
$if_dw="/usr/sbin/ngctl msg ".$interface.":inet.0-0-m setconf { upstream={ cbs=".$cbs." ebs=".$ebs." cir=".$speed_shape." greenAction=1 yellowAction=1 redAction=2 mode=3 } downstream={ cbs=".$cbs." ebs=".$ebs." cir=".$speed_shape." greenAction=1 yellowAction=1 redAction=2 mode=3 } }";

exec($if_up);
exec($if_dw);

    Где: $speed_shape - скорость в Кбит/с, $interface - ngXX

    Соотвественно, надо заранее знать имя ноды. У меня сохранялость в самодельную табличку скриптами up/down значения login/ip/ng* и пр., затем оттуда бралось.

  23. Опубликовано · Жалоба на ответ

    Чтобы правильно работало списание типа "Ежедневно равными долями" нужно в верхней шапке тарифа выставить метод списания - "Динамически". В таком сочетании все работает корректно.

  24. Опубликовано · Жалоба на ответ

    vpn1# limits

    Resource limits (current):

    cputime infinity secs

    filesize infinity kB

    datasize 524288 kB

    stacksize 65536 kB

    coredumpsize infinity kB

    memoryuse infinity kB

    memorylocked infinity kB

    maxprocesses 7390

    openfiles 112500

    sbsize infinity bytes

    vmemoryuse infinity kB

    Выделенное значение указывает на то, что максимальный объем выделяемой памяти для одного приложения равен 512 Мб, причем, насколько я понимаю, туда входят и ресурсы всех порожденных дочерних процессов. Данное значение установлено для GENERIC ядра 32-bit систем FreeBSD.

    Изменить этот параметр можно пересобрав ядро с такими опциями:

     

    options MAXDSIZ=(2048UL*1024*1024)

     

    где - 2048UL - это размер памяти, выбеляемый для одного приложения (2 ГБ). Данное значение не предтендует на идеальное, я подбирал его для своей конфигурации с 4ГБ памяти. Поэксперементируйте и подберите размер для себя.

    После пересборки ядра у меня исчезли грабли с mpd, когда процесс самостоятельно, без видимых причин и записей в логах, закрывался и закрывал все соединения.