Skip to content

README.md

Latest commit

 

History

History
590 lines (430 loc) · 29.6 KB

README.md

File metadata and controls

590 lines (430 loc) · 29.6 KB
Raw

MidPoint Changeset Scripts

Automatisering van MidPoint configuratie-overdracht tussen omgevingen (DEV → TEST → ACC → PROD) via ninja.sh, Docker en SSH.

Inhoud

Bestand Doel
midpoint-pipeline-config.json Centrale configuratie voor alle omgevingen en scripts
deploy-midpoint-scripts.sh Eenmalige uitrol van de scripts naar alle omgevingen
run-midpoint-pipeline.sh Interactieve pipeline: exporteren, deployen, promoten, opruimen, vergelijken
export-midpoint-config.sh Alleen export uitvoeren (ook zelfstandig bruikbaar)
transfer-midpoint-export.sh Alleen transfer uitvoeren (ook zelfstandig bruikbaar)
import-midpoint-config.sh Alleen import uitvoeren (ook zelfstandig bruikbaar)
compute-delta.py Delta-berekening tussen twee full exports (semantisch — negeert metadata, runtime-velden, prefix-rotatie)
compare-changeset-env.py Vergelijk changeset met live MidPoint-omgeving via REST API
midpoint_xml_compare.py Gedeelde Python-module met XML-vergelijkingslogica voor compute-delta.py en compare-changeset-env.py
strip-runtime-fields.py Verwijdert top-level runtime-velden uit TaskType/ResourceType XMLs bij export, zodat geïmporteerde tasks niet als "voltooid" worden herkend en direct opgeruimd door MidPoint's Cleanup-task
RECOMPUTE-2026-05-01.md Bewijs-rapport hergeneratie historische deltas (na PR #52/#53): per delta de oude/nieuwe tellers en lijst geëlimineerde fantoom-bestanden

Vereisten

Op de source host (midpoint-dev):

  • jq — JSON verwerking
  • python3 — delta-berekening (compute-delta.py) en vergelijking (compare-changeset-env.py)
  • curl — GitHub downloads
  • scp / ssh — toegang tot remote hosts (sleutelgebaseerd, zonder wachtwoord)
  • docker — toegang tot de MidPoint containers (gebruiker in docker groep)

Op alle remote hosts (midpoint-tst, etc.):

  • docker — toegang tot de MidPoint containers (gebruiker in docker groep)

GitHub:

  • Een Personal Access Token (PAT) met leesrechten op de repository Fortigi/MidPoint-training

Stap 0 — Inrichten van een nieuwe omgeving

Doe deze stappen eenmalig per host (Linux VM, getest op Debian/Ubuntu) voordat de pipeline kan worden gebruikt.

0.1 — Basistools en Docker

Op de host als root of via sudo:

apt-get update
apt-get install -y docker.io docker-compose-plugin jq curl
usermod -aG docker <gebruiker>     # bv. midpoint; daarna eenmalig uit/inloggen

0.2 — MidPoint zelf installeren via midpoint-quickstart.sh

Het Evolveum-quickstart-script bouwt zelf de Docker-compose-stack (server + Postgres). Zie ook de MidPoint Quick Start Guide. Haal het naar de home-directory van je gebruiker:

curl -O https://raw.githubusercontent.com/Evolveum/midpoint-docker/master/midpoint-quickstart.sh
chmod +x midpoint-quickstart.sh

Verplichte heap-tuning voor wie met realistische resources werkt (zoals AD-resources met grote schemas): voeg MP_MEM_MAX=4096m en MP_MEM_INIT=2048m toe aan het environment-blok van service midpoint_server in de getDockerCompose-functie van het script. Met de default 1/2 GB knalt MidPoint bij ResourceType-open op een AD-schema van ~32 MB direct OOM.

sed -i "/- MP_NO_ENV_COMPAT=1$/a\     - MP_MEM_MAX=4096m\n     - MP_MEM_INIT=2048m" \
  ~/midpoint-quickstart.sh

Aanbeveling Proxmox/VM-resources: 8 GiB RAM, 6 vCPU, 30 GB disk. Daarmee past 4 GB heap + Postgres + buffer comfortabel.

Start daarna de stack:

~/midpoint-quickstart.sh start

Het admin-wachtwoord wordt eenmalig gegenereerd en getoond in de output (en bewaard in ~/midpoint-home/init_pw). Noteer hem voor de pipeline-config.

0.3 — Truststore voorbereiden voor LDAPS-resources (optioneel)

Voor resources die via LDAPS verbinden (bv. AD), import het DC-certificaat in de MidPoint-truststore:

CID=$(docker ps -q --filter name=midpoint_server | head -1)
docker cp dc-certificate.pem "$CID":/tmp/dc-certificate.pem
docker exec "$CID" /usr/lib/jvm/java-21-openjdk/bin/keytool -importcert \
  -keystore /opt/midpoint/var/keystore.jceks -storetype jceks -storepass changeit \
  -alias <bondige-alias> -file /tmp/dc-certificate.pem -noprompt
~/midpoint-quickstart.sh down && ~/midpoint-quickstart.sh up   # truststore wordt bij start geladen

0.4 — SSH-toegang inrichten vanaf de source host

Vanaf midpoint-dev (of de host die je als source kiest) een sleutel zonder wachtwoord uitwisselen met elke remote host:

# Op midpoint-dev:
ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519        # sla over als sleutel al bestaat
ssh-copy-id <gebruiker>@midpoint-tst                     # idem voor acc, prod, ...

Test daarna ssh <gebruiker>@midpoint-tst zonder dat er een wachtwoord wordt gevraagd.

0.5 — GitHub Personal Access Token regelen

Maak een PAT in GitHub → Settings → Developer settings → Personal access tokens met scope repo (of fine-grained: Contents: Read op Fortigi/MidPoint-training). Bewaar de token alleen lokaal; gebruik hem in deploy-midpoint-scripts.sh als die erom vraagt.

0.6 — Eerste keer pipeline-scripts op midpoint-dev krijgen

Op een schone source-host staat deploy-midpoint-scripts.sh nog niet — dus haal de scripts één keer handmatig op:

mkdir -p ~/midpoint-tools && cd ~/midpoint-tools
curl -H "Authorization: Bearer <PAT>" \
  -L https://api.github.com/repos/Fortigi/MidPoint-training/tarball/master | \
  tar -xz --strip-components=2 --wildcards "*/Scripts/*"
chmod +x *.sh

Daarna kun je deploy-midpoint-scripts.sh gebruiken om dezelfde scripts naar alle remote hosts te pushen — zie Stap 2.

0.7 — Pipeline-config bijwerken

Voeg de nieuwe omgeving toe aan midpoint-pipeline-config.json (zie Stap 1 voor de structuur). Vul host, ssh_user, container_id en ssh_port correct in en zet de naam in pipeline.active_environments als hij meedoet.

Het juiste container_id haal je op met:

ssh <gebruiker>@<host> 'docker ps --filter name=midpoint_server --format "{{.ID}}"'

Let op: de container_id verandert bij elke down+up van de quickstart. De pipeline detecteert hem live via docker ps als het veld leeg is in de config, dus je hoeft de waarde niet bij te houden tenzij je hem voor andere redenen wilt vastleggen.

Stap 1 — Configuratie aanpassen

Pas midpoint-pipeline-config.json aan voor jouw omgeving:

{
  "github": {
    "account": "admin@demo.local",
    "repo": "Fortigi/MidPoint-training",
    "branch": "master",
    "scripts_subdir": "Scripts"
  },
  "pipeline": {
    "chain": ["dev", "test", "acc", "prod"],
    "active_environments": ["dev", "test"]
  },
  "export": {
    "mode": "delta",
    "archive_dir": "~/midpoint-archive"
  },
  "environments": {
    "dev": {
      "host": "midpoint-dev",
      "ssh_user": "midpoint",
      "container_id": "138470c613f4",
      ...
    }
  }
}

Aandachtspunten:

  • active_environments bepaalt welke omgevingen meedoen in de pipeline en deployment.
  • Omgevingen met "PLACEHOLDER" als host of container_id worden automatisch overgeslagen.
  • export.mode bepaalt de standaard exportmodus: "delta" of "full".
  • export.archive_dir is de locatie van het changeset-archief op de source host.

Stap 2 — Scripts uitrollen naar alle omgevingen

Voer dit eenmalig uit vanaf midpoint-dev nadat de scripts zijn bijgewerkt in GitHub:

cd ~/midpoint-tools
./deploy-midpoint-scripts.sh

Het script vraagt om een GitHub Personal Access Token (verborgen input), valideert dit, en deployt daarna de scripts naar alle geselecteerde omgevingen.

Opties:

# Interactief selecteren welke omgevingen
./deploy-midpoint-scripts.sh

# Alle active_environments in één keer
./deploy-midpoint-scripts.sh --all

# Eén specifieke omgeving
./deploy-midpoint-scripts.sh --env test

Stap 3 — Pipeline uitvoeren

Voer dit uit vanaf midpoint-dev (buiten de container):

cd ~/midpoint-tools
./run-midpoint-pipeline.sh

Het script toont een interactief hoofdmenu:

Wat wil je doen?
  1) Nieuwe changeset exporteren  (-> DRAFT_T, altijd FULL + DELTA)
  2) Bestaande changeset deployen
  3) Changeset promoten
  4) Overzicht changesets
  5) Changeset opruimen
  6) Wat mis ik?  (changeset vs live omgeving)
  7) Omgeving leegmaken
  8) Afsluiten

