Я иногда пишу скрипты, которые помогают мне в работе с Mikrotik RouterOS. Они, конечно, не идеального качества, но работают.
Вот и сейчас пришлось набросать скриптик, который помог мне вывести соответствие Interface - MAC на коммутаторе.
#Mikrotik #RouterOS #script
https://github.com/devi1/RouterOS-scripts/blob/master/MACs%20on%20switch%20interface
Вот и сейчас пришлось набросать скриптик, который помог мне вывести соответствие Interface - MAC на коммутаторе.
#Mikrotik #RouterOS #script
https://github.com/devi1/RouterOS-scripts/blob/master/MACs%20on%20switch%20interface
GitHub
devi1/RouterOS-scripts
RouterOS-scripts - scripts for Mikrotik RouterOS
Затем полученный список я загнал в другой скрипт и запустил его на маршрутизаторе, который является DHCP севрером. И легко и быстро узнал соответствие MAC - IP - hostname.
В моем гитхабе есть ещё несколько скриптов для RouterOS и PowerShell. Посмотрите, может пригодится.
#Mikrotik #RouterOS #script
https://github.com/devi1/RouterOS-scripts/blob/master/MAC%20to%20IP%26Hostname
В моем гитхабе есть ещё несколько скриптов для RouterOS и PowerShell. Посмотрите, может пригодится.
#Mikrotik #RouterOS #script
https://github.com/devi1/RouterOS-scripts/blob/master/MAC%20to%20IP%26Hostname
GitHub
devi1/RouterOS-scripts
RouterOS-scripts - scripts for Mikrotik RouterOS
Часто приходится писать bash скрипты. Я далеко не специалист в баше и недавно осознал одну вещь.
Каждый скрипт должен иметь статус выхода. Зачем? Да просто потому что он может использоваться другими скриптами или вызываться из других систем, например CI. Если скрипт выполнился с ошибками, но на выходе мы получили статус 0, что говорит о его успешном выполнении, то, к примеру Gitlab CI, посчитает его успешно выполнившимся и передаст управление следующей задаче. Но ведь наш скрипт может готовить данные для следующих задач, а значит они пройдут некорректно.
ВЫВОД 1: скрипт должен иметь статус выхода: 0 - всё хорошо, !0 - что-то пошло не так
Решить эту задачу достатчно просто: используем
Но иногда команда может выполниться с ошибкой, но для нас это ожидаемо и нужно продолжить выполнение кода. Например, мы хотим проверить существование репозитория в GitHub и, если его нет - создать репозиторий. В CI имеем две джобы - проверка и создание.
Для проверки запускаем
ВЫВОД 2: при ожидании ошибки нужно проверять вывод и, в зависимости от него, выдавать статус выхода
#bash #script
Каждый скрипт должен иметь статус выхода. Зачем? Да просто потому что он может использоваться другими скриптами или вызываться из других систем, например CI. Если скрипт выполнился с ошибками, но на выходе мы получили статус 0, что говорит о его успешном выполнении, то, к примеру Gitlab CI, посчитает его успешно выполнившимся и передаст управление следующей задаче. Но ведь наш скрипт может готовить данные для следующих задач, а значит они пройдут некорректно.
ВЫВОД 1: скрипт должен иметь статус выхода: 0 - всё хорошо, !0 - что-то пошло не так
Решить эту задачу достатчно просто: используем
set -euo pipefail
-e
заставляет скрипт немедленно остановиться после ошибки в любой команде-u
проверяет корректность заданных переменных. Если на вход скрипта не пришла нужная переменная, то он упадет с ошибкой-o pipefail
проверяет работу перенаправлений. Например, эта команда выполнится без ошибки без флага -o pipefail : grep some-string /non/existent/file | sort
. А с флагом выпадет с ошибкойНо иногда команда может выполниться с ошибкой, но для нас это ожидаемо и нужно продолжить выполнение кода. Например, мы хотим проверить существование репозитория в GitHub и, если его нет - создать репозиторий. В CI имеем две джобы - проверка и создание.
Для проверки запускаем
gh repo view $REPO
. Если репозиторий есть, код выхода 0. Если нет - 1. Если мы не смогли получить доступ к GitHub из-за протухшего токена, тоже получим 1. Но ведь в случае ошибки нам нужно запустить следующую джобу, а она не запустится, если проверка выпала с ошибкой. ВЫВОД 2: при ожидании ошибки нужно проверять вывод и, в зависимости от него, выдавать статус выхода
# Получаем сообщение от GitHub. 2>&1 указывает, что в переменную нужно писать не только успешный вывод, но и ошибкуДля многих это очевидно, но я в очередной раз столкнулся с этой проблемой и решил написать об этом, чтобы не забыть на будущее и лучше разобраться в вопросе. Этот пример успешно работает в ArgoWorkflow. Понятное описание флагов тут
RESULT=$(gh repo view $REPO 2>&1)
# Если репа существует - считаем скрипт успешно выполненным и выходим
if [ $? -eq 0 ]; then
echo "0"
exit 0
# Если репы нет - считаем скрипт успешно выполненным и отдаем на выход 1. Следующая джоба по этому коду понимает, что нужно запуститься
elif [ "$RESULT" = "GraphQL error: Could not resolve to a Repository with the name $REPO." ]; then
echo "1"
exit 0
else
# если текст ошибки другой - считаем, что что-то пошло не так и выходим с ошибкой exit 255
echo ERROR: $RESULT
exit 255
fi
#bash #script
Gist
set -e, -u, -o, -x pipefail explanation
set -e, -u, -o, -x pipefail explanation. GitHub Gist: instantly share code, notes, and snippets.