{"id":19490798,"url":"https://github.com/n3tuk/scripts-mikrotik","last_synced_at":"2025-04-25T19:32:11.081Z","repository":{"id":186840510,"uuid":"675861197","full_name":"n3tuk/scripts-mikrotik","owner":"n3tuk","description":"A set of scripts and Taskfile to build and manage RouterOS configuration scripts for mulitple routers and switches, including support for configuration storage in Vault.","archived":false,"fork":false,"pushed_at":"2024-09-06T18:10:55.000Z","size":216,"stargazers_count":10,"open_issues_count":3,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2024-09-06T21:19:17.261Z","etag":null,"topics":["firewall","gomplate","ipv4","ipv6","mikrotik","mikrotik-routeros","mikrotik-routeros-script","mikrotik-script","networking","ros","routeros","routeros-scripts","taskfile"],"latest_commit_sha":null,"homepage":"","language":"Raku","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/n3tuk.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":".github/CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-08-07T22:52:43.000Z","updated_at":"2024-09-06T18:10:58.000Z","dependencies_parsed_at":null,"dependency_job_id":"6d4abd9c-5fad-45d1-8c14-e93979ce18db","html_url":"https://github.com/n3tuk/scripts-mikrotik","commit_stats":null,"previous_names":["n3tuk/scripts-mikrotik"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/n3tuk%2Fscripts-mikrotik","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/n3tuk%2Fscripts-mikrotik/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/n3tuk%2Fscripts-mikrotik/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/n3tuk%2Fscripts-mikrotik/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/n3tuk","download_url":"https://codeload.github.com/n3tuk/scripts-mikrotik/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":224014224,"owners_count":17241282,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["firewall","gomplate","ipv4","ipv6","mikrotik","mikrotik-routeros","mikrotik-routeros-script","mikrotik-script","networking","ros","routeros","routeros-scripts","taskfile"],"created_at":"2024-11-10T21:14:23.709Z","updated_at":"2024-11-10T21:14:24.939Z","avatar_url":"https://github.com/n3tuk.png","language":"Raku","funding_links":[],"categories":["Scripts"],"sub_categories":[],"readme":"# n3t.uk Mikrotik RouterOS Scripts\n\nThis repository hosts a set of scripts, templates, and a [Taskfile][taskfile] to\nmanage the building of RouterOS scripts for multiple Mikrotik hosts (including\nrouters, switches, and access points) using a centralised defined configuration,\nwith emphasis on the management of VLANs and Firewall Rules.\n\n![Overview Diagram for Mikrotik Scripts](https://github.com/n3tuk/scripts-mikrotik/blob/main/docs/overview-diagram.svg?raw=true)\n\n\u003e [!WARNING]\n\u003e This repository is designed to specifically configure the multiple routers,\n\u003e switches, and access points that are used as part of the network for the\n\u003e [`n3t.uk`][n3tuk] Lab and Home environments. However, this is open-source and\n\u003e can be used by anyone for their own hosts if they so wish. Updates are welcome\n\u003e to help generalise and secure, if suitable.\n\nFeel free to fork it, and if you wish to contribute back to the repository, see\nthe document [`CONTRIBUTE.md`][contribute-md] for further details.\n\n[n3tuk]: https://github.com/n3tuk\n[contribute-md]: https://github.com/n3tuk/scripts-mikrotik/blob/main/.github/CONTRIBUTE.md\n\n## How Mikrotik Scripts Operates\n\nThe script is ultimately designed to take complete control of the hosts its\nconfigured for, although not every feature is supported. It's been written to\nsupport the most common and currently needed features for the [`n3t.uk`][n3tuk]\nnetwork at this time.\n\nThis repository therefore operates in two parts:\n\n| Step | Name                               | Description                                                                                                                                                                                                                                                                                                                                                |\n| ---: | :--------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n|   1. | [`netinstall.scr`](#netinstallscr) | Provide a baseline for each MikroTik host which should be installed as the default configuration using the [`netinstall-cli`][netinstall-cli] utility, and ensures that when a host is initiall configured or reset to the default configuration, it has secure settings and the `management` VLAN configured, allowing easy remote access to reconfigure. |\n|   2. | [`update.scr`](#updatersc)         | Provides the up-to-date current configuration for each MikroTik host, installing the full initial configuration for all VLANs, Firewalls, User, Ports, etc., and updaing them as needed over time.                                                                                                                                                         |\n\n[netinstall-cli]: https://mikrotik.com/download\n\nOnce the [`netinstall.scr`](#netinstallscr) script is loaded onto a MikroTik\nhost, and the define initialised, it should always be accessible within the\nnetwork without needing physical access. The configuration will also facilitate\nthe passing of `management` VLAN traffic over it (if configured to do so), so\nall MikroTik hosts, and other hosts directly connected to the `management`\nVLAN should remain accessible, even if no other traffic is allowed to pass.\n\nThat should allow each host to be loaded with the [`update.rsc`](#updatersc)\nscript which sets it to the current full configuration of the interfaces,\nbridge, ports, VLANs, firewalls, and users, with that same script or similar\nexports) to then keep the host up-to-date.\n\n## Using Taskfile\n\n[Taskfiles][taskfile] is used to manage the running of the scripts, including\nthe operation and dependencies of the scripts to build the configurations for\nall hosts, or just for selected hosts or exports, as required.\n\nRun `task --list` to see all supported tasks:\n\n```console\n$ task --list\ntask: Available tasks for this project:\n* clean:         Clean up the temporary files from the repository\n* default:       Run the default task (export)\n* export:        Build and export the scripts for all hosts\n* force:         Clean up and then re-export all scripts\n* lint:          Check and lint files for correctness\n```\n\n## Exporting Mikrotik Scripts\n\nTo build and export the configuration scripts for all known hosts and all\nknown export types, just use `force` (which calls `clean` and then `export`) or\njust `export`.\n\n\u003e [!NOTE]\n\u003e This repository does not, by default, include any configuration files for\n\u003e hosts or networks. As such, running `export` will not output any scripts.\n\u003e Instead example hosts and an example network are found within the\n\u003e [`examples/`][examples] directory, and can be test exported using `examples`\n\u003e rather than `export`.\n\n[examples]: https://github.com/n3tuk/scripts-mikrotik/tree/examples\n\n```console\n$ task clean examples\ntask: [lint-yaml] yamllint -c .yamllint.yaml \\\n  {examples,hosts,networks}/*.yaml\ntask: [examples] scripts/exports  \\\n  | parallel -kj 10 scripts/export\n==\u003e ap/firewall\n -\u003e Sourcing local://examples/ap.yaml\n==\u003e ap/netinstall\n -\u003e Sourcing local://examples/ap.yaml\n==\u003e router/firewall\n -\u003e Sourcing local://examples/router.yaml\n==\u003e switch/firewall\n -\u003e Sourcing local://examples/switch.yaml\n==\u003e router/netinstall\n -\u003e Sourcing local://examples/router.yaml\n==\u003e switch/netinstall\n -\u003e Sourcing local://examples/switch.yaml\n```\n\nOr, when using `export` (or `examples`), you can select specific hosts or export\ntypes through a fuzzy search by appending the search term to the end of\ncommand-line (following `--`):\n\n```console\n$ task clean examples -- switchfirewall\ntask: [lint-yaml] yamllint -c .yamllint.yaml \\\n  {examples,hosts,networks}/*.yaml\ntask: [examples] scripts/exports switchfirewall \\\n  | parallel -kj 10 scripts/export\n==\u003e switch/firewall\n -\u003e Sourcing local://examples/switch.yaml\n```\n\n## Export Types\n\n### `netinstall.scr`\n\n```console\ntask export -- netinstall\n```\n\nThis is the \"part 1\" of the configuration and provides an `.scr` script which\ncan be used with [`netinstall-cli`] to load a host with the default\nconfiguration that prepares that host for the network on first boot or\nconfiguration reset.\n\nSpecifically, most services are pre-configured (logging, graphing, services,\nDNS, NTP) and users are added with public SSH key for remote access.\n\n\u003e [!IMPORTANT]\n\u003e Users will be added by `netinstall.scr` with passwords (as this is required\n\u003e for `/user add` in RouterOS) but the password is thrown away. This is chosen\n\u003e as otherwise the password must be output to the system log or to a local file\n\u003e which would be open for all other users who have access. Users must first log\n\u003e in with their SSH private key and then set the password if WinBox or WebFig\n\u003e access is required. This will ensure that no one user can know more than their\n\u003e own password on any host.\n\nThe network is also configured by `netinstall.scr`, but only to support access\nto `management` VLAN. The `management` and `blocked` VLANs are created and\ninterfaces are attached based on three rules:\n\n- If `vlans:` is set on the interface, and `vlans` contains the `management`\n  VLAN, that interface is configured as `tagged` on `management` and `untagged`\n  for `blocked` (and only VLAN-tagged frames are allowed);\n- If the above doesn't match, but `vlan:` is set, and its value is `management`,\n  that interface is configured as `untagged` on `management` (and only untagged\n  or priority tagged frames are allowed);\n- All other interfaces are configured as `untagged` on `blocked` (and only\n  untagged or priority tagged frames are allowed).\n\nAs any host should have access to the `management` VLAN on its initial\ninstallation, or when reset to the default configuration, it should be possible to\nremotely access the host without any further access to the host. Additionally,\nas the `management` VLAN is supported in both tagged and untagged modes, any\nswitch or router may connect to multiple MikroTik hosts, allowing them to all\ncommunicate over the `management` VLAN as normal.\n\nAs such, easy remote access to a host should be possible on reset, enabling an\nadministrator to remotely log in over SSH and run the update scripts to install\nthe full configuration of the current known network quickly.\n\n### Testing Default Configurations\n\nDue to the way scripts are structured when making changes to resources (see\n[Safe Changes of Live Configurations](#safe-changes-of-live-configurations)\nbelow), the `netinstall.scr` is not dependent on there being no resources\npresent on the host to run successfully.\n\nAlthough it is not recommended to run on a fully-configured system (it will most\nlikely still work, even in this case, but it should remove all \"unknown\" VLANs\nand remove all but the basic Firewall rules, etc.), it is safe to run on a reset\nhost. As such it allows for the rapid testing of the configuration on a fully\nreset host, including repeated re-running on the same host to validate the\nconfiguration.\n\n### `update.rsc`\n\n```console\ntask export -- update\n```\n\nThe `update.rsc` export is in effect a superset of the following exports, with\ntwo exceptions:\n\n1. The [SSH Host Private Key][ros-ssh] is not exported as this should normally\n   only be set once. Use [`certificates.rsc`](#certificatesrsc) to set the host\n   private key, and as such should be exported and run explicitly once the host\n   has been initialised or reset.\n1. The [TLS Certificates][ros-certificates] needed to provide access to the\n   WebFig and API services over HTTPS.\n1. The [CAPsMAN][ros-capsman] Host Certificate and Client Authority Certificate\n   will not be set, nor the Client Certificate on any Access Points.\n\n[ros-ssh]: https://help.mikrotik.com/docs/display/ROS/SSH\n[ros-certificates]: https://help.mikrotik.com/docs/display/ROS/Certificates\n[ros-capsman]: https://help.mikrotik.com/docs/display/ROS/CAPsMAN\n\nThis exported script is therefore the default script to be run once a device has\nbeen initialised or reset, and will bring the host up to the current network\nconfiguration. It is also probably the general script to run on most updates.\n\nIf the update needs to be more targeted, there are exported scripts to\nfacilitate smaller sub-sets of changes, such as [`network.rsc`](#networkrsc) and\n[`firewall.rsc`](#firewallrsc).\n\n### `certificates.rsc`\n\n```console\ntask export -- certificates\n```\n\nThe `certificates.rsc` export provides SSH- and certificate-specific and\nsettings, should they be changed. More explicitly, this allows the configuration\nof the Host Private Key (and hence public key provided for clients to verify the\nhost is who we expect them to be) and certificate public and private keys, which\nshould be protected.\n\n### `network.rsc`\n\n```console\ntask export -- network\n```\n\nThe `network.rsc` script is for the configuration of network settings,\nspecifically:\n\n1. Update the basic settings on all physical interfaces (except `mtu` and\n   `l2mtu` settings, as this can cause temporary interface resets and therefore\n   packet drops);\n1. Update the bridge on the host and all of the bridge ports on the bridge,\n   including default VLAN settings and frames permitted on ports, as well as\n   costs and MSTP settings on the bridge and ports.\n1. CRUD the VLANs based on network changes as defined, and ensure that they are\n   associated with the bridge ports and as tagged or untagged.\n\n### `firewall.rsc`\n\n```console\ntask export -- firewall\n```\n\nThe `firewall.rsc` script is for the configuration of the firewall (both IPv4\nand IPv6) on each host, updating the address lists as needed, and then update\nthe firewall with the current set of rules.\n\nRegardless of if there are IPv4 or IPv6 address settings defined, both versions\nof the firewall are installed; which ones are used therefore depend on which\ntraffic the host is configured to support.\n\n### `users.rsc`\n\n```console\ntask export -- users\n```\n\nThe `users.rsc` script is for the configuration of users on each host, and any\nSSH public keys for each users.\n\n\u003e [!IMPORTANT]\n\u003e Users will be added by `users.rcs` (like `netinstall.scr` above) with\n\u003e passwords (as this is required for `/user add` in RouterOS) but the password\n\u003e is thrown away. Users must either first log in with their SSH private key and\n\u003e then set the password if WinBox or WebFig access is required, or the\n\u003e administrator running `user.rcs` should manually update and then expire the\n\u003e password and pass it on to the user. This will ensure that no one user can\n\u003e know more than their own password on any host.\n\n### `dns.rsc`\n\n```console\ntask export -- dns\n```\n\nThe `dns.rsc` script is for the configuration of static DNS records and the\noverall DNS settings of each host (i.e. the DNS server and DNS over HTTPS\nsettings).\n\n## Safe Changes of Live Configurations\n\nAlthough there are different ways to handle changes in configurations, such as\nby clearing out the existing settings and then replacing them, the templates\nhere are designed to handle changes for live systems in a safe way. In most\nsituations any change applied should not effect running system in a way which\nbreaks existing processing (even momentarily).\n\nFor example, for static DNS records:\n\n1. Each record is wrapped into an `:if () do={}` statement which checks for its\n   presence first, and if not present, then it is created;\n1. Any additional information which do not form part of the minimum required\n   values (e.g. `comment`) is/are updated; then\n1. All entries for the record which do not match the known configuration are\n   removed.\n\n\u003e [!NOTE]\n\u003e This method ensures that new records are created before then removing those no\n\u003e longer required. Even if all records are changed in a single pass, both sets\n\u003e of records are present before the old set is removed. At no point should there\n\u003e be an empty set.\n\nAlternately, for firewall rules:\n\n1. Each existing (or new) address list is (re)created with a new prefix (as set\n   in the `$rubId` variable for each run of the script) within which contains\n   the latest set of entries for each of the address lists (Any prefixed as\n   `dynamic:` are not managed by scripts so are not touched);\n1. Each existing (or new) chain is (re)created with a new prefix (as set in the\n   `$runId` variable for each run of the script) within which contains the\n   latest set of rules for each chain;\n1. A new `jump` target is set in each of the default chains for each table which\n   redirects traffic to the new set of chains, and then all other rules in the\n   default chain which do not `jump` to the new `$runId` chains are removed.\n1. All existing address lists which do not have the `$runId` prefix are removed\n   from the tables.\n1. All existing chains which do not have the `$runId` prefix are removed from\n   the tables.\n\n\u003e [!NOTE]\n\u003e This method ensures that two full sets of firewall chains, with `jump` rules\n\u003e in the default chains, are configured in all tables before the traffic is then\n\u003e switched by removing the old `jump` rule. This ensures that there are no\n\u003e partially complete chains while packets are being processed, and therefore not\n\u003e unintentionally blocked or allowing live packets in connections during\n\u003e updates. As all firewall chains either `accept` or `deny` traffic, traffic in\n\u003e the new chains will not be processed until the old `jump` rule is removed; an\n\u003e atomic change.\n\nThis is not a truly idempotent configuration in that there should be no changes\nmade if the resources match what is defined, but it should make the changes\natomic (e.g. packets are not processed by the new chain until the chain is fully\ncreated and the parent rule directing the jump to the chain is replaced).\n\n## Opinionated Network Settings\n\nThis script is designed with a specific purpose: To ease the day-to-day\nmanagement of the network of the [`n3t.uk`][n3tuk] network for general home\noperation as well as the setup and communications in the `n3t.uk` Lab and Home\nenvironments. As such this script is not specifically for general configuration\nof any networks, but can be used as a base for that. Many of the names, options\nchose, and settings used, are opinionated for what I like to use and how I need\nthe network to run.\n\n### Bridge and VLANs\n\nEvery connected MikroTik host operates though a combination of a single Bridge\n(not all hosts support hardware-accelerated multiple Bridges) and\n[`802.1q`][wikipedia-8021q] VLANs to segment networks as required.\n\nThe Bridge (named `bri01`) is by default tagged, and the bridge and all trunk\ninterfaces (i.e those with only `vlans` configured) are set to only accept\npackets with `802.1q` tagged packets. Edge ports can have a combination of\ntagged and untagged support for various VLANs, as needed.\n\n[wikipedia-8021q]: https://en.wikipedia.org/wiki/IEEE_802.1Q\n\n### Management Port\n\nWhere a host has a Management Port, that will be named `mgt01` and associated,\nuntagged, with the `management` VLAN. This will allow access to the management\nnetwork for maintenance and debugging on both the host itself, as well local\nconnected hosts over the `management` VLAN.\n\n### Blocked VLAN\n\nAll ports which are unconnected and unused will be both disabled and associated\nwith the Blocked VLAN (i.e. `99`). As such, in the event that any port is\naccidentally enabled, the VLAN ensures that the connected host is still not\nable to access anything on the network, other than any other potential host\nconnected to a blocked (but enabled) port.\n\nThis VLAN has no interface on any bridge on any host and has no DHCP server\n(either via IPv4 or IPv6, nor SLAAC enabled via IPv6). Any communications are\nlocal to the host itself too as this does not transit over any trunked physical\ninterface.\n\n### Interface Naming\n\nThe following list is the set of standard base names of all interfaces within\nthe [n3t.uk][n3tuk] network. These will be configured by the netinstall script,\nalthough the actual names are arbitrary and defined by the host configuration\nitself (`hosts/{host}.yaml`), and not the templates themselves. However, any\ndefault configurations may reference these (e.g. the default bridge name is set\nto `bri01`, but this may be configurable eventually).\n\n| Type            | Original           | Name            | Example            |\n| :-------------- | :----------------- | :-------------- | :----------------- |\n| 1000BASE-T      | `ether{x}`         | `gbe{xx}`       | `gbe01`            |\n| 2500BASE-T      | `ether{x}`         | `tge{xx}`       | `tge01`            |\n| 10GBASE-T       | `ether{x}`         | `xge{xx}`       | `xge01`            |\n| SFP             | `sfp{x}`           | `sfp{xx}`       | `sfp01`            |\n| SFP+            | `sfp-sfpplus{x}`   | `xfp{xx}`       | `xfp01`            |\n| SFP28           | `sfp28-{x}`        | `tfp{xx}`       | `tfp01`            |\n| QSFP+           | `qsftpplus{x}-{y}` | `qfp{x}{y}`     | `qfp21`            |\n| QSFP28          | `qsftp28-{x}-{y}`  | `ofp{x}{y}`     | `ofp32`            |\n| Bridge          | `bridge{x}`        | `bri{xx}`       | `bri01`            |\n| VLAN            | `vlan{x}`          | `bri{xx}.{yy}`  | `bri01.10`         |\n| WAN             | `ether{x}`         | `wan{xx}`       | `wan01`            |\n| Management      | `ether{x}`         | `mgt{xx}`       | `mgt01`            |\n| WireGuard       | `wg{x}`            | `wgd{xx}`       | `wgd01`            |\n| WiFi (Main)     | `wlan{x}`          | `wfi{ghz}`      | `wfi24` or `wfi50` |\n| WiFi (Children) | `n/a`              | `wfi{ghz}.{xx}` | `wfi24.22`         |\n\n### Fixed Defaults\n\nThe following items are fixed defaults and should always be present for the\ntemplates to work correctly:\n\n| Type   | Name                   | Description                                                                                                                                                                                                                                                                    |\n| :----- | :--------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| VLAN   | `management` (`name:`) | This VLAN name is searched for when managing some network interfaces, e.g. when setting network baseline during the `netinstall` export to inititally configure the network ports, so it should always be preset and be set to the VLAN ID associated with management network. |\n| VLAN   | `blocked` (`name:`)    | This VLAN name is searched for when managing some network interfaces, e.g. when there is no pre-defined VLAN configuration on an interface, so it should always be present and set to the VLAN ID associated with blocked interfaces.                                          |\n| VLAN   | `1` (`id:`)            | This VLAN ID is a default when the `blocked` VLAN cannot be found, so it is not recommended to be used in normal circumstances. (This is also the default VLAN for ports without VLANs assigned to them too, and as such is a reserved VLAN ID.)                               |\n| VLAN   | `2` (`id:`)            | This VLAN ID is a possible default when the `management` VLAN cannot be found, so it is not recommended to be used in normal circumstances.                                                                                                                                    |\n| VLAN   | `4095` (`id:`)         | This VLAN ID is not recommended for use in VLANs as it's a reserved ID.                                                                                                                                                                                                        |\n| Bridge | `bri01` (`name:`)      | This is the name of the default and only bridge configured by these scripts and when setting up the bridge ports it is this bridge they are connected to (unless `bridge: false` is set for the interface).                                                                    |\n\n## Configuration\n\nThe configuration for the networks and the associated host are handled by a\nnumber of configuration files within the repository, and potentially within\n[Hashicorp Vault][vault]. Each level overrides the next and allows for general\nconfigurations with specific overrides, as needed.\n\n| File                    | Description                                                                                                                                                                                                                                                                                            |\n| :---------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `networks/{name}.yaml`  | This is the general settings of the local network, including the VLANs to be configured, and their network settings, as well as address lists, intereface lists, users, and other general settings. The file to be used is selected by the `network: {name}` setting in the host's configuration file. |\n| `hosts/{name}.yaml`     | This is the configuration file for the specific MikroTik host. This should configure the local settings specific to each host, such as interface names, which VLANs are attached to ports, etc..                                                                                                       |\n| `vault://{host}/{path}` | This is the configuration location for Vault-managed configurations and will be used to access (typically) secrets which should override values `hosts/{name}.yaml`. See `examples/vault.json` for an example of what can be supported.                                                                |\n\n[vault]: https://www.vaultproject.io\n\n## Layout of Exports and Parts\n\nThe templates (`exports`) used within this repository are heavily broken down\ninto smaller sections (`parts`), allowing them to be easily understood, and also\nto allow the to be re-used when building up the configuration for the different\ntypes of exports.\n\nFor example, the [`users.rsc.t`][p-users-rsc] file, which is used to manage\n`/users` and their public SSH keys for remote access, is used by the\n[`netinstall.scr.t`][e-netinstall-scr] export type when generating the initial\nconfiguration to be loaded onto a host, alongside the general deployment export\ntype ([`update.rsc.t`][e-update-rsc]), and of course a dedicated\n[`users.rsc.t`][e-users-rsc] for exporting just changes to `/users` on hosts.\n\nIt is not included in the [`firewall.rsc.t`][e-firewall-rsc] export type as you\ndon't need to update `/users` if you're just deploying changes to the firewall\nconfiguration.\n\nExporting is quick too. When run on an Intel 12th-gen laptop, it can generally\nexport about 20-30 configurations per second, so even with a large number of\nhosts, or export types, it doesn't take long to collate the data and then build\nthe scripts for the hosts. This can be improved further by limiting the outputs\nusing a fuzzy matcher to build only selected configurations when needed as well\n(see [#Using Taskfile](#using-taskfile) above for details).\n\n[taskfile]: https://taskfile.dev\n[p-users-rsc]: templates/parts/users.rsc.t\n[e-netinstall-scr]: templates/exports/netinstall.scr.t\n[e-update-rsc]: templates/exports/update.rsc.t\n[e-users-rsc]: templates/exports/users.rsc.t\n[e-firewall-rsc]: templates/exports/users.rsc.t\n\n## Authors\n\n- Jonathan Wright (\u003cjon@than.io\u003e)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fn3tuk%2Fscripts-mikrotik","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fn3tuk%2Fscripts-mikrotik","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fn3tuk%2Fscripts-mikrotik/lists"}