In sub-menu's is altijd 0) Terug naar hoofdmenu beschikbaar om zonder actie terug te keren.

Changeset-levenscyclus

Elke changeset doorloopt een statustraject via naamprefix in het archief (~/midpoint-archive/):

DRAFT_T_FULL_<naam>-<timestamp>   ->  alleen deploybaar naar test
         (menu-optie 3: promoten)
DRAFT_A_FULL_<naam>-<timestamp>   ->  alleen deploybaar naar acceptatie
         (menu-optie 3: promoten)
FULL_<naam>-<timestamp>           ->  klaar voor productie (geen prefix)

Hetzelfde geldt voor delta-changesets (DELTA_ i.p.v. FULL_).

Naamgeving:

  • Naam is altijd verplicht (ook bij full exports)
  • Spaties in de naam worden automatisch omgezet naar koppeltekens
  • Timestamp formaat: YYYYMMDD_HHMMSS

Deltalogica:

  • Een delta wordt altijd berekend t.o.v. de meest recente gepromoveerde full export (zonder prefix)
  • Als er geen gepromoveerde full export bestaat, wordt automatisch overgeschakeld naar een full export
  • compute-delta.py detecteert nieuwe, gewijzigde en verwijderde objecten via semantische XML-vergelijking. De volgende drift-bronnen worden genegeerd, omdat ze tussen exports rouleren maar functioneel niets betekenen:
    • Metadata (_metadata, operationExecution, fetchResult, version, ...) — administratie
    • Runtime-velden in TaskType (progress, lastRunStartTimestamp, operationStats, executionState, resultStatus, ...) en ResourceType (schema-cache, capabilities)
    • Blanco regels in tekst-content (groovy-scripts, documentation-blokken)
    • XML-namespace-prefix-rotatie (gen63/qn672 → gen989/qn588) — door QName-resolutie naar URI's
    • connectorRef/@oid in ResourceType — wordt door de import sowieso geremapt naar de doelomgeving op basis van connector-identity
  • ConnectorType wordt gematcht op identity-tuple (connectorBundle, connectorType, connectorVersion, framework) in plaats van filename. MidPoint genereert nieuwe OIDs per herregistratie; filename-matching zou anders alle connectors als nieuw markeren.

