Een tweede paneel koppelen

Een tweede merk is een tweede CoreCP-installatie. Het draait dezelfde software, installeert dezelfde pakketten uit dezelfde bron — en deelt verder niets. Eigen database, eigen klanten, eigen sleutels, eigen certificaatautoriteit, eigen huisstijl.

Wat het eerste paneel (de primary) wél van het tweede (de replica) weet: welke versie het draait, of het gezond is, in welk kanaal en welke golf het zit, en of de licentie loopt. Verder niets. Dat is geen afspraak die je kunt vergeten: het paneel aan de andere kant heeft simpelweg geen commando dat een klantgegeven kan teruggeven.

Alleen beheerders zien dit. Resellers en eindklanten merken er niets van.

Wat je nodig hebt

• Een tweede server. Kaal mag: een verse Ubuntu 26.04 met root-toegang is genoeg — sinds de plakregel hieronder installeert die machine CoreCP zelf. Draait er al een paneel, dan kan dat ook; dan koppel je alleen.
• Een domeinnaam voor die machine die publiek resolvet. Zonder DNS-record krijgt hij geen Let's Encrypt-certificaat en serveert hij een zelfondertekend exemplaar tot je het record publiceert.
• Uitgaand HTTPS van die machine naar poort 8443 van dit paneel, en naar packages.corecp.dev. Inkomend hoeft er niets open: die machine belt naar buiten, nooit andersom.
• Ongeveer 10 GB vrije schijfruimte; de installatie controleert het en zegt het als het krap is.

Twee werelden, en de regel die ze overbrugt

Installeren en koppelen blijven twee verschillende dingen op twee verschillende plekken — dezelfde scheiding die Plesk 360 en Rancher maken. Wat erbij is gekomen, is een regel die ze in één handeling doet:

De derde regel verandert niets aan de eerste twee. Dit paneel installeert nog steeds nooit iets op de andere machine en heeft er nooit een inlog voor: het geeft een regel om te plakken, en wie daar root heeft, plakt hem. Alles wat er daarna gebeurt, belt van díé machine naar dit paneel — nooit andersom.

De korte weg: in het paneel

Vloot → Gekoppelde panelen → Paneel koppelen. Alleen voor beheerders — een reseller ziet het menu-item niet, en de API weigert de routes erachter ongeacht wat het zijmenu toont.

1. Geef het paneel een korte identificatie (panel2), een naam voor in de lijst, en het kanaal en de golf waarin het updates krijgt.
2. Beantwoord "Wat staat er op de andere machine?":

• Nog niets — een kale Ubuntu-server: je krijgt de plakregel die installeert én koppelt.
• Er draait al een CoreCP-paneel: je krijgt de regel die alleen koppelt. Je krijgt allebei de regels te zien; deze keuze zet alleen de juiste bovenaan (de andere staat eronder, achter De andere regel). Dezelfde code werkt voor allebei.

1. Optioneel: pin het op een IP-adres — het uitgaande adres van de andere machine. Een koppeling vanaf een ander adres wordt dan geweigerd.
2. Klik op Code uitgeven. Het paneel toont de exacte regel, met een kopieerknop en een aflopende geldigheid:

curl -fsSL https://get.corecp.dev | CORECP_PANEL=1 CORECP_CONNECT_CODE=corecpf1.eyJ2IjoxLCJwIjoicGFuZWwyIiwi… bash

of, op een machine waar al een paneel draait:

corecp-panel connect --code corecpf1.eyJ2IjoxLCJwIjoicGFuZWwyIiwi…

De code wordt één keer getoond. Alleen een hash ervan is bewaard, dus dit is de enige plek waar hij ooit staat. Kwijt? Geef gewoon een nieuwe uit voor hetzelfde paneel — verder hoeft er niets opnieuw. Koppelcode intrekken maakt hem meteen waardeloos.

1. Plak de regel op de andere machine, als root. En kijk dan naar het scherm: de voortgangskaart vult zich terwijl het gebeurt, fase voor fase.

De voortgangskaart

Zes fasen, in deze volgorde. Die machine meldt ze zelf, naar buiten toe — dit paneel kijkt niet mee op die server en kan dat ook niet.

Gaat er iets mis, dan blijft de kaart staan op de fase waar het misging, met de foutmelding en een uitklapbaar logboek eronder. Je kunt dan een nieuwe code uitgeven en het opnieuw proberen; er hoeft niets opgeruimd te worden.

Een geslaagde koppeling toont daarna de versie, de gezondheid en de vingerafdruk van de eigen server-CA van de replica.

