Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jalmargyyk/ripe-updater/llms.txt

Use this file to discover all available pages before exploring further.

RIPE Updater uses a three-file template system to define the RIPE database attributes written for every managed prefix. Rather than hard-coding attributes per prefix, you define reusable building blocks — an LIR-to-organisation mapping, one or more base attribute files, and a named template list — that compose the final RIPE object at runtime. This keeps attribute management centralised and makes it straightforward to serve multiple customers or LIRs with different RIPE attributes from a single deployment. Place all template files in the directory specified by TEMPLATES_DIR (default: /opt/ripeupdater/templates). When running in Docker, mount this directory into the container as a read-only volume.

​
The three template components

1. lir_org.json — LIR to organisation mapping

lir_org.json maps each LIR identifier (as it appears in the NetBox lir custom field on aggregates) to a RIPE organisation handle. The application looks up the aggregate that contains the prefix being processed, reads its lir custom field, and uses this file to resolve the corresponding org attribute.LIR identifiers in this file must be lowercase and match the choices you configured on the lir NetBox custom field exactly.
lir_org.json
{
    "templates": {
        "lir_org": {
            "de.examplelir1": "ORG-EIPB1-TEST",
            "nl.examplelir2": "ORG-TT1-TEST"
        }
    }
}
Create this file by copying the example and editing it:
cp templates/lir_org.example.json templates/lir_org.json
A base template file defines a set of RIPE object attributes that are shared by a group of prefixes — typically all prefixes belonging to one operator or one customer. You can have as many base files as you need; the naming convention is base_<name>.json.Each file contains an attributes array of single-key objects. The special entry {"org": ""} is a placeholder that tells the application to auto-fill the org attribute from the lir_org mapping at runtime. Any other entry with a non-empty value is included verbatim in the generated RIPE object.Example — your own company:
base_mycompany.example.json
{ "attributes": [
    {"org": ""},
    {"remarks": "Managed by ripe-updater"},
    {"admin-c": "AA1-TEST"},
    {"tech-c": "AA1-TEST"},
    {"notify": "noc@example.com"},
    {"mnt-by": "TEST-DBM-MNT"},
    {"source": "TEST"}
]}
Example — a customer with different contact handles:
base_mycustomer1.example.json
{ "attributes": [
    {"remarks": "Managed by ripe-updater"},
    {"org": "ORG-EIPB1-TEST"},
    {"admin-c": "AA2-TEST"},
    {"tech-c": "AA2-TEST"},
    {"abuse-c": "AA1-TEST"},
    {"notify": "noc@example.com"},
    {"mnt-by": "TEST-NCC-HM-MNT"},
    {"source": "TEST"}
]}
Notice that the customer base template hard-codes the org handle instead of using the empty {"org": ""} placeholder. Use this approach when a customer’s organisation handle is fixed and does not come from the LIR mapping.Start from the example:
cp templates/base_mycompany.example.json templates/base_mycompany.json
templates.json lists every named template that operators can select on a NetBox prefix via the ripe_template custom field. Each entry specifies:
  • inherit — the base template file to merge attributes from.
  • attributes — a list of template-specific attribute overrides, typically just a descr field that identifies the use case.
templates.json
{
    "templates":
    {
        "CLOUD-POOL": {"attributes": [
            {"descr": "MyCompany Cloud Pool"}
        ],
            "inherit": "base_mycompany.example.json"
        },
        "INFRA-TRANSFER-NET": {"attributes": [
            {"descr": "MyCompany Infrastructure Transfer Network"}
        ],
            "inherit": "base_mycompany.example.json"
        },
        "CUST-ACCESS-NET": {"attributes": [
            {"descr": "MyCompany Customer Access"}
        ],
            "inherit": "base_mycompany.example.json"
        },
        "CUST-ACCESS-NET-MYCUSTOMER1": {"attributes": [
            {"descr": "MyCustomer 1 Ltd., Example Street 33"}
        ],
            "inherit": "base_mycustomer1.example.json"
        }
    }
}
Template names must be unique across the file and are matched case-insensitively (the application uppercases the value from the NetBox webhook before lookup).Create this file by copying the example:
cp templates/templates.example.json templates/templates.json
Every template name in templates.json must also be added as a choice on the ripe_template custom field in NetBox. Without this, operators cannot select the template from the prefix edit form.

​
How inheritance works

When a webhook arrives for a prefix, the application:
  1. Reads the template entry from templates.json that matches the ripe_template field on the prefix.
  2. Loads the inherit base template file and collects its attributes.
  3. Merges the template-level attributes with the base attributes. Template-level attributes take precedence over base attributes with the same key (with the exception of descr and country, which can appear multiple times).
  4. Prepends the dynamically generated attributes: the prefix itself (as inetnum or inet6num), netname (set to the template name), org (resolved from the LIR mapping or from the base template), and country (resolved from the site region hierarchy).
  5. Appends the status attribute last.
This means you can override any base attribute by including the same key in the template’s attributes list, and you can add attributes that do not exist in the base at all.

​
The {"org": ""} placeholder

Including {"org": ""} (an empty string value) in a base template tells the application to substitute the org attribute with the RIPE organisation handle resolved from the lir_org.json mapping for the aggregate that contains the prefix. This is the recommended approach for your own LIRs, because it keeps the organisation reference in one place. If you hard-code {"org": "ORG-EXAMPLE1-RIPE"} instead, that value is used directly and no lookup is performed. Use this when the organisation handle is always the same regardless of which LIR owns the aggregate — for example, for a customer who has their own RIPE organisation.

​
TEST database attribute patching

When RIPE_DB=TEST, the application automatically rewrites the following attributes in every generated object before submitting it to the RIPE test database. This is necessary because your production RIPE objects (maintainers, organisations, persons) are not present in the test database.
AttributeReplaced with
orgValue of RIPE_TEST_ORG
mnt-by, mnt-ref, mnt-lower, mnt-domains, mnt-routes, mnt-irtValue of RIPE_TEST_MNT
admin-c, tech-c, abuse-cValue of RIPE_TEST_PERSON
sourceTEST
status (IPv4)Value of RIPE_TEST_STATUS_V4
status (IPv6)Value of RIPE_TEST_STATUS_V6
This patching happens after template merging, so your production values can remain in the template files. You do not need separate template files for TEST and RIPE databases.
The provided .env.example file is pre-configured to work with the example template files against the RIPE TEST database. You can use these together to validate your setup before switching RIPE_DB to RIPE for production.

Build docs developers (and LLMs) love

Get started for freeTalk to us