Hergeneratie historische deltas (eenmalig, 2026-05-01): alle vier prod-deltas die vóór PR #52 met byte-vergelijking zijn berekend, zijn opnieuw gegenereerd met de semantische logica. De hergegenereerde versies hebben de oorspronkelijke directory-naam (DELTA_<naam>-<timestamp>/) en oorspronkelijke display_name — dit zijn de canonieke versies. De originelen zijn ernaast bewaard met afwijkende namen, zodat ze in het overzicht (menu 4) direct herkenbaar zijn:

  • directory-suffix _LEGACY_BYTECMP;
  • display_name suffix [legacy byte-cmp];
  • extra velden algorithm: "byte-cmp (legacy)" en superseded_by: <canonieke-naam> in meta.json;
  • een LEGACY_BYTECMP.md marker-bestand met verwijzing en aanmaak-timestamp.

Bewijs per delta — oude vs. nieuwe tellers en de lijst van geëlimineerde fantoom-bestanden — staat in RECOMPUTE-2026-05-01.md. De DRAFT_A-delta is bewust niet hergegenereerd (zie het rapport).

Runtime-veld-stripping bij export: voor TaskType en ResourceType worden top-level runtime-velden door export-midpoint-config.sh gestript via strip-runtime-fields.py (gedreven door dezelfde TYPE_RUNTIME_FIELDS-lijst uit midpoint_xml_compare). Reden: zonder deze stap krijgt een geïmporteerde task velden als executionState=closed, schedulingState=closed en completionTimestamp=<oud> mee. MidPoint's Cleanup-task ziet zulke tasks dan als "voltooide eenmalige tasks van X dagen geleden" en verwijdert ze direct. Voor ResourceType wordt de gecachte schema en capabilities gestript — die wordt door MidPoint zelf opnieuw opgehaald bij de eerste connector-verbinding. De helper is byte-stabiel: alleen de te schrappen elementen worden verwijderd, namespace-declaraties en default namespace blijven intact (downstream-scripts zoals import-midpoint-config.sh doen regex-matches die anders breken). Bestaande archieven (FULLs en deltas) zijn op 2026-05-01 eenmalig door de helper geprocesseerd zodat ze opnieuw deploybaar zijn.