Daarna toont de lijst elk gekoppeld paneel met versie, gezondheid, kanaal, golf en licentie. Een klik op een rij opent het: kanaal toewijzen, golf toewijzen, update starten, updates vasthouden, en — pas nadat je de naam van het paneel hebt getypt — de licentie intrekken.

Wat het scherm nooit doet. Het toont de vingerafdruk van de fleet-CA naast de server-CA van dit paneel, zodat je met eigen ogen ziet dat het twee verschillende autoriteiten zijn. Het maakt, roteert of exporteert er geen van beide: dat zijn root-handelingen in een terminal (corecp-panel panels ca). En er is nergens een knop die bij de klanten van dat andere paneel komt — de agent aan de andere kant kent geen enkele opdracht die dat zou kunnen beantwoorden.

De lange weg: in een terminal

Alles wat het scherm doet, is ook een commando — wat je wilt bij tien panelen in plaats van één. De rest van deze pagina is die weg.

Stap 1 — maak het paneel aan op de primary

$ corecp-panel panels add panel2 --name "Tweede merk" --channel beta --wave 2 \
    --config /etc/corecp-panel/panel.yaml
managed panel panel2 created (beta, wave 2)
Next: corecp-panel panels code panel2 --config /etc/corecp-panel/panel.yaml

De naam panel2 is een korte code die je zelf kiest. Hij komt terug in het certificaat en in de apt-inlognaam, dus houd hem kort en laat hem staan.

--channel is het releasekanaal: edge of beta. stable en steady worden ook geaccepteerd, maar op de pakketbron van de buildserver zijn het aliassen van beta en serveren ze precies wat beta serveert. --wave is de golf waarin dit paneel updates krijgt. Panelen zijn de buitenste ring van hetzelfde golfsysteem dat de servers gebruiken.

Stap 2 — vraag een koppelcode

$ corecp-panel panels code panel2 --ip 185.117.226.123 --ttl 15m \
    --config /etc/corecp-panel/panel.yaml
Run this on panel2, within 15m0s — on a machine with nothing on it yet:

  curl -fsSL https://get.corecp.dev | CORECP_PANEL=1 CORECP_CONNECT_CODE=corecpf1.eyJ2IjoxLCJwIjoicGFuZWwyIiwi… bash

or, on a machine that already runs corecp-panel:

  corecp-panel connect --code corecpf1.eyJ2IjoxLCJwIjoicGFuZWwyIiwi…

progress     https://panel1.corecp.dev/managed-panels/panel2
run id       0f2b1c4e-8a77-4a11-9a1e-9b0a2c7f5d31
valid until  2026-08-09T17:10:24Z
pinned to    185.117.226.123 — a connect from any other address is refused
The code is single use and is burned on the first attempt that gets past the address check.

Draait er al een paneel op de doelmachine, geef dan --installed mee: dan komt de koppelregel bovenaan en weet de voortgangskaart dat hij geen installatiefasen hoeft te verwachten.

Gebruik --ip. Zonder dat vlaggetje werkt de code vanaf elke machine; met dat vlaggetje werkt hij alleen vanaf de server die je bedoelt. Een code die iemand over je schouder meeleest is dan waardeloos.

De code is één keer te gebruiken en vervalt vanzelf. Er zit géén wachtwoord in: het apt-wachtwoord komt pas terug in het antwoord, over een verbinding die de replica al gecontroleerd heeft. Een code in een chatvenster is dus geen wachtwoord in een chatvenster.

Stap 3 — plak de regel op de andere machine

Op een kale machine

Eén regel, als root. Hij installeert en koppelt in één keer, en meldt onderweg elke fase terug aan dit paneel:

# curl -fsSL https://get.corecp.dev | CORECP_PANEL=1 CORECP_CONNECT_CODE=corecpf1.eyJ2… bash
[corecp] installing base packages
[corecp] == preflight == checking this machine before anything is installed
  ok   running as root
  ok   operating system
  ok   this machine has a domain name
  ok   free disk space
  ok   the primary panel is reachable
[corecp] == repository == adding the CoreCP package source and its key
  ok   signed apt source
