По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Графический интерфейс Cisco Unified Communications Manager (CUCM) имеет раздел Disaster Recovery System (DRS), который предназначен для проведения резервного копирования (backup) и восстановления системы (restore). Но бывают ситуации, когда GUI недоступен, например, из-за проблем с сетью. В этом случае, провести процедуры бэкапирования и восстановления можно через консоль CLI и сейчас мы расскажем как это сделать. Процедура бэкапа Перед началом процедуры, у вас должен быть настрое SFTP сервер, куда вы будете заливать бэкап с CUCM. Для начала нужно добавить сервер, куда мы будем загружать бэкап. Для этого вводим команду: utils disaster_recovery device add network [number of backups] Где: backup device name - Имя устройства, куда будем заливать бэкап; path - Путь, куда будем заливать бэкап на данном устройстве; ip-address of remote server - IP адрес удалённого устройства; username - Имя пользователя; number of backups - Количество резервных копий После ввода данной команды, вас попросят ввести пароль пользователя, из под которым вы хотите осуществить бэкап (в нашем случае - ccmadmin) admin: utils disaster_recovery device add network merionbckp ./ 10.20.30.123 ccmadmin Please enter password to connect to network server 10.20.30.123:**** drfCliMsg: Backup Device has been saved successfully. Проверим, что устройство для бэкапа успешно добавилось, для этого введём команду: utils disaster_recovery device list В выводе мы должны увидеть устройство, добавленное ранее: admin:utils disaster_recovery device list Device Name Device Type Device Path -------------------------------------------------------------- merionbckp NETWORK ./ Волшебно! Теперь мы можем осуществить бэкап. Для этого пишем в консоли: utils disaster_recovery backup network Где: backup device name - Имя устройства, куда будем заливать бэкап; featurelist - Список функционала, который нужно забэкапить; Для того, чтобы посмотреть какой функционал доступен для бэкапирования наберите команду: utils disaster_recovery show_registration , где servername - имя сервера, на котором осуществляется бэкап. admin:utils disaster_recovery backup network UCM,CDR_CAR,PLM merionbckp drfCliMsg: Backup initiated successfully. Please run 'utils disaster_recovery status backup' command to see the status Всё, бэкап запущен! Чтобы проверить статус, нам предлагают ввести: utils disaster_recovery status backup admin:utils disaster_recovery status backup Status: SUCCESS :Backup Completed... Tar Filename: 2019-02-16-04-21-37.tar Storage Location: NETWORK Operation: backup Percentage Complete: 100 PLM CCM01 ELM-AGENT SUCCESS Sat Feb 16 04:17:25 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_plm_elm-agent.log PLM CCM01 ELM-SERVER SUCCESS Sat Feb 16 04:17:26 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_plm_elm-server.log CDR_CAR CCM01 CAR SUCCESS Sat Feb 16 04:17:27 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_cdr_car_car.log UCM CCM01 BAT SUCCESS Sat Feb 16 04:19:23 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_bat.log UCM CCM01 CCMPREFS SUCCESS Sat Feb 16 04:19:25 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ccmprefs.log UCM CCM01 PLATFORM SUCCESS Sat Feb 16 04:19:30 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_platform.log UCM CCM01 TCT SUCCESS Sat Feb 16 04:19:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_tct.log UCM CCM01 SYSLOGAGT SUCCESS Sat Feb 16 04:19:35 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_syslogagt.log UCM CCM01 CDPAGT SUCCESS Sat Feb 16 04:19:36 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_CCM01_ucm_cdpagt.log UCM CCM01 CLM SUCCESS Sat Feb 16 04:19:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_clm.log UCM CCM01 CCMDB SUCCESS Sat Feb 16 04:19:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ccmdb.log UCM CCM01 TFTP SUCCESS Sat Feb 16 04:21:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_tftp.log UCM CCM01 ANN SUCCESS Sat Feb 16 04:21:33 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ann.log UCM CCM01 MOH SUCCESS Sat Feb 16 04:21:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ccm01_ucm_moh.log Всё, бэкап готов! Процедура восстановления Чтобы восстановить конфигурацию CUCM из бэкапа, нужно сначала посмотреть – что доступно для восстановления на удалённом сервере? Проверить это можно командой: admin:utils disaster_recovery show_backupfiles merionbckp 2019-02-16-04-21-37 2018-12-25-21-52-19 Выбираем нужный нам бэкап и вводим следующую команду: admin:utils disaster_recovery restore network 10.20.30.123 2019-02-16-04-21-37 merionbckp drfCliMsg: WARNING! There are nodes in current production cluster but NOT present in the backup. These nodes will be removed if you restore the Publisher. If you want to keep these nodes, you will need to manually re-add them after the restore. Do you want DRS to perform a SHA-1 File Integrity Check of your backup archives y/n ?(n) : y Please enter the comma seperated features you wish to restore. Valid features for server CCM01 are PLM,CDR_CAR,UCM:PLM,CDR_CAR,UCM Do you want to restore database from the subscriber y/n ?(n) : n drfCliMsg: Restore initiated successfully. Please run 'utils disaster_recovery status restore' command to see the status ALERT: Please restart the server(s) before performing the next restore for changes to take effect. In case of a cluster, restart the entire cluster. Теперь проверяем статус восстановления: admin:utils disaster_recovery status restore Status: SUCCESS :Restore Completed... Tar Filename: 2019-02-16-04-21-37.tar Storage Location: NETWORK Operation: restore Percentage Complete: 100 CDR_CAR CCM01 CAR SUCCESS Sun Feb 17 11:20:15 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_cdr_car_car.log PLM CCM01 ELM-AGENT SUCCESS Sun Feb 17 11:24:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_plm_elm-agent.log PLM CCM01 ELM-SERVER SUCCESS Sun Feb 17 11:24:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_plm_elm-server.log UCM CCM01 BAT SUCCESS Sun Feb 17 11:25:06 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_bat.log UCM CCM01 CCMPREFS SUCCESS Sun Feb 17 11:37:06 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_ccmprefs.log UCM CCM01 PLATFORM SUCCESS Sun Feb 17 11:37:13 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_platform.log UCM CCM01 TCT SUCCESS Sun Feb 17 12:11:10 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_tct.log UCM CCM01 SYSLOGAGT SUCCESS Sun Feb 17 12:14:19 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_syslogagt.log UCM CCM01 CDPAGT SUCCESS Sun Feb 17 12:14:39 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_cdpagt.log UCM CCM01 CLM SUCCESS Sun Feb 17 12:17:03 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_clm.log UCM CCM01 CCMDB SUCCESS Sun Feb 17 12:17:05 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_ccmdb.log UCM CCM01 TFTP SUCCESS Sun Feb 17 12:25:12 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_tftp.log UCM CCM01 ANN SUCCESS Sun Feb 17 12:26:38 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_ann.log UCM CCM01 MOH SUCCESS Sun Feb 17 12:26:39 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_moh.log
img
Частый сценарий: новый сервер, на котором проводятся отладочные работы и требуется быстро подключиться по SSH. Обычно, сначала необходимо авторизоваться под админом, и только затем переключиться на root пользователя. В это статье мы расскажем, как сделать так, чтобы можно было подключаться под root сразу, минуя аутентификацию под admin. Важно! Мы рекомендуем выставлять данную настройку только на время пуско – наладочных работ. После вывода сервера в продакшн, рекомендуем вернуть 2х ступенчатую авторизацию в целях безопасности. Настройка Итак, подключитесь к серверу под root и откройте для редактирования файл /etc/ssh/sshd_config: vim /etc/ssh/sshd_config Далее, найдите существующий параметр PermitRootLogin, либо, если его нет, создайте его вручную. Данный параметр также может быть закомментирован символом решетки # - если это так, то нужно будет раскомментировать эту строку удалив символ #. В итоге, в настройках файла /etc/ssh/sshd_config и у вас должна быть строка PermitRootLogin yes - то есть должно быть отмечено значение yes (разрешено подключение под root): # Authentication: #LoginGraceTime 2m PermitRootLogin yes Сохраняем изменения в файле /etc/ssh/sshd_config. Если вы открыли файл через vim (как показано в нашем примере), то укажите комбинацию ниже с клавиатуры и нажмите Enter: :x! Теперь осталось только перезагрузить SSH сервер: service sshd restart Готово!
img
Модуль, отвечающий за распределение вызовов по времени – Time Conditions. Данный модуль представляет из себя набор правил, в который включены временные группы (Time Group).В модуле настраиваются два условия: первое – если выполняются правила Time Group, а второе, если данные правила не выполняется. Модуль Time Conditions чаще всего применяется для маршрутизации вызовов в зависимости от рабочего времени в компании, например, маршрут для вызовов с 10:00 до 19:00 на секретаря, а после и по выходным, вызовы маршрутизируются на заранее записанное голосовое сообщение. /p> Важно отметить, что если вы решили настроить данный модуль, то стоит начать с настройки Time Group. Итак, приступаем к настройке. Для этого, подключитесь к интерфейсу FreePBX в правами администратора, и перейдите во вкладку Applications и далее во вкладку Time Conditions Перейдя в интерфейс настройки, нажимаем Add Time Condition и добавляем новое условии маршрутизации по времени: Разберемся конкретнее с каждым из параметров настройки: Time Condition Name - Укажите название данного условия. Удобнее всего давать имена в соответствие с логикой работы данных кондиций. Например, «Work Hours» для рабочего времени и «Holidays» для выходных. Override Code Pin - В FreePBX13 существует Feature Code, по умолчанию это *27. С его помощью можно менять временные кондиции (Time Conditions). Поле Override Code Pin позволяет ввести пин-код, который будет запрошен у пользователя, который попытается изменить это временное условие. Invert BLF Hint - Да/Нет. Для каждой из временных кондиций, создается BLF хинт (hint). Соответственно, ка телефонном аппарате с поддержкой BLF можно отображать статус данной временной кондиции. По умолчанию, (Invert BLF Hint = No) – это означает, что в случае, если данный временная кондиция не совпадает, то в BLF выставляется статус «INUSE», а это как правило, красная лампочка. В случае, если кондиция совпадает с временной группой, то выставляется статус «NOT_INUSE», а это, как правило зеленая лампочка. В случае, если параметр Invert BLF Hint = Yes, то указанные выше позиции определяется в обратном порядке. Change Override - Текущий статус перезаписи временного условия отображается в выпадающем меню. Если это новое временное условие, которое ещё не сохранено, статус будет НЕИЗВЕСТНО. В ином случае, вы увидите текущий статус. Выпадающее меню дает вам возможность изменять статус перезаписи: Unchanged - статус перезаписи не будет изменен. Reset Override - удаляет любой статус перезаписи, который отмечен. Temporary Matched / Unmatched - создает временную перезапись, пока текущий промежуток времени не истечет. Permanent Matched / Unmatched - создает постоянную перезапись, пока перезапись не будет удалена. Time Group - Временная группа, в которой отмечается временной промежуток, дни недели и месяцы. Именно на базе Time Group происходит маршрутизация вызовов в Time Condition Destination non-matches - Направление для вызова, если вызов не попал под правила настроенные в Time Group После внесения всех настроек необходимо нажать Save, а затем Apply Config.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59