Namespace-prefix-onafhankelijke regex in import-midpoint-config.sh: extract_first_tag_value, extract_attr_value en rewrite_resource_connector_ref accepteren zowel default-namespace (<connectorRef ...>) als prefix-vorm (<c:connectorRef ...>). Dat houdt het script robuust tegen exporters of post-processing tools die de XML-formattering wijzigen.

Menu-opties

Optie 1 — Nieuwe changeset exporteren

Exporteert de huidige configuratie uit de dev-container en archiveert altijd zowel een FULL als een DELTA changeset met dezelfde naam. De DELTA wordt berekend t.o.v. de meest recente gepromoveerde full baseline. Als er geen baseline is, wordt alleen de FULL aangemaakt.

  Naam      : Mijn Baseline
  FULL      : DRAFT_T_FULL_Mijn-Baseline-20260329_120000
  DELTA     : DRAFT_T_DELTA_Mijn-Baseline-20260329_120000
  Basis op  : FULL_Vorige-Baseline-20260320_090000

Na een succesvolle import staat het volledige pad naar SECRETS_TO_RESTORE.md in de output:

  - Raadpleeg /home/midpoint/midpoint-archive/DRAFT_T_FULL_Mijn-Baseline-.../SECRETS_TO_RESTORE.md

Optie 2 — Bestaande changeset deployen

Toont een overzicht van alle actieve omgevingen inclusief dev (bron). Na omgevingskeuze verschijnt een gefilterde tabel van changesets (gesorteerd op datum, nieuwste eerst):

