Skip to content

Importing a stock template

A stock template becomes a policy definition in two stages. First rConfig downloads the template repository. Then you create a new policy definition from one of its files, save it, and assign it to devices.

  1. Go to Compliance → Definitions.

  2. Click Import Templates.

    rConfig clones rconfig/pro-policy-definitions onto the rConfig server, replacing any copy it downloaded before. The server needs git installed and outbound HTTPS access to GitHub. When the download finishes, an Import Successful message shows how many files were downloaded.

rConfig downloads the current version of the repository’s main branch, which can be newer than the release these pages document. Re-run Import Templates whenever you want the latest files. It only refreshes the downloaded templates: definitions you have already saved are stored separately and do not change.

  1. On Compliance → Definitions, click New Policy Definition.
  2. Enter a Policy Name (required, and unique) and, optionally, a Description.
  3. Under Imported Templates, click Choose from Imported Templates. This button only appears once the templates have been downloaded.
  4. In the Select from imported policy templates dialog, open Select Vendor and choose a vendor folder, for example cisco.
  5. Open Select Template and choose a file, for example ios-aaa.policy.
  6. Click Apply. The template is loaded into the editor and replaces anything already there.
  7. Edit the definition if you need to (see editing a copy safely), then click Save.

The vendor pages describe every rule in each file, so you can decide which rules to keep before you save.

  1. Go to Compliance → Assignments and click New Policy Assignment. Choose the devices, the command whose output the rules check (for example show running-config for Cisco IOS), and the definition you saved. Policy Assignments covers every field.
  2. Run it from the assignment’s actions menu with Run now, or let it run on its schedule or after each backup with Run on backup. Policy Compliance Results explains the reports.

Each vendor page states the config format its rules expect. A definition assigned to the wrong command’s output fails rules that would otherwise pass.

The editor and the save check both validate the format, but a few rules are easy to break when you edit by hand or paste text from elsewhere:

  • Use LF line endings. rConfig expects a newline straight after each #[method] line, so a file saved with CRLF (Windows) line endings loads with zero rules. This matters most when you edit a copy outside rConfig and paste it back.
  • One #[ directive per // description. A second directive under the same description is read as part of the first rule’s body. Give every rule its own description line.
  • No blank line after a // line. The directive must be on the line directly after the description, and the first rule line directly after the directive. rConfig rejects a definition with a blank line in either place when you save it.
  • Use // only at the start of a description line. rConfig splits the file on every //, so a // anywhere else cuts the rule in two.

When you change a build template, replace every example value (hostnames, addresses, servers) with your own standard. Rules that still hold example values fail. The MikroTik RouterOS page explains how to edit values inside its regex rules.

Test an edited definition against a stored config before you assign it. The policy development workflow covers this.