К основному контенту

Oxidized. Резервное копирование конфигураций Mikrotik и не только


На днях переносил Oxidized со старенького сервера с CentOS 7 на актуальную Ubuntu, повспоминал нюансы с настройкой и решил написать небольшую заметку.

Oxidized позволяет сохранять конфигурации сетевых устройств, забирая их регулярно по ssh или telnet. Это гораздо удобнее, чем бэкапы скриптами с самих железок или какие-то самоприколоченные решения, т.к. все настраивается централизованно, а шаблонами можно изменять логику сбора конфигурации сразу для большого количества устройств.

Oxidized написан на Ruby. Устанавливается как служба и работает в фоне, периодически опрашивая указанные железки. По сути состоит из двух составляющих: самой службы и веб-части. Веб-интерфейс лишен аутентификации, поэтому сразу рекомендуется настроить обратный прокси хотя бы с базовой аутентификацией.

Основной экран со списком устройств и датами последних бэкапов

Сама служба скачивается как gem-пакет и устанавливается в глубинах системы, в которые лезть особенно не придется, если только не захочется что-то "допилить". Основная конфигурация сохраняется в домашнем каталоге пользователя в ~/.config/oxidized. Туда же можно добавить новые или измененные шаблоны.

Основные настройки задаются в файле ~/.config/oxidized/config. Наиболее важные параметры: source и output. Source определяет, где будет храниться список устройств для бэкапирования. Возможно использовать csv-файл, MySQL, SQLite. Output определяет, куда будут сохраняться бэкапы: Oxidized может просто создавать текстовики (1 файл на 1 устройство), отправлять данные по http и что самое крутое - сохранять в git-репозиторий. Последнее - просто незаменимая опция, если у вас периодически возникает вопрос: а что поменялось в конфиге за последние несколько часов/дней/месяцев? Инструмент для сравнения встроен прямо в веб-часть, так что сопоставить пару бэкапов с интервалом в несколько дней или недель крайне просто. По-умолчанию Oxidized хранит всю историю (как и положено в git).

Экран с логом бэкапов из git

Сервис развивается, и хотя документация по-прежнему не очень богая, особенно для новичка, разобраться можно без необходимости лезть в код. Шаблоны тоже дорабатываются, добавляются новые. В общем, разработка потихоньку продолжается. Из коробки сервис умеет создавать резервные копии устройств:
  • Mikrotik (есть поддержка ROS v7 в части нового синтаксиса отображения паролей в конфиге, SwOS),
  • коммутаторов D-Link (правда не всех),
  • Cisco (iOS, ASA и т.д.),
  • Brocade,
  • Frotigate,
  • Juniper,
  • pfSense,
  • TPLink,
  • Ubiquiti (не Unifi, а именно Edge линейки и AirOS),
  • Zyxel (ndms в Keenetic 2 версии и старше, коммутаторы, но не ZyWALL)
Немного покопавшись в уже имеющихся шаблонах, вполне можно написать свой. Oxidized позволяет выполнять постобработку конфига, удаляя ненужные строки. Например, последние записи лога или пароли. Для последних здесь даже есть системная переменная remove_secret. Если ее значение учитывается в шаболоне, можно глобально устанавливать предпочтения: сохранять конфигурации с секретами или без. Например, с Mikrotik это точно работает.

Раньше я использовал Oxidized только для Mikrotik, но сейчас начинаю пробовать подключать и другие устройства, так как хранить конфигурации для быстрого восстановления или анализа изменений оказалось очень удобным.

Комментарии

Популярные сообщения из этого блога

В чем разница между частотами russia, russia2, russia3 и russia4 в Mikrotik.

Для большинства пользователей WiFi бывает только 2,4 ГГц и 5 ГГц. Если кто-то еще и слышал о стандартах вроде b/g/n/ac, то уж про каналы почти никто не знает, а про частоты — тем более. К счастью, мы с вами (я надеюсь) разбираемся в вопросе лучше простых пользователей, а значит должны настраивать оборудование правильно. С начала года все ввозимые на территорию РФ устройства Mikrotik с поддержкой WiFi залочены на Country: russia3. Увидеть это можно, если открыть свойства беспроводного интерфейса, нажать на кнопку Advanced Mode/Simple Mode и оценить поля Frequency Mode и Country. Наиболее простым и понятным вариантом здесь является regulatory-domain, т.е. на основе законодательства страны, выбранной в поле Country. Это гарантированно избавит вас от возможных проблем с радиочастотными службами и подбором силы излучения передатчика. Напомню, что для России максимально разрешенным является уровень излучения 20 dBm или 100 мВт. Устанавливая значение передатчика больше умышленно, вы не...

Кратко и понятно о SR-IOV

Эту статью я публикую с целью лишь познакомить читателя с самим фактом существования технологии SR-IOV, а не с тонкостями настройки Hyper-V или сетевых адаптеров. Я сам впервые столкнулся с ней, и потратил много времени, чтобы понять, что к чему, такого очень краткого ликбеза мне не хватало. В связи с запуском новых серверов и переходом на 10 Гбит/с. решил поразбираться с SR-IOV. После прочтения пачки статей сложилось поверхностное понимание того, что это и как им пользоваться. И почему после установки галочки «Включить SR-IOV» в свойствах сетевого адаптера ВМ в Hyper-V магии не случается. Сразу отмечу, что пытаться запустить ее на 1Гбит/с. нет смысла. Не все адаптеры это поддерживают, да и толку будет мало. SR-IOV (Single Root Input/Output Virtualization) — технология виртуализации части аппаратных функций хоста, которая позволяет предоставлять виртуальным машинам прямой доступ к ним. По сути, насколько я понимаю, это еще один механизм оптимизации виртуализации вроде Intel VT-x...

Проблема в Zabbix: Ping loss is too high при больших задержках

Столкнулся с интересной проблемой, до сути которой докопался как-то не сразу, хотя решение в итоге вышло простым. После настройки мониторинга резервных каналов связи на объектах Zabbix стал регулярно ругаться, что на этих элементах большие потери пакетов, хотя по факту их не было. Зато были задержки: по 900 и более мс. Попытавшись как-то потюнить сам Zabbix, начал копать глубже, в результате чего выяснилось, что простые проверки, реализованные в частности в дефолтном шаблоне системы Template ICMP Ping, опираются на fping с параметрами по-умолчанию, что описано в данной статье . То есть если ответ на ICMP запрос не получен в установленное время, пинг считается потерянным. В моем случае zabbix 3.0 и fping 3.8 значение таймаута по умолчанию составляет 500 мс, что явно меньше того, что требуется. Увеличить это можно в самих настройках шаблона, указав в элементе ICMP loss ключ icmppingloss[,,,,3000], где 3000 - искомый таймаут (тут каждому свой, я установил 3000 для компенс...