Omgeving Zichtbare changesets
Dev (bron) Alle changesets (geen statusbeperking)
Test Alle changesets (DRAFT_T_*, DRAFT_A_* en prod-ready)
Acceptatie DRAFT_A_* en prod-ready (geen DRAFT_T_*)
Prod Alleen changesets zonder prefix (prod-ready)

Dev-deploys verlopen volledig lokaal (geen SSH of SCP): de transfer en import worden direct uitgevoerd op de bronhost via docker cp en docker exec. Dit maakt het mogelijk een changeset op dev te herimporteren, bijvoorbeeld na een reset of om een bekende staat terug te zetten.

Optie 3 — Changeset promoten

Hernoemt de changeset-directory in het archief (gesorteerd op datum, nieuwste eerst):

DRAFT_T_FULL_Mijn-Baseline-20260329_120000
  -> DRAFT_A_FULL_Mijn-Baseline-20260329_120000

DRAFT_A_FULL_Mijn-Baseline-20260329_120000
  -> FULL_Mijn-Baseline-20260329_120000

Optie 4 — Overzicht changesets

Toont alle changesets in het archief (gesorteerd op datum, nieuwste eerst) met status, type, naam (max. 40 tekens), datum, objectaantal en basis:

  STATUS     TYPE    NAAM                                     DATUM             OBJECTEN       BASIS
  ---------- ------- ---------------------------------------- ----------------- -------------- --------------------
  DRAFT_T    DELTA   Mijn wijziging                           2026-03-29 14:00  N:1 M:2 D:0    FULL_Mijn-Baseline-...
  prod       FULL    Mijn Baseline                            2026-03-29 12:00  38             -

Optie 5 — Changeset opruimen

Toont alle changesets in het archief en laat je er één verwijderen. Vraagt om bevestiging vóór verwijdering.

Optie 6 — Wat mis ik?

Vergelijkt een geselecteerde changeset met de live stand van een doelomgeving via de MidPoint REST API. Het script:

  1. Haalt het MidPoint-wachtwoord automatisch op van de doelhost (~/midpoint-home/init_pw)
  2. Vraagt optioneel of metadata-velden meegenomen moeten worden in de vergelijking
  3. Haalt alle bekende configuratietypen op uit de omgeving (niet alleen de types die in de changeset voorkomen), zodat ook objecten worden ontdekt die buiten de changeset-pipeline om zijn aangemaakt
  4. Vergelijkt in beide richtingen en op inhoud:
    • Objecten in de changeset die ontbreken in de omgeving
    • Objecten in de omgeving die niet in de changeset staan
    • Objecten die in beide voorkomen maar qua configuratie verschillen

Omgevingsscan — uitgesloten types: De volgende types worden nooit breed gescand in de omgeving, ook al staan ze in de changeset:

Type Reden
UserType, ShadowType Identiteitsdata; potentieel duizenden objecten
OrgType, RoleType, ServiceType Aangemaakt via sync-taken; niet representatief voor config
ArchetypeType, MarkType MidPoint built-in systeemobjecten; worden nooit via de pipeline geëxporteerd

Als een uitgesloten type wél in de changeset staat, worden die specifieke objecten alsnog via OID vergeleken op inhoud. Alleen de richting omgeving→changeset is dan niet mogelijk.

Filtering (standaard aan): De volgende velden worden standaard uitgefilterd om valse positieven te voorkomen:

Categorie Gefilterde velden
Metadata (alle types) metadata, fetchResult, operationExecution, trigger, _metadata, version-attribuut
TaskType runtime lastRunStartTimestamp, lastRunFinishTimestamp, completionTimestamp, operationStats, activityState, result
ResourceType runtime schema, capabilities, iteration, iterationToken, operationalState, operationalStateHistory
LookupTableType row — MidPoint REST API retourneert rijen altijd als @incomplete; vergelijking niet mogelijk

Via de vraag in het menu (Inclusief metadata? [j/N]) zijn metadata-velden optioneel mee te nemen. Type-specifieke runtime-velden worden altijd weggefilterd.

