По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Apache Cassandra — это популярное программное обеспечение базы данных NoSQL с открытым исходным кодом. Cassandra обеспечивает высокую доступность при обработке большого объема данных. Обычные реляционные базы данных не могут справиться с линейным масштабированием, бесшовным распределением данных и другими требованиями к большим данным так же эффективно, как Cassandra.
Ряд крупных игроков в онлайн-индустрии используют Apache Cassandra, такие как Netflix, Apple, Uber и eBay.
В этом руководстве мы расскажем как установить Apache Cassandra на Ubuntu Linux с необходимыми пакетами.
ШАГ 1: Установите пакеты, необходимые для Apache Cassandra
Прежде чем приступить к установке Cassandra в Ubuntu, убедитесь, что вы установили Java OpenJDK 8 и пакет api-transport-https.
Если у вас уже установлены эти пакеты, вы можете перейти к шагу 2 руководства.
Примечание. В качестве примеров мы использовали Ubuntu 20.04, но инструкции применимы и к другим версиям Ubuntu.
Установите Java OpenJDK
Apache Cassandra нуждается в OpenJDK 8 для работы в системе Ubuntu. Сначала обновите репозиторий пакетов:
sudo apt update
Когда процесс завершится, установите OpenJDK 8 с помощью следующей команды:
sudo apt install openjdk-8-jdk -y
Когда установка завершится, проверьте, успешно ли установлена Java, проверив версию Java:
java -version
На выходе должна быть показана версия Java.
Вторая цифра (8) представляет версию Java.
Установите пакет apt-transport-https
Затем установите транспортный пакет APT. Вам необходимо добавить этот пакет в свою систему, чтобы разрешить доступ к репозиториям с использованием HTTPS.
Введите эту команду:
sudo apt install apt-transport-https
В приведенном выше примере выделены последние два шага процесса установки apt-transport-https.
ШАГ 2. Добавьте репозиторий Apache Cassandra и импортируйте ключ GPG
Вам нужно добавить репозиторий Apache Cassandra и получить ключ GPG перед установкой базы данных.
Введите команду ниже, чтобы добавить репозиторий Cassandra в список источников:
sudo sh -c 'echo "deb http://www.apache.org/dist/cassandra/debian 40x main" > /etc/apt/sources.list.d/cassandra.list'
Вывод возвращается к новой строке без сообщения.
Последний крупный выпуск Cassandra на момент написания этой статьи — 4.0. Вот почему мы использовали 40 в команде. Чтобы установить более старую версию, например 3.9, замените 40x на 39x.
Затем используйте команду wget, чтобы получить открытый ключ по указанному ниже URL-адресу:
wget -q -O - https://www.apache.org/dist/cassandra/KEYS | sudo apt-key add -
Если вы правильно ввели команду и URL-адрес, на выходе выводится сообщение «ОК».
Примечание: обратите внимание на регистр букв в URL-адресе выше. Вам нужно ввести правильный регистр и тире в конце команды.
ШАГ 3: Установите Apache Cassandra
Теперь вы готовы установить Cassandra на Ubuntu.
Обновите список пакетов репозитория:
sudo apt update
Затем запустите команду установки:
sudo apt install Cassandra
В приведенном выше выводе показан последний раздел процедуры установки Cassandra в Ubuntu 20.04. Вывод должен выглядеть аналогично в более старых версиях Ubuntu.
Примечание. После завершения установки служба Cassandra запускается автоматически. Также в процессе создается пользователь cassandra. Этот пользователь используется для запуска службы.
Проверка установки Apache Cassandra
Наконец, чтобы убедиться, что процесс установки Cassandra завершился правильно, проверьте состояние кластера:
nodetool status
Буквы UN в выводе сигнализируют о том, что кластер работает.
Вы также можете проверить статус Cassandra, введя:
sudo systemctl status cassandra
Выход должен отображаться как active (running) зеленым цветом.
Команды для запуска, остановки и перезапуска службы Cassandra
Если по какой-либо причине после установки служба показывается неактивной, вы можете запустить ее вручную.
Используйте следующую команду для запуска Cassandra:
sudo systemctl start cassandra
Еще раз проверьте статус услуги. Он должен измениться на активный.
Чтобы перезапустить службу, используйте команду перезапуска:
sudo systemctl restart cassandra
Чтобы остановить службу Cassandra, введите:
sudo systemctl stop cassandra
Статус отображается как неактивный после использования команды остановки.
Автоматически запускать службу Apache Cassandra при загрузке
Когда вы выключаете или перезагружаете систему, служба Cassandra становится неактивной.
Чтобы запустить Cassandra автоматически после загрузки, используйте следующую команду:
sudo systemctl enable cassandra
Теперь, если ваша система перезагрузится, служба Cassandra включается автоматически.
ШАГ 4. Настройка Apache Cassandra
Вы можете изменить настройки конфигурации Cassandra в зависимости от ваших требований. Конфигурации по умолчанию достаточно, если вы собираетесь использовать Cassandra на одной ноде. При использовании Cassandra в кластере вы можете настроить основные параметры с помощью файла cassandra.yaml.
Мы рекомендуем создать резервную копию файла cassandra.yaml, если вы собираетесь его редактировать. Для этого используйте эту команду:
sudo cp /etc/cassandra/cassandra.yaml /etc/cassandra/cassandra.yaml.backup
Мы использовали каталог /etc/cassandra в качестве места назначения для резервной копии, но вы можете изменить путь по своему усмотрению.
Переименовать кластер Apache Cassandra
Используйте текстовый редактор по вашему выбору, чтобы открыть файл cassandra.yaml (мы будем использовать nano):
sudo nano /etc/cassandra/cassandra.yaml
Найдите строку, которая гласит cluster_name:. Имя по умолчанию — Test Cluster. Это первое изменение, которое вы хотите сделать, когда начнете работать с Cassandra.
Если вы не хотите вносить дополнительные изменения, выйдите и сохраните файл.
Добавить IP-адреса узлов Cassandra
Еще одна вещь, которую вы должны добавить в cassandra.yaml, если вы используете кластер, — это IP-адрес каждого узла.
Откройте файл конфигурации и в разделе seed _provider найдите запись seeds
Добавьте IP-адрес каждого узла в вашем кластере. Разделите записи, используя запятую после каждого адреса.
ШАГ 5. Протестируйте оболочку командной строки Cassandra
Программный пакет Cassandra поставляется с инструментом командной строки (CLI). Этот инструмент использует язык запросов Cassandra - CQL для связи.
Чтобы запустить новую оболочку, откройте терминал и введите:
cqlsh
Загружается оболочка, показывающая подключение к кластеру по умолчанию. Если вы изменили параметр cluster_name, он покажет тот, который вы определили в файле конфигурации. В приведенном выше примере показано подключение по умолчанию к локальному хосту.
Итоги
Следуя этим простым шагам, у вас должна быть работающая установка Cassandra в вашей системе Ubuntu.
Кроме того, мы показали вам, как редактировать наиболее важные параметры в файле конфигурации Cassandra. Не забудьте сделать резервную копию файла conf на всякий случай, и вы можете начать использовать программное обеспечение базы данных Cassandra.
Узнайте больше о том, как использовать Cassandra, в нашем руководстве о том, как создавать, удалять, изменять и очищать таблицы Cassandra.
Всем привет! В сегодняшней статье мы расскажем, как победить очень надоедливый “баг” во 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:
И логи тоже проверьте, они будут чистыми, никаких предупреждений :)
На этом – всё. Надеемся, что наша статься будет вам полезна и поставит, наконец, точку в истории этого надоевшего всем бага. Выражаем благодарность нашим читателям, которые активно обсуждали данную проблему в комментариях и подсказали правильное направление для её решения.
Привет всем! В сегодняшней статье мы хотим рассказать об одном крайне полезном трюке, который поможет сохранить время Вам и клиентам, позвонившим в Вашу компанию. Демонстрировать этот функционал мы будем на IP-АТС Asterisk через графический интерфейс FreePBX 14.
Данная статья будет особенно актуальна для тех, кто пользуется переадресацией входящих звонков на мобильный телефон.
Возможно, кто-то уже использует данный способ, но многие могут о нем и не знать.
Кейс
Итак, представим себе такую гипотетическую ситуацию:
К нам в компанию позвонил клиент;
Звонок поступил на ринг группу 345, в которой находится 3 внутренних номера;
Звонки с этих внутренних номеров переадресовываются на мобильные номера менеджеров;
И вот на своём мобильном телефоне звонок клиента принял менеджер Алексей;
Они общаются, и тут у клиента возникает вопрос к инженеру, клиент просит перевести его на инженера;
Алексей может находиться вне офиса и не за стационарным телефоном и не может перевести звонок клиента обратно;
Он просит клиента перезвонить на общий номер компании и донабрать внутренний номер инженера;
Ситуация вполне нормальная, но мы вынуждены просить нашего клиента звонить повторно, донабирать номер, тратить свое время и так далее.
Вот бы было здорово иметь возможность перевести звонок клиента на нужный номер прямо с мобильного? А ещё лучше, если мы сможем поговорить с человеком, на которого нужно перевести звонок и узнать не занят ли он, прежде чем делать трансфер!
Такая возможность есть и сейчас мы объясним как её реализовать.
Решение
Дело в том, что когда звонки с нашей IP-АТС переводятся на мобильный телефон, то канал между ними не разрывается. Например, если у вас включена запись, то вы можете увидеть, что такие звонки также записываются. А значит, мы можем контролировать такие звонки на любом устройстве, даже на мобильном телефоне. Делать трансфер, ставить на ожидание, парковать и так далее.
Для того, чтобы открылась возможность сделать трансфер на другой номер, находясь в звонке, нужно передать приложению Asterisk Dial() нужный аргумент. Во FreePBX это настраивается в Settings → Advanced Settings в разделе Dialplan and Operational.
Здесь есть два поля - Asterisk Dial Options, в котором можно добавить аргументы Dial() при совершении внутренних звонков и Asterisk Outbound Trunk Dial Options, который отвечает за обработку аргументов Dial() при совершении внешних звонков через транк, как раз это поле нам и нужно.
По умолчанию в данном поле всего один аргумент - большая буква T. Этот аргумент позволяет позвонившей стороне сделать трансфер используя feature code - ##
Сервисный код ## соответствует функции “слепого” трансфера -In-Call Asterisk Blind Transfer
Однако, когда мы принимаем звонок на мобильном телефоне, то являемся вызываемой стороной, поэтому нам нужен другой аргумент – маленькая буква t. С помощью данного аргумента, мы сможем делать трансфер находясь в звонке, используя всё тот же feature code - ##.
Итак, можно добавить аргумент t в поле Asterisk Outbound Trunk Dial Options, но тогда этот функционал распространится на все транки, которые созданы на вашей IP-АТС.
Есть более безопасный способ включить трансфер на принимающей стороне. Для этого переходим в Connectivity → Trunks и в настройках транка на вкладке General ищем опцию Asterisk Trunk Dial Options
По умолчанию, в данной опции мы так же увидим аргумент T, так как стоит параметр System, который просто подтягивает значения аргумента из Asterisk Outbound Trunk Dial Options в Advanced Settings
Выбрав параметр Override, мы можем записать сюда какие угодно аргументы и они будут действовать только для данного конкретного транка. Запишем сюда маленькую t.
Итак, теперь, если Вы приняли вызов на мобильном телефоне, а человек, с которым Вы разговариваете просит перевести его на другого сотрудника, Вы можете просто:
Нажать ## на своём мобильном телефоне, после чего Вы услышите в трубке сообщение “перевод”;
Набрать нужный номер (например - 529). В это время позвонивший будет слышать музыку на ожидании;
Вызов автоматически завершится, а звонок будет переадресован тому, чей номер Вы набрали;
Profit;
А помните мы говорили, что можно ещё поговорить с тем, кому нужно перевести вызов, прежде чем его переводить, чтобы уточнить не занят ли этот человек? Так вот такая возможность при принятии звонка на мобильном тоже есть!
Если мы откроем возможные сервисные коды (feature code) функций трансфера, то увидим, что их два - ## - In-Call Asterisk Blind Transfer, который мы уже знаем, и *2 - функция консультативного трансфера - In-Call Asterisk Attended Transfer.
Таким образом, можно также пользоваться консультативным трансфером, в этом случае нужно:
Нажать *2 на своём мобильном телефоне, после чего Вы услышите в трубке сообщение “перевод”;
Набрать нужный номер (например - 529). В это время позвонивший будет слышать музыку на ожидании;
Дождаться, пока человек, которому нужно перевести вызов, ответит и узнать у него можно ли делать перевод. Если он сбросит или не возьмёт трубку, то ваш разговор с ожидающим на линии абонентом возобновится и Вы сможете объяснить ему, что соединиться не удалось;
Если человек, которому нужно перевести вызов готов поговорить с ожидающим на линии абонентом, то нужно просто завершить вызов. Тогда разговор продолжится уже между ними;
Кстати! Номер, который Вы набираете после того или иного сервисного кода, не обязательно должен быть внутренним. Это может быть любой другой номер (например, мобильный - *289012345678). Главное набирать его в таком формате, чтобы Ваша IP-АТС могла до него дозвониться.