Комментарии 71
3.быть уверенным в том, что они отработал без ошибок или узнать о том, что конфиг выполнился не корректно.
В другом случае, код бы стал слишком загроможденный ямликами, чтобы получить ответ, что все хорошо.
sudo chmod +x newsh1.sh
sudo ./newsh1.sh
Не сидите под рутом, говорили они, отключайте рута на ссш, говорили они…
Согласен. А вместо портянок на баше пишется шаблон на jinja2 и потом к нему применяется шаблонизатор с параметрами. Плюсы — даже не специалист разберётся что там поправить, нет уродливых и ненадежных конструкций с sed/awk, можно обойтись без промежуточных файлов (если кормить выхлоп шаблонизатора через пайп куда угодно). Минусы — надо ставить jinja в систему, но, внезапно, она там обычно есть, вместе с интерпретатором python
А ещё для пакетной загрузки файлов по фтп except не нужен.
Уважаемые, коллеги-сетевики! Вместо того, чтобы рожать кадавров — посмотрите вокруг и поспрашивайте знакомых, программистов — как можно решить задачу красивее, эффективнее, надёжнее
нет уродливых и ненадежных конструкций с sed/awk
ммм, как-то вы радикально…
пару десятков лет работают скрипты и ничего не глючит
То что написано — переписывать уже не нужно. Это наше достояние, наследие )
Но новое — лучше писать на надежном, простом фундаменте. Забор из sed/awk'а в принципе нечитаем, неудобно его поддерживать, а еще нужно понимать, что многие не умеют в один проход подставить значения. Нужно еще держать в голове — in-place редактирование файла или нет. Сложную шаблонизацию на них (с циклами, всякими хитрыми подстановками и пр.) в принципе сделать очень больно. Но… Каждому свое )
Единственный плюс у sed/awk в том, что это проверенные временем мощные утилиты, которые есть почти везде. Но на этом преимущества и заканчиваются.
Если речь дошла до автоматизации, почему выбран microtik, а не cisco?
Сколько неговорил с сетеваками один негатив от микротика
- Какая связь между автоматизацией и выбором типа оборудования?
- По соотношению цена/качество микротик лучше виски. Да, продукт со своими недостатками. Но задачи выполняет и обходится существенно дешевле. Кому-то нужно 99.99999% и там свои решения, кому-то достаточно 99.99% или даже 99.9% и там микротик уже ничем не хуже.
p.s. А есть ещё отличная шутка, когда стоит железа на дохриллион долларов, резервные каналы, отдельные вводы и всё такое, дублирующие дизеля,… а потом пара экскаваторов одновременно на удалении в километр+ от датацентра умудряются порвать и основную и резервную оптику, а возможно сразу и резерв резерва порвут… ;)
Netwatch — очень облегчает жизнь, если модем подвисает то ребутает его скриптом(netwatch функционал Mikrotika). Мониторинг Zabbix написано очень много для него шаблонов.
У меня Микротик с LTE (SXT LTE Kit) ровно один :) И всё не могу понять — 3-4 подвисания LTE-интерфейса в сутки (тем самым netwatch по пропаданию пинга до 1.1.1.1 дёргается скрипт, который делает /interface lte disable lte1, потом /interface lte enable lte1 и шлёт отчёт о содеянном на почту, — ребутать дольше) — это для него нормально? Смотрит в упор на вышку в 650 метрах прямой видимости от себя, так что это не проблемы с качеством сигнала. Или это уже проблема с железом?
И всё не могу понять — 3-4 подвисания LTE-интерфейса в сутки (тем самым netwatch по пропаданию пинга до 1.1.1.1 дёргается скрипт.
Какой-то топорный подход. В корне неправильный. Это же беспроводная связь. Потери пакетов там — это нормальная ситуация, а вы, зачем-то, интерфейс перевключаете по этому событию. Какой в этом принципиальный смысл? Он сам заработает, если ему не мешать.
Собственно, я и начал решать проблему именно обнаружив, что связи с модемом по LTE нет уже пару дней (канал резервный, нужен раз в месяц, отдельно его не мониторил — а тут отвалился основной, а раз — резервного-то тоже нет). Ребутнул — связь появилась тут же. Сначала поставил watchdog, который тупо делает ребут, потом поменял на netwatch, который дёргает кастомный скрипт и рестарт интерфейса без ребута.
У netwatch задаётся интервал, в течение которого он пытается достучаться до хоста, прежде чем сделать вывод о его недоступности. Если ставить 5 секунд и более — то это уже точно не обычные потери.
Если городить такой огород, то уж лучше по событию registration-status: !registered
А ещё лучше обновиться до последней stable.
И обновить модем
/interface lte firmware-upgrade lte1 upgrade=yes
Думаю все проблемы и так уйдут.
registration-status, что характерно, при большинстве таких зависаний остаётся registered, и лишь изредка unknown. Но мысль понял, позаписываю вывод "/interface lte info lte1 once" до/после возникновения проблем, попробую поймать, что конкретно является корректным признаком ситуации «вот сейчас точно зависли»
P.S. Я не настоящий микротикщик :), эту железку взял просто потому, что в таком форм-факторе и ценовом диапазоне выбора не было. И вот на её примере первый раз в жизни Mikrotik осваиваю. И сильно ругаюсь после Ubiquiti :)
registration-status, что характерно, при большинстве таких зависаний остаётся registered
Я и не удивлен, потому что если модем остается подключен, то он сам заработает, когда оператор восстановит транзит или связь чуть улучшится. Последите тогда ещё за functionality: full
И на заметку, если модем реально подвис, то переключение интерфейса ему не поможет, нужно снимать питание:
/system routerboard usb power-reset duration=10
В вашем случае самое простое это, если уж так хочется использовать netwatch, то делайте проверку после status: down на netwarch, что functionality: !full и registration-status: !registered. И желательно секунд 20-30 спустя. Так как если связь сразу восстановится вы не получаете около минутный перерыв связи на включение и выключение, поиск оператора и регистрацию.
Пока ситуация и так устраивала, ибо канал сугубо резервный и шансы, что проблемы с основным каналом и зависание LTE на этом модеме совпадут по времени, крайне невысоки. Главное, чтобы он не зависал надолго и не оказался недоступен ни с какой стороны как раз в тот момент, когда понадобится.
Но перфекционизма ради, безусловно, хочется разобраться окончательно и сделать всё правильно.
А ещё лучше обновиться до последней stable.
Stable уже не совсем stable. Они в какой то момент всё передвинули и сейчас лучше сидеть на — long-term.
Я придерживаюсь следующей стратегии, при выходе новой минорной версии на stable дождаться х.х.1, тогда проблем точно не будет.
Один раз, по совету саппорта микротика, пришлось мигрировать на «testing», в связи с проблемами с только что разработанным железом, и долго на ней работал и то ничего не случилось.
Зачем выбрали OpenVPN? Да ещё over TCP (ибо поверх UDP ovpn в микротике не поддерживается). Работать, конечно, будет, но на плохом соединении (как вы сами и писали) инкапсуляция в TCP начнёт совсем всё портить, а вы до кучи рискуете ещё и что-то типа tcp retransmit storm получить, когда из-за потери одного tcp пакета туннеля у вас начнут тормозить и слать горы ретрансмитов все tcp сессии внутри тоннеля.
p.s. Да, знаю про 7ю версию с ovpn over udp, но она ещё не production-ready.
А как это относится к вопросу OpenVPN: UDP vs TCP?
Просто если так рассуждать, то надо вообще SSTP поднимать )
В RouterOS всего два тунельных клиент-серверных протокола, позволяющих задать порт вручную, чтобы обойти блокируемый номер порта на транзите. Другие типы VPN из набора, либо не позволяют поменять порт, либо не позволяют подключатся без двух реальных адресов на концах.
Это SSTP(TCP) и OpenVPN(TCP).
Так вот SSTP не прокачивает больше 11 Mbit/s на ходовых однопроцессорных моделях и его работа упирается куда-то ещё, кроме как в работу процессора. Куда? Непонятно. OpenVPN не то чтобы далеко ушел, но 20 Mbit/s можно выжать.
К слову из-за userspace OpenVPN может грузить только дно ядро, если их больше одного.
Я SSTP упомянул не в ключе UDP, а в ключе "маскировать трафик под легитимный, например, https"
Касательно OpenVPN TCP — tcp amplification/pollution или как оно там называется — я в курсе.
Другие типы VPN из набора, либо не позволяют поменять порт, либо не позволяют подключатся без двух реальных адресов на концах.
Насчет микротика не в курсе, но, во-первых, как минимум, нужен реальный адрес на одном конце (например, IPSec — легко). А вообще — можно туннель и с двумя "серыми" адресами, но там начинаются пляски со всякой дичью типа STUN, т.е. работает будет… далеко не всегда и будет зависимость от фаз луны и положения марса )
не прокачивает больше 11 Mbit/s на ходовых однопроцессорных моделях и его работа упирается куда-то ещё, кроме как в работу процессора
А часто ли ходовые однопроцессорные модели стоят на канале > 100MBit, а по факту даже — 5-10MBit, учитывая, что для юриков интернет весьма дорогой?
А вообще — можно туннель и с двумя «серыми» адресами, но там начинаются пляски со всякой дичью типа STUN, т.е. работает будет… далеко не всегда и будет зависимость от фаз луны и положения марса )
Есть только единственный вариант, где заработает схема с двумя серыми адресами на концах. Это когда оператор NAT`ит один к одному, серый в белый. И трансляции отрываются как со стороны интернет, так и с внутренней стороны. Это уже не является, образно, серой адресацией, т.к. по факту это обычный реальник. В этом случае будет достаточно воспользоваться встроенным /ip cloud, который среди прочего является ddns клиентом. И по этому доменному имени подключаться. Будет работать без проблем, без всяких бубнов.
А часто ли ходовые однопроцессорные модели стоят на канале > 100MBit, а по факту даже — 5-10MBit, учитывая, что для юриков интернет весьма дорогой?
Я бы не мешал в одну кучу LTE, с которого началось обсуждение, где совсем другие задачи и каналы не "> 100MBit". И юридических лиц, где реальник и скорости лишь проблема тарификации. В первом случае безраздельно властвует OpenVPN. Во втором случае лучше IPsec ещё ничего не придумали. В большом количестве микротиков есть аппаратная поддержка шифрования. Там можно нагрузить и очень широкие каналы. Гигабит — не предел.
FTP оно говно мамонта конечно, но рядом с микротиком выглядит вполне гармонично.
Опять же, со слов автора (я не умею в микроты), применять команды из загруженонго конфига можно только при загрузке этого конфига по FTP. Хотя мне кажется что scp/sftp тоже вполне сгодятся, но я не копенгаген, да.
А вот что удивляет в 2019, так это использование expect
мне кажется вся та простыня в newsh2.sh (названия скриптов отдельно умиляет) прекрасно заменяется одной строчкой типа:
curl -T config1.txt ftp://microtik1 --user=user:pssw -sS || 2>mikrotik1.err
Хотя конкретно для этой задачи уместней ансибл. Правда с ансиблом так
пару десятков лет работают скрипты и ничего не глючитне получится.
Оно слишком быро развивается и многие параметры уходят в deprecated. И зависимость от переменных окружения дикая.
С expect тоже не получится. Не обманывайте себя. Любой скринскрэйпинг — зло. Нельзя на нем автоматизацию строить
curl -T config1.txt microtik1 --user=user:pssw -sS || 2>mikrotik1.errСпасибо буду знать.
В RouterOS можно автоматически выполнять скрипты (ваш файл скрипта должен иметь вид- имя.auto.rsc). После того, как файл будет загружен с помощью FTP на маршрутизатор, он будет автоматически выполнен, как и с командой '/import' (этот метод работает только с FTP).
Опять же, повторюсь, с микротиками не знаком, пожтому не сильно минусуйте есличто, но что мешает выполнить ваш скрипт после загрузки на устройстве отдельной командой:
/import file-name=имя.auto.rsc
ну т.е. ансибл сценарий грубо такой:
tasks:
- name: config upload
net_put:
src: {{ cfg_filename }}
protocol: sftp
- name: apply config
routeros_command:
commands: /import {{ cfg_filename }}
Ftp по умолчанию не безопасен. Пароль перехватить — раз-два.
Может sftp или ftps, всё-таки ?
В RouterOS можно автоматически выполнять скрипты (ваш файл скрипта должен иметь вид- имя.auto.rsc). После того, как файл будет загружен с помощью FTP на маршрутизатор, он будет автоматически выполнен, как и с командой '/import' (этот метод работает только с FTP).Моя не знать как вам еще объяснить.
Как только файл загружен, он автоматически выполняется. Информация об успешности выполнения команд записывается в имя.auto.log
FTP небезопасный в конце концов.А если все в ovpn завернуто с сертификатами? Или вы в серьезе думаете по FTP в интернете кидать это?
Баг-репорт, надеюсь, отправили ?
Automatic Import
In RouterOS it is possible to automatically execute scripts — your script file has to be named anything.auto.rsc — once this file is uploaded using FTP to the router, it will automatically be executed, just like with the '/import' command. This method only works with FTP.
Once the file is uploaded, it is automatically executed. Information about the success of the commands that were executed is written to anything.auto.log
Тут описан механизм.
Вряд ли у меня есть шансы.
Знаете, что меня смущает… Выглядит как крутая штука, когда реально нет никаких других возможностей настроить микротик, есть проблемы со стабильностью канала и пр. (я сам в первую очередь поклонник максимально надежных процессов), но вот интересно — если был обрыв связи по FTP, то может ли микротик случайно запустить половинчатый auto.rsc файл? А если их несколько качается в одном сеансе связи? Наверняка разработчики задумывались об этом (хотя не факт — ту же имплементацию OpenVPN over UDP их умоляли ГОДЫ реализовать, а совместимость IPIP-IpSec у микротика с другими корпорат.железками не на уровне 100%, тот же strongswan более надежен), но вот в доке ответа я при беглом просмотре не нашел.
Ну, и я не понимаю, чем хуже двухшаговый вариант (загрузка скрипта + /import) по сравнению с автостартом скрипта после загрузки.
Я никогда таким способом не пользовался, т.к. в dude есть намного более мощный и бесплатный механизм для работы с конфигурациями. Взять хотя бы очень интересную опцию как работу с оборудованием не доступным по l2/l3 от точки управления, но вполне доступным через цепочку mikrotik`ов и им мы через dude можем отправить команды или считывать телеметрию. Можно нечто подобное реализовать на ansible?
1) Why auto import * .auto.rsc works just under FTP protocol and not work for sftp / scp.
2) Is there any plans for deploy sftp / scp auto import?
3) Is there some mechanism for handle upload errors like session disconnect and * .auto.rsc is not upload completely?
4) Is there some mechanism for error handling content of * .auto.rsc in case of some wrong syntacsis.
По факту несколько часов назад выкатили stable 6.46.1. Там есть пункт:
*) system — fixed "*.auto.rsc" file execution (introduced in v6.46);
Так вот я обновился, проверил, scp/sftp auto import все ещё не работают.
Плюс фишка auto.rsc. если конфиг который отправили с ошибкой, то весь скрипт откатиться и даст лог(не вкрячится в состоянии полтора). Там очень много тонкостей.
В первом же комментарии указали на то что, сейчас целесообразно сразу начинать использовать современные инструменты. Инфраструктура как код ( ansible + git) это действительно правильный, современный подход. А то что показал в статье автор, похвально, но я извиняюсь, так делали 15 — 20 лет назад, когда не было никаких инструментов автоматизации, и каждый админ, на своих коленках писал как мог. Сейчас на это нет смысла тратить время.
Автору — попробуйте все таки ansible, вам понравится.
SFTP was already working for a while but got broken in latest RouterOS versions. v6.47beta upcoming releases will contain a fix for the problem.
Best regards,
Mārtiņš S.
Скудненький ответ. Но хоть что-то. Будет значит нам sftp. Просто со временем.
Автору — попробуйте все таки ansible, вам понравится.
начать можно отсюда mum.mikrotik.com/presentations/RU16/presentation_3841_1476092869.pdf
Написал как делаю примерно то же самое чуть более современными средствами
https://m.habr.com/en/post/482194/
Mikrotik и Linux. Рутина и автоматизация