Because we implemented a lot of RouterOS devices, we need keep them updated. So primary we need:
- Check for new version of RouterOS
- If new version is availible - send notification
- If new version is availible - download and install new version
- If new version is availible - reboot running instance
- If new version is availible - check firmware version
- If new version is availible - upgrade firmware
- If new version is availible - reboot and send notification
Solution, which worked for me:
At the first point, I set up e-mail configuration for sending notification. Because there may be problems with internal mail server, I choose to use gmail. In scripts I also use Identity and current time:
/tool e-mail
set address=173.194.70.108 from=“Sender Name <anything@gmail.com>” \
password=“Password” port=587 start-tls=yes user=anything@gmail.com/system clock
set time-zone-name=Europe/Prague
/system identity
set name=NAME
/system ntp client
set enabled=yes primary-ntp=217.31.205.226 secondary-ntp=195.113.144.201We must take all process backwards. So we must send notification about successful RouterBoard firmware upgrade:
/system scheduler
add comment=“Send SMS when upgrade was successful” disabled=yes name=
send-sms-succesful-upgrade on-event=“:delay 60s;\r
\n/tool e-mail send to="some@email.eg" body="" subject
="RouterOS $[/system identity get name] successfuly upgraded";\r
\n/system scheduler disable send-sms-succesful-upgrade;” policy=
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api
start-time=startupAt the next we must make very simple script for firmware upgrade. Another solution isn’t possible, because when you’re upgrading firmware you will be asked for answer on question about confirmation upgrade.
/system script
add name=upgrade-bootloader policy=
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api
source=“/system routerboard upgrade"Next we make schedule for firmware upgrade:
/system scheduler
add comment=“Auto upgrade bootloader” disabled=yes name=auto-upgrade-bootloader
on-event=”:delay 100s;\r
\n/system scheduler disable auto-upgrade-bootloader;\r
\n/system routerboard\r
\n:global current [get current-firmware];\r
\n:global latest [get upgrade-firmware];\r
\n:if ($current != $latest) do={ /tool e-mail send to="some@email
.eg" body="Performing bootloader upgrade from $current to $latest" sub
ject="$[/system identity get name] $[/system clock get date] $[/system c
lock get time] performing bootlader upgrade"; /system scheduler enable send
-sms-succesful-bootloader-upgrade; /system script run upgrade-bootloader; /
system reboot; }" policy=ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api
start-time=startupNext we make schedule for alert about successful RouterOS upgrade:
/system scheduler
add comment=“Send SMS when upgrade was successful” disabled=yes name=
send-sms-succesful-upgrade on-event=“:delay 60s;\r
\n/tool e-mail send to="some@email.eg" body="" subject
="RouterOS $[/system identity get name] sucessfuly upgraded";\r
\n/system scheduler disable send-sms-succesful-upgrade;” policy=
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api
start-time=startupFinally we make scheduler task for checking new RouterOS, upgrade and so on. Actually we setup task to run once a week at night Monday/Tuesday at 4:00 AM
/system scheduler
add comment=“Auto upgrade RouterOS Monday/Tuesday 4:00AM” interval=1w name=
auto-upgrade on-event=“/system package update\r
\ncheck-for-updates\r
\n:delay 1s;\r
\n:global current [get current-version];\r
\n:global latest [get latest-version];\r
\n:if ($current != $latest) do={ /tool e-mail send to="some@email
.eg" body="Performing upgrade from $current to $latest" subject="$[/
system identity get name] $[/system clock get date] $[/system clock get ti
me] performing upgrade"; /system scheduler enable send-sms-succesful-upgrad
e; /system scheduler enable auto-upgrade-bootloader; upgrade; }” policy=
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api
start-date=mar/18/2014 start-time=04:00:00
. I have setup DNS static record for MikroTik update server and all is going to proxy server, where is setup stable tested version. In network we have currently about 150 devices, so is were important for us to test new versions and if there aren’t problems distribute it directly to all devices. Because some devices are between client’s buildings on his network and we provide only support and services for him, we can’t connect them to central network in Dude and upgrade devices from there. So we’re using standard features to do this behind their network.