По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Одна из предыдущих статей была посвящена созданию групп перехвата в OpenScape Voice. Сейчас мы поговорим про другой тип групп – группы поиска или Hunt Groups.
/p>
Теория
Hunt группа представляет из себя несколько телефонных номеров, объединенных в одну группу внутри которой происходит распределение вызова по определенному алгоритму. Для вызова группы используется либо отдельный внутренний номер (Pilot Hunt Group), либо номер, состоящий в группе (Master Hunt Group). В одной группе может находиться 2048 номеров, а один номер может находиться в 32 группах одновременно.
Рассмотрим алгоритмы распределения вызовов в группе.
Circular (Циклический) - Распределение вызовов происходит по порядку, согласно списку абонентов. Если абонент не отвечает, то через заранее определенное время вызов передается следующему абоненту из списка, и так далее. Если последний абонент не ответил, то вызов снова передается первому. Новый вызов адресуется абоненту, который идет в списке за тем, который принял предыдущий вызов.
Linear (Линейный) - Распределение вызовов так же происходит по порядку, согласно списку абонентов, и если абонент не отвечает, то вызов передается следующему. Но отличие состоит в том, что новый вызов всегда адресуется первому свободному абоненту в списке.
Manual – Application Controlled (Управляемый внешним приложением) - Распределением вызовов управляет внешнее приложение по протоколу CSTA.
Parallel – Call Pickup Model (Параллельный, на основе перехвата вызова) - Для распределения используется циклический алгоритм и при этом дополнительно всем свободным абонентам группы посылается уведомление о вызове, и вызов может быть перехвачен любым свободным абонентом. Абонент может быть включен только в одну группу такого типа, и не может одновременно быть членом другой стандартной группы перехвата.
Parallel – Simultaneous Alerting Model (Параллельный, на основе одновременного вызова) - Одновременный вызов всем участникам группы.
UCD – Uniform Call Distribution (Универсальный) - Вызов адресуется абоненту, который был свободен дольше других. Если абонент не отвечает, то вызов передается следующему абоненту, который был свободен дольше других и так далее.
Настройка группы поиска
Создадим номер вызова группы. Для этого перейдем во вкладку Configuration → OpenScape Voice → Business Group → Members → Subscribers и нажмем на Add. Во вкладке General указываем номер для группы в строке Directory Number и в строке Type of Number указываем тип номера → Public для городского и Private для корпоративного.
Переходим на вкладку Connection и в Connection Information указываем Profile Only
После создания номера приходим в меню Configuration → OpenScape Voice → Business Group → Teams - Hunt Groups и нажмем на Add для создания Hunt группы.
Во вкладке General нужно указать название группы в строке Name, ниже в строке Pilot Directory Number указать номер группы, который мы создавали до этого и в поле Type в выпадающем списке выбрать алгоритм распределения вызова. Также в этом меню и во вкладке Advance можно выставить дополнительные настройки очереди.
Добавлять абонентов в группе можно во вкладке Members, нажав на кнопку Add. В строке Directory Number указываем внутренний номер абонента, и также можем сразу указать в поле Position порядковый номер абонента в списке.
После добавления номера появляются в списке, в котором можно изменять позицию номера при помощи кнопок Move Up и Move Down.
Добавлять телефон в группу можно еще из меню настроек номера Configuration → OpenScape Voice → Business Group → Members - Subscribers во вкладке Groups, где нужно указать либо номер, либо имя группы, и нажать затем Save.
Часто бывает, что на системе Linux произошла незапланированная или по неизвестным очевидным причинам, перезагрузка. Поиск и устранение первопричины может помочь предотвратить повторение таких проблем и избежать незапланированных простоев.
Есть несколько способов выяснить, что вызвало перезагрузку. В этой статье мы обсудим эти способы и способы использования доступных утилит и журналов в системе Linux для устранения таких сценариев.
Проверка времени перезагрузки
Чтобы посмотреть, когда именно произошла перезагрузка системы можно воспользоваться командами who и last
Проверка системных журналов
Кроме того, можно сопоставить время перезагрузки, которую требуется диагностировать, с системными сообщениями.
Для систем CentOS/RHEL журналы можно найти по адресу /var/log/messages, а для систем Ubuntu/Debian - по адресу /var/log/syslog. Для фильтрации или поиска конкретных данных можно использовать команду tail или любимый текстовый редактор.
Как видно из приведенных ниже журналов, такие записи предполагают завершение работы или перезагрузку, инициированную администратором или пользователем root. Эти сообщения могут варьироваться в зависимости от типа ОС и способа запуска перезагрузки или завершения работы, но вы всегда найдете полезную информацию, просматривая системные журналы, хотя этого не всегда может быть достаточно, чтобы определить причину.
Ниже приведена одна такая команда, которую можно использовать для фильтрации системных журналов:
sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel'
/var/log/messages /var/log/syslog /var/log/apcupsd*
| grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups'
Зафиксированные события не всегда могут быть конкретными. Всегда отслеживайте события, которые дают признаки предупреждений или ошибок, которые могут привести к выключению или сбою системы.
Проверка журнала auditd
Для систем, использующих auditd – это отличное место для проверки различных событий с помощью инструмента ausearch. Используйте приведенную ниже команду для проверки последних двух записей из журналов аудита.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
Появится сообщение о двух последних остановках или перезагрузках. Если это сообщает о SYSTEM_SHUTDOWN, за которым следует SYSTEM_BOOT, все должно быть хорошо. Но, если он сообщает две строки SYSTEM_BOOT подряд или только одно сообщение SYSTEM_BOOT, то, скорее всего, система некорректно завершила работу. Вывод при нормальной работе должен быть примерно следующим:
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
В приведенных ниже выходных данных перечислены два последовательных сообщения SYSTEM_BOOT, которые могут указывать на аварийное завершение работы, хотя результаты нужно скорректировать с данными системного журнала.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
Анализ журнала systemd
Чтобы сохранить журнал системных логов на диске, необходимо иметь постоянный системный журнал, иначе логи будут очищаться при перезагрузке. Для этого можно либо внести изменения в /etc/systemd/journald.conf, либо создать каталог самостоятельно с помощью следующих команд:
$ sudo mkdir /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null
$ sudo systemctl -s SIGUSR1 kill systemd-journald
После этого можно дополнительно перезагрузить систему для ввода нескольких записей перезагрузки в журнал, хотя это и не требуется.
Приведенную ниже команда позволяет выводить список записанных событий о загрузке из журнала:
$ journalctl --list-boots
Вот его выходные данные на моем сервере:
Как видно на рисунке, в системе есть несколько событий загрузки. Для дальнейшего анализа причины конкретной перезагрузки используйте:
$ journalctl -b {num} –n
Здесь {num} будет индексом, заданным в команде journalctl --list-boots в первом столбце.
В приведенных выше выходных данных можно просмотреть сообщения, зарегистрированные в журнале, и отследить аномалии, если таковые имеются.
Заключение
Не всегда можно определить причину перезагрузки Linux с помощью одной команды или из одного файла журнала. Поэтому всегда удобно знать команды и журналы, которые фиксируют события, связанные с системой, и могут сократить время, необходимое для поиска первопричины.
Приведенные выше примеры дают вам возможность начать поиск и устранение неисправностей. Используя комбинацию таких инструментов и журналов, вы можете быть уверены в том, что произошло и как перезагрузилась ваша система.
Vagrant является инструментом с помощью которого осуществляется создание и управление виртуальными машинами с помощью технологии виртуализации.
Благодаря простому в использовании алгоритму и автоматизации процессов, Vagrant сокращает время настройки и оптимизации среды в которой вы будете работать. Погнали.
Установка для Windows
Установка Vagrant сама по себе очень проста, Вам необходимо скачать клиент с официального сайта для операционной системы, которую вы планируете юзать и запустить процесс установки. Для работы Vagrant также необходимо скачать VirtualBox с официального сайта.
VirtualBox гипервизор, осуществляющий процесс виртуализации (опа, тавтология) систем Linux, macOS, Windows и других. Установка софта VirtualBox, как и самого Vagrant проста и не вызовет у вас никаких вопросов и проблем, а как только вы установите две программы, рекомендуется выполнить перезагрузку Вашей системы.
Кстати, почитать об установке VirtualBox 6.0 на Linux вы можете в нашей статье
После установки откройте командную строку и проверьте доступность Vagrant с помощью следующих строк кода:
$ vagrant
Usage: vagrant [options] <command> []
-v, --version Print the version and exit. -h, --help Print this help.
# ...
Первым шагом в настройке виртуальной машины с помощью Vagrant является создание Vagrantfile, который будет содержать все необходимые настройки. Введите следующую команду:
mkdir vagrant_demo && cd vagrant_demo
vagrant init ubuntu/trusty64
Vagrantfile - это файл Ruby, который описывает, как настроить и подготовить виртуальную машину.
Однако, вместо создания виртуальной машины с нуля, софт предлагает вам воспользоваться базовыми образами для использования "шаблонов" виртуальной машины. Эти базовые образы в Vagrant называются "Vagrant box", которые добавляются в Vagrant с помощью инструмента vagrant box add, сохраняющего Vagrant box под определенным именем, предоставляя возможность использовать несколькими средами повторно. Круто, не правда ли?
$ vagrant box add hashicorp/precise64
С помощью этой команды вы сможете загрузить готовый Vagrant box с названием "hashicorp/precision64" из каталога Vashgrant Cloud, предоставляемого разработчиками для обмена готовыми образами. Следует отметить и то, что имеется возможность добавления образов из локальных файлов или пользовательского URL.
"Боксы" хранятся для каждого пользователя отдельно. Каждый проект Vagrant box создает новую копию "бокса" и никогда не изменяет исходный образ. Это означает, что если у вас есть два проекта, в которых используется один образ Vagrant box hashicorp/precision64, добавление файлов на одной виртуальной машине не повлияет на другую.
Когда Vagrant box добавлен в Vagrant, вы можете настроить его для использования в качестве основы. Откройте Vagrantfile и измените содержимое на следующее:
Vagrant.configure("2") do |config|
config.vm.box = "hashicorp/precise64"
end
Вы можете указать версию "бокса", указав config.vm.box_version, например:
Vagrant.configure("2") do |config|
config.vm.box = "hashicorp/precise64"
config.vm.box_version = "1.1.0"
end
Также возможно указать URL-адрес, используя config.vm.box_url:
Vagrant.configure("2") do |config|
config.vm.box = "hashicorp/precise64"
config.vm.box_url = "https://vagrantcloud.com/hashicorp/precise64"
end
Загружаем первую виртуальную машину Vagrant и вводим команду: $ vagrant up
В течении минуты работа этой команды завершится, загрузив для Вас виртуальную машину с Ubuntu. Процесс загрузки будет выглядеть примерно следующим образом:
Чтобы проверить его работоспособность производится подключение SSH к виртуальной машине: $ vagrant ssh.
Эта команда переведет вас в полноценный SSH-сеанс. Теперь у Вас есть возможность взаимодействия с виртуальной машиной. Сеанс SSH может быть завершен с помощью сочетания клавиш CTRL + D.
vagrant@precise64:~$ logout
Connection to 127.0.0.1 closed.
По окончанию работы с виртуальной машиной следует запустить команду vagrant destroy и Vagrant прекратит использование любых ресурсов, потребляемых виртуальной машиной.
Установка на Ubuntu:
Устанавливаем Virtualbox, который, кстати, сразу доступен в репозиториях Ubuntu: >sudo apt install virtualbox
Совет: Следует отметить, что Vagrant и Virtualbox, доступные в репозиториях Ubuntu могут быть не самой актуальной версии, для установки последних версий этих программ, загрузите их с официальных сайтов разработчиков.
Чтобы убедиться, что установка прошла успешно с помощью следующей команды мы можем проверить версию программы Vagrant: vagrant --version
Вы должны увидеть примерно следующее: Vagrant 2.0.2
Убедившись, что Vagrant установлен в системе Ubuntu, мы можем создать среду разработки, которая является наиболее распространенным вариантом использования данной программы.
Первым шагом является создание каталога, который будет корневым каталогом проекта. И делаем файл Vagrantfile.
Создайте каталог проекта и переключитесь на него:
mkdir ~/my-first-vagrant-project
cd ~/my-first-vagrant-project
Следующим шагом является инициализация нового Vagrantfile с помощью команды vagrant init. В этом примере мы у нас CentOS 7. Запустите следующую команду, чтобы инициализировать новый Vagrantfile:
vagrant init centos/7
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read the comments in the Vagrantfile as well as documentation on `vagrantup.com` for more information on using Vagrant.
Запустив vagrant up, мы получаем возможность создать и настроить среду в соответствии с Vagrantfile.
vagrant up
==> default: Configuring and enabling network interfaces...
default: SSH address: 192.168.121.74:22
default: SSH username: vagrant
default: SSH auth method: private key
==> default: Rsyncing folder: /home/linuxize/Vagrant/my-first-vagrant-project/ => /vagrant
Как видно из приведенной выше информации, Vagrant также внедряет каталог проекта в /vagrant на виртуальной машине, что позволяет вам работать с файлами вашего проекта на вашем хост-компьютере.
Чтобы войти в среду, просто запустите ее с помощью команды:
vagrant ssh
Остановка работы среды:
vagrant halt
Следующая строка остановит работу среды, а также очистит всю информацию, которая была необходима для ее работы:
vagrant destroy
Благодаря нашей статье, вы увидели процесс установки и настройки виртуальной машины на свой компьютер на Windows или Ubuntu 18.04, а также в статье наглядно продемонстрирован процесс создания и настройки виртуальной машины. Профит!