The System section is always on. Even the shortest script gives the device a name and sets a password, because a RouterOS device ships without one. The rest of this section covers things you only miss once something has gone wrong: a clock that is right, a log that survives a reboot, and a router that updates itself or deliberately does not.
Where it sits
In the wizard this is the last step, Name and password, with four questions: the name, the password, the time zone and whether NTP should be on. Everything else below lives in advanced under System.
Name and password
The router name becomes the identity. You see it back in WinBox, in neighbor discovery, in log lines and in the terminal prompt. It starts as a suggestion based on your model; in a network with more than one device, something like gw-01 or sw-office is more use than hAP ax3.
The password for admin is required. The button next to it generates one of sixteen characters. Below twelve characters you get a warning above the script, leaving it empty is an error. You can also rename the admin user, which halves the work for anyone guessing their way in: they now have to guess the name as well as the password.
The password is deliberately the very last line of the script. If something fails earlier, the old password is still in place, so you are locked out of nothing: you keep access to a half-configured router instead of losing access to one.
Time zone and NTP
The time zone defaults to Europe/Amsterdam. The script pins it and switches autodetection off, so the clock does not drift along with whatever the router thinks it sees.
The NTP client is on, with nl.pool.ntp.org and time.cloudflare.com. A router with the wrong time is more trouble than it looks: certificates appear expired or not yet valid, log lines sit in 1970 and can no longer be lined up with anything, and a scheduler fires at the wrong moment. If you run your own time server, enter it instead, separated by commas. Check afterwards with /system ntp client print that the status reads synchronized.
Login note
A short line everyone sees when they log in, for example who manages the device and where changes should be reported. Useful on equipment you manage for a customer that other people can also reach.
Logging
By default RouterOS keeps the log in memory. That is gone after a reboot, and a reboot is exactly what you want to explain afterwards. There are two alternatives:
- Also to flash disk: the script creates a logging action
diskwith five files of a thousand lines and sends info, warning and error there. Bear in mind that writing to flash wears it; for a device that runs for years, a syslog server is kinder. - Also to a syslog server: you enter an address and a port (514 by default). Info, warning, error and critical go there. This is the only option where the log still exists when the device itself no longer boots.
Log firewall drops sends the firewall topic along to your log destination. The other topics explicitly exclude firewall, so you do not get it twice. Which rules have anything to log is decided in the Firewall section; here you only decide where those lines end up.
Watchdog
The watchdog lets the router reboot itself when an address becomes unreachable. The script sets a five minute grace period after boot and a one minute timeout. Pick an address at your ISP or further out on the internet, not something on your own network that can fail by itself, or the router will reboot every time a switch is off. On a router with two uplinks, Netwatch is usually the better tool, because it can act without taking the whole router down.
RouterOS version and updates
RouterOS version on the device tells the tool what is running now. The script is written for that version, because the spelling of some commands differs between them. Check with /system resource print. Preferably upgrade to the newest version first and leave this on the recommended setting.
The update channel goes into /system package update. stable is the normal choice, long-term only gets fixes, and testing does not belong on a device that has a job to do.
Automatic updates creates a script called upgrade and a scheduler called weekly-upgrade that checks and installs every Sunday at 04:00. Remember that the router reboots when it does. Fine for a home router, not fine for a device a business runs on at night. On RouterBOARD hardware, upgrade RouterBOOT automatically is on as well, so the bootloader keeps pace with the firmware; a CHR or an x86 install has no bootloader and does not show the option.
Device-mode
Newer RouterOS versions block a number of features (containers, hotspot, IPsec, fetch, e-mail) until you unlock them, and unlocking asks for a physical restart. The switch apply parts blocked by device-mode later takes those lines out of your script and puts them in a script that runs once at the next start. The script then ends with /system device-mode update activation-timeout=1d: you have to power the device off and on again within a day or the change never takes effect. Between pasting and that restart, the device is only partly configured. On an ordinary router nothing is blocked and this only adds risk, so leave it off unless you use containers or a hotspot.
What the script makes of it
You recognise this section by /system identity, /system clock, /system ntp client, possibly /system note, /system logging, /system watchdog, /system package update, and right at the bottom /user set admin password=….
When something is off
- Certificates are rejected or VPNs will not come up: check the clock first.
- The log is empty after a reboot: logging was still set to memory.
- The router reboots on its own: see whether the watchdog is on and which address it watches.
- You can no longer log in as
admin: check whether you renamed the user. The handover sheet lists the name you chose.
Read on: Management access for who may reach the device from where, Using the script for applying it safely, and Troubleshooting when it still goes wrong.