Commands and Templates

Mass commands

The Commands page takes one RouterOS command line and a set of devices. Targets can be picked one at a time, by site — the site checkbox toggles everything under it — or by tag: each tag becomes a chip, and clicking it selects every device carrying that tag. "All CPE", "all core", "everything at the coast" are tag questions, and tagging devices well is what makes this page quick.

A filter box above the list narrows it first, by name, site, model, version, tag or status, using the same terms described under Picking devices on the Upgrades page. A device the filter hides is deselected, and Select All, Select Online and the tag chips act only on what is shown. (v1.88.0+)

Two kinds of device are absent from the list on purpose: disabled ones, and SNMP-only ones, which have no command channel at all. The same two are left out of the template dialogs, and both are dropped server-side as well, so an id that reaches the run by any other route is simply not contacted.

Execution is sequential, one device after another, and the page does not wait for it. Each device's output appears as it finishes, and the run is recorded in the history table below with the device count and how many succeeded. That output stream is private to whoever started the run — another operator with the same page open does not see it.

Over SSH a command has fifteen seconds to answer. Past that it is reported as a failure for that device and the run moves on to the next one: the ceiling is on one command, not on the run.

The command itself is passed through as you typed it. The manager does not parse, validate or fix your syntax, so quoting is your responsibility — an interface name containing a space needs its quotes, or RouterOS answers with a syntax error that will show up in your device's own log as well as in the output here.

On devices set to the REST connection method, the command line is translated into a REST call before it is sent: print and getall become a GET, every other action verb becomes a POST, and a [find …] clause becomes a query. Devices on SSH get the line as written.

Stopping after failures

A command that breaks something should not go on to every device you picked. Under Safety stop (this run only) you can set how many failed devices end the run — the rest are held, never contacted, and the output says why — and a number of seconds to wait after each device before checking that it still answers. A device that stops answering counts as a failure, which is how a command that cuts a router off, such as a firewall rule or an address change, stops the run before it reaches the next router. Both are off unless set here or as defaults under Settings → Safety stop, and 0 turns either off for one run. The wait accepts up to ten minutes. (v1.88.0+)

The check does not undo anything; it only stops the run from carrying on. The same two fields are in the Execute Template dialog; a script deploy has none of its own and takes whatever Settings holds. With either limit on, devices run strictly one at a time, so a large run with a wait takes correspondingly longer.

History on this page lists runs that touched more than one device. A run that spanned two sites shows a site-scoped user only their own devices and only those devices' output.

Running as a different account

Under the command box, "Use different credentials (this run only)" takes a RouterOS username and password used for that execution and nothing else. It is there for the case where the stored account is deliberately read-only and a change needs a person's own login behind it.

Over SSH such a run gets its own connection outside the pool, used once and dropped, so the pooled connection that the sixty-second poll shares stays authenticated as the device's own stored account. On a device managed over REST the same username and password go on that run's API calls in place of the stored ones.

The password is not stored anywhere and does not appear in any log. The username does: the activity log records which account the run was made under, which is the entire point of the feature.

Templates

A template is a saved command set with a name, an optional description, a category — Security, Network, Services, System or General — and an enabled flag. Templates come in two types, and the type decides which button you get.

Clearing the enabled flag leaves a template in the list, and in an export, but takes its Execute or Deploy button away — somewhere to park a set you are not ready to delete.

Executing a template works through five devices at a time, or one at a time when a safety stop is on; within one device the commands run in order, so a template that disables a service and then enables its replacement stays in the sequence you wrote. A failing command does not stop the ones after it — each command reports its own result, and the summary at the end counts successes and failures across the whole run.

A Script-type template cannot be executed, only deployed. That is the point of the type: bodies with loops and variables belong on the device, run by a scheduler or by hand, not pushed through a command channel one line at a time.

Deploying a script

Deploy asks for the name the script will have on the device — letters, digits, dot, underscore and hyphen only — and offers to replace an existing script of that name. Without that box ticked, a name that already exists is an error, not a silent overwrite. Deploy has the same Safety stop (this run only) as Execute (v1.96.0+).

On a device managed over SSH the body travels to the router as a file rather than inline on a command line, which is what lets long scripts arrive intact: it is uploaded, added with /system/script/add reading the file's contents, checked for length, and the temporary file is removed. If the stored script comes back empty — a delivery that silently failed — the deploy reports an error for that device instead of leaving a script that does nothing.

Nothing runs. Deploying a GeoIP script to twelve routers changes no traffic until something runs it on each of them, which is exactly what the generator's optional weekly scheduler is for. The GeoIP section covers that generator in full.

Moving templates between installations

Templates export as JSON, one at a time or all at once. Each template in the file carries its name, description, type, commands and category, and nothing else — no identifiers, no device references — so a template written on a laptop install works unchanged on a production one. The file around them adds only the export's own format and version, the moment it was written, and the version of the install that wrote it.

Import shows a preview before anything is written: how many templates the file holds, which version wrote them, which names already exist, and how many commands look destructive. That last count is a keyword match on things like reset-configuration, remove, reboot and shutdown. It is a prompt to read the file, not a safety net — a template from a stranger deserves the same reading as a script from a stranger.

Where a name collides, you choose once for the whole file:

• Skip — keep what you have and ignore the imported one. The default.
• Rename — import as "name (imported)", numbered if that exists too.
• Overwrite — replace the existing template with the imported version.

The file declares a format and a version, and an import refuses anything that is not a templates export of the version this build understands. Hand-editing an export is fine; changing its format or version line is not.

Who can do what

Three columns, because those are the roles these two pages tell apart. A superadmin has everything in the Admin column, and nothing here is reserved to that role alone. The rights of the RouterOS account behind a device are a separate question from all of this: a stored account that may only read will fail the command on the router, not in the manager.

Site scope applies on top of the role. A mass command, a template execution and a script deploy all take their target list from the browser, so all three narrow it server-side before anything runs, and a device outside your sites is dropped rather than run against. What a run made only of such devices comes back as differs: a mass command finds nothing left to do, while a template execution or a deploy is refused outright.

The four roles and how scope is assigned are covered on the Users and Access page.