Page 1 of 1
Unimus Mass Config Push Handling Reboot
Posted: Wed Jun 25, 2025 4:18 am
by david.aghaian
Hi All,
I'm currently working to evaluate the Unimus tool for a use case in which we wish to centralize the configuration of MikroTik RemoteAPs globally. Currently, my thought was to instruct the RemoteAPs to download a .rsc file, which they can then proceed to run. My question is, if the script should trigger a reboot of the device, I would assume the Mass Config Push is going to report failure. What sorts of options do I have to work around this dependency? Does Unimus have a concept of trying to reconnect upon disconnect? The only thing I saw was to use wait-reply=no, but this would never give me the confirmation that the configuration from the script was completed successfully. Thank you, and I look forward to getting some input!
Re: Unimus Mass Config Push Handling Reboot
Posted: Fri Jun 27, 2025 4:00 pm
by Tommy.c
David,
I am pretty sure that there isn't a way for Mass Config Push to re-login to a device once it closes the Telnet/SSH session. I am talking to the devs about this, but I don't see a way around the SSH session being automatically terminated by the MikroTik during the reboot process.
You can get around some of your issues with the "$(wait-reply no)" command. This would at least get you the output up to the point of the device rebooting.
Note, here's my testing script that allows me to not get the "INTERACTION_ERROR" message and no output.
Code: Select all
interface print
/sys reboot
y$(wait-reply no)
gives me:
Code: Select all
<prompt> interface print
Flags: R - RUNNING
Columns: NAME, TYPE, ACTUAL-MTU, MAC-ADDRESS
# NAME TYPE ACTUAL-MTU MAC-ADDRESS
0 R ether1 ether 1500 BC:24:11:2B:0D:C2
1 R ether2 ether 1500 BC:24:11:7D:B3:3C
2 R ether3 ether 1500 BC:24:11:CD:0C:44
3 R lo loopback 65536 00:00:00:00:00:00
<prompt> /sys reboot
RReboot, yes? [y/N]:
I think the best option currently is to have a second Mass Config Push that you run after the first that will check the config once the .rsc has run.
We are working on a configuration validation add-on to Unimus, but it isn't quite ready for prime time yet. Basically you would run your Mass Config Push, and then the next backup that would be run for the devices Unimus could verify the configs against a rule set that you create. This would give you a yes/no on if the devices are matching your intended end configuration.
Re: Unimus Mass Config Push Handling Reboot
Posted: Tue Jul 01, 2025 5:29 pm
by david.aghaian
Thanks for the info. I'll go ahead and try the wait-reply approach to see if it works for our use case. Thanks!
Re: Unimus Mass Config Push Handling Reboot
Posted: Mon Jul 07, 2025 1:53 pm
by Tommy.c
Okay, so talked to the Devs in detail on this one.
They are already adding in some logic for handling expected disconnects, so you will get successful runs when rebooting. These should be coming out with our 2.8.0 release later this year. (around September is the expected time-frame)
That said, a reconnect mechanism is not in the cards at the moment, the devs see the utility, but our developer resources are pretty well tied up for the rest of the year. It is in the log of requests and we will be considering adding it to the roadmap.
Re: Unimus Mass Config Push Handling Reboot
Posted: Fri Aug 15, 2025 10:46 pm
by david.aghaian
Hey Tommy,
So I keep trying to send a command which responds with:
Dangerous! Reset anyway? [y/N]:
Attempting to put "y" on the next line does not seem to get it to send. I've also tried adding $(wait-reply no) to the line before it. Heres the full set of lines that lead to this behavior.
Code: Select all
/system reset-configuration no-defaults=yes run-after-reset="full_config.rsc"$(wait-reply no)
y
or
Code: Select all
/system reset-configuration no-defaults=yes run-after-reset="full_config.rsc"
y
or
Code: Select all
/system reset-configuration no-defaults=yes run-after-reset="full_config.rsc"
y$(wait-reply no)
Re: Unimus Mass Config Push Handling Reboot
Posted: Fri Aug 15, 2025 11:21 pm
by david.aghaian
Interestingly enough, if I just made a new Config preset and added just the reset command + the "y", it works just fine.
I don't understand if this is due to the size of the script itself but its getting to the prompt after running the command and not sending what it should
Re: Unimus Mass Config Push Handling Reboot
Posted: Sat Aug 16, 2025 1:16 pm
by Tommy.c
Oh... That's cool. I like weird problems.
Do you have debugging turned on for the zone? I am curious what Unimus is saying it's sending vs what it's getting back.
Are you testing with pieces of equipment or possibly against RouterOS v6 vs v7?
Are you using other Modifiers in the script before the reset command?
https://wiki.unimus.net/display/UNPUB/M ... -Modifiers
Re: Unimus Mass Config Push Handling Reboot
Posted: Sun Aug 17, 2025 10:48 pm
by david.aghaian
I went and dug into the output and I think I have the answer, yet I"m not 100% sure it makes sense to me.
Originally,
I'm wrapping the whole block of commands to run in a
I think the problem with this is Unimus is going to execute this as one giant entity, so things like responding to prompts ("y" in this case), dont happen as we would expect.
If I leave all the other portions of my config between the curly braces but thne at the very end run the system reset command with wait-reply, it sends it as expected. Any clarification would be appreciated!
Re: Unimus Mass Config Push Handling Reboot
Posted: Wed Aug 20, 2025 6:28 pm
by Tommy.c
I am not certain what was happening, curly brackets "{...}" do not have anything explicitly defined in the documentation. I wonder if the device was expecting the end curly bracket "}" and then being told to reboot probably made for an undefined state for the driver and Unimus kicked itself out before anything further broke...
Pure guesswork though. I can ask the devs if you want, but this feels like a problem solved to me.