Комментарии 26
Можно делать без пароля:
dont-encrypt=yes
Пользователь на устройстве микротик не вытягивается никак(насколько я знаю). Да и смысла особого нет его вытягивать, можно написать скрипт, который его так же создаст, задаст пароль и наимпортирует ключей.
Касательно файлов на устройстве — в самом скрипте это уже делается. Когда создаётся бэкап, он кладётся на устройство, а потом с устройства копируется, и сразу же удаляется, ибо если они накопятся, то места под новые бэкапы уже не будет.
создаётся, копируется, удаляется:
T_BKPSTR="system backup save name=$TGT_BKPNAME_BIN dont-encrypt=no password=$BKP_BINPWD"
T_BKPCLN="file remove [find name=$TGT_BKPNAME_BIN]"
$SSH_STR $T_BKPSTR # Initializing backup
sleep $IDL && $SCP_STR # Copy file to storage
sleep $IDL && $SSH_STR $T_BKPCLN # Remove created file on mikrotik
1. либо явно прописывают системный путь, т.е. /bin/ln, /usr/bin/env…
2. либо меняют текущий PATH
У вас ничего из перечисленного не происходит, CMD_CHO etc затрудняют чтение и не добавляют функциональности.
У нас используется сервер мониторинга Nagios, в конфигах которого (текстовых) описаны разные железки, которые мониторятся. Так-же есть скрипт, который смотрит эти конфиги, и, в зависимости от типа устройства, вызывает тот или иной способ получения бекапа (через ssh, telnet, wget). Скрипт может быть запущен вручную, через cron или как сервис самого Nagios. Собственно сами резервируемые конфиги устройств ложатся в каталог /etc/backups/ на сервере мониторинга с установленным пакетом etckeeper, который в свою очередь коммитит их в git репозиторий и отправляет красивое письмо и нотифай в Telegram об изменениях.
Идея скрещивания функционала системы мониторинга с системами резервного копирование — не очень. Ну как-то это не то, я думаю, что какие-то действия при триггерах настроить через Zabbix(Nagios отрицаю) можно, к примеру как переключение на резервный канал, выключение интерфейса и.т.д., но очень странно слышать про бэкап.
Мониторинг по пингу включен на всех железках. Грех не использовать этот полный список.
Указываем в мониторинге тип железки, а в скрипте бекапа — смотреть на этот тип, ну и соответственно вызывать тот или иной алгоритм скачивания конфига. Что-бы не потерять что-то, проще вести единую базу.
И чего только люди не придумают, чтобы не ставить Noc.
А вы подумали, уместна ли она везде? Вот прям везде, где у вас только, к примеру, микротик, который туннели в дц поднимает, а остальное вас не интересует?
Такие вещи уместны более в достаточно серьёзных сетях. Тут рассматривается нечто иное.
Я соглашусь, что возможны ситуации когда админу наплевать на варианты типа "выполнить не удалось; повторить через час".
Бывает что им не нужна история или историю они делают через mkrtk_22.`date +%s`.txt
Бывает что потом когда на сети появляется еще один вендор эти админы разводят руками и говорят "ой мой скрипт перестал работать напишу еще один" и заканчивают с 15 вендорами и богатым кроном.
Все эти варианты вполне…
Верно. больше хороших штук. Только в проде не оставляйте как наиграетесь. Пожалейте приемника ему же это поддерживать, а он ни в чем не виноват…
А преемник, ну тут достаточно просто виртуалку выключить или cron-джобы убрать и всё(я думаю разберутся).
Это просто виртуалка, в которой специальный пользователь работает по ssh, и вообще ничего криминального не вижу в этом.Работает это и с CCR и CCS, и с более простыми моделям и вообще не обламывается.
По мне так лучше писать скрипты, чем не писать. Инфраструктуры переменчивы и я думаю, что это вполне практичный скрипт для простого бэкапа. Мне и людям достаточен более чем.
Я вот жалею человека, которому после меня достанется нок. Он просто сетевой админ и ни в чём не виноват. Скрипт бы он поправил, а вот с ноком...
Печально, что не видно вменяемых альтернатив.
Можно и через expect какой-нибудь, удобно если на железках разные пароли
что-то типа такого
#!/usr/bin/expect
set remote_server [lindex $argv 0]
set my_password { pass1 pass2 pass3}
spawn ssh user@$remote_server
expect {
"(yes/no)?*" {
send "yes\n"
}
}
set try 0
set timeout 1
expect {
"*word:*" {
if { $try>3} {exit 1}
send [lindex $my_password $try]\r
incr try
exp_continue
}
}
set timeout 15
expect " > "
send "/export compact file=\"file.log\"\r"
expect " > "
send "/tool fetch address=\"IP_ADDR_FTP\" src-path=\"file.log.rsc\" user=\"config\" mode=ftp password=config dst-path=\"file.log.rsc\" upload=yes\r"
expect " > "
send "\n"
expect " > "
send "quit\r"
Никто не спорит, что это есть, в примерах это тоже есть и я об этом написал.
Так же я написал почему это не стал использовать и почему это централизованный бэкап. При любом изменении вы будете на каждом микротике всё перенастраивать? Для моего скрипта разницы нет, какие там пароли на устройстве, — он авторизуется по ключу.
К тому же надо сервер FTP держать, а зачем?
В моём решении достаточно чтобы устройство было доступно по ssh для создания и копирования бэкапа. Ничего городить и открывать не надо и пароли нигде не светятся.
Централизованный бэкап Mikrotik устройств при помощи bash-скрипта