Уточнение: решение настроено для D-Link DFL, cisco 29xx и WatchGuard Firebox, но подходит для всего, что умеет делать бэкапы при подключении по ssh и/или заливать их по расписанию/событию на ftp/tftp сервер.
Всё началось с того, что мой знакомый программист спросил: «А почему ты не хранишь сетевые конфиги в системе контроля версий?». А и правда – подумала я – почему? Большая часть конфигурационных файлов может быть выгружена в текстовом формате (ну, это бинарники, конечно, но в текстовом редакторе открываются и отображается читабельная информация).
В сети у нас около 30 разных D-Link DFL, десяток Cisco 29xx и пара WatchGuard Firebox. К каждому устройству имеют доступ уровня администратора сотрудники ИТ филиала, где оно стоит, плюс ИТ головного офиса. Это влечёт за собой проблемы вида «я не делал бэкап полгода и всё сломал, у вас нет нашего бэкапа?» и «у нас сгорело оборудование последний бэкап делал предыдущий админ, я не знаю куда, настройте нам как было». И если cisco и так автоматически сбрасывает running-config на ftp при каждом сохранении, то с D-Link такого нет. А система контроля версий помогла бы отследить проблемы вида «я не помню, что и когда поменял, но у нас сломалась штука, которая используется раз в месяц». Регламент о резервном копировании не спасает от человеческого фактора и не сделает бэкап за вас, так что лучше предупредить, чем расхлебывать.
Признаюсь честно, до того, как я села писать пост, я не знала про rancid и oxidized. Но они оба не умеют то, что нужно мне в полном объеме. Первый заточен на cisco и со всякой экзотикой работает не очень, второй не имеет авторизации пользователей (хотя это обходится несложными манипуляциями с web-сервером), а, главное, оба они требуют наличия логина и пароля в резервируемую систему. Все D-link DFL поддерживают логин по ключу ssh. Cisco сливает бэкапы сама и вообще не требует коннекта на неё. Соответственно, зачем хранить пароли, периодически меняющиеся, к тому же, если можно логиниться по ключу.
Было решено сделать что-то меня устраивающее самостоятельно.
Собственно, автобэкапы напрашивались давно. А вот система контроля версий – это было свежо.
Итак, задача: собрать все значимые конфиги с сетевого оборудования в одном месте с поддержкой версионности файлов, регулярно их там обновлять в автоматическом режиме, дать возможность админам в другом часовом поясе их скачать простым способом, не звоня мне в 3 утра. Всё это, конечно, бесплатно.
У всех DFL файл конфига называется одинаково, соответственно надо было их при копировании внятно называть. Также не хотелось перенастраивать уже существующую систему заливки running-config на ftp у cisco.
Я взяла svn, т.к. svn – единственный из популярных хранит diff бинарников, а не все файлы в истории. Не то, чтобы это было важно на малых объемах, но приятно. В целом, учитываю малый объем конфигурационных файлов, какую систему контроля версий брать – без разницы.
Устанавливается сервер Visual SVN с официального сайта методом далее-далее-готово. Я ставила на сервер под Windows, чтоб коллегам было проще администрировать (пользователей создавать, права раздавать). Далее создаётся репозиторий, в нем необходимые разделы и создаётся (пока) единственный пользователь с полными правами на репозиторий. На винде действия закончены.
Автобэкапы у меня делаются скриптом с одной линуксовой машинки (под Debian).
Сначала ставим svn, чтоб у нас появился клиент:
Теперь руками создается копия проекта (создастся в текущей директории):
Сейчас у меня в репозитории три раздела:
Коннект идет по ssh. Чтобы не светить пароли в открытом виде, используется пара открытый-закрытый ключ. Закрытый хранится на сервере в /usr/dfl_scripts/sshkeys/dfl_key.
Генерируем пару открытый-закрытый ключ на сервере автобэкапов:
открытый залит во все DFL и сделано правило доступа по ssh:
Ну и разрешен соответствующий remote management. Порт с дефолтного можно изменить на, например, 2222, хотя доступ и так только с определенных адресов.
Файл с текущей конфигурацией у D-Link DFL лежит в корне и называется config.bak, его можно просто скопировать себе, используя scp.
Итак, скрипт (я порезала список филиалов, чтоб не было простыни):
Скрипт запихнут в cron и запускается в 8:30 утра ежедневно. Вот так выглядит crontab:
На самих устройствах настроено что-то вроде этого:
В итоге, по команде write-memory текущая конфигурация сбрасывается на ftp. У меня ftp находится на другом сервере, чем сборище автобэкапов. Тут 2 пути: сделать и на том сервере копию репозитория и добавлять конфиги там или копировать конфиги на соседний сервер. В принципе, вся разница в том, делать cp или scp.
На директорию, куда падают конфиги с cisco, я сажаю incron следить за появлением файлов. По появлению файла – переименовываю его как надо и копирую на сервер-сборщик автобэкапов во временную директорию. По отсечке, файлы из временной директории заливаются в svn. Итого я имею в системе контроля версий актуальный конфиг на определенное время раз в день. На мой взгляд, этого достаточно, но система без проблем модифицируется под любые хотелки.
Конфигурация incrontab выглядит так:
Сам скрипт:
На сервере автобэкапов по расписанию запускается следующий скрипт:
Как видно, тут речь еще и о WatchGuard Firebox. Мне было откровенно лениво делать для них отдельную директорию. Так что бэкапы падают на ftp туда же, куда и cisco. WatchGuard бэкапится отдельным скриптом на полчаса раньше и вообще раз в неделю. Обратите внимание, с версии прошивки 12 изменился синтаксис. Раньше это можно было делать одной командой backup image to ftp, а теперь добавился export. На нём я не смогла настроить логин через ssh по ключу, так что используются пароли.
У WatchGuard файлы бинарники экспортируются только шифрованные, так что тут с текстовым видом и diff не очень получится. Обратите внимание на ключ шифрования: обязательный заглавные, строчные буквы и цифры, не менее 8 символов. При не соответствии просто не выполняется команда, конкретно не указывается, где ошибка.
Итак, всё сделалось. Теперь ставим клиента на свой рабочий комп под виндой. Просто посмотреть файлы и diff можно и из браузера, а вот скачать версию из определенной ревизии только из клиента. Ставим TorToSiteSVN с официального сайта.
На сервере создаем пользователя с необходимыми правами (на чтение) для филиалов.
Потом надо зайти в клиент через контекстное меню к любому файлу и подключиться к хранилищу. Себе копию хранилища создавать не обязательно, если вы не планируете вносить изменения в файлы. Ну и осторожнее с этим, с копией надо будет работать через систему контроля версий, а не просто как с куском файловой системы.
Чтоб заработали diff’ы на нестандартных тексовых файлах, надо сделать так, чтоб SVN считал эти файлы не бинарными, а текстовыми. Вот так:
Эту команду выполнить, например, под linux и после сделать commit.
Ну и вот изменения, смотрим глазками. Видим, что менялись правила firewall:
В браузере смотреть удобнее.
Если что стряслось, то админ может скачать нужный бэкап без лишних телодвижений на нужную дату.
Хотя, обычно, хватает последнего актуального.
В некотором роде, получилось изобретение велосипеда. Но оно работает на D-link DFL уже почти год, именно так, как мне надо, и иногда очень выручает.
Надеюсь, кому-то пригодится.
Ссылки:
Про rancid
WatchGuard Firebox CLI manual
Про oxidized
Всё началось с того, что мой знакомый программист спросил: «А почему ты не хранишь сетевые конфиги в системе контроля версий?». А и правда – подумала я – почему? Большая часть конфигурационных файлов может быть выгружена в текстовом формате (ну, это бинарники, конечно, но в текстовом редакторе открываются и отображается читабельная информация).
В сети у нас около 30 разных D-Link DFL, десяток Cisco 29xx и пара WatchGuard Firebox. К каждому устройству имеют доступ уровня администратора сотрудники ИТ филиала, где оно стоит, плюс ИТ головного офиса. Это влечёт за собой проблемы вида «я не делал бэкап полгода и всё сломал, у вас нет нашего бэкапа?» и «у нас сгорело оборудование последний бэкап делал предыдущий админ, я не знаю куда, настройте нам как было». И если cisco и так автоматически сбрасывает running-config на ftp при каждом сохранении, то с D-Link такого нет. А система контроля версий помогла бы отследить проблемы вида «я не помню, что и когда поменял, но у нас сломалась штука, которая используется раз в месяц». Регламент о резервном копировании не спасает от человеческого фактора и не сделает бэкап за вас, так что лучше предупредить, чем расхлебывать.
Признаюсь честно, до того, как я села писать пост, я не знала про rancid и oxidized. Но они оба не умеют то, что нужно мне в полном объеме. Первый заточен на cisco и со всякой экзотикой работает не очень, второй не имеет авторизации пользователей (хотя это обходится несложными манипуляциями с web-сервером), а, главное, оба они требуют наличия логина и пароля в резервируемую систему. Все D-link DFL поддерживают логин по ключу ssh. Cisco сливает бэкапы сама и вообще не требует коннекта на неё. Соответственно, зачем хранить пароли, периодически меняющиеся, к тому же, если можно логиниться по ключу.
Было решено сделать что-то меня устраивающее самостоятельно.
Собственно, автобэкапы напрашивались давно. А вот система контроля версий – это было свежо.
Итак, задача: собрать все значимые конфиги с сетевого оборудования в одном месте с поддержкой версионности файлов, регулярно их там обновлять в автоматическом режиме, дать возможность админам в другом часовом поясе их скачать простым способом, не звоня мне в 3 утра. Всё это, конечно, бесплатно.
У всех DFL файл конфига называется одинаково, соответственно надо было их при копировании внятно называть. Также не хотелось перенастраивать уже существующую систему заливки running-config на ftp у cisco.
Сначала настраиваем систему контроля версий
Я взяла svn, т.к. svn – единственный из популярных хранит diff бинарников, а не все файлы в истории. Не то, чтобы это было важно на малых объемах, но приятно. В целом, учитываю малый объем конфигурационных файлов, какую систему контроля версий брать – без разницы.
Устанавливается сервер Visual SVN с официального сайта методом далее-далее-готово. Я ставила на сервер под Windows, чтоб коллегам было проще администрировать (пользователей создавать, права раздавать). Далее создаётся репозиторий, в нем необходимые разделы и создаётся (пока) единственный пользователь с полными правами на репозиторий. На винде действия закончены.
Автобэкапы у меня делаются скриптом с одной линуксовой машинки (под Debian).
Сначала ставим svn, чтоб у нас появился клиент:
sudo apt-get install svnТеперь руками создается копия проекта (создастся в текущей директории):
svn checkout https://servername.mydomain.ru/svn/DFL_BACKUPS/ DFL_BACKUPS --username goСейчас у меня в репозитории три раздела:
- Current_backup, где хранятся и перезаписываются конфиги D-Link DFL.
- Old_versions, где хранятся конфиги с приписанной датой для удобства скачивания админами филиалов.
- Cisco, где хранятся конфиги cisco и WatchGuard Firebox (ну, так сложилось).
Начнем с автобэкапов DFL и настройки самого DFL
Коннект идет по ssh. Чтобы не светить пароли в открытом виде, используется пара открытый-закрытый ключ. Закрытый хранится на сервере в /usr/dfl_scripts/sshkeys/dfl_key.
Генерируем пару открытый-закрытый ключ на сервере автобэкапов:
ssh-keygen –t rsaоткрытый залит во все DFL и сделано правило доступа по ssh:
Ну и разрешен соответствующий remote management. Порт с дефолтного можно изменить на, например, 2222, хотя доступ и так только с определенных адресов.
Файл с текущей конфигурацией у D-Link DFL лежит в корне и называется config.bak, его можно просто скопировать себе, используя scp.
Итак, скрипт (я порезала список филиалов, чтоб не было простыни):
#!/bin/bash
rm /usr/dfl_scripts/dflbackup/* #очищаем старые файлы бэкапа
dfls=( "amur:10.28.10.254" #перечисляем филиалы
"arhangelsk:10.29.10.254"
"buratia:10.3.10.254"
"volgograd:10.34.10.254"
"voronezh:10.36.10.254"
"irkutsk_210:10.38.20.253"
"irkutsk_260:10.38.20.254"
"yaroslavl:10.76.10.254" )
rm /usr/dfl_scripts/log.txt #очищаем лог-файл
for dfl in "${dfls[@]}" ; do #цикл по всем ДФЛ-кам
filial="${dfl%%:*}" #delete the longest substr :* search from the end of string
ip_addr="${dfl##*:}" #delete the longest substr *: search from the head of string
echo $filial $ip_addr >> /usr/dfl_scripts/log.txt #Пишем в лог текущий филиал
scp -P 2222 -i /usr/dfl_scripts/sshkeys/dfl_key admin@$ip_addr:config.bak /usr/dfl_scripts/dflbackup/$filial.bak 2>>/usr/dfl_scripts/log.txt #скачиваем конфиг с дфл, ошибки пишем тоже в лог
done
FILES=$(ls /usr/dfl_scripts/dflbackup) #Запихиваем имена файлов в массив
now=$(date +"%d_%m_%Y") #записываем в переменную текущую дату
for f in $FILES ; do #цикл по всем файлам в директории (которые уже упиханы в массив)
cp /usr/dfl_scripts/dflbackup/$f /usr/dfl_scripts/DFL_BACKUPS/current_backup/$f #копируем как есть в папку текущего бэкапа
cp /usr/dfl_scripts/dflbackup/$f /usr/dfl_scripts/DFL_BACKUPS/old_versions/${f%.bak}_$now.bak #копируем с датой в папку свалки всех конфигов
done
cd /usr/dfl_scripts/DFL_BACKUPS #переходим в папку svn проекта
svn add * --force -q >> /usr/dfl_scripts/log.txt #добавляем новые файлы. и пишем в лог.
svn commit -m "added backups $now" >> /usr/dfl_scripts/log.txt #коммитим и пишем в лог
/usr/bin/mail it@mydomain.ru < /usr/dfl_scripts/log.txt -s "Отчет о бэкапах DFL" #и отправляем письмо с лог-файлом на почтуСкрипт запихнут в cron и запускается в 8:30 утра ежедневно. Вот так выглядит crontab:
30 08 * * * /usr/dfl_scripts/autobackup.sh
30 06 * * * /usr/dfl_scripts/ciscobackup.sh
00 06 * * 1 /usr/dfl_scripts/fireboxbackup.shТеперь про cisco
На самих устройствах настроено что-то вроде этого:
archive
log config
logging enable
logging size 500
hidekeys
path ftp://ftp.mydomain.ru/in/autolog/$H-$T
write-memory
ip ftp username user
ip ftp password mypass
ip scp server enableВ итоге, по команде write-memory текущая конфигурация сбрасывается на ftp. У меня ftp находится на другом сервере, чем сборище автобэкапов. Тут 2 пути: сделать и на том сервере копию репозитория и добавлять конфиги там или копировать конфиги на соседний сервер. В принципе, вся разница в том, делать cp или scp.
На директорию, куда падают конфиги с cisco, я сажаю incron следить за появлением файлов. По появлению файла – переименовываю его как надо и копирую на сервер-сборщик автобэкапов во временную директорию. По отсечке, файлы из временной директории заливаются в svn. Итого я имею в системе контроля версий актуальный конфиг на определенное время раз в день. На мой взгляд, этого достаточно, но система без проблем модифицируется под любые хотелки.
Конфигурация incrontab выглядит так:
/var/ftp/cisco/in/autolog/ IN_CREATE /usr/ftp_scripts/incron_cisco.sh $# $%Сам скрипт:
#!/bin/bash
if [[ $2 == "IN_MOVED_TO" || $2 == "IN_CREATE" ]]; then
sleep 10
filial="${1%%-*}" #delete the longest substr -* search from the end of string. Обрезаем дату и оставляем только имя устройства
scp -P 2222 -i /usr/ftp_scripts/ssh_key_private /var/ftp/cisco/in/autolog/$1 go@10.10.10.220:/usr/dfl_scripts/ciscobackup/$filial.conf
fiНа сервере автобэкапов по расписанию запускается следующий скрипт:
#!/bin/bash
logfile=/usr/dfl_scripts/log_cisco.txt
rm $logfile
now=$(date +"%d_%m_%Y")
cd /usr/dfl_scripts/DFL_BACKUPS
cp /usr/dfl_scripts/ciscobackup/* /usr/dfl_scripts/DFL_BACKUPS/cisco/
svn add * --force –q >> $logfile
svn commit -m "added cisco backups $now" >> $logfile
/usr/bin/mail it@mydomain.ru < $logfile -s "Отчет о бэкапах cisco и watchguard"Как видно, тут речь еще и о WatchGuard Firebox. Мне было откровенно лениво делать для них отдельную директорию. Так что бэкапы падают на ftp туда же, куда и cisco. WatchGuard бэкапится отдельным скриптом на полчаса раньше и вообще раз в неделю. Обратите внимание, с версии прошивки 12 изменился синтаксис. Раньше это можно было делать одной командой backup image to ftp, а теперь добавился export. На нём я не смогла настроить логин через ssh по ключу, так что используются пароли.
#!/bin/bash
watchguards=( "10.10.10.20:password1"
"10.97.10.20:password2" )
now=$(date +"%Y_%m_%d")
for wg in "${watchguards[@]}" ; do
ip_addr="${wg%%:*}"
pass="${wg##*:}"
sshpass -p $pass ssh backupuser@$ip_addr -p 4118 << ENDME
backup image WG_$now.fxi
export image WG_$now.fxi 123456qQ to ftp://user:mypass@ftp.mydomain.ru/in/autolog/WG_$ip_addr-$now.fxi
ENDME
DoneУ WatchGuard файлы бинарники экспортируются только шифрованные, так что тут с текстовым видом и diff не очень получится. Обратите внимание на ключ шифрования: обязательный заглавные, строчные буквы и цифры, не менее 8 символов. При не соответствии просто не выполняется команда, конкретно не указывается, где ошибка.
Итак, всё сделалось. Теперь ставим клиента на свой рабочий комп под виндой. Просто посмотреть файлы и diff можно и из браузера, а вот скачать версию из определенной ревизии только из клиента. Ставим TorToSiteSVN с официального сайта.
На сервере создаем пользователя с необходимыми правами (на чтение) для филиалов.
Потом надо зайти в клиент через контекстное меню к любому файлу и подключиться к хранилищу. Себе копию хранилища создавать не обязательно, если вы не планируете вносить изменения в файлы. Ну и осторожнее с этим, с копией надо будет работать через систему контроля версий, а не просто как с куском файловой системы.
Чтоб заработали diff’ы на нестандартных тексовых файлах, надо сделать так, чтоб SVN считал эти файлы не бинарными, а текстовыми. Вот так:
svn propset svn:mime-type text/plain current_backup/*.bakЭту команду выполнить, например, под linux и после сделать commit.
Ну и вот изменения, смотрим глазками. Видим, что менялись правила firewall:
В браузере смотреть удобнее.
Если что стряслось, то админ может скачать нужный бэкап без лишних телодвижений на нужную дату.
Хотя, обычно, хватает последнего актуального.
В некотором роде, получилось изобретение велосипеда. Но оно работает на D-link DFL уже почти год, именно так, как мне надо, и иногда очень выручает.
Надеюсь, кому-то пригодится.
Ссылки:
Про rancid
WatchGuard Firebox CLI manual
Про oxidized
