Коль уж имеется достаточное количество статей на хабре по этой теме, добавлю и я свои «пять копеек». Отличие от опубликованных методов — возможность просмотра истории изменений по дням или восстановления конфигурации на конкретную дату.
Что имеем
- Несколько маршрутизаторов RB2011iL (конкретно в моём случае — 6 в работе и 2 в «холодном резерве»
- Виртуальный сервер на Ubuntu 14.04 с установленным redmine, git (да много что ещё)
Redmine используется в качестве журнала, куда записываем поставленные задачи, решения. Ведётся вики. В общем, полезная штука, но речь не об этом. В redmine есть плюшка под названием «Хранилище» с прикручиваемой системой контроля версий. По умолчанию это предназначено, видимо, для разработки ПО, но скрипты конфигурации — по сути, код программы и есть.
Идея
Идея прозрачна и проста. Устройства по расписанию создают скрипты своих конфигураций по окончанию рабочего дня, bash-скрипт на сервере забирает всё по tftp, добавляет в git-репозиторий и коммитит. Redmine в данном разрезе используется только как средство просмотра репозитория, позволяет забрать конфигурацию на дату любого изменения и просмотреть эти самые изменения.
Реализация
На микротиках:
/system script add name=export_script owner=admin policy=ftp,read,write,policy,test source="/export compact file="export_script" hide-sensitive"
/system scheduler add interval=1d name=getscript-schedule on-event=export_script policy=ftp,read,write,policy,test start-date=mar/22/2016 start-time=17:00:00
/ip tftp add ip-addresses=192.168.88.0/24 real-filename=export_script.rsc req-filename=export_script.rsc
Скрипт на сервере просматривает файл ./nodes, в котором перечислены (по одному в строке) ip-адреса устройств и достаёт скрипты:
#!/bin/bash
# настройки скрипта - пути к программам и временной папочке
tftp=/usr/bin/tftp
git=/usr/bin/git
tmpdir=/run/user/1000
rsc_name=export_script.rsc
logger=/usr/bin/logger
# запись в syslog сообщения о старте скрипта (для отладки, да и не часто он вызывается)
${logger} -t $0 "starting script $0. home directory - `pwd`"
# получаем все конфиги и убираем из них верхнюю строчку (дата/время создания, нам лишние изменения не нужны)
for node in `cat ./nodes`
do
${tftp} ${node} -m binary -c get ${rsc_name} ${tmpdir}/${rsc_name}
# а получилось ли скачать? (в случае ошибок создаётся файл нулевого размера)
if [ -s ${tmpdir}/${rsc_name} ]
then
tail -n +2 ${tmpdir}/${rsc_name} > ../data/${node}.rsc
rm ${tmpdir}/${rsc_name}
else
${logger} -t $0 "error while transfer ${rsc_name} from ${node}"
fi
done
# обновляем всё в git'е
${git} add ../data
${git} commit -m "autocommit `date`"
По настройкам redmine ничего не скажу, ибо записей по действиям не сохранилось, всё делалось по доступным мануалам. Git тоже стоит настроить для пользователя, под которым запускается скрипт, чтобы не задавалось лишних вопросов.
Как это выглядит в redmine
Все изменения, например:
Изменения конфига конкретного микротика:
(и вроде все адреса внутренние, а всё равно сетить не хочется)
Про восстановление конфигурации
Когда необходимо залить конфигурацию в новый микротик из данных скриптов (в случае выхода из строя одного из узлов), можно воспользоваться командой (на сброшенных настройках)
import <имя файла>Можно также выполнить сброс и применение конфигурации одной командой:
/system reset-configuration no-default=yes run-after-reset=<имя файла>
При этом стоит помнить, что скрипты не содержат паролей и ключей всяческих, поэтому после восстановления их нужно вводить вручную.
Более того, крайне желательно, чтобы совпадали модели и версии RouterOS исходного устройства и устройства назначения, т.к. иногда меняется синтаксис команд. Также желательно, чтобы совпадал набор включенных пакетов — буквально недавно испытывал негодование по причине ошибок в импорте конфигурации с устройства без пакета ntp на устройство с ним. Ещё, бывает, что веб-интерфейс позволяет выставить некорректные параметры и они успешно экспортируются, а импорт с ними не работает.
Таким образом, бэкап и восстановление конфигурации удобнее и надёжнее выполнять с помощью файлов backup, а данный способ больше подходит для отслеживания изменений и анализа конфигурации в случае, когда узел недоступен.
Надеюсь, представленная информация окажется кому-нибудь полезной. Буду рад замечаниям и предложениям.
Автор: диванный аналитик
