По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! В сегодняшней статье мы расскажем, как победить очень надоедливый “баг” во FreePBX, который кочует из версии в версию и сильно мешает пользователям, которые используют кириллицу, то есть русские буквы, в именах внутренних номеров своей IP-АТС. Точно можно сказать, что данная проблема присутствовала в FreePBX 13 и перебралась в 14 релиз.
/p>
Как многие могли догадаться, речь пойдёт о неправильном отображении русской кодировки в модуле CDR, в простонародье – кракозябры в CDR.
Предыстория
Итак, вот вы установили самый последний актуальный FreePBX Distro SNG7-FPBX-64bit-1707-1, долго ждали когда же наконец закончится загрузка 571 пакета (если устанавливаете на VM)
Небольшой оффтоп для тех, кто устанавливает FreePBX 14 на VM и подумал, что процесс установки завис на 571 пакете и надо его прервать – НЕТ, он не завис, наберитесь терпения, правда. Да, это долго, мы, например, ждали полтора часа. Отдохните, попейте кофе, почитайте о нововведениях в FreePBX 14
И, наконец, дождались - всё готово, пора регистрировать абонентов. Вы добавили два внутренних номера с русскими именами, пусть будет Алексей Добронравов и Сергей Злонамеров
Зарегистрировали для каждого по софтфону и провели тестовый звонок – успех. А что же в CDR? Открываете Reports → CDR Reports и видите те самые “кракозябры”, которые мало чем напоминают имена наших внутренних абонентов.
Знакомо? Тогда читай дальше!
Быстро проверим таблицу cdr в базе asteriskcdrdb и убедимся, что там такая же картина:
Решение
Внимание! Прежде чем повторять дальнейшие инструкции – сделайте полный бэкап системы или снэпшот виртуальной машины. Компания Мерион Нетворкс не несёт ответственности за потенциальные проблемы, которые могут возникнуть на вашей IP-АТС. Неправильное выполнение нижеизложенных действий может привести к полной неработоспособности FreePBX и Asterisk!
В интернете можно найти много советов по устранению данной проблемы, начиная от выставления значения charset = utf8 в файле /etc/asterisk/cdr_mysql.conf и выполнения core reload, когда записи опять слетают и заканчивая написанием скрипта, который будет время от времени производить принудительную перекодировку записей. Но всё это либо “костыль”, либо не помогает вовсе.
На сайте разработчика freepbx.org по данной проблеме даже заведён официальный Bug FREEPBX-15268, который по сегодняшний день имеет статус (11.10.2017) DEV TESTING: Unresolved, то есть – не решён.
Более менее действенным способом решения этой проблемы является снос старого MySQL коннектора и установка mysql-connector-odbc-5.3.9 (ANSI Driver), а затем внесение изменений в файл /etc/odbc.ini следующего вида:
[MySQL-asteriskcdrdb]
driver=MySQL ODBC 5.3 ANSI Driver
После этого записи в CDR, конечно, будут отображаться корректно, однако, все логи будут завалены предупреждениями типа:
[2017-10-13 22:31:16] WARNING[8933] cel_odbc.c: Insert failed on 'asteriskcdrdb:cel'. CEL failed: INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,extra) VALUES ('CHAN_START',{ts '2017-10-13 22:31:16.974567'},'Алексей Добронравов','175','','','','s','from-internal','SIP/175-00000001','','',3,'','1507923076.1','1507923076.0','','','')
[2017-10-13 22:31:18] WARNING[8933] cel_odbc.c: Insert failed on 'asteriskcdrdb:cel'. CEL failed: INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,extra) VALUES ('ANSWER',{ts '2017-10-13 22:31:18.631244'},'Алексей Добронравов','175','175','','','175','from-internal','SIP/175-00000001','AppDial','(Outgoing Line)',3,'','1507923076.1','1507923076.0','','','')
При этом в самой таблице cel, на которую ругается сервер, всё будет нормально:
Вроде решение, CDR корректен, но лог будет буквально забит этими предупреждениями, а мы этого не хотим.
Итак, сейчас мы опишем способ решения, после которого и логи будут чистыми и никаких “кракозябр” в CDR вы не увидите.
Для начала, нужно удалить текущий mysql-connector-odbc, однако, в силу того, что он связан зависимостями, вместе с ним удалится и сам Asterisk. Поэтому, сначала нужно узнать, какой именно коннектор установлен на сервере, и удалить его отдельно. Для этого пишем команду:
rpm -qa | grep mysql-connector-odbc
Ну и после предыдущих манипуляций видим, что у нас установлен mysql-connector-odbc-5.3.9-1.el7.x86_64, вероятнее всего у вас будет mysql-connector-odbc-5.3.6. Теперь его нужно удалить, но не учитывая при этом его зависимости. Нам нужно удалить только коннектор, для этого пишем следующую команду:
rpm -e --nodeps "mysql-connector-odbc-5.3.9-1.el7.x86_64"
Теперь нужно установить новый коннектор, но только не от MySQL, а от MariaDB, для этого пишем:
Внимание! Ввод следующей команды без предварительного сноса прежнего коннектора может привести к полному отказу Asterisk!
yum install mariadb-connector-odbc
Теперь проверьте файл /etc/odbcinst.ini в нём обязательно должна быть запись:
[MariaDB]
Description=ODBC for MariaDB
Driver=/usr/lib64/libmaodbc.so
Setup=/usr/lib64/libodbcmyS.so
UsageCount=1
Теперь сделаем перезагрузку fwconsole restart и всё готово. Проводим ещё пару тестовых звноков, смотрим в модуль CDR во FreePBX и проверяем таблицу cdr в asteriskcdrbd:
И логи тоже проверьте, они будут чистыми, никаких предупреждений :)
На этом – всё. Надеемся, что наша статься будет вам полезна и поставит, наконец, точку в истории этого надоевшего всем бага. Выражаем благодарность нашим читателям, которые активно обсуждали данную проблему в комментариях и подсказали правильное направление для её решения.
Само слово состоит из двух частей - Dev (Development), то есть разработка и Ops (Operations) - эксплуатация.
Разработка и эксплуатация. Ок, запомнили. Но что это конкретно? Танец? Напиток? Профессия?
Не совсем, девопс - это модель взаимодействия тех, кто пишет код с теми, кто этот код заставляет работать - раскатывает в продакшн, управляет серверами, сетью и вот этим вот всем. Такая профессия называется ДевОпс-инженер
Любая компания, которая делает деньги на разработке программного обеспечения, хочет быстро расти, быть технологичнее и быстрее своих конкурентов, при это не забывать о наличии печенек и вкусного чая на кухне в офисе.
У серьезных компаний большая и сложная инфраструктура: куча серверов, коммутаторов, маршрутизаторов, и все это еще и раскидано географически по миру. А чтобы код их приложения заработал у пользователей, без лагов, багов и задержек, нужно учесть кучу факторов!
До появления методологии DevOps, при разработке, могли возникать случаи, когда что-то не работает, или работает не так, как хотелось бы:
«Мой код превосходен, а сервера сконфигурированы хреново, а еще ваша сеть, кхм-кхм, - говно» - говорит разработчик
«Сеть работает отлично, задержка в пределах нормы, а вы там что то наговнокодили» - парирует администратор
И понеслась. У сетевого администратора не хватало компетенций и информации о том как надо настраивать сервера, в результате чего приходилось подключать для этого разработчиков, у которых в свою очередь не было компетенций админов.
Короче, ДевОпс инженер это по сути системный администратор который работает с программным обеспечением, серверами и сетью, а также понимает как происходит процесс разработки и умеет программировать. Новый виток эволюции админа, который умеет больше и, конечно, получает больше денег.
Девопс исключит перекидывание мячика из отдела разработки к администраторам, значительно ускорит релизы новых фич и исправлений в продукте, откроет дорогу к легкому масштабированию и повышению надежности инфраструктуры, превратит вашу разработку в полноценный конвейер, даст прохладу, влажность и, скорее всего, силу земли
Итак, вот базовые вещи, которые должен знать девопс инженер:
Легко ориентироваться в Windows и Linux операционных системах - кстати, по ним у нас есть собственные курсы и никто не помешает тебе пройти бесплатный вводный урок по ссылке.
Нужно знать сетевые технологии на уровне Cisco CCNA - вот это совпадение! У нас также есть большой курс по сетевым технологиям, который поможет тебе познать самые нужные сетевые аспекты работы DevOps.
ДевОпс должен знать инструменты для управления конфигурацией и автоматизации серверов Chef, Puppet, Ansible.
И уметь писать скрипты. Ну минимум на Python. Зачем это надо? Как раз чтобы работать с этими инструментами.
Этого достаточно, чтобы уже получать в среднем по РФ 100-200 тысяч рублей!
Ну и как видавшие девопсов добавим, что будет отлично так же знать:
Про непрерывную интеграцию и доставку (CI/CD) – сборка и тестирование конечного продукта (Jenkins, TeamCity, Bamboo)
Распределенный контроль версий (Git, Mercurial, Subversion, CVS)
Контейнеризацию и оркестровку (Docker, Kubernetes, Docker Swarm)
Управление инфраструктурой как кодом (Puppet, Chef, Ansible, Salt)
Виртуализацию (Vagrant, VMware)
Подробнее об этих и других инструментах можно прочитать в этой статье.
Неизменяемая резервная копия защищает данные, фиксируя их и не позволяя их менять. Этот тип резервного копирования предотвращает возможность удаления данных и позволяет восстановить их в любое время. В результате неизменяемые резервные копии защищают данные от случайного или преднамеренного удаления данных или атак программ-вымогателей.
Что же такое неизменяемые резервные копии?
Данные – это критически важная часть любой организации. Именно по этой причине они являются основной целью кибератак.
Программа-вымогатель – это тип вредоносного ПО, которое шифрует данные так, что их больше нельзя использовать. Шифрование может доходить до уровня загрузочной записи, чтобы загрузка была невозможна. Это также распространяется и на резервные копии данных.
Атака программы-вымогателя приводит к отключению важнейших бизнес-служб. Для того, чтобы получить доступ к вашим данным снова, вам придется заплатить выкуп.
Одним из способов минимизировать вред от атак программ-вымогателей является регулярное резервное копирование данных, что является последней линией защиты. Однако обычное копирование данных вовсе не означает, что они защищены от кибератак.
Усовершенствованные атаки программ-вымогателей могут быть теперь нацелены и на резервные копии. Злоумышленники могут изменить или удалить резервную копию и потребовать крупный выкуп. Чтобы предотвратить такую ситуацию, можно воспользоваться неизменяемой резервной копией.
Неизменяемость препятствует несанкционированному доступу к данным или их удалению. Наличие неизменяемой резервной копии гарантирует, что у вас всегда будет самая последняя верная копия ваших данных, безопасная и доступная для восстановления в любое время.
Неизменяемые резервные копии создаются путем копирования битов данных в облако сразу после их создания.
После того, как данные попадут в облако, пользователь может установить флаг неизменяемости (неизменяемости битов). Этот флаг блокирует данные, предотвращая случайное удаление данных, заражение вредоносным ПО или повреждение данных.
Пользователь может установить флаг на определенный период времени. То есть если вы установите флаг на семь дней, то не сможете удалить или изменить резервную копию в течение этого периода времени.
Вы можете хранить краткосрочные неизменяемые резервные копии локально или многоуровневые резервные копии данных в неизменяемом объектном хранилище удаленно. Таким образом, вы защищаете данные от непредвиденного вредоносного действия или случайного удаления.
Недостатки изменяемой инфраструктуры
Изменяемая инфраструктура – это инфраструктура информационного сервера, которую можно постоянно изменять и обновлять в обычном порядке.
Несмотря на то, что такая инфраструктура имеет свои преимущества, она также имеет и несколько недостатков в сравнении с неизменяемой инфраструктурой.
Недостатки изменяемой инфраструктуры следующие:
Конфигурационный дрейф. Изменения конфигурации сервера не регистрируются систематически, трудно диагностировать или воспроизвести технические проблемы.
Недискретное управление версиями. Отслеживание версий затруднено, поскольку изменения сервера не всегда документируются.
Ошибки обновления. Обновления с большей долей вероятности завершатся сбоем из-за различных проблем с сетью (DNS в автономном режиме, плохое подключение, не отвечающие репозитории и т.д.)
Медленная отладка. Проблемы с отслеживанием версий замедляют процесс отладки. Следовательно, пользователи могут столкнуться с несколькими версиями обновлений и большими рабочими нагрузками в случае обновлений с ошибками.
Повышенный риск. Изменяемая инфраструктура увеличивает риск потери данных и атак программ-вымогателей, если сравнивать с неизменяемой инфраструктурой.
Ручная настройка. Изменяемая инфраструктура требует ручной настройки сервера, что проводит к увеличению длительности процесса подготовки серверов.
Как реализовать стратегию неизменяемого резервного копирования?
Компании часто пытаются противостоять программам-вымогателям, вкладывая средства в надежную и устойчивую к отказам систему защиты. Однако лучше стоит подготовиться к наихудшему сценарию – сценарию, при котором системы защиты компании откажут.
Внедрение стратегии неизменяемого резервного копирования – лучший способ защитить ваши данные и быстро отреагировать на кибератаку без необходимости платить огромный выкуп.
Многие передовые методы резервного копирования и восстановления данных не защищены от атак программ-вымогателей.
Например, репликация данных в удаленный центр обработки данных не обеспечивает защиту от программ-вымогателей, поскольку непрерывное резервное копирование может перезаписывать исправные файлы зашифрованными версиями. Поэтому сложно точно определить начальную точку возникновения вируса.
Правило резервного копирования 3-2-1 (3-2-1 backup rule) – это стратегия защиты данных, которая предполагает, как минимум, три копии данных. Две копии являются локальными, но находятся на разных носителях, а третья – удаленная (например, неизменяемая резервная копия с воздушным зазором в облаке).
Передовые методы для реализации неизменяемого резервного копирования:
Целостность данных
Лучший способ защитить резервную копию данных – хранить ее на платформе, которая не позволит вносить изменения. Некоторые фирмы-поставщики предлагают объектно-ориентированное хранилище, которое делает невозможным изменение данных или их шифрование при атаке программы-вымогателя.
Модель нулевого доверия
Такая модель включает строгую проверку личности для любого, кто получает доступ к вашим резервным копиям данных в частной сети. Такой целостный подход состоит из нескольких методов и технологий, которые обеспечивают повышенный уровень безопасности и надежность резервного копирования.
Один из таких методов – усиление безопасности с помощью многофакторной аутентификации.
Многоуровневая устойчивость к отказам
Хорошая стратегия защиты сочетает в себе неизменяемое резервное копирование данных с новейшими технологиями кибербезопасности и обучением сотрудников.
Платформы, включающие в себя функции предотвращения удаления лишних файлов или удаления с возможность восстановления, гарантируют наличие копии данных, даже если программа-вымогатель проникнет в систему.
Другой уровень защиты заключается в использовании формата WORM (write once read many - однократная запись и многократное считывание), который предлагают многие фирмы-поставщики.
Автоматическое реагирование
Атаки программ-вымогателей обычно происходят через несколько месяцев после того, как система была заражена. Злоумышленники специально выжидают столько времени, чтобы программа-вымогатель могла незаметно распространиться и найти все резервные копии данных. Затем, когда в офисе никого не остается, они заполучает ваши данные.
Внедрите систему автоматического реагирования в решение для резервного копирования, чтобы помещать зараженные системы в «карантин», даже если в этот момент в офисе никого нет.
«Чистое» восстановление
Убедитесь, то ваша резервная копия данных не содержит вредоносных программ, чтобы предотвратить повторное заражение. Сканируйте резервные копии на наличие вредоносных программ или индикаторов компрометации перед тем, как восстанавливать данные.
Храните неизменяемые резервные копии данных в формате WORM, чтобы защитить данные от шифрования и обеспечить быстрое восстановление данных.
Заключение
Теперь вы знаете, что такое неизменяемые резервные копии и как они могут защитить ваши данные от кибератак. Когда речь идет о программах-вымогателях, то лучшее нападение – это надежная защита.