По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Эта статья подробно объясняет функции и терминологию протокола RIP (административное расстояние, метрики маршрутизации, обновления, пассивный интерфейс и т.д.) с примерами.
RIP - это протокол маршрутизации вектора расстояния. Он делится информацией о маршруте через локальную трансляцию каждые 30 секунд.
Маршрутизаторы хранят в таблице маршрутизации только одну информацию о маршруте для одного пункта назначения. Маршрутизаторы используют значение AD и метрику для выбора маршрута.
Первая часть статьи про базовые принципы работы протокола RIP доступна по ссылке.
Административная дистанция
В сложной сети может быть одновременно запущено несколько протоколов маршрутизации. Различные протоколы маршрутизации используют различные метрики для расчета наилучшего пути для назначения. В этом случае маршрутизатор может получать различную информацию о маршрутах для одной целевой сети. Маршрутизаторы используют значение AD для выбора наилучшего пути среди этих маршрутов. Более низкое значение объявления имеет большую надежность.
Административная дистанция
Протокол/Источник
0
Непосредственно подключенный интерфейс
0 или 1
Статическая маршрутизация
90
EIGRP
110
OSPF
120
RIP
255
Неизвестный источник
Давайте разберемся в этом на простом примере: А маршрутизатор изучает два разных пути для сети 20.0.0.0/8 из RIP и OSPF. Какой из них он должен выбрать?
Ответ на этот вопрос скрыт в приведенной выше таблице. Проверьте объявленную ценность обоих протоколов. Административное расстояние - это правдоподобие протоколов маршрутизации. Маршрутизаторы измеряют каждый источник маршрута в масштабе от 0 до 255. 0 - это лучший маршрут, а 255-худший маршрут. Маршрутизатор никогда не будет использовать маршрут, изученный этим (255) источником. В нашем вопросе у нас есть два протокола RIP и OSPF, и OSPF имеет меньшее значение AD, чем RIP. Таким образом, его маршрут будет выбран для таблицы маршрутизации.
Метрики маршрутизации
У нас может быть несколько линий связи до целевой сети. В этой ситуации маршрутизатор может изучить несколько маршрутов, формирующих один и тот же протокол маршрутизации. Например, в следующей сети у нас есть два маршрута между ПК-1 и ПК-2.
Маршрут 1:
ПК-1 [10.0.0.0/8] == Маршрутизатор OFF1 [S0/1 - 192.168.1.254] = = Маршрутизатор OFF3 [S0/1-192.168.1.253] = = ПК-2 [20.0.0.0/8]
Маршрут 2:
ПК-1 [10.0.0.0/8] == Маршрутизатор OFF1 [S0/0 - 192.168.1.249] == Маршрутизатор OFF2 [S0/0 - 192.168.1.250] == Маршрутизатор OFF2 [S0/1 - 192.168.1.246] == Маршрутизатор OFF3 [S0/0 - 192.168.1.245] == ПК-2 [20.0.0.0/8]
В этой ситуации маршрутизатор использует метрику для выбора наилучшего пути. Метрика - это измерение, которое используется для выбора наилучшего пути из нескольких путей, изученных протоколом маршрутизации. RIP использует счетчик прыжков в качестве метрики для определения наилучшего пути. Прыжки - это количество устройств уровня 3, которые пакет пересек до достижения пункта назначения.
RIP (Routing Information Protocol) - это протокол маршрутизации вектора расстояния. Он использует расстояние [накопленное значение метрики] и направление [вектор], чтобы найти и выбрать лучший путь для целевой сети. Мы объяснили этот процесс с помощью примера в нашей первой части этой статьи.
Хорошо, теперь поймите концепцию метрики; скажите мне, какой маршрут будет использовать OFF1, чтобы достичь сети 20.0.0.0/8? Если он выбирает маршрут S0/1 [192.168.1.245/30], он должен пересечь устройство 3 уровня. Если он выбирает маршрут S0/0 [19.168.1.254/30], то ему придется пересечь два устройства уровня 3 [маршрутизатор OFF! и последний маршрутизатор OFF3], чтобы достичь целевой сети.
Таким образом, он будет использовать первый маршрут, чтобы достигнуть сети 20.0.0.0/8.
Маршрутизация по слухам
Иногда RIP также известен как маршрутизация по протоколу слухов. Потому что он изучает информацию о маршрутизации от непосредственно подключенных соседей и предполагает, что эти соседи могли изучить информацию у своих соседей.
Обновления объявлений
RIP периодически транслирует информацию о маршрутизации со всех своих портов. Он использует локальную трансляцию с IP-адресом назначения 255.255.255.255. Во время вещания ему все равно, кто слушает эти передачи или нет. Он не использует никакого механизма для проверки слушателя. RIP предполагает, что, если какой-либо сосед пропустил какое-либо обновление, он узнает об этом из следующего обновления или от любого другого соседа.
Пассивный интерфейс
По умолчанию RIP транслирует со всех интерфейсов. RIP позволяет нам контролировать это поведение. Мы можем настроить, какой интерфейс должен отправлять широковещательную передачу RIP, а какой нет. Как только мы пометим любой интерфейс как пассивный, RIP перестанет отправлять обновления из этого интерфейса.
Расщепление горизонта
Split horizon-это механизм, который утверждает, что, если маршрутизатор получает обновление для маршрута на любом интерфейсе, он не будет передавать ту же информацию о маршруте обратно маршрутизатору-отправителю на том же порту. Разделенный горизонт используется для того, чтобы избежать циклов маршрутизации.
Чтобы понять эту функцию более четко, давайте рассмотрим пример. Следующая сеть использует протокол RIP. OFF1-это объявление сети 10.0.0.0/8. OFF2 получает эту информацию по порту S0/0.
Как только OFF2 узнает о сети 10.0.0.0/8, он включит ее в свое следующее обновление маршрутизации. Без разделения горизонта он будет объявлять эту информацию о маршруте обратно в OFF1 на порту S0/0.
Ну а OFF1 не будет помещать этот маршрут в таблицу маршрутизации, потому что он имеет более высокое значение расстояния. Но в то же время он не будет игнорировать это обновление. Он будет предполагать, что OFF1 знает отдельный маршрут для достижения сети 10.0.0.0/8, но этот маршрут имеет более высокое значение расстояния, чем маршрут, который я знаю. Поэтому я не буду использовать этот маршрут для достижения 10.0.0.0/8, пока мой маршрут работает. Но я могу воспользоваться этим маршрутом, если мой маршрут будет недоступен. Так что это может сработать как запасной маршрут для меня.
Это предположение создает серьезную сетевую проблему. Например, что произойдет, если интерфейс F0/1 OFF1 выйдет из строя? OFF1 имеет прямое соединение с 10.0.0.0/8, поэтому он сразу же узнает об этом изменении.
В этой ситуации, если OFF1 получает пакет для 10.0.0.0/8, вместо того чтобы отбросить этот пакет, он переадресует его из S0/0 в OFF2. Потому что OFF1 думает, что у OFF2 есть альтернативный маршрут для достижения 10.0.0.0/8.
OFF2 вернет этот пакет обратно в OFF1. Потому что OFF2 думает, что у OFF1 есть маршрут для достижения 10.0.0.0/8.
Это создаст сетевой цикл, в котором фактический маршрут будет отключен, но OFF1 думает, что у OFF2 есть маршрут для назначения, в то время как OFF2 думает, что у OFF1 есть способ добраться до места назначения. Таким образом, этот пакет будет бесконечно блуждать между OFF1 и OFF2. Чтобы предотвратить эту проблему, RIP использует механизм подсчета прыжков (маршрутизаторов).
Количество прыжков
RIP подсчитывает каждый переход (маршрутизатор), который пакет пересек, чтобы добраться до места назначения. Он ограничивает количество прыжков до 15. RIP использует TTL пакета для отслеживания количества переходов. Для каждого прыжка RIP уменьшает значение TTL на 1. Если это значение достигает 0, то пакет будет отброшен.
Это решение только предотвращает попадание пакета в петлю. Это не решает проблему цикла маршрутизации.
Split horizon решает эту проблему. Если расщепление горизонта включено, маршрутизатор никогда не будет вещать тот же маршрут обратно к отправителю. В нашей сети OFF2 узнал информацию о сети 10.0.0.0/8 от OFF1 на S0/0, поэтому он никогда не будет транслировать информацию о сети 10.0.0.0/8 обратно в OFF1 на S0/0.
Это решает нашу проблему. Если интерфейс F0/1 OFF1 не работает, и OFF1, и OFF2 поймут, что нет никакого альтернативного маршрута для достижения в сети 10.0.0.0/8.
Маршрут отравления
Маршрут отравления работает противоположном режиме расщепления горизонта. Когда маршрутизатор замечает, что какой-либо из его непосредственно подключенных маршрутов вышел из строя, он отравляет этот маршрут. По умолчанию пакет может путешествовать только 15 прыжков RIP. Любой маршрут за пределами 15 прыжков является недопустимым маршрутом для RIP. В маршруте, находящимся в неисправном состоянии, RIP присваивает значение выше 15 к конкретному маршруту. Эта процедура известна как маршрутное отравление. Отравленный маршрут будет транслироваться со всех активных интерфейсов. Принимающий сосед будет игнорировать правило разделения горизонта, передавая тот же отравленный маршрут обратно отправителю. Этот процесс гарантирует, что каждый маршрутизатор обновит информацию об отравленном маршруте.
Таймеры RIP
Для лучшей оптимизации сети RIP использует четыре типа таймеров.
Таймер удержания (Hold down timer) - RIP использует удерживающий таймер, чтобы дать маршрутизаторам достаточно времени для распространения отравленной информации о маршруте в сети. Когда маршрутизатор получает отравленный маршрут, он замораживает этот маршрут в своей таблице маршрутизации на период таймера удержания. В течение этого периода маршрутизатор не будет использовать этот маршрут для маршрутизации. Период удержания будет прерван только в том случае, если маршрутизатор получит обновление с той же или лучшей информацией для маршрута. Значение таймера удержания по умолчанию составляет 180 секунд.
Route Invalid Timer - этот таймер используется для отслеживания обнаруженных маршрутов. Если маршрутизатор не получит обновление для маршрута в течение 180 секунд, он отметит этот маршрут как недопустимый маршрут и передаст обновление всем соседям, сообщив им, что маршрут недействителен.
Route Flush Timer - этот таймер используется для установки интервала для маршрута, который становится недействительным, и его удаления из таблицы маршрутизации. Перед удалением недопустимого маршрута из таблицы маршрутизации он должен обновить соседние маршрутизаторы о недопустимом маршруте. Этот таймер дает достаточно времени для обновления соседей, прежде чем недопустимый маршрут будет удален из таблицы маршрутизации. Таймер Route Flush Timer по умолчанию установлен на 240 секунд.
Update Timer -В RIP широковещательная маршрутизация обновляется каждые 30 секунд. Он будет делать это постоянно, независимо от того, изменяется ли что-то в маршрутной информации или нет. По истечении 30 секунд маршрутизатор, работающий под управлением RIP, будет транслировать свою информацию о маршрутизации со всех своих интерфейсов.
RIP - это самый старый протокол вектора расстояний. Для удовлетворения текущих требований к сети он был обновлен с помощью RIPv2. RIPv2 также является протоколом вектора расстояния с максимальным количеством прыжков 15.
Вы все еще можете использовать RIPv1, но это не рекомендуется. В следующей таблице перечислены ключевые различия между RIPv1 и RIPv2.
Основные различия между RIPv1 и RIPv2
RIPv1
RIPv2
Он использует широковещательную передачу для обновления маршрутизации.
Он использует многоадресную рассылку для обновления маршрутизации.
Он посылает широковещательный пакет по адресу назначения 255.255.255.255.
Он отправляет многоадресную рассылку по адресу назначения 224.0.0.9.
Он не поддерживает VLSM.
Он поддерживает VLSM.
Он не поддерживает никакой аутентификации.
Он поддерживает аутентификацию MD5
Он поддерживает только классовую маршрутизацию.
Он поддерживает как классовую, так и бесклассовую маршрутизацию.
Он не поддерживает непрерывную сеть.
Он поддерживает непрерывную сеть.
В данной статье мы рассмотрим процессы CICD автоматизации.
Разберем роль такого продукта, как Jenkins и его аналогов. Программное обеспечение Jenkins написано на языке программирования Java, по отзывам ИТ сообщества, данный продукт написан очень хорошо. Но самое главное данное программное обеспечение полностью бесплатное. Многие энтузиасты в мире для данного продукта пишут плагины, которые расширяют функционал Jenkins. Рассмотрим 2 ключевых понятия CICD Автоматизации.
CI – Continuous Integration. Это DevOps модель, в которой разработчики делают commit кода в репозиторий (обычно используется github или gitlab, для хранения кода) и автоматически запускается build или компиляция этого кода, после этого запускаются автоматические тесты кода: Unit Test, Integration Test, Functionality Test.
CD – Continuous Delivery and Deployment. Это DevOps модель, в которой разработчики делают commit кода в репозиторий и автоматически запускается build или компиляция этого кода, после этого запускаются автоматические тесты кода и готовый Artifact (скомпилированный код, например если это Java, то артефактом является var, если это Android приложение, то apk файл) делает деплой в Staging и Production, т.е происходит установка кода в развернутую вашу среду в необходимом контуре. Рассмотрим процесс на примере.
Процесс CICD автоматизации
Первым шагом в процессе является Commit to Source Control (github, gitlab или bitbucket), система определяет наличие нового кода, срабатывает триггер и автоматически запускается следующий этап BuildCompile - компиляция кода.
Система скачивает новый код, например, если код попал в master branch (основную ветку). После получения ответа от сборки, что все прошло успешно, запускается следующий этап тестов. Все тесты пишут все те же программисты, для того, чтобы проверить на сколько корректно отработал код. Весь этот процесс называется Continuous Integration. Это классическая схема содержит 3 этапа, иногда включаются дополнительные шаги, но они не принципиальны. В результате данного процесса мы получаем скомпилированный и протестированный код.
Давайте рассмотрим последующие шаги. Следующий шаг мы можем сделать deployment кода. По сути это тот же процесс копирования файлов кода на сервера. Процесс деплоя можно делать в разные места, можно делать в AWS или Azure, можно делать в свое частное облако, развернутое на VMware. Весь процесс с добавочными шагами называется Continuous Delivery and Deployment.
Получается следующее: за Source Control – отвечает git. За шаг build и compile будет отвечать Jenkins. Следовательно, Jenkins запустится, когда кто-нибудь сделает комит в систему контроля версий, в основную ветку или не основную, смотря как настроено. Следующим шагом Jenkins выполнит все необходимые тесты, которые подготовили программисты. Следующий шаг Deploy так же запустит Jenkins и скопирует код на необходимые сервера, с помощью скрипта или scp если это Linux сервер. Существуют вариации с использованием Puppet или Ansible если мы делаем Deploy артефакта или конфигурации в целом.
Существуют альтернативы Jenkins, например, Bamboo, Circleci, Gitlab CICD, TeamCity.
Установка Jenkins
Для развертывания Jenkins нам понадобится виртуальная машина на Ubuntu версии 18 или выше.
Идем на официальный сайт Jenkins,в разделе Download мы можем увидеть 2 версии. На момент написании статьи актуальная версия Jenkins 2.319.2LTS и во второй колонке мы можем увидеть недельные версии Jenkins 2.333
Как видите дистрибутивы есть практически под все операционные системы. Мы будем использовать стабильную версию под UbuntuDebian. Ознакомимся с требованиями к установке продукта Jenkins. Для инсталляции потребуется минимум 256 МБ RAM, места 1 ГБ, а также на сайте написаны рекомендованные требования, с которыми будет достаточно комфортно работать с продуктом.
Так как Jenkins написан на Java, то для запуска и работы потребуется непосредственно установленная на сервере Java. Для начала проверим версию java на сервере.
java –version
Если сервер свежий или Java не установлена, то операционная система сообщит, что такая команда не найдена и предложить установить Java. Java устанавливается достаточно просто:
sudo apt update – oбновляем репозиторий
sudo apt search openjdk – ищем необходимый пакет
sudo apt install openjdk-11-jdk – запускаем установку java в процессе система попросит подтвердить. Чтобы предупреждение не выскочило мы можем запустить установку с ключем –y
По окончанию установки мы опять проверяем версию. Система покажет версию и билд Java. Теперь наш сервер готов к началу установки Jenkins.
Добавляем ключ и репозиторий в операционную систему:
curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo tee
/usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc]
https://pkg.jenkins.io/debian-stable binary/ | sudo tee
/etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt-get update – обновляем репозиторий
sudo apt-get install Jenkins – инсталлируем непосредственно сам Jenkins
Теперь мы можем сделать пост настроечные мероприятия непосредственно в Jenkins.
Открываем браузер и переходим на веб интерфейс http://ipaddr:8080, где вместо ipaddr – подставляем IP адрес сервера. В ответ получаем вот такое сообщение - Unlock Jenkins
Система просит ввести дополнительный ключ, который был сгенерирован при установке сервера. Найти его достаточно просто достаточно ввести в консоли сервера
sudo cat /var/lib/jenkins/secrets/initialAdminPassword
Копируем и вставляем в веб форму. После прохождения этой несложной системы безопасности мы можем начать базовую настройку.
Система предлагает выбрать стандартную установку или кастомизированную с выбором плагинов (расширений для различного функционала). Если мы выбираем стандартную установку, установятся только те плагины, которые сами разработчики протестировали и выбрали. Если мы выберем установку с выбором, соответственно система даст возможность установить не только стандартные, но и другие плагины.
Выбираем стандартную установку и начинается процесс настройки самого Jenkins.
Мы можем видать, что ставится git плагин, LDAP для работы с Active Directory, ssh для взаимодействия по протоколу ssh, расширение E-mail для отправки уведомлений и.т.д
После непродолжительного ожидания, система предлагает создать суперпользователя с правами администратора в системе.
Заполнение не сложное. Если бы мы выбрали другой вариант установки, то система нам предложила бы выбрать самостоятельно нужные плагины.
Примерно вот в такой форме. Форма от версии к версии может отличатся.
По окончанию заполнения формы, попадаем на экран где нам предлагают проверить URL, т.к эти данные будет Jenkins использовать, как переменные среды.
В итоге мы попадаем на главный экран Jenkins. Данный экран – это основной рабочий стол. С помощью плагинов его можно кастомизировать. Так же можно в джобы добавить много разных параметров.
Дружище! В этой статье мы пошагово разберем процесс установки и первичной настройки Kamailio SIP сервера. Установку будем производить на Ubuntu 18.04/16.04. Готов приблизиться к телефонии уровня энтерпрайз, построенной на open – source? :)
А что есть Kamailio?
Kamailio берет начало от SER/Open SER. Откровенно говоря, Kamailio это масштабируемая и гибкая SIP – платформа, созданная как для маленьких инсталляций, так и для больших проектов уровня сервис – провайдеров. Продукт написан на C и работает на Linux/Unix машинах. Kamailio используется в связке с медиа – сервером (RTP потоки и данные, например, Asterisk) и обеспечивает такие фичи как:
До 5000 вызовов в секунду;
Поддержка 300 000 абонентов (WOW!) при условии наличия всего 4ГБ оперативной памяти для сервера Kamailio!
Легкая кластеризация и добавление новых нод в существующих кластер;
Вообще, Kamailio может выполнять такие роли как:
Registrar server - точка для регистрации клиентов (UAC) ;
Location server - сервер определения местоположения. Сервер хранит адрес (сетевой) абонента и отдает его SIP – серверам по запросу;
Proxy server - роль посредника для дальнейшего проксирования этих запросов далее по цепочке SIP - серверов;
SIP Application server - он же SAS. Сервер приложений. Любых. Плечи в БД, API, XML и так далее – все здесь;
Redirect server - информация клиенту (UAC) о его маршруте. Условно говоря, перенаправляет SIP – потоки по нужному пути;
На этом прелести Kamailio не заканчиваются. Вот еще немного фич, на которые стоит обратить внимание:
Поддержка NAT –T (NAT traversal) для SIP и RTP трафика;
Балансировка нагрузки и отказоустойчивость с множеством сценариев/алгоритмов распределения трафика (на случай отказа);
Лёгкий механизм настрйоки правил маршрутизации;
Простота в реализации отказоустойчивой маршрутизации! Отвалился один маршрут – легко перенаправить трафик на другой;
Поддержка IPv4 и IPv6;
SCTP (Stream Control Transmission Protocol) с поддержкой многопоточности и так называемого multi – homing (синхронизация хостов по двум и более физическим каналам);
Коммуникация по протоколам UDP, TCP, TLS и SCTP;
Кодите на Java, Python, Lua, Perl? Ваши навыки точно пригодятся :)
Приступаем
Перед началом работ, у вас должны быть выполнены следующие требования:
У вас есть сервер, с установленной на него Ubuntu 18.04/16.04;
Вы установили MariaDB на этот сервер;
Вы добавили репозитории Kamailio;
Мы предполагаем, что 1 и 2 пункты вы выполнили :) Приступаем к третьему.
Добавляем репозиторий Kamailio
Если у вас установлена Ubuntu версии 16.04 вам нужно добавить репозиторий Kamailio, который будет использован при установке этой SIP – платформы.
Для начала скачиваем и добавляем GPG ключ:
wget -O- http://deb.kamailio.org/kamailiodebkey.gpg | sudo apt-key add -
После этого нужно добавить строки в файл /etc/apt/sources.list. Работать мы будем с версией 5.1 Kamailio:
$ sudo vim /etc/apt/sources.list.d/kamailio.list
Добавляем данные:
deb http://deb.kamailio.org/kamailio51 xenial main
deb-src http://deb.kamailio.org/kamailio51 xenial main
Установка Kamailio
Как только мы сконфигурировали репозитории, приступаем к установке самого продукта. В том числе, мы установим некоторые MySQL модули:
$ sudo apt install kamailio kamailio-mysql-modules
Установим так же модуль для web – сокетов:
$ sudo apt install kamailio-websocket-modules
Ждем. Как только процессы, рождаемые этими командами будут выполнены, мы можем проверить приложение kamailio и увидеть его версию командой kamailio -V:
$ which kamailio
/usr/sbin/kamailio
$ kamailio -V
version: kamailio 5.1.2 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 7.3.0
Огонь. После этого, правим файл /etc/kamailio/kamctlrc (откройте так же через vim) и проверяем, что параметр DBENGINE выставлен в значение MySQL.
Раскомментируйте значение DBENGINE=MYSQL, удалив # перед строчкой
Далее, создаем базу данных. Команда, указанная ниже, создаст пользователей и таблицы, необходимые для Kamailio:
$ kamdbctl create
INFO: creating database kamailio ...
INFO: granting privileges to database kamailio ...
INFO: creating standard tables into kamailio ...
INFO: Core Kamailio tables succesfully created.
Install presence related tables? (y/n): y
INFO: creating presence tables into kamailio ...
INFO: Presence tables succesfully created.
Install tables for imc cpl siptrace domainpolicy carrierroute
drouting userblacklist htable purple uac pipelimit mtree sca mohqueue
rtpproxy rtpengine? (y/n): y
INFO: creating extra tables into kamailio ...
INFO: Extra tables succesfully created.
Install tables for uid_auth_db uid_avp_db uid_domain uid_gflags
uid_uri_db? (y/n): y
INFO: creating uid tables into kamailio ...
INFO: UID tables succesfully created.
Во время инсталляции, вам нужно будет указать пароль для MySQL. Инсталлятор сделает следующих юзеров:
kamailio - с паролем kamailiorw. Этот юзер имеет права на чтение и запись в БД;
kamailioro - с паролем kamailioro. Этот юзер имеет права только на чтение;
Почти готово. Теперь слегка поправим конфигурационный файл Kamailio /etc/kamailio/kamailio.cfg. Настроим SIP – домен:
$ sudo vim /etc/kamailio/kamctlrc
## ваш SIP домен
SIP_DOMAIN=wiki.merionet.ru
В том же файле, включим некоторые нужные модули. Расположите следующий код в том же файле, прямо под строкой #!KAMAILIO:
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_USRLOCDB
#!define WITH_ACCDB
Включаем Kamailio!
$ sudo systemctl restart kamailio
Командой systemctl status kamailio можно проверить текущий статус Kamailio. Если что-либо не работает, лог – файл приложения можно найти в /var/log/kamailio.log.