Резервное копирование - важная составляющая стабильной работы инфраструктуры. Каждый подходит к вопросу резервного копирования со своими взглядами. Сетевое оборудование также нуждается в постоянном бэкапе конфигураций. Но в силу того, что сети редко бывают моновендорными и найти один метод управления для всей сети часто невозможно, резервное копирование сетевых устройств часто вводит в замешательство администраторов.
Для автоматизации резервного копирования конфигураций сетевого оборудования инженеры часто применяют системы контроля версий. Такой подход позволяет не только всегда иметь актуальную копию конфигурации, но и оперативно находить изменения в настройках, которые могли привести к неправильной работе сети.
Во время подготовки к выступлению на MUM 2017 я изучил несколько систем, позволяющих автоматизировать резервное копирование в git.
Unimus
Разработана Tomas Kirnak - моим коллегой - тренером Mikrotik из США. Система писалась исходя из потребностей Томаса для его сети из 1500 RouterOS и других устройств. На тему управления этим парком Томас докладывал на МУМе.
Unimus инсталлируется на Windows, *nix, имеется portable версия для Windows. Устанавливать я не пробовал, но portable версию запустил. Все заработало без особых телодвижений, открылся приятный веб интерфейс. Поддерживается работа с 58 вендорами, бэкапит в git
Система простая, удобная и, главное, работающая. За что автор и просит денег.
Oxidized
Аналогичная предыдущей система. Менее приятный интерфейс, что не мешает выполнять oxidized свою основную функцию. Поддерживается 91 вендор, среди которых Cisco, Juniper, Mikrotik, D-Link, Cumulus Linux, pfSense.
На русском языке информацию об oxidized я не нашел. Поэтому постараюсь восполнить этот пробел.
Oxidized создавался как альтернатива RANCID двумя разработчиками: Saku Ytti и Samer Abdel-Hafez. Кстати, парням нужен разработчик на Ruby для помощи в разработке. Явное преимущество над RANCID - удобный веб-интерфейс, взглянуть на него можно по ссылке: https://oxidized.arahant.net/nodes.
В основном окне можно увидеть список устройств и сравнить их бэкапы. Хорошая фича системы - поиск по конфигурациям в верхнем правом углу. Например, можно найти конфиги всех точек доступа с SSID=bubnovd.net. Веб интерфейс очень быстрый! Работая с более, чем 300 девайсами, я не заметил сколь-нибудь заметных задержек.
Провалившись в меню девайса, открывается список различных версий конфига этого устройства.
Каждую версию можно сравнить с другой и увидеть что именно происходило с устройством между этими версиями.
На вкладке stats отображается результат резервного копирования.
Можно увидеть сколько попыток бэкапа были неудачными, сколько времени занимает процесс бэкапа, время последнего удачного и неудачного бэкапов.
Установка
Я опишу установку на Debian. Установку ОС и её первичную настройку описывать не буду, благо всё уже много раз сделано. Всё делал по инструкции.
apt install ruby ruby-dev libsqlite3-dev libssl-dev pkg-config cmake libssh2-1-dev
gem install oxidized oxidized-script oxidized-web
Установка не вызывает вопросов, всё проходит стандартно. В описании системы не очень понятно что и как делать дальше. Я постараюсь объяснить.
Конфигурация
Запускать oxidized с правами суперпользователя - не самая лучшая идея. Поэтому создадим пользователя oxidized, с правами которого будет запускаться система бэкапа:
useradd oxidized
Создадим для нового пользователя домашний каталог, в котором будут лежать конфигурационные файлы, список устройств и база git:
mkdir /home/oxidized
И дадим права на этот каталог юзеру oxidized:
chown oxidized:oxidized /home/oxidized
Первый запуск создаст все необходимые файлы и каталоги. Не забыли, что запускать надо под специальным пользователем?
su - oxidized
oxidized
Создался каталог /home/oxidized/.config/oxidized, в котором находится всё, что нужно для дальнейшей настройки. Основные настройки системы хранятся в файле config в формате YAML. Он состоит из нескольких частей:
Input
Output
Source
Основные настройки
Привожу свой конфиг:
bubnov@oxidized:~$ cat /home/oxidized/.config/oxidized/config
\---
//пользователь и пароль, от которых система будет коннектиться к девайсам
username: oxidized
password: p@ssw0rd
//вендор. Я указывал вендора для каждого устройства в файле router.db. Но можно выставить и здесь
model: junos
//Периодичность снятия бэкапа в секундах
interval: 3600
use\_syslog: false
debug: false
threads: 30
//таймаут сессии. Многие устройства не успевают выгрузить конфигурацию в дефолтные 20 секунд. Приходится увеличивать
timeout: 140
//количество попыток снять бэкап с каждого устройства, после чего считается, что бэкап сделать не удалось
retries: 3
prompt: !ruby/regexp /^(\[\\w.@-\]+\[#>\]\\s?)$/
//IP адрес и порт, на котором будет работать REST API (веб интерфейс по простому)
rest: 127.0.0.1:8888
next\_adds\_job: false
Vars:
//позволяет исключить из бэкапа критичную информацию, такую как snmp-community, ключи шифрования и т.п.
remove\_secret: true
groups: {}
models: {}
pid: "/home/oxidized/.config/oxidized/pid"
log: "/home/oxidized/.config/oxidized/log"
//тип подключения к управляемым устройствам
input:
default: ssh
debug: false
ssh:
secure: false
//где хранится конфигурации (git, text, ...) и настройки хранилища
output:
default: git
git:
user: oxidized
email: admin@bubnovd.net
repo: "/home/oxidized/.config/oxidized/devices.git"
//откуда берется информация о бэкапящихся девайсах
source:
default: csv
csv:
file: "/home/oxidized/.config/oxidized/router.db"
delimiter: !ruby/regexp /:/
map:
name: 0
model: 1
ip: 2
model\_map:
cisco: ios
juniper: junos
Из важного здесь:
Логин и пароль пользователя на устройствах, под именем которого будет делаться бэкап. Я рекомендую создать на всех девайсах специального пользователя с ограниченными правами, позволяющими бэкапить. К примеру, на RouterOS это группа read
Разделы input, output, source. В них указывается как подключаться к устройствам, где взять их список и куда выгружать бэкап
Адрес и порт REST API. Чуть позже я объясню, почему он должен быть 127.0.0.1:8888
В разделе source указано, что информацию о девайсах нужно брать из CSV файла, путь к нему и порядок полей в нем. В моем случае формат такой: имя\_устройства:модель:ip
Сам файл router.db:
RB128:routeros:192.168.3.128
RB121:routeros:192.168.3.1:oxidized:drugoi\_password
sw11:dlink:192.168.3.11:::2222
В первой строке указан роутер Mikrotik, о чем говорит поле routeros, с адресом 192.168.3.128 и называться в oxidized он будет RB128. Логин и пароль для подключения будет браться из файла config. Второе устройство RB121 имеет другую учетную запись, параметры которой указаны после IP адреса - логин:пароль. А третий девайс производства D-Link, с логином/паролем из файла config, но SSH на порту 2222.
Стоит сказать, что устройства можно группировать по вендору или учетным записям. Об этом можно почитать в официальной документации.
Авторизация
На этом этапе уже можно запускать систему и набрав в браузере http://localhost:8888 увидеть её интерфейс. Но у oxidized есть большой недостаток: нет аутентификации в системе. То есть любой может открыть в браузере веб-интерфейс и увидеть все конфиги ваших сетевых устройств. Разработчик занимается только системой бэкапа и смежные фичи внедрять пока не планирует.
Обойдем этот недостаток с помощью Reverse-proxy.
Ставим nginx:
apt install nginx
И настраиваем его на работу как реверс прокси:
nano etc/nginx/sites-available/default
auth\_basic “Username and Password Required”;
auth\_basic\_user\_file /etc/nginx/.htpasswd;
location / {
proxy\_set\_header Host $host;
proxy\_set\_header X-Real-IP $remote\_addr;
proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for;
proxy\_pass http://127.0.0.1:8888;
}
И создаем юзера и пароль:
sudo htpasswd /etc/nginx/.htpasswd username
Теперь nginx будет работать на стандартном порту (или на том, который вы укажете в его настройках), при обращении к нему будет происходить авторизация и пользователь будет перенаправлен на адрес proxy_pass (127.0.0.1:8888 в нашем случае).
Хочу обратить ваше внимание на опцию remove_secrets в конфиге. Она удаляет критичную информацию из бэкапа, такую как SNMP-community, ключи шифрования, ключи Wi-Fi. Например, Mikrotik RouterOS в дефолте умеет скрывать эти данные, если экспорт выполнять с опцией hide-sensitive. Oxidized же может исключать эти данные из конфигов любого вендора.
Узнать что именно удаляется из конфига, можно посмотрев в описание вашего вендора в списке. Например, для Cicso:
Для того, чтобы oxidized стартовал как служба, сделайте следующее:
sudo cp /usr/local/share/gems/gems/oxidized-0.19.0/extra/oxidized.service /lib/systemd/system/
sudo systemctl enable oxidized.service
sudo systemctl start oxidized
Я же просто прописал в crontab запуск после ребута:
sudo -u oxidized crontab -l
@reboot /usr/local/bin/oxidized
Для подготовки к посту использовались следующие материалы:
https://github.com/ytti/oxidized#installation
https://unimus.net/
http://packetpushers.net/install-oxidized-network-configuration-backup/
http://www.whoopis.com/core/oxidized-quickstart-tutoria.html
https://log.cyconet.org/2016/01/29/oxidized-silly-attempt-at-really-awesome-new-cisco-config-differ/
http://shairosenfeld.blogspot.ru/2011/03/authorization-header-in-nginx-for.html
https://community.openhab.org/t/using-nginx-reverse-proxy-authentication-and-https/14542
Надеюсь, эта статья поможет вам в настройке резервного копирования. Любые вопросы вы можете задать в комментариях к статье. Я постараюсь на них ответить.
comments powered by Disqus