Чем отличаются COR, COS и FRL

COR - class of restriction (Класс ограничения). COR определяет куда телефон может позвонить, а куда нет.

cos - class of service (Класс сервиса). COS определяет возможность пользователя телефона получить доступ к функциям из определенного списка (список этих функций в форме ch cos)

FRL - facility restriction level (Уровень ограничения функций).
FRL это просто число от 0 до 7 которое используется для маршрутизации исходящих звонков. В зависимости от значения FRL,  route pattern может направить звонок в тот или иной транк. В настройках транка также указываетсяFRL.
Самые низкие полномочия на выполнение вызовов соответствуют FRL, имеющему значение 0.

Replacement string в AAR digit-conversion

В форме change aar digit-conversion есть одно поле, назначение которого не совсем очевидно. Это поле Replacement String. Первая мысль которая приходит в голову, это поле предназначено для замены какой-либо цифры в номере на другую. Но на самом деле это поле не заменяет, а добавляет слева определенную цифру к номеру, например 0, или любую другую, которую мы зададим.

Настройка параллельной логической линии.

У нас для самого главного начальника есть особая телефонная линия, которая связывает его с другой организацией. Когда ему по ней звонят то звонок приходит секретарю, а у него только мигает лампочка без звонка и он может подключиться к звонку либо нет.
Называется это все "Параллельная логическая линия". Станция у нас древняя, настроена давно и не мной, но если есть такая настройка, то надо разобраться как она делается. После первого прочтения соответствующего раздела документации понимания совершенно не прибавилось  (документы avaya славятся своей заковыристостью и непонятными формулировками).  Но у меня была настроенная система, и после пары часов чтения мануалов и сравнения уже имеющихся настроек на станции я разобрался как это настраивается.
Абоненту avaya/definity можно настроить одну или несколько параллельных логических линий (запараллелить аппараты нескольких абонентов).
Допустим мы хотим подключить к телефону с номером 100 две параллельные логические линии с телефонами имеющими номера 101 и 102. Логично предположить, что для этого на телефоне 100 нужно выполнить некоторые настройки. Но странность состоит в том, что все
 настройки производятся на телефонах 101 и 102, а на 100 ничего делать не нужно.
Разберем на примере номера 101, для номера 102 все будет также. В терминологии Avavy один из телефонных аппаратов 100 и 101 является первичным, а другой - вторичным, но какой из них какой из документации совсем неочевидно, будьте внимательны. (В моем распоряжении был документ с кодом 555-233-506RU  Avaya Communication Manager Admin guide) Затем я нашел другой документ - "Avaya Описание и установка функций" код 555-245-205RU и пользовался им.
Итак, даем команду change station 101. Нас интересуют параметры Per Button Ring Control? , Bridged Call Alerting? и Auto Select Any Idle Appearance?.
Они могут принимать значения "y" и "n". От комбинации первых двух зависит какой из телефонов входящих в группу параллельных (100, 101 и 102) будет выдавать звуковой сигнал при вызове, или не будет, или будут звонить все сразу, или не будут звонить, но выдавать визуальный сигнал. Параметр Auto Select Any Idle Appearance? влияет на то будет ли  автоматически выбираться свободная линия в группе для направления входящего звонка или нет.
Теперь переходим в раздел Button Assignments и назначаем кнопку на которую будет повешена параллельная логическая линия с телефоном 100. Выбираем кнопку и вводим в соответствующее поле значение brdg-appr и нажимаем Enter. После этого появляется дополнительное поле Ext вводим в него 100 и нажимаем Enter. На некоторых аппаратах здесь может еще присутствовать поле Ring, но у меня его нет. Параллельная логическая  линия подключена. Для номера 102 действия аналогичны.
Неочевидным для меня остается следующее: Мы запараллелили телефон 100 с телефоном 101, или запараллелили телефон 101 с телефоном 100?
Возможно для понятия "параллельнные телефоны" некорректно говорить какой с каким запараллелен - они ведь параллельны, но каждый из телефонных аппаратов имеет отдельный extension. И почему чтобы назначить номеру 100 "параллельную логическую линию" мы настраивали телефон 101?

Порядок прохождения звонков через AVAYA.

Команды приведенные в тексте могут не соответствовать правильному синтаксису, а приведены только для того чтобы было понятно что это за команда.

 В выводе команды ch dial plan parameters есть параметр определяющий порядок поиска набираемого номера. Если у вас используется Uniform Dial Plan (UDP) вы можете указать станции где сначала она должна искать правила для обработки звонка - в диал-плане или в униформ-диал плане.