Voorbeeld output:

  30 object(en) controleren tegen midpoint-tst:8080 ...
  Let op: LookupTable-rijen worden niet vergeleken (MidPoint REST API retourneert rijen altijd als @incomplete).

  Omgeving ophalen (16 objecttype(n)) ...
    → ConnectorHostType ... 0 object(en)
    → ConnectorType ... 7 object(en)
    → DashboardType ... (geen endpoint)
    → FormType ... 0 object(en)
    → LookupTableType ... 5 object(en)
    → ObjectTemplateType ... 2 object(en)
    → ReportType ... 13 object(en)
    → ResourceType ... 2 object(en)
    → SchemaType ... 2 object(en)
    → SystemConfigurationType ... 1 object(en)
    → TaskType ... 5 object(en)
    ...

  ──────────────────────────────────────────────────────────────
  IN CHANGESET, ONTBREEKT IN OMGEVING  (7 object(en))
  ──────────────────────────────────────────────────────────────
    [ConnectorType]
      - Built-in ManualConnector v1.0.0  (01613417-...)
      - ConnId com.evolveum.polygon.connector.csv.CsvConnector v2.8  (3412e855-...)
      - ConnId org.identityconnectors.databasetable.DatabaseTableConnector v1.5.2.0  (55f6a291-...)
      ...

  ──────────────────────────────────────────────────────────────
  IN OMGEVING, ONTBREEKT IN CHANGESET  (17 object(en))
  ──────────────────────────────────────────────────────────────
    [ConnectorType]
      - Built-in ManualConnector v1.0.0  (d4c091a7-...)
      - ConnId com.evolveum.polygon.connector.csv.CsvConnector v2.8  (d54ddd2b-...)
      ...
    [ObjectTemplateType]
      - Organization template for HR Context hierarchy  (56bf2c20-...)
    [ResourceType]
      - HR demo Context  (65fc6753-...)
      - HR demo users  (49ad23ba-...)
    [SchemaType]
      - demoOrgExtension  (31870dac-...)
      - demoShadowExtension  (94ee1de2-...)
    [TaskType]
      - Cleanup  (00000000-...)
      - Import HR Demo identities  (f88fb118-...)
      - HR demo Context import  (5ae8304e-...)
      ...

  ──────────────────────────────────────────────────────────────
  CONFIGURATIEVERSCHILLEN  (1 object(en))
  ──────────────────────────────────────────────────────────────
    [SystemConfigurationType]

      ● SystemConfiguration  (00000000-0000-0000-0000-000000000001)

        Blokken met verschil (1):
          • defaultObjectPolicyConfiguration

        Velden (1):
          defaultObjectPolicyConfiguration
            changeset : '(ontbreekt)'
            omgeving  : 'ref:56bf2c20…'

  ──────────────────────────────────────────────────────────────
  IDENTIEK IN BEIDE  (22 object(en))
  ──────────────────────────────────────────────────────────────
    [LookupTableType]
      - Languages  (00000000-0000-0000-0000-000000000200)
      - Lifecycle States  (00000000-0000-0000-0000-000000000230)
      ...
    [ReportType]
      - All audit records report  (00000000-0000-0000-0000-000000000080)
      ...

  ──────────────────────────────────────────────────────────────
  SAMENVATTING
  ──────────────────────────────────────────────────────────────
    Identiek in beide                    : 22
    Aanwezig in beide, met verschil      : 1
    In changeset, ontbreekt in omgeving  : 7
    In omgeving, ontbreekt in changeset  : 17

Verwachte (niet-problematische) verschillen na een correcte import:

Verschil Reden
ConnectorType OID-mismatches MidPoint genereert per herstart nieuwe OIDs; dit is verwacht gedrag
connectorRef/@oid in resources Verwijst naar de lokale connector-OID; altijd verschillend per omgeving
connectorConfiguration/.../password, .../bindPassword, .../clientSecret, etc. REST API retourneert nooit secret-waarden; exportbestand bevat ook geen secrets meer na masking
Cleanup, Trigger Scanner, Validity Scanner tasks MidPoint systeem-taken; automatisch aangemaakt, niet in changeset

