Автобэкапы сетевого оборудования и хранение их в системе контроля версий

Уточнение: решение настроено для 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, чтоб у нас появился клиент:

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

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 14

    0
    На мой взгляд не оптимальное решение.
    во-первых не любое сетевое оборудование имеет возможность авторизации по ключу.
    во-вторых если делать, то делать все единообразное, для простоты поддержки. У Вас же получается что часть по ftp, часть другим образом. Да и использование у cisco только сохраненную конфигурацию не оптимально.

    Сам давно использую самописный скрипт на expect, который просто сохраняет текущий sh run, с помощью cvs организована работа с версиями, ну и viewvc как веб-интерфейс.
    В итоге получилось универсальное решение с поддержкой практически любого оборудования, где возможно посмотреть конфиг по ssh (cisco, hpe, juniper, mikrotik, и пр.).
    Все крутится на Linux, скрипт запускается по крону в качестве аргумента файл со списком серверов, что позволяет иметь несколько списков и разные устройства опрашивать с разным периодом. При изменении конфигурации отправляется письмо на почту.
    Ну и для большей секурности, для авторизации, использую сервер Tacacs+, и пользователь который собирает конфиги ограничен в правах и может только конфиг посмотреть.
      0
      Безусловно, решение не претендует на оптимальное, и оправдывает его использование на работе только достаточная степень задокументированности. Однако, как не каждое устройство поддерживает логин по ключу, так и не каждое устройство позволяет скачать конфиг пользователю с правами на чтение (DFL и WatchGuard не позволяют), а с вывода на экран восстанавливать построчно — занятие на любителя (у D-link DFL нельзя вывод сохранить как конфиг и залить обратно, например). Так что и в вашем решении есть минусы, хотя, оно, вероятно, более оптимально, чем моё на классическом оборудовании.
      За Tacacs+ спасибо, не знала, это интересно.
        0
        во-первых не любое сетевое оборудование имеет возможность авторизации по ключу.

        Даже больше скажу — не любое оборудование имеет возможность авторизации по ssh. В нашей сети до сих работает примерно три сотни D-Link 3526 (те, которые могли сдохнуть, уже сдохли и были заменены, но оставшиеся какие-то неубиваемые), к которым уже по ssh не подключишься без танцев с бубном. И некоторое количество оптических приёмников и усилителей, у которых ssh нет в принципе — только telnet, web и snmp (ну и ещё консольный порт для первоначальной настройки).
        +1

        git + git LFS и у вас диффы бинарников

          0

          Даже без lfs git хранит бинарники как диффы после gc. И вроде бы, даже при передаче отправляет сразу диффы.

          0

          Велосипед, лучше смотрите на https://en.wikipedia.org/wiki/RANCID_(software) и его клоны

            0
            Признаюсь честно, до того, как я села писать пост, я не знала про rancid и oxidized. Но они оба не умеют то, что нужно мне в полном объеме. Первый заточен на cisco и со всякой экзотикой работает не очень, второй не имеет авторизации пользователей (хотя это обходится несложными манипуляциями с web-сервером)
              0
              Посмотрите на коментарии ниже + посмотрите на том же специализированном форуме forum.nag.ru
            0
            Ни разу не реклама, да собственно и тут разработчик уже отписывался. Где-то с год уже юзаем в боевом режиме cbackup. Сейчас обкатываем на зоопарке из ~150 свитчей SNR, cisco, Dlink, Qutech, Mikrotik, Eltex предвидится еще +300-400
            Почти без допилинга, из коробки уже доступен git контроль версий, как локальный так и в облако.
            Пока все как часы, проблем замечено не было, система работает как часы, пока все устраивает.
            Правда продукт подзаброшен разрабами, последнее ядро 2018 года.
              0

              Я бы вам предложил посмотреть Noc Project.
              Кроме всего прочего он умеет снимать конфиги с широкого диапазона различных устройств, оповещать об изменениях и разумеется хранить и сравнивать конфиги на разные даты.

                0
                +1
                  +1
                  Спасибо, обязательно посмотрю. И по остальным советам выше тоже.
                  +1

                  Судя по всему большую пользу автору принесла сама разработка решения, чем результат, советовать смотреть готовые решения не буду. Добавлю разве что имеет смысл обратить внимание на содержимое конфигов, существует вероятность получить битый файл. Делал сам подобное, дифы отправлялись ежедневно по почте, плюс репорт, что не забекапилось. Кроме того посоветую брать просто список всех хостов, хоть из DNS, а уже тип железки определять по SNMP или по другим повадкам, автоматизация же!

                    0
                    Достойно уважения! Как раз думаю о том, что неплохо бы хранить бэкапы оборудования, но думал в сторону внедрения этой фичи в биллинг

                    Only users with full accounts can post comments. Log in, please.