Alexandr N

Из моего опыта работы с Carbon Billing и работы с другими биллингами, если у моих друзей появится желание - я буду отговаривать всех. Моими словами будет: Этот биллинг ДНОО!! 1. Раз в год умирает база данных так как транзакции к сожалению лимитизированы на Firebird 2 - ответ? исправим через 3-5 лет. Раз в год итого совет техподдержки - восстановитесь из бекапа. 2. Идея разделения на микросервисы загнала в тупик всю разработку которая основана на chroot, когда люди давно делают API и раскидывают по докерам (это удобно даже с точки зрения обновления). Я уж помолчу про зоопарк в клетках, какого там только софта не живет. 3. Базовые функции могут произвольно умереть, причины могут быть исправлены только в рабочее время или покупайте иной SLA, и это не шутка, код никто не копает, сервер не ломает, места хватает - а сервисы какие то просто умирают. При условии коробочного продукта мне почему то кажется оно должно работать, а уж если есть ошибка разрабов и косяк то оно должно быть исправлено оперативно невзирая на SLA - мы платим не за опыты над нами, а за работающий продукт Я уже промолчу что Centos вообще прекратил свое существование как ОС - а мы еще на Centos 6, зато стабильно скажут мне. Было стабильно и в 7-й и в 8-й ветке где еще репозитории не доумерли. Я понимаю что на мой пост, а уж простите накипело, ответит product manager CB5, свой же продукт принято защищать. Но мы как вынужденные пользователи продукта, оставляем информацию чтобы в сознании овнеров продукта что-то поменялось, что есть проблемы, но когда техпод отвечает на вопрос о базовом функционале что "ждите завтра", тем временем сервис должен лежать, как мне не закипеть? (и еще раз замечу что я не прошу поддержки, я не прошу доработок, мне нужно что бы то что заявлено - работало). ps. когда заявку делать на сайте: Fatal error: Cannot use string offset as an array in /var/www/portal/HelpDesk/TicketDetail.php on line 64

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

узкая задача fb по сравнению с оператором с 5-15к активных абонентов это как сравнить Солнце и Плутон :) и кстати они там кучи презентаций делали как они "пылающей тропой" перешли на 8.0

статья рассказывает про MySQL 5.5 дата выхода которой 2010 год дата релиза Centos 6 на которой работает карбон 2011 год. ну то есть около 10 лет прошло как бы :)   fb.com надо было рассказать который использует MySQL что это не серьезно :)

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

Обсудили из того что сказали и из того что было почитано мною про firebird (в группах) оказывается из-за устаревшего софта (firebird версии 2) на кол-ве транзакций к базе данных равное 2147483648 бд самоумирает и биллинг ломается. для firebird 3 это чисто 281474976710656 (что в 131072 больше). Напоминает логическую бомбу.

Так надо же сказать об этом в тикете/звонком или как то еще, а то сижу и жду. Бекапы есть, инструкцию нашел как восстановить, сам сделал, сам молодец. Вопрос: как так произошло? (Жесткий диск не убился), Вопрос: данные за день потерялись, как бы восстановить? Я не про докер как систему резервирования, а про то что докер и был придуман для того что бы такие "зоопарки" (когда внутри живет очень много разного софта/языков/баз данных) упорядочивать имея адекватную систему управления, тогда как chroot выполняя те же задачи не имеет ее, точнее почти ничего не имеет :)

Что ответят через пару дней, но прошло пять. С учетом того что у вас очень много разного софта докер вероятнее всего бы наоборот помог бы содержать основную систему в актуальном состоянии, а контейнеры могли бы частично работать и на более старых версиях. upd. ответили что займутся

присунуть эластик, фаирберд, заббикс, кабинет на вордпресе, админку на джанго... я наверное многое не упомню что еще туда засунули. и все это натянуть через chroot на centos 6 (который кстати все). ну такое да... удовольствие :)

биллинг взял себе и сломал базу данных, работал-работал и потом сказал что у вас файл бд кривой :) отлично! разрабы кстати раз уж поставили все что только можно было в биллинг из софта, то может они хотя бы слышали что есть docker

https://demo5.carbonsoft.ru/rest_api/v2/ 502 Bad Gateway nginx/1.0.15 ну почините уже

Вы сами пишете "CMS", ответ - не на CMS :) С таким походом скоро и на Битриксе можно будет делать. Смотри в сторону фреймворков, например Yii2

про кабинет на WordPress я молчу, а чего уж сразу не на phpBB ?

Шел третий день рассмотрения тикета, закономерно в конце рабочего дня CB5 сообщение... "Извините, сегодня мы не смогли решить Вашу задачу, продолжим завтра." (Представьте что я прикрепил картинку ждуна)

Ну вы сами понимаете что говорите?) Ситуация из жизни: Звоню, говорю - вопрос в стиле "мне лень прочитать мануал". Отвечают, "хорошо, но пишите тикет" - иду пишу. Написали тикет, а у вас там что-то еще открыто и что бы побыстрее закрыть, а текущее приподнять ? "Звоните" ! хорошо, иду звоню :)

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

отвратительно, невероятно! Почему я лютую? Я познакомился с работой поддержки биллинга, за которую идет плата и понимаю поддержка не в состоянии ответить на бытовые вопросы в разумные сроки. 1. Если у вас осталась открытая заявка, и вы создали другую - то она не будет обрабатываться тк есть созданная другая, хорошо, зайду в старую и нажму "закрыть". Но "закрыть" в понимании поддержки CB5, это отправить обращение на закрытие, которое может рассматриваться... ну хз сколько. 2. Вы создали заявку, но всем на нее по...фигу, робот будет вам писать в заявке в конце рабочего дня поддержки вот что: "Извините, сегодня мы не смогли решить Вашу задачу, продолжим завтра.". - это вообще бесит! Почему бы не вычитать тогда те дни из платы месячной поддержки, если поддержка не была оказана?

помогали в срочном вопросе по адресам, все замечательно. хвалю! Илье отдельное спасибо.

https://gist.github.com/avelardi/1338d9d7be0344ab7f4280618930cd0d закройте пакеты на L7 в которых содержится запрос "GET /current_config/passwd"

мне кажется что в общем дереве не найду, но поищу :) обращусь, но тут собственно есть стандартный для всех mib : LLDP-MIB прошивка то что у вас на data.nag.ru последнее.

Подскажите, lldp нормально работает, включен, но по snmp нет такой ветки, может быть есть какая то специфическая или нужно отдельно что-то активировать? # snmpwalk -v2c -On -Cc -c private 192.168.10.1 .1.0.8802.1.1.2.1.4 .1.0.8802.1.1.2.1.4 = No Such Object available on this agent at this OID

Спасибо, такой вариант вполне работает

Подскажите как можно снять таблицу соответствия mac -> port. Не может walk считать next oid. # snmpwalk -v2c -On -c test 192.168.100.2 .1.3.6.1.2.1.17.7.1.2.2.1.2 .1.3.6.1.2.1.17.7.1.2.2.1.2.1.0.12.66.198.228.88 = INTEGER: 1 .1.3.6.1.2.1.17.7.1.2.2.1.2.1.0.12.66.198.228.54 = INTEGER: 1 Error: OID not increasing: .1.3.6.1.2.1.17.7.1.2.2.1.2.1.0.12.66.198.228.88 >= .1.3.6.1.2.1.17.7.1.2.2.1.2.1.0.12.66.198.228.54

Переход проплачен сообществом PG, негоже специалистам PG в стороне стоять

info@netorn.ru