Cosmetische verschillen worden automatisch gefilterd in compare-changeset-env.py (zie PATH_SKIP_ATTRS / TYPE_RUNTIME_FIELDS), o.a. connectorConfiguration/@type (xsi:type-attribuut dat REST-API weglaat) en definition/schema/@space (XML whitespace-attribuut).

Prism _value wrapper: MidPoint schrijft in changeset XML soms <element><_value>x</_value></element> terwijl de REST API <element>x</element> retourneert. Het compare-script normaliseert beide vormen automatisch zodat dit geen valse verschillen geeft.

Blanco regels in script-tekst: De REST API verwijdert blanco regels uit tekst-content (bv. groovy-scripts in ReportType en documentation-blokken in ObjectTemplateType), terwijl de changeset-XML ze behoudt. Het compare-script collapsed daarom opeenvolgende blanco regels naar één newline (functie _normalize_text) vóór vergelijking. Inspringing per regel blijft intact — alleen whitespace-only regels worden geraakt.

Optie 7 — Omgeving leegmaken

Reset een omgeving volledig en start hem daarna opnieuw op. Het script detecteert automatisch het nieuwe Docker container ID en werkt dit bij in de lokale config én in GitHub.

Stappen:

  1. Selecteer de te resetten omgeving uit active_environments
  2. Voor acc en prod: extra bevestiging vereist (typ de omgevingsnaam)
  3. JAR-bestanden veiligstellen uit de huidige container (live gedetecteerd via docker ps): zowel /opt/midpoint/var/lib/ als /opt/midpoint/var/icf-connectors/ worden gescand op *.jar bestanden
  4. midpoint-quickstart.sh clean-db uitvoeren — stopt containers en verwijdert volumes (inclusief de PostgreSQL-database). Uitgevoerd vanuit de directory van het quickstart script zodat het juiste Docker Compose project wordt aangesproken.
  5. midpoint-quickstart.sh start uitvoeren (idem) — initialiseert een verse omgeving
  6. Nieuw container ID detecteren via docker ps
  7. JAR-bestanden terugplaatsen via ~/midpoint-home/lib/ op de host (Docker volume-mount, persistent na restart) en container herstarten
  8. midpoint-pipeline-config.json lokaal bijwerken en pushen naar GitHub (PAT vereist)

Waarom clean-db en niet reset? Het commando reset verwijdert alleen ~/midpoint-home maar laat het PostgreSQL-volume intact. Na een verse start genereert MidPoint een nieuwe keystore waarmee de oude versleutelde credentials in de database niet meer leesbaar zijn — inloggen is dan onmogelijk. clean-db wist ook de database zodat alles consistent opnieuw initialiseert.

Locatie quickstart script: Configureerbaar via quickstart_script per omgeving in midpoint-pipeline-config.json (standaard: ~/midpoint-quickstart.sh).

JAR-bestanden: Connector-drivers (bijv. mssql-jdbc-13.2.1.jre11.jar) worden automatisch veiliggesteld vóór de reset (uit /opt/midpoint/var/lib/ en /opt/midpoint/var/icf-connectors/) en teruggezet via ~/midpoint-home/lib/ na de start (deze map is via Docker volume gemount als /opt/midpoint/var/lib/ in de container). Hierdoor blijven resources zoals SQL Server-connecties werkend na een reset zonder handmatige stap.

Let op: Als de JAR na een reset ontbreekt, is ~/midpoint-home/lib/mssql-jdbc-*.jar op de host de herstellocatie. De JAR kan ook tijdelijk op /tmp/ staan als fallback.

