По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Данное улучшение официально было представлено в марте 2020 года и версия 2.0 была опубликована на GitHub.
Очень ценное приложение rdiff-backup позволяет пользователям выполнять резервное копирование каталога в другое удаленное или локальное хранилище. Одной из ключевых преимуществ приложения является его простота. Пользователи могут создавать свои первые резервные копии с помощью одной простой команды:
# rdiff-backup source-dir backup-dir
Чего не было в версии 1.2.8
Основные модификации были сделаны для инструментов разработки, включая Travis Pipeline, автоматизированное тестирование для Linux и Windows, новый Ubuntu PPA, новый Fedora COPR и новый репозиторий Pypi.org.
Эти улучшения призваны помочь пользователям легко перейти на новую версию простым и доступным способом. В соответствии с этими улучшениями, мы включили в выпуск следующую новую визуальную идентичность.
Особенности rdiff-backup
Этот выпуск направлен в основном на обновление и поддержку Python 3.5 и выше в Linux и Windows и поэтому не включает много новых функций по сравнению с предыдущей официальной версией 1.2.8. Тем не менее, он по-прежнему содержит несколько патчей, написанных на протяжении многих лет для различных дистрибутивов Linux, а также некоторые улучшения с точки зрения скорости и эффективности использования доступного места.
Rdiff-backup улучшен для обеспечения эффективного резервного копирования во всех сценариях. Вот несколько особенностей:
Дружелюбный интерфейс
Функция зеркалирования
Отмена стратегии инкрементного хранения резервных копий
Сохранение внутренней информации
Эффективное использование места
Оптимизация использования пропускной способности
Прозрачность всех типов и форматов данных
Автообнаружение файловой системы
Поддержка расширенных атрибутов и атрибутов ACL
Сохранение статистики
Поддержка Linux и Windows; также работает на BSD и macOS X
Установка rdiff-backup на Linux
Установка rdiff-backup как для существующих, так и для новых пользователей одиноков. Ниже приведены несколько команд для развертывания rdiff-backup
Чтобы установить Rdiff-Backup на Ubuntu Focal или Debian Bullseye или новее наберите следующую команду:
$ sudo apt install rdiff-backup
Чтобы установить утилиту на более старые версии Ubuntu^
$ sudo add-apt-repository ppa:rdiff-backup/rdiff-backup-backports
$ sudo apt update
$ sudo apt install rdiff-backup
Чтобы установить Rdiff-Backup на CentoOS или RHEL 7
$ sudo yum install yum-plugin-copr epel-release
$ sudo yum copr enable frankcrawford/rdiff-backup
$ sudo yum install rdiff-backup
Чтобы установить на CentoOS или RHEL 7
$ sudo yum install dnf-plugins-core epel-release
$ sudo dnf copr enable frankcrawford/rdiff-backup
$ sudo yum install rdiff-backup
Для установки на Fedora 32 и выше
$ sudo dnf install rdiff-backup
Для установки Rdiff-Backup на Debian и его производных, Raspbian и т.д. (из PyPi):
$ sudo apt install python3-pip python3-setuptools python3-pylibacl python3-pyxattr
$ sudo pip3 install rdiff-backup
Для установки Rdiff-Backup на Fedora и его производных (из PyPi):
$ sudo dnf install python3-pip python3-setuptools py3libacl python3-pyxattr
$ sudo pip3 install rdiff-backup
Интерфейс управления Asterisk, или как его называют Asterisk Manager Interface (AMI) представляет собой интерфейс для управления вашей IP – АТС внешними приложениями, путем передачи команд или получения различных телефонных событий. Зачастую, данный интерфейс используется для интеграции 1С и asterisk, что позволяет принимать звонки в интерфейсе 1С, выполнять вызовы, подтягивать карточку клиента при входящем звонке и так далее.
Разберем настройку данного интерфейса и параметров подключения к нему на примере настройки через графический интерфейс администратора FreePBX 13 и через консоль сервера (CLI) в настройках CentOS
Настройка AMI в FreePBX
В верхнем меню навигации, выберите вкладку Settings и далее перейдите в раздел Asterisk Managers, как указано на скриншоте ниже:
Далее, для того, чтобы добавить нового пользователя, нажмите на кнопку Add Manager:
Откроется окно настройки нового пользователя. Разберем каждый пункт отдельно:
Manager Name - Имя пользователя AMI. Не должно содержать в себе пробелы.
Manager Secret - Пароль для пользователя AMI.
Deny - В данном поле вы можете указать IP – адрес и маску подсети, с которых необходимо запретить подключение к AMI по указанным данным. Если хотите указать несколько подсетей, то используйте символ &. Например, 192.168.1.0/255.255.255.0&192.168.2.0/255.255.255.0
Permit - Укажите IP – адрес и маску подсети, с которых разрешено подключение к AMI через этого пользователя. Синтаксис аналогичен как и в поле Deny.
Write Timeout - Укажите таймаут, который будет использовать Asterisk при записи данных через данную AMI учетную запись. По умолчанию, период равен 100 миллисекунд.
Следующим шагом будет настройка прав данного пользователя. Для этого, необходимо перейти во вкладку Rights
По окончанию настроек нажмите Submit
Настройка AMI в CLI
Сделаем тоже самое, но через консоль CentOS. Для этого, необходимо подключиться к серверу по SSH и выполнить следующие итерации:
Перед началом работ по изменению конфигурации, рекомендуем сделать резервную копию файла.
[root@localhost ~]# vim /etc/asterisk/manager.conf //подключаемся к конфигурационному файлу manager.conf
Делаем следующие настройки в секции [general]:
[general]
enabled = yes //включает AMI
port = 5038 //порт для подключения к AMI интерфейсу
bindaddr = 0.0.0.0 //откуда принимать подключения (по умолчанию, 0.0.0.0 – разрешено подключаться со всех адресов)
displayconnects=no ; //отображать ли подключения к Asterisk в командной строке
Переходим к настройке самого пользователя. Для этого, под секцией [general] необходимо создать нового пользователя. Дадим ему имя – test с паролем P@ssw0rd :
[test] //аналогично полю Manager Name в FreePBX
secret = P@ssw0rd //аналогично полю Manager Secret
deny=0.0.0.0/0.0.0.0 //аналогично полю Deny
permit=127.0.0.1/255.255.255.0 //аналогично полю Permit
read = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate,message
write = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate,message
writetimeout = 5000 //аналогично полю Write Timeout
По окончанию настроек, нажмите комбинацию клавиш :x! для сохранения файла. После этого, введите команду:
[root@localhost ~]# asterisk -rx "core restart now"
Проверяем подключения к AMI
Теперь, после настроек, проверим подключение к AMI через созданного пользователя. Для этого, через консоль сервера сделаем подключение по протоколу telnet на порт 5038, который указан в секции [general] в параметре Port, конфигурационного файла manager.conf :
[root@localhost ~]# telnet localhost 5038
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Asterisk Call Manager/2.8.0
Action: login
Username: test
Secret: P@ssw0rd
Response: Success
Message: Authentication accepted
Готово. Ответом на подключения является сообщение Success. Это означает, что интерфейс настроен и готов к работе.
Мы продолжим рассмотрение вопроса об устранении неполадок в объявлениях о маршрутах BGP. Все маршрутизаторы будут иметь рабочие соседние узлы BGP.
Рекомендуем также почитать первую часть статьи по траблшутингу протокола BGP.
Видео: Основы BGP за 7 минут
Урок 1
Новый сценарий. R1 и R2 находятся в разных автономных системах. Мы пытаемся объявить сеть 1.1.1.0 / 24 от R1 до R2, но она не отображается на R2. Вот конфигурации:
На первый взгляд, здесь все в порядке.
Однако R2 не узнал никаких префиксов от R1
Может быть, используется distribute-list. Но нет, это не тот случай. Это означает, что нам придется проверять наши все команды network.
Проблема заключается в команде network. Она настраивается по-разному для BGP и нашего IGP. Если мы применяем команду network для BGP, она должна быть полной. В этом случае забыли добавить маску подсети
R1(config)#router bgp 1
R1(config-router)#network 1.1.1.0 mask 255.255.255.0
Мы должны убедиться, что ввели правильную маску подсети.
Итак, видно, что мы узнали префикс, и R2 устанавливает его в таблицу маршрутизации ... проблема решена!
Итог урока: введите правильную маску подсети ... BGP требователен!
Урок 2
Давайте перейдем к следующей проблеме. Системный администратор из AS1 хочет объявить summary в AS 2. Системный администратор из AS 2 жалуется, однако, что он ничего не получает..., давайте, выясним, что происходит не так!
Вот конфигурация. Вы можете увидеть команду aggregate-address на R1 для сети 172.16.0.0 / 16.
Жаль ... префиксы не были получены R2. Здесь мы можем проверить две вещи:
Проверьте, не блокирует ли distribute-list префиксы, как это мы сделали в предыдущем занятии.
Посмотрите, что R1 имеет в своей таблице маршрутизации (Правило: "не могу объявлять то, чего у меня нет!").
Давайте начнем с таблицы маршрутизации R1. Из предыдущих уроков вы знаете, как выглядит distribute-list.
Здесь нет ничего, что выглядело бы даже близко к 172.16.0.0 /16. Если мы хотим объявить summary, мы должны сначала поместить что-то в таблицу маршрутизации R1. Рассмотрим различные варианты:
R1(config)#interface loopback 0
R1(config-if)#ip address 172.16.0.1 255.255.255.0
R1(config-if)#exit
R1(config)#router bgp 1
R1(config-router)#network 172.16.0.0 mask 255.255.255.0
Это вариант 1. Создам интерфейс loopback0 и настроим IP-адрес, который попадает в диапазон команды aggregate-address.
Теперь мы видим summary в таблице маршрутизации R2. По умолчанию он все равно будет объявлять другие префиксы. Если вы не хотите этого, вам нужно использовать команду aggregate-address summaryonly!
Второй вариант объявления summary:
R1(config)#ip route 172.16.0.0 255.255.0.0 null 0
R1(config)#router bgp 1
R1(config-router)#network 172.16.0.0 mask 255.255.0.0
Сначала мы поместим сеть 172.16.0.0 / 16 в таблицу маршрутизации, создав статический маршрут и указав его на интерфейсе null0. Во-вторых, будем использовать команду network для BGP для объявления этой сети.
Итог урока: Вы не можете объявлять то, чего у вас нет. Создайте статический маршрут и укажите его на интерфейсе null0, чтобы создать loopback интерфейс с префиксом, который попадает в диапазон суммарных адресов.
Урок 3
Следующая проблема. Вы работаете системным администратором в AS 1, и однажды получаете телефонный звонок от системного администратора AS 2, который интересуется у вас, почему вы публикуете сводку для 1.0.0.0 / 8. Вы понятия не имеете, о чем, он говорит, поэтому решаете проверить свой роутер.
Это то, что видит системный администратор на R2.
Мы видим, что у нас есть сеть 1.0.0.0 / 8 в таблице BGP на R1. Давайте проверим его таблицу маршрутизации.
Сеть 1.1.1.0 / 24 настроена на loopback интерфейс, но она находится в таблице BGP как 1.0.0.0 / 8. Это может означать только одну вещь ... суммирование.
Беглый взгляд на выводы команды show ip protocols показывает, что автоматическое суммирование включено. Отключим это:
R1(config)#router bgp 1
R1(config-router)#no auto-summary
Мы отключим его на R1.
Теперь мы видим 1.1.1.0 / 24 на R2 ... проблема решена!
Итог урока: если вы видите classful сети в своей таблице BGP, возможно, вы включили автоматическое суммирование.
Некоторые из проблем, которые были рассмотрены, можно легко решить, просто посмотрев и/или сравнив результаты команды "show run". И это правда, но имейте в виду, что у вас не всегда есть доступ ко ВСЕМ маршрутизаторам в сети, поэтому, возможно, нет способа сравнить конфигурации. Между устройствами, на которых вы пытаетесь устранить неисправности или которые вызывают проблемы, может быть коммутатор или другой маршрутизатор. Использование соответствующих команд show и debug покажет вам, что именно делает ваш маршрутизатор и что он сообщает другим маршрутизаторам.
Урок 4
Та же топология, другая проблема. Персонал из AS 2 жалуются, что они ничего не получают от AS 1. Для усложнения проблемы, конфигурация не будет показана.
Для начала, мы видим, что R2 не получает никаких префиксов.
Так же можем убедиться, что R1 не имеет каких-либо distribute-lists.
Мы видим, что R1 действительно имеет сеть 1.1.1.0 /24 в своей таблице маршрутизации, так почему же он не объявляет ее в R2?
Давайте посмотрим, может на R1 есть какие-то особенные настройки для своего соседа R2:
Будем использовать команду show ip bgp neighbors, чтобы увидеть подробную информацию о R2. Мы видим, что route-map была применена к R2 и называется "NEIGHBORS". Имейте в виду, что помимо distribute-lists мы можем использовать также route-map для фильтрации BGP.
Существует только оператор соответствия для prefix-list "PREFIXES".
Вот наш нарушитель спокойствия ... он запрещает сеть 1.1.1.0 / 24!
R1(config)#router bgp 1
R1(config-router)#no neighbor 192.168.12.2 route-map NEIGHBORS out
Удалим route-map
И наконец R2 узнал об этом префиксе ... проблема решена!
Итог урока: убедитесь, что нет route-map, блокирующих объявление префиксов.
BGP иногда может быть очень медленным, особенно когда вы ждете результатов, когда вы работаете на тестовом или лабораторном оборудовании. "Clear ip bgp *" - это хороший способ ускорить его ... просто не делайте этого на маршрутизаторах в производственной сети)
Урок 5
Наконец, третий участник выходит на арену, чтобы продемонстрировать новую проблему. R1-это объявляемая сеть 1.1.1.0 / 24, но R3 не изучает эту сеть. Здесь представлены конфигураций:
Соседство настроено, R1 - объявляемая сеть 1.1.1.0 / 24.
R3#show ip route bgp
Мы можем видеть сеть 1.1.1.0 / 24 в таблице маршрутизации R2, но она не отображается на R3.
Технически проблем нет. Если вы внимательно посмотрите на конфигурацию BGP всех трех маршрутизаторов, то увидите, что существует только соседство BGP между R1 и R2 и между R2 и R3. Из-за split horizon IBGP R2 не пересылает сеть 1.1.1.0 / 24 в направлении R3. Чтобы это исправить, нам нужно настроить R1 и R3, чтобы они стали соседями.
R1(config)#ip route 192.168.23.3 255.255.255.255 192.168.12.2
R3(config)#ip route 192.168.12.1 255.255.255.255 192.168.23.2
Если мы собираемся настроить соседство BGP между R1 и R3, нам нужно убедиться, что они могут достигать друг друга. Мы можем использовать статическую маршрутизацию или IGP ... чтобы упростить задачу, на этот раз мы будем использовать статический маршрут.
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.23.3 remote-as 1
R3(config)#router bgp 1
R3(config-router)#neighbor 192.168.12.1 remote-as 1
Примените правильные настройки команды neighbor BGP.
И R3 имеет доступ к сети 1.1.1.0 / 24!
Итог урока: соседство по IBGP должно быть полным циклом! Другим решением было бы использование route-reflector или confederation.
Урок 6
Очередная проблема. R3 является объявляемой сетью 3.3.3.0 / 24 через EBGP, а R2 устанавливает ее в таблицу маршрутизации. R1, однако, не имеет этой сети в своей таблице маршрутизации. Вот конфигурации:
Вот конфигурации. Для простоты мы используем IP-адреса физического интерфейса для настройки соседей BGP.
Мы можем проверить, что сеть 3.3.3.0 / 24 находится в таблице маршрутизации R2.
R1#show ip route bgp
Однако в таблице маршрутизации R1 ничего нет. Первое, что мы должны проверить - это таблицу BGP.
Мы видим, что он находится в таблице BGP, и * указывает, что это допустимый маршрут. Однако мы не видим символа >, который указывает лучший путь. По какой-то причине BGP не может установить эту запись в таблице маршрутизации. Внимательно посмотрите на следующий IP-адрес прыжка (192.168.23.3). Доступен ли этот IP-адрес?
R1 понятия не имеет, как достичь 192.168.23.3, поэтому наш следующий прыжок недостижим. Есть два способа, как мы можем справиться с этой проблемой:
Используйте статический маршрут или IGP, чтобы сделать этот next hop IP-адрес доступным.
Измените next hop IP-адрес.
Мы изменим IP-адрес следующего прыжка, так как мы достаточно изучили применение статических маршрутов и IGPs.
R2(config)#router bgp 1
R2(config-router)#neighbor 192.168.12.1 next-hop-self
Эта команда изменит IP-адрес следующего перехода на IP-адрес R2.
Теперь мы видим символ >, который указывает, что этот путь был выбран как лучший. IP-адрес следующего перехода теперь 192.168.12.2.
Ура! Теперь он есть в таблице маршрутизации. Мы уже закончили? Если наша цель состояла в том, чтобы она отобразилась в таблице маршрутизации, то мы закончили...однако есть еще одна проблема.
Наш пинг не удался. R1 и R2 оба имеют сеть 3.3.3.0 / 24 в своей таблице маршрутизации, поэтому мы знаем, что они знают, куда пересылать IP-пакеты.
Давайте взглянем на R3:
R3 получит IP-пакет с пунктом назначения 3.3.3.3 и источником 192.168.12.1. Из таблицы маршрутизации видно, что она не знает, куда отправлять IP-пакеты, предназначенные для 192.168.12.1. Исправим это:
R2(config)#router bgp 1
R2(config-router)#network 192.168.12.0 mask 255.255.255.0
Мы будем объявлять сеть 192.168.12.0 / 24 на R2.
Теперь R3 знает, куда отправлять трафик для 192.168.12.0 / 24.
Проблема устранена!
Итог урока: убедитесь, что IP-адрес следующего перехода доступен, чтобы маршруты могли быть установлены в таблице маршрутизации, и чтобы все необходимые сети были достижимы.