Есть ли вообще такая штука как "Режим тишины" или /y или вообще без запроса?

Теперь перезагрузка системы требует подтверждения. Без возможности обходить подтверждения и запросы паролей мы не можем автоматизировать почти ничего. Это огромная проблема.

Я согласен, что малейшие изменения в синтаксисе ломают всё. Каждый релиз, даже точечный, требует тщательного тестирования каждого скрипта. Это ж настоящая морока.

Ты пробовал это на 5.21? Я только что тестировал, и ROS не очень обрадовался, выдаёт ошибку, что `y` — плохая команда, и всё равно просит подтверждение. /system reboot раньше работал, но в какой-то момент это подтверждение появилось и стало приводить к сбоям в скриптах.

16.11.2012 13:28:06 по RouterOS 5.21 /system scheduler add name=schedule1 on-event=“/system reboot” policy= ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api start-date=nov/16/2012 start-time=13:27:00
Роутер успешно перезагрузился.

Второй тест: 16.11.2012 13:33:41 по RouterOS 5.21 /system script add name=script1 policy= ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api source=“/system reboot” /system scheduler add name=schedule1 on-event=script1 policy= ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api start-date=nov/16/2012 start-time=13:32:00
И угадайте что? Успешная перезагрузка!

У меня нет роутерборда для тестов, но... а что насчет '/system make-me-a-coffee'?.. зачем вообще нужен параметр 'upgrade' в scheduler?!? %)

Мы пытаемся полностью автоматизировать входящее тестирование, настройку, перезагрузки и обновление прошивки роутеров MikroTik. Гораздо легче сказать, чем сделать, когда нужно многократно перезагружать платы, обновлять прошивку и так далее. Особенно, когда инструменты вроде FlashFig работают некорректно с версией ROS, которая установлена на новых платах (5.11). С сотнями плат, которые нужно настроить, делать всё это вручную просто невозможно. Мы бы очень предпочли использовать стандартную загрузку по PXE и иметь нормальный образ vmlinux, который можно было бы запустить, а не использовать FlashFig. В основном потому, что это известно как работающий способ, и его можно запустить при загрузке, чтобы не приходилось вручную запускать сервер. NetInstall подходит для одной платы, но для массового производства его недостаточно. В итоге, единственный способ, чтобы команда /system reboot работала корректно из скрипта импорта (/system script import blah), заключался в: Создании скрипта из импортируемого скрипта, содержащего команду /system reboot. Затем запуске команды /system script run для скрипта, который мы создали из импортируемого скрипта. Это работает и обходит подтверждения. Предложение: при запуске скриптов из команды импорта, отключать все подтверждения. Мы пробовали разные способы запустить /system upgrade из скрипта, но ничего не получается. Это требует ручного выполнения из-за подтверждений. Мы пробовали запускать из импортного скрипта, скрипта run и запланированного скрипта. Ничего не работает. Мы бы также хотели иметь возможность импортировать защищённые паролем сертификаты (openvpn, ssl и т.д.), но нет возможности заскриптовать поле пароля. Конечно, мы бы не отправляли пароли к сертификатам после установки, но для массового производства это тоже было бы полезно. На данный момент наш процесс выявляет около 10-15% поступающих плат как дефектные непосредственно от MT. Проблемы либо постоянные перезагрузки (кажется, это сбой загрузчика), и их нельзя сбросить (поскольку нет доступа к консоли платы), либо повреждённый NAND с неисправными блоками. 15% брака – это очень плохо, но если мы можем выявлять их при поступлении, то хотя бы они не попадают клиентам, и мы можем получить замены от дистрибьютора, а не проходить через невероятно долгий процесс RMA.

Добавь в расписание задачу по обновлению Routerboard через /system routerboard upgrade, без запроса подтверждения "да или нет".

Мы поняли, что заставить перезагрузку работать можно, импортируя скрипт, который создает другой скрипт и добавляет событие в планировщик, которое запускается через минуту-две после запуска первого скрипта. Еще нужно, чтобы при старте системы запускался скрипт, отключающий планировщик перезагрузки. Получилось довольно криво. Мы делаем что-то похожее при обновлении системы, чтобы обновить загрузчик. Работает примерно 50% времени. Мы не можем как-то это отладить. Логи отладки и скриптов не дают ни малейшего представления о том, почему иногда работает, а иногда нет. В общем, да, можно перезагружаться из скриптов, но только не через импорт или запуск из командной строки. Можно иногда и обновление запускать из скрипта, но оно тоже работает примерно в 50% случаев и его нельзя запускать через импорт или командную строку.