Na het leegmaken:

  • Wacht tot MidPoint volledig is opgestart (http://<host>:8080)
  • Importeer een changeset via menu-optie 2

Automatisch doorlopen (CI/scripts)

# Export + deploy naar test zonder bevestigingsvragen (maakt altijd FULL + DELTA aan)
./run-midpoint-pipeline.sh --auto

# Met expliciete naam
./run-midpoint-pipeline.sh --name "Release 1.0" --auto

# Alleen overzicht tonen
./run-midpoint-pipeline.sh --list

Losse scripts (handmatig gebruik)

Export

Draait in de source container:

./export-midpoint-config.sh \
  --config /opt/midpoint-tools/midpoint-pipeline-config.json \
  --env dev

De export wordt opgeslagen in /tmp/midpoint-export/<timestamp>/ met de structuur:

<timestamp>/
  raw/          # Originele export per type
  clean/        # Opgeschoonde XML (metadata verwijderd)
  split/        # Losse bestanden per object
  logs/         # Logbestanden per type
  manifest.txt  # Overzicht van de export
  SECRETS_TO_RESTORE.md  # Welke secrets na import hersteld moeten worden

Secret-masking (export): Alle <protectedString>, <encryptedData>, en <clearValue> elementen worden gemaskeerd, ongeacht namespace-prefix (t:, c:, zonder prefix) en ongeacht parent-element. De maskering werkt op álle geëxporteerde objecttypen — niet alleen ResourceType. Hierdoor worden onder andere de volgende secret-dragende velden veilig afgedekt:

  • Connector credentials: password, bindPassword, authenticatorPassword, bindCredentials
  • REST-API credentials in connector/expression configuratie: clientSecret, accessToken, refreshToken, secretKey, apiKey
  • SMTP-wachtwoorden in SystemConfigurationType/notificationConfiguration
  • Credentials in MessageTemplateType, TaskType of overige ProtectedStringType-velden

De gemaskeerde waarde wordt vervangen door <t:encryptedData>***MASKED***</t:encryptedData> zodat SECRETS_TO_RESTORE.md automatisch de plekken kan terugvinden waar handmatig een waarde ingevuld moet worden na import.

Secret-strip (import): Als veiligheidsnet verwijdert het import-script alle secret-elementen uit de XML voordat ninja.sh het object importeert — ook op niet-ResourceType bestanden. Dit voorkomt dat ciphertext van een vreemde keystore MidPoint bereikt en als "unencrypted" wordt geïnterpreteerd.

Import

Draait in de target container:

./import-midpoint-config.sh \
  --config /opt/midpoint-tools/midpoint-pipeline-config.json \
  --env test \
  --import-root /tmp/midpoint-import-source/DRAFT_T_FULL_naam-timestamp

Na de import

Na een succesvolle import dienen de connector wachtwoorden handmatig ingevuld te worden via de MidPoint GUI. Raadpleeg SECRETS_TO_RESTORE.md voor een overzicht van welke wachtwoorden hersteld moeten worden.

SchemaType objecten: Als de changeset SchemaType-objecten bevat (schema-extensies), herstart het script automatisch de doelcontainer na de import en wacht totdat de container weer healthy is. MidPoint laadt schema-extensies alleen bij opstart — zonder herstart zouden taken die gebruikmaken van custom attributen (bijv. extension/businessKey) mislukken.

Configuratie uitbreiden (ACC / PROD)

Wanneer ACC of PROD beschikbaar komen:

  1. Vervang de PLACEHOLDER waarden in midpoint-pipeline-config.json
  2. Voeg de omgeving toe aan active_environments
  3. Commit en push naar GitHub
  4. Voer deploy-midpoint-scripts.sh opnieuw uit
"active_environments": ["dev", "test", "acc"]

Bronnen

De scripts zijn gebaseerd op de volgende Jupyter notebooks in deze repository:

  • Midpoint-quickstart-guides/7 - Midpoint config export documentation.ipynb
  • Midpoint-quickstart-guides/8 - Midpoint config import documentation.ipynb
  • Midpoint-quickstart-guides/9 - MidPoint Pipeline Management.ipynb

Zie ook: GUARDRAILS.md voor het branch- en werkproces.