админы неплохие люди. Я там вон сверху написал, «хочу поделиться вариантом установки». Ещё вопросы? Я не думаю, что можно автоматизировать установку с офф дистрибутива, скажем сразу на 80 нод, а тут можно.
Идея выбора бэкапа меня заинтересовала, кажется разумной.
Идея скрещивания функционала системы мониторинга с системами резервного копирование — не очень. Ну как-то это не то, я думаю, что какие-то действия при триггерах настроить через Zabbix(Nagios отрицаю) можно, к примеру как переключение на резервный канал, выключение интерфейса и.т.д., но очень странно слышать про бэкап.
как раз отдал людям в прод, не считаю глупостью или чем-то таким. У всех свои бюджеты, я просто помог людям задаром ради интереса.
А преемник, ну тут достаточно просто виртуалку выключить или cron-джобы убрать и всё(я думаю разберутся).
Это просто виртуалка, в которой специальный пользователь работает по ssh, и вообще ничего криминального не вижу в этом.Работает это и с CCR и CCS, и с более простыми моделям и вообще не обламывается.
По мне так лучше писать скрипты, чем не писать. Инфраструктуры переменчивы и я думаю, что это вполне практичный скрипт для простого бэкапа. Мне и людям достаточен более чем.
на устройстве у вас тогда будет лежать скрипт с паролем в обычном тексте, который видно даже от аккаунта readonly. А FTP должен быть открыт и принимать соединения от кого попало по сути.
В моём решении достаточно чтобы устройство было доступно по ssh для создания и копирования бэкапа. Ничего городить и открывать не надо и пароли нигде не светятся.
кто ж спорит, умеет. Это ещё один коммент вида habrahabr.ru/post/342060/#comment_10517694
Никто не спорит, что это есть, в примерах это тоже есть и я об этом написал.
Так же я написал почему это не стал использовать и почему это централизованный бэкап. При любом изменении вы будете на каждом микротике всё перенастраивать? Для моего скрипта разницы нет, какие там пароли на устройстве, — он авторизуется по ключу.
К тому же надо сервер FTP держать, а зачем?
ну круто, да, комплексная управлялка.
А вы подумали, уместна ли она везде? Вот прям везде, где у вас только, к примеру, микротик, который туннели в дц поднимает, а остальное вас не интересует?
Такие вещи уместны более в достаточно серьёзных сетях. Тут рассматривается нечто иное.
файлы — без проблем. А пользователей никак не вытянуть.
Пользователь на устройстве микротик не вытягивается никак(насколько я знаю). Да и смысла особого нет его вытягивать, можно написать скрипт, который его так же создаст, задаст пароль и наимпортирует ключей.
Касательно файлов на устройстве — в самом скрипте это уже делается. Когда создаётся бэкап, он кладётся на устройство, а потом с устройства копируется, и сразу же удаляется, ибо если они накопятся, то места под новые бэкапы уже не будет.
создаётся, копируется, удаляется:
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
не знаком с руби, да и не хочу быть знаком.
Тут ещё и в простоте дело, всё с минимумом зависимостей на обычном ssh, единственное это openssl, что надо ставить.
Идея скрещивания функционала системы мониторинга с системами резервного копирование — не очень. Ну как-то это не то, я думаю, что какие-то действия при триггерах настроить через Zabbix(Nagios отрицаю) можно, к примеру как переключение на резервный канал, выключение интерфейса и.т.д., но очень странно слышать про бэкап.
А преемник, ну тут достаточно просто виртуалку выключить или cron-джобы убрать и всё(я думаю разберутся).
Это просто виртуалка, в которой специальный пользователь работает по ssh, и вообще ничего криминального не вижу в этом.Работает это и с CCR и CCS, и с более простыми моделям и вообще не обламывается.
По мне так лучше писать скрипты, чем не писать. Инфраструктуры переменчивы и я думаю, что это вполне практичный скрипт для простого бэкапа. Мне и людям достаточен более чем.
В моём решении достаточно чтобы устройство было доступно по ssh для создания и копирования бэкапа. Ничего городить и открывать не надо и пароли нигде не светятся.
Никто не спорит, что это есть, в примерах это тоже есть и я об этом написал.
Так же я написал почему это не стал использовать и почему это централизованный бэкап. При любом изменении вы будете на каждом микротике всё перенастраивать? Для моего скрипта разницы нет, какие там пароли на устройстве, — он авторизуется по ключу.
К тому же надо сервер FTP держать, а зачем?
А вы подумали, уместна ли она везде? Вот прям везде, где у вас только, к примеру, микротик, который туннели в дц поднимает, а остальное вас не интересует?
Такие вещи уместны более в достаточно серьёзных сетях. Тут рассматривается нечто иное.
Пользователь на устройстве микротик не вытягивается никак(насколько я знаю). Да и смысла особого нет его вытягивать, можно написать скрипт, который его так же создаст, задаст пароль и наимпортирует ключей.
Касательно файлов на устройстве — в самом скрипте это уже делается. Когда создаётся бэкап, он кладётся на устройство, а потом с устройства копируется, и сразу же удаляется, ибо если они накопятся, то места под новые бэкапы уже не будет.
создаётся, копируется, удаляется:
Тут ещё и в простоте дело, всё с минимумом зависимостей на обычном ssh, единственное это openssl, что надо ставить.
Нет веба, баз данных — нечему ломаться
Про бэкап лицензии в первый раз слышу, а зачем?
Работает ещё и для сборки пакетов из aur с repo.archlinux.fr
там ещё есть powerprill, но я ниасилил :)