We have used the dude to mass upgrade RouterOS software.

Is there a way to use it to mass update the firmware and trigger a reboot?

you have no option like this. if you want to upgrade firmware you should do this 1 by 1. you can create a tool for doing this with commands but you cant use this tool for many device at one time. you can do this only one by one unfortunately.

no, why? you can make a bash script that sends SSH commands to a list of devices in a row.

hi normis,

in dude is possible ?

Not yet at least. But, more importantly, why? RouterBOOT does not contain any benefits for the user 99% of the time.
Very rare there is something that affects operation.

Hey for windows we do this by creating a tool call send command list.
cmd /C (IF EXIST c:\dude\plink.exe (echo y | c:\dude\plink.exe -ssh [Device.UserName]@[Device.FirstAddress] -pw [Device.Password] -m c:\dude\cmdlst.txt))

On the pc running it you need plink.exe in the listed folder (from https://www.chiark.greenend.org.uk/~sgt ... atest.html)
Then create a text file with the commands you want to send to the router in the same folder. (so for updating /system package update or /system routerboard upgrade)

It's a little annoying cause you can't multiselect the devices and need to right click each one, but its easier than manually doing it.

You need two scripts. Schedule the first one for 11:30 pm. This gives enough time for all your routers to download the update (if there is one). Then, if and only if there was an update, the second script gets called which reboots all routers with an update simultaneously. (make sure you use NTP) I regularly update ~40 routers in about 1 minute 30 seconds downtime across the entire network.


UPDATE1

UPDATE2

Thread Mining I know, as always there are many ways to skin the cat so here is how I get my units to update.
Sunday midnight they download the packages if there is an update and reboot 1 hour later.
I delay the reboot so everyone has a good chance of downloading the packages, on rare occasions Mikrotik change things that creates a compatibility issue between ROS versions.

Code: Select all

/system script
add name=Autoupdater owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="system package update check-for-updates\r\
    \n:global FWstatus [/system package update get status];\r\
    \n\r\
    \nif (\$FWstatus = \"New version is available\") do={system package update download; delay delay-time=3600; system reboot} else={}"
    
    /system scheduler
add interval=1w name="Sunday Midnight" on-event="system script run Autoupdater" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=dec/03/2017 start-time=00:00:00
add interval=1w name="Saturday Midnight" on-event="system script run Email configuration backup" policy=\

Thread Mining I know, as always there are many ways to skin the cat so here is how I get my units to update.
Sunday midnight they download the packages if there is an update and reboot 1 hour later.
I delay the reboot so everyone has a good chance of downloading the packages, on rare occasions Mikrotik change things that creates a compatibility issue between ROS versions.

Hi,

I want to ask you something that I'm curious about it, in this script all device will reboot same time, if device powerbox and this powerbox supply voltage to some SXTs on it . what happen if SXTs and powerbox reboot it self at same time for upgrade ? is powerbox or OmniTik UPA will not cut power to devices that connected on it while upgrading ?

Thanxx

Code: Select all

/system script
add name=Autoupdater owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="system package update check-for-updates\r\
    \n:global FWstatus [/system package update get status];\r\
    \n\r\
    \nif (\$FWstatus = \"New version is available\") do={system package update download; delay delay-time=3600; system reboot} else={}"
    
    /system scheduler
add interval=1w name="Sunday Midnight" on-event="system script run Autoupdater" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=dec/03/2017 start-time=00:00:00
add interval=1w name="Saturday Midnight" on-event="system script run Email configuration backup" policy=\

Thread Mining I know, as always there are many ways to skin the cat so here is how I get my units to update.
Sunday midnight they download the packages if there is an update and reboot 1 hour later.
I delay the reboot so everyone has a good chance of downloading the packages, on rare occasions Mikrotik change things that creates a compatibility issue between ROS versions.

Hi,

I want to ask you something that I'm curious about it, in this script all device will reboot same time, if device powerbox and this powerbox supply voltage to some SXTs on it . what happen if SXTs and powerbox reboot it self at same time for upgrade ? is powerbox or OmniTik UPA will not cut power to devices that connected on it while upgrading ?

Thanxx

Upgrade will not be done if there's a power loss. It has turned be a reboot.

On a personal note (take it for what it's worth), I'm always fearful about mass (automated) upgrades. If something goes wrong, what then? Yes, it's long, but I prefer 1 by 1. I've had occurrences of upgrade bugs. You're better off knowing now than finding about it in the morning.

Regards,

Sent from Tapatalk

Code: Select all

/system script
add name=Autoupdater owner=admin policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon source="system package update check-for-updates\r\
    \n:global FWstatus [/system package update get status];\r\
    \n\r\
    \nif (\$FWstatus = \"New version is available\") do={system package update download; delay delay-time=3600; system reboot} else={}"
    
    /system scheduler
add interval=1w name="Sunday Midnight" on-event="system script run Autoupdater" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=dec/03/2017 start-time=00:00:00
add interval=1w name="Saturday Midnight" on-event="system script run Email configuration backup" policy=\

Thread Mining I know, as always there are many ways to skin the cat so here is how I get my units to update.
Sunday midnight they download the packages if there is an update and reboot 1 hour later.
I delay the reboot so everyone has a good chance of downloading the packages, on rare occasions Mikrotik change things that creates a compatibility issue between ROS versions.

Hi,

I want to ask you something that I'm curious about it, in this script all device will reboot same time, if device powerbox and this powerbox supply voltage to some SXTs on it . what happen if SXTs and powerbox reboot it self at same time for upgrade ? is powerbox or OmniTik UPA will not cut power to devices that connected on it while upgrading ?

Thanxx

Upgrade will not be done if there's a power loss. It has turned be a reboot.

On a personal note (take it for what it's worth), I'm always fearful about mass (automated) upgrades. If something goes wrong, what then? Yes, it's long, but I prefer 1 by 1. I've had occurrences of upgrade bugs. You're better off knowing now than finding about it in the morning.

Regards,

Sent from Tapatalk

while upgrading if power loss nothing will happen ? if its true its good

I agree with your personal note, doing 1 by 1 better but sometimes some companies have more than 500-600 device and they looking for mass cayse its hard to make 1 by 1

Thnxx

Of course when the router is providing power supply to the access points it is dangerous to update them at exactly the
same time as the power will be cut when the access points are doing the flash writes...
What is true in that posting: when the files are downloaded (and the device has big flash) and then the power is cycled,
the update is not done. I found that when I downloaded the update on many routers guessing that they would update
at the next powercycle, but that did not happen.

Of course when the router is providing power supply to the access points it is dangerous to update them at exactly the
same time as the power will be cut when the access points are doing the flash writes...
What is true in that posting: when the files are downloaded (and the device has big flash) and then the power is cycled,
the update is not done. I found that when I downloaded the update on many routers guessing that they would update
at the next powercycle, but that did not happen.

On powercycle Update package not install, When reboot a device Update package installing , So I found a program for ssh and sending command to download update first and after sending reboot command to all device step by step every 4 min. Program sent reboot command wait 4 minute and sent command to another device. this is most stable method for me for upgrading many device.

On powercycle Update package not install, When reboot a device Update package installing , So I found a program for ssh and sending command to download update first and after sending reboot command to all device step by step every 4 min. Program sent reboot command wait 4 minute and sent command to another device. this is most stable method for me for upgrading many device.

Yes that is the better way, not all at the same time (using scheduled job) but at different times.
With Linux I would use a combination of "ssh" and "expect" to do that. With "expect" you can program a multi-step procedure that
would login to the device, check the current version, when required download an update, reboot to install it, login again after a
couple of minutes to verify that the device came back and the software indeed was upgraded, and finish.
Around that I would program a loop (probably in the shell) to call this procedure one by one for every device that has to be upgraded
and stop when something unexpected happens.

I have done this at work to upgrade switches (different manuf) and it worked fine.
Of course it would cause multiple network interruptions, compared to the method where first the firmware was downloaded
everywhere and then a reboot at the same time at all routers. However, that method is not safe when power over ethernet
is in use! Then at least you need a different install time for powering- and powered devices.

Yes that is the better way, not all at the same time (using scheduled job) but at different times.
With Linux I would use a combination of "ssh" and "expect" to do that. With "expect" you can program a multi-step procedure that
would login to the device, check the current version, when required download an update, reboot to install it, login again after a
couple of minutes to verify that the device came back and the software indeed was upgraded, and finish.
Around that I would program a loop (probably in the shell) to call this procedure one by one for every device that has to be upgraded
and stop when something unexpected happens.

I have done this at work to upgrade switches (different manuf) and it worked fine.
Of course it would cause multiple network interruptions, compared to the method where first the firmware was downloaded
everywhere and then a reboot at the same time at all routers. However, that method is not safe when power over ethernet
is in use!

Then at least you need a different install time for powering- and powered devices.
exatly yes there are multiple network interruptions while mass upgrade , for 100 device takes 400 min and disconnect every 4 min is not good But I have no any other method yet

Then at least you need a different install time for powering- and powered devices.

good idea, It will take a time to prepare devices in category's but I will do it.
Thanks sharing your experience

Hi,
I want to ask you something that I'm curious about it, in this script all device will reboot same time, if device powerbox and this powerbox supply voltage to some SXTs on it . what happen if SXTs and powerbox reboot it self at same time for upgrade ? is powerbox or OmniTik UPA will not cut power to devices that connected on it while upgrading ?

Thanxx

It possible it will do that, but if it does the SXT will upgrade itself next week.

It possible it will do that, but if it does the SXT will upgrade itself next week.

I have never tried it with MikroTik equipment but usually when doing software upgrades there is a prominent "do not remove power during upgrade" warning and I think it would be unwise to remove power from the SXT precisely at the time it is doing its upgrade (i.e. around the reboot phase).
It may well be that it won't boot after that and will require a netinstall.

But again, I have not tried that. It could also be that the upgrade procedure is very sturdy and uses the required journalling to roll-back all update actions when the entire update is not correctly completed.

I have never tried it with MikroTik equipment but usually when doing software upgrades there is a prominent "do not remove power during upgrade" warning and I think it would be unwise to remove power from the SXT precisely at the time it is doing its upgrade (i.e. around the reboot phase).

Will today I had a little drive to go correct one of these. Mass upgrading at the same time seems to not really be an issue, one of my networks with two POE devices seems to handle it fine and always has for about 2 years. The other one which I freshly installed two weeks ago didn't have the time synched across all the devices and well that caused a few issues when some of the POE powered devices were still doing upgrades when the supplying device rebooted.

I'll figure out some way to detect if there are POE powered devices, if there are, I will wait a further three minutes until it reboots.

Took a little while and I needed a bit of help along the way. But here it is an updating script.

It will check for updates,
If there are it will start downloading.
If there are POE powered devices on port 5 it will wait 3900 seconds otherwise it will wait 3600 seconds for the download to finish before rebooting.

Well, it failed again, think i need more of a time differential to allow the POE powered devices more time to install, might make it 15 minutes.
After going through the logs on some of the devices there was only a 30 second differential in the boot time of the router and the SXT that is powered from that router.

Its apparent the time delay is not working. I'll work on it, test it and hopefully come up with some thing that works properly.

I think that will work,I had to define the global variable POEstatus, if you try to define it within {} its only available within the {}.
https://wiki.mikrotik.com/wiki/Manual:Scripting#Scopes

I've tried it on a pair of units and it looks good.
So next ROS update I'll let you know how it goes.

So a couple of ROS updates later and a couple of failures too.
The basic theory was working, except it wasn't ordered right, so it would wait for the delay and then go for the download +upgrade. Ending up in a race condition where multiple units would be downloading and one would finish first and reboot, cutting off internet access for the rest.
I've now got it to check for an update, if there is one, start downloading it and then do the time delay.

Now to wait for the next ROS update.

It works!
Feel free to use/modify/curse at, too your hearts content.

I think there is an easier solution; set auto-upgrade to yes on all devices Then upgrade software via Dude as always - devices will reboot, but they need another reboot to load the firmware. Select updated devices, go to settings and click reboot. They should all load new firmware. I always do it like this, takes me 30 seconds to update 50+ devices.

If anyone happens to be using this I've updated it.

Lately I've been having issues where the tiks would report connection failures or timeouts when attempting their upgrades.
I suspect there might be a lot of systems all over the world hammering away at the upgrade servers as each hour falls. Hence I've given it a 30 minute random variable. The limited testing I did suggests it does improve the chances of a unit upgrading successfully.

Apologies, I should have tested that more thoroughly first. That previous post is junk.
I've fixed the bugs. Now it will still try 5 times to download the package. Upon failure it will report it to the log.
Upon success it will reboot at 1am local time unless it's supplying POE on port5, then it will be 1:03am
It has successfully gotten my fleet of units to update for 7.15.2