Обычно этот параметр установлен в значение local-extensions-first. То-есть станция будет сначала искать набранный номер на своих локальных портах, а потом уже в других местах. Будем считать что у нас так и настроено.
Когда мы поднимаем трубку на телефонном аппарате и набираем какой-либо номер, avaya первым делом обращается к диал-плану и смотрит как нужно поступить с набранными цифрами. Если там нет подходящего шаблона, то просматривается UDP, если и там нет, то звонок отбрасывается. Когда набранный номер принадлежит телефону подключенному к порту самой станции, то она направляет вызов в этот порт, и вызываемый телефон звонит, прошла коммутация звонка между двумя телефонами подключенными к самой станции. А если мы звоним на телефон в другом офисе, или даже в другом городе, то должна произойти маршрутизация звонка на соответсвующий выходной канал.
В зависимости от настроек маршрутизация может происходить либо через AAR либо через ARS. AAR и ARS в свою очередь состоят из двух частей: (aar/ars)-analisys и (aar/ars)-digits-conversion. Но возникает вопрос что происходит сначала, analisys или digits-conversion? И вообще, какова последовательность прохождения звонков через станцию? Почему-то за многие годы я так и не нашел в интернете статью объясняющую эту тему простыми словами. (Наверное плохо искал.) Конечно, в многочисленных книгах по avaye эта информация, наверняка есть. Но их довольно трудно читать, написаны они очень сложным языком.
И вот недавно мне попалась картинка схемы прохождения звонка через avaya и там многое становится ясно. Эту схему я нашел в одной бумажной брошюре с лекциями с курсов AVAYA, так что источник надежный. Правда на этой картинке показана схема прохождения через ARS, но думаю для AAR схема такая-же. Вот эта картинка.

Сохранение параметров и настроек станции Avaya/Definity

Сохранение настроек и параметров станции - это тоже своего рода бэкап, но, конечно, он отличается от способа сохранения на флеш-карту описанного в одной предыдущей заметке. Сохранение происходит в виде выгрузки настроек станции в текстовые файлы, которые впоследствии могут быть использованы для восстановления станции.
Однажды мне довелось быть свидетелем ситуации когда бы эта информация пригодилась, но ее не было.
Вышел из строя сервер управления станцией (станция по-моему S8300, могу ошибаться, но это не важно). Починить сервер возможности нет, купить новый или взять где-то аналогичный - тоже. На складе лежала старая атс Definity серии SI. Пришлось доставать ее и разворачивать. Станция запустилась и начала работать, но вот все настройки (хант-группы, пикап-группы, транки, соответствие портов и екстеншенов и почее) на этой станции были не актуальны. и актуализация прошла бы гораздо быстрее если-бы были соответствующие записи.
По-этому, после этой аварии я решил периодически делать выгрузки различных настроек в файлы, на всякий случай. Встал вопрос а что собственно нужно сохранять и как? Я составил для себя список команд которые выполняю в конце каждого месяца. Делаю я это через отчеты в Avaya Site Administration (ASA). Правда отчеты приходится запускать вручную потому что ASA не может быть запущена всегда, а отчеты запускаются по расписанию только если сама ASA запущена.
Вот список того что я сохраняю в файлы:
display system-parameters customer - функции приобретенные компанией.
display capacity - активированные мощности коммутатора.
list cabinet - количество стативов и платодержателей.
list configuration all или disp circuit-packs - типы и модели плат.
list trunks - список транков.
list aar analysis, list ars analysis, list route-pattern - информация о маршрутизации звонков
list station, list extension-type - информация о номерах абонентов.
list cor, display cos - информация о привилегиях.
display feature-access-codes - коды доступа к функциям.
display system-parameters features - функции системы.
display dial plan, display uniform dial plan - планы нумерации.
list coverage path - пути переадресации.
display anouncements - информация об используемых сообщениях.
list vector, list vdn - информация о векторах.
list hunt-group, list pickup-group - информация о группах.
Очевидно этот список не полный, и у каждого он свой, но я периодически добавляю в него какие-либо нужные мне команды. С удовольствием отнесусь к рекомендациям, которые кто-нибудь захочет дать для пополнения/изменения этого списка.
Хотелось бы все это автоматизировать, но пока не знаю как. Находил несколько англоязычных ссылок в интернете что инфу с Avaya можно получить используя VBscript. Приводились даже конкретные скрипты для получения инфы со станции. Но мне они не подошли. Изучать VBscript  чтобы самому писать нужные скрипты - совершенно не хочется. Считаю что VBscript не та вещь на которой нужно учиться программировать в современых условиях. Есть гораздо более полезные вещи для изучения, да и "по религиозным убеждениям" не хочу связываться с ним, потому что эта вещь из мира Windows, а я поборник Open Source и Linux в частности.