[corecp] == install == installing corecp-panel and everything it runs on
== runtime packages
== service account and directories
== node certificate authority (this machine's own)
   [corecp] CA ready in /var/lib/corecp/ca
== PostgreSQL
   created database corecp_panel
== configuration
   wrote /etc/corecp-panel/panel.yaml
== database migrations
== systemd units
== nginx vhost
  ok   corecp-panel installed
[corecp] == connect == redeeming the code against the primary
connected as panel2
[corecp] == health == starting the panel and checking that it answers
  ok   corecp-panel is running
  ok   it reports to the primary

[corecp] done. This machine is a panel and it is connected.
[corecp]   its own address     https://panel2.corecp.dev
[corecp]   create an admin     corecp-panel user add --email <you> --level admin --config /etc/corecp-panel/panel.yaml

De laatste regel is geen detail: een vers paneel heeft nog geen beheerder. Maak er één aan voordat je de browser opent.

Wil je alleen installeren en later pas koppelen, laat dan de code weg:

# curl -fsSL https://get.corecp.dev | CORECP_PANEL=1 bash

Op een machine waar al een paneel draait

$ corecp-panel connect --code corecpf1.eyJ2IjoxLCJwIjoicGFuZWwyIiwi… \
    --config /etc/corecp-panel/panel.yaml
connected as panel2
  channel      beta (wave 2)
  fleet CA     739d876dc5d26c76
  its node CA  c4430ea564db75b6
  our node CA  ed466a89fea08858   (verified different — neither panel signs for the other's nodes)
  apt login    panel-panel2 at packages.corecp.dev

Restart the panel to start reporting: systemctl restart corecp-panel

Die vierde regel is de belangrijkste van deze hele pagina. De twee panelen hebben elkaar hun eigen server-CA laten zien en vastgesteld dat het er twee zijn. Waren ze gelijk geweest, dan was er geen certificaat uitgegeven en had er niets gewerkt — zo hoort het.

Daarna:

$ systemctl restart corecp-panel
$ corecp-panel connect status --config /etc/corecp-panel/panel.yaml
connected to panel1.corecp.dev:8443 as panel2
  since        2026-08-09T16:45:23Z
  channel      beta (wave 2)
  entitlement  installed
  last contact 9s ago

Het duurt tot een minuut voordat apt op de replica werkt: de buildserver haalt de lijst met geldige inloggegevens elke minuut op bij de primary.

Stap 4 — kijk vanaf de primary

$ corecp-panel panels list --config /etc/corecp-panel/panel.yaml
ID      STATE      CHANNEL  WAVE  HOLD  VERSION  HEALTH  LICENCE  LAST SEEN
panel2  connected  beta     2     no    0.14.0   ok      live     9s ago

Wat je kunt doen met een gekoppeld paneel

$ corecp-panel panels channel panel2 stable --config …   # ander releasekanaal
$ corecp-panel panels wave panel2 1 --config …           # andere golf
$ corecp-panel panels upgrade panel2 --config …          # nu bijwerken
$ corecp-panel panels hold panel2 --config …             # even geen updates
$ corecp-panel panels resume panel2 --config …           # weer wel
$ corecp-panel panels revoke panel2 --config …           # licentie intrekken
$ corecp-panel panels reinstate panel2 --config …        # licentie terug

Elk van deze is ook een bedieningselement in Vloot → Gekoppelde panelen, op dezelfde API — een vloot van veertig panelen blijft scriptbaar, en één paneel blijft een klik.

Een opdracht wordt in de wachtrij gezet en uitgevoerd zodra de replica zich weer meldt (elke 15 tot 30 seconden). Wat er echt gebeurd is, zie je terug — in de terminal, en in de lijst Openstaande opdrachten op het scherm zelf:

$ corecp-panel panels show panel2 --config … | tail -3
  DIRECTIVE  VERB          STATE  DETAIL
  1          update.apply  done   upgraded: corecp-agent 0.30.12 -> corecp-agent 0.32.7

En dat is de hele lijst. Er is geen panels accounts, geen panels sql, geen panels shell — niet omdat ze vergeten zijn, maar omdat de agent aan de andere kant er geen antwoord op heeft.

Hoe een gekoppeld paneel installeert, en wat het weigert

Een replica neemt een pakket niet aan omdat apt het aanbiedt. Vóórdat dpkg bij een bestand mag, controleert het paneel dezelfde drie dingen die een hostingserver controleert:

1. het ondertekende releasemanifest voor precies de versie die apt wil installeren klopt onder een sleutel die in de software zelf zit, niet onder een sleutel die op de pakketserver staat;
2. de versie in die handtekening is de versie die geïnstalleerd wordt;
3. het bestand dat apt heeft opgehaald heeft precies de lengte en precies de controlesom die het manifest noemt.

Klopt er één van de drie niet, dan wordt er niets geïnstalleerd en komt de opdracht terug met de zin die zegt welke:

$ corecp-panel panels show panel2 --config … | tail -2
  DIRECTIVE  VERB          STATE   DETAIL
  7          update.apply  failed  refusing the update: corecp-agent_0.32.7_amd64.deb does not
                                   match its signed SHA-512 — the file apt fetched is not the
                                   file we published

Dat is geen mislukte download. apt controleert de pakketbron; apt controleert niet de server waar die bron op staat, en dít is de controle die dat wel doet.

Een vastgezette versie gaat over één pakket. corecp-panel en corecp-agent hebben hetzelfde productversienummer, maar een pin verplaatst er maar één: een kaal nummer wordt gelezen als de versie van het paneel zelf, het nummer dat ook in de lijst staat. Bedoel je op een machine met allebei de agent, noem hem dan:

corecp-panel panels upgrade panel2 --version corecp-agent=0.50.0 --config …

Een nummer dat het paneel niet kan plaatsen wordt geweigerd, niet geraden.

Terug naar een oudere versie

Een paneel onthoudt de hoogste versie die het ooit heeft geaccepteerd, en weigert alles daaronder. Een ondertekend maar ouder pakket is precies de manier waarop een vloot wordt teruggezet op een gat dat al gedicht was — dus "ouder" is standaard een weigering:

$ corecp-panel panels upgrade panel2 --version 0.30.12 --config …
$ corecp-panel panels show panel2 --config … | tail -2
  DIRECTIVE  VERB          STATE   DETAIL
  8          update.apply  failed  refusing the update: corecp-agent 0.30.12 is older than
                                   0.32.7, the highest version this node has accepted

Er is een eerlijke weg eromheen, en die vraagt om twee dingen: de stap terug bij naam, en een zin die zegt waarom.

corecp-panel panels upgrade panel2 --version 0.30.12 \
  --allow-downgrade --downgrade-reason "0.32.7 breekt de mailwachtrij op dit paneel" \
  --config /etc/corecp-panel/panel.yaml

In Vloot → Gekoppelde panelen zijn het dezelfde twee dingen: zet een versie vast, vink Dit is een bewuste stap terug aan, en de knop blijft dicht tot het veld eronder een antwoord heeft.

Die reden is geen formaliteit. Hij komt in het auditlog van dít paneel én in het updatelogboek van de replica, en daar blijft hij:

$ corecp-panel panels show panel2 --config … | tail -2
  DIRECTIVE  VERB          STATE  DETAIL
  9          update.apply  done   DOWNGRADED by primary directive 9: corecp-agent 0.32.7 ->
                                  corecp-agent 0.30.12 (reason: 0.32.7 breekt de mailwachtrij…)

De ondergrens zelf zakt niet mee. De eerstvolgende gewone update gaat gewoon weer vooruit, zonder enige uitzondering.

Wat "licentie intrekken" doet, en wat niet

panels revoke haalt de apt-inloggegevens weg en sluit de fleet-toegang af. Binnen een minuut kan dat paneel niets meer installeren.

Het raakt geen data. De klanten van dat paneel blijven bediend, de database blijft staan, de certificaten blijven vernieuwen, de back-ups blijven lopen. Een licentie die afloopt is een paneel dat geen updates meer krijgt — niet een paneel dat stopt.

Weer loskoppelen

Op de replica:

$ corecp-panel connect leave --config /etc/corecp-panel/panel.yaml
left the fleet of panel1.corecp.dev:8443 (was panel2)
A running panel notices within one poll interval and stops reporting; there is
nothing to restart.

De apt-inloggegevens blijven staan tot je ze zelf weghaalt (rm -f /etc/apt/auth.conf.d/corecp-fleet.conf).

Waarom een eigen CA

Elk paneel heeft een eigen certificaatautoriteit voor zijn servers. Die mag je nóóit delen tussen twee merken. Deelden ze er één, dan zou een replica die gekraakt wordt certificaten kunnen uitgeven die de servers van de primary vertrouwen — en dan is het tweede merk een sleutel tot het eerste.

Er zijn er dus drie: de server-CA van de primary, de server-CA van de replica, en een derde autoriteit alleen voor de koppeling zelf (de fleet-CA). Beide kanten controleren dit bij het koppelen en weigeren als er twee gelijk zijn.

$ corecp-panel panels planes --config /etc/corecp-panel/panel.yaml | head -8
PLANE  SHARED     THING                                       WHY
build  SHARED     apt repository                              one pool of packages: …
…
data   per panel  node CA                                     NEVER shared: a compromised replica …

Zie ook: docs/architecture.md, "Primary and replica panels (three planes)", en docs/research/ui-vs-cli.md voor waarom koppelen een scherm is en sleutelbeheer niet.