Если кто-то может подсказать как можно получить информацию со станции программным способом, буду очень признателен.

Сохранение изменений и резервные копии в АТС Avaya/Definity

Существуют два метода сохранения изменений: временное сохранение и постоянные резервные копии.

Временное сохранение

Когда мы выполняем какие-либо команды в терминале, при успешном их выполнении мы видим возвращаемое значение "command successfully completed". Эти изменения сохраняются в энергозависимой памяти станции и когда все работает, то вроде как и все хорошо. Но если пропадет питание, то пропадут и все внесенные вами изменения. Чтобы этого избежать нужно либо сохранять изменения вручную командой save translations, либо проследить чтобы станция делала это автоматически.
Команда save translations имеет различные варианты,  я упомяну о них ниже.
Чтобы станция автоматически сохраняла внесенные изменения нужно выполнить команду change system-parameters maintenance и убедиться что в разделе scheduled maintenance заданы параметры сохранения изменений.

Резервные копии

Резервные копии могут создаваться вручную, с помощью команды save translation, либо можно настроить станцию делать их автоматически.
При создании резервной копии все изменения копируются в энергонезависимую память, например флэш-карту, или ленту, или специальную плату. Далее будем считать что у нас флэш-карта
Перед тем как создать резервную копию вручную, нужно убедиться что карта памяти находятся на месте. Нужно чтобы на панели не горело ни одного светового аварийного сигнала.
Чтобы создать резервную копию дайте команду save translation. Эта команда сначала записывает первую полную резервную копию на флэш-карту, а затем - вторую, но в другой участок памяти карты. Обе копии имеют одинаковые временные метки. Если во время создания одной из копий произойдет сбой по питанию, то другая останется целой и с нее можно будет восстановиться. Поврежденная копия помечается "bad".
В документе 555-233-506 описывается присвоение каких-то уникальных номеров (translation-ID), которые дублируются и на платы процессоров и на флэш-карты. Этот момент мне не совсем понятен, но при инициализации (перезагрузке) системы с флэш-карты которая не содержит тот-же идентификационный номер, что содержится и на плате процессора система выдает "мажорную" ошибку и ограничивает доступ к функциям станции для всех "неаваевских" учетных записей. Нужно обращаться в поддержку Avaya чтобы они решили эту проблему. Обращение должно быть сделано в течении определенного периода времени иначе доступ к системе еще более ограничивается и вы не сможете выполнять практически ничего. Этот период устанавливается специалистами Avaya во время установки или модернизации системы.
Где можно посмотреть этот translation-ID я не знаю, но его можно сбросить командой reset translation-id, которая мне недоступна на моей станции. Видимо процедура сброса translation-ID используется в случаях, когда заменяется плата процессора или флэш-карта и таким образом устанавливаются одинаковые translation-ID и на процессоре, и на флэш-карте.
Команда без параметров save translation сохраняет изменения на карте вставленной в плату активного процессора. Если у вас в системе две процессорых платы (статив А, статив В), то имеется несколько параметров команды позволяющих сохранять копии в разные места. Описание параметров на русском языке можно найти в документе 555-230-126RU в разделе "Команды технического обслуживания" save translation.
Процесс резервного копирования может занять длительное время, в течении которого станция будет не администрируема. В некоторых источниках пишут, что станцию все-таки можно администрировать, но с другого терминала и не полностью.
Более подробную информацию о создании резервных копий нужно собирать из нескольких мест. В первую очередь это документ "Definity ECS administrator's guide" для вашей системы. В моем случае, нужно обратиться к документу 555-233-506 (на английском) в подраздел "Save Translations" раздела 1 страница 41. Там описывается как делать копии, а за более подробной информацией отсылают к maintenance service guide для вашей системы. Там можно найти описание параметров команды save translation.

Юниты в Systemd

Юниты (UNITS) - это такое понятие (скорее, наверное, логическое), которое разделяет все те вещи которыми может управлять systemd на функциональные блоки. Например юниты служб, сокетов, файловых систем, устройств и т.д. Для работы с юнитами systemd использует особые конфигурационные файлы (unit files). Systemd использует эти файлы для конфигурации и управления системными ресурсами, такими как процессы или ваши файловые системы. Используя эти файлы вы заставляете systemd управлять вашей системой так как вам это нужно.

Для каждого юнита есть свой конфигурационный unit file.Эти файлы могут располагаться в нескольких разных местах в системе. Systemd ищет unit files в следующих каталогах:

/etc/systemd/system
/run/systemd/system
/usr/lib/systemd/system

Файлы в более высоком в иерархии каталоге имеют приоритет над низшими. Предпочтительно создавать и редактировать файлы в /etc так как там в основном сосредоточены все настройки в системе. Опасайтесь помещать и редактировать юнит-файлы в /usr поскольку в этот каталог система инсталлирует данные пакетов которые не желательно менять.

Systemd может быть запущен и в контексте конкретного пользователя и управлять его ресурсами. Unit-files для пользователя находятся в каталогах

/etc/systemd/user
/run/systemd/user
/usr/lib/systemd/user.

Приоритет каталогов такой-же как описано выше.

Для просмотра всех юнит-файлов установленных в системе, иначе говоря для того чтобы вывести список всех юнитов имеющихся в системе, используем команду

systemctl list-unit-files

Каждый юнит-файл содержит опции вида OptionName=value. Все опции разбиты по секциям. Синтаксис секций следующий [SectionName]

Два основных и наиболее общих для всех пользователей юнита - это service и target.

Чтобы посмотреть юнит-файлы относящиеся к определенному юниту, надо дать команду

systemctl list-unit-files --type service
systemctl list-unit-files --type target

Общий синтаксис команд таков:

sudo systemctl [command] NAME.OF.UNIT

Наиболее распространенными [command] являются start, stop, status,restart,enable,disable
Например, чтобы посмотреть статус юнита rsyslog.service даем команду systemctl status rsyslog.service
Для юнита nfs-client.target команда systemctl status nfs-client.target
Для более глубокого понимания как устроены юнит-файлы и как их писать смотри man systemd.unit
Существует также детальная информация для типов юнитов service и target

man systemd.service
man systemd.target

В конфигурационных файлах systemd можно найти строки содержащие  описание зависимостей, то есть, например, один юнит может потребовать для своей работы чтобы работал какой-либо другой юнит. Между юнитами существуют зависимости двух видов. Один юнит может "хотеть" (want) или "требовать" (require) другой юнит.

• U1 Wants=U2

 Когда U1 запущен, U2 тоже успешно запустится. Если U2 сбойнет, то это не влияет на работу U1

• U1 Require=U2 

Когда U1 запущен, U2 тоже успешно запустится. Но если U2 сбойнет, то U1 прекратит работу, даже если группа процессов U1 и работала нормально.

В этих примерах U1 и U2 стартуют в одно и то же время. Важно понимать что в systemd "зависимости" и "последовательность запуска" - это разные вещи. За последовательность запуска отвечают опции Before и After.

• U1 Before=U2

U1 будет выполняться до старта U2

• U1 After=U2

U2 будет выполняться до старта U1

Если нужна информация о том как systemd контролирует и управляет процессами, контрольными группами (cgroups) смотри этот полезный блог

Из чего состоит Systemd

Однажды на просторах интернета нашел картинку на которой изображено устройство systemd. Мне она показалась интересной и я попробовал в ней разобраться. Вот эта картинка:

Как видим systemd состоит из нескольких уровней. На уровне ядра systemd работает с контрольными группами (cgroups). А также с autofs и kdbus.
Если подниматься по рисунку снизу вверх, то выше мы увидим библиотеки используемые systemd.
Еще выше - systemd Core (ядро systemd). На этом уровне systemd состоит из менеджера и собственно systemd. Также на этом уровне используются так называемые юниты.
Юниты (UNITS) - это такое понятие (скорее, наверное, логическое), которое разделяет все те вещи которыми может управлять systemd на функциональные блоки. Например юниты служб, сокетов, файловых систем, устройств и т.д.
В systemd используется такое понятие как Цели (targets). Все они представлены на рисунке в разделе systemd Targets
В разделе systemd Daemons мы видим из каких демонов состоит systemd, а в самом верху рисунка перечислены утилиты по использованию, управлению и настройке systemd.
Некоторые из этих утилит доступны из командной строки непосредственно по названию (systemctl, journalctl, loginctl), а некоторые - с использованием суффикса systemd (systemd-analyze, systemd-notify).
Кроме того есть еще ряд утилит, которые не представлены на рисунке, но существуют, например systemd-cat, systemd-path, systemd-run и др. Если в консоли linux ввести команду sys и два раза нажать клавишу Tab, то можно увидеть список всех утилит, в том числе тех, которых нет на рисунке.
Отсутствие многих утилит на рисунке видимо связано с тем что все они не поместились, либо, вероятно эти новые утилиты были добавлены впоследствии, после того как был создан systemd и нарисован данный рисунок.