Waar een website draait

Een CoreCP-website staat niet op "een server". Hij heeft vijf diensten — zijn webserver, zijn database, zijn mailopslag, zijn nameservers en zijn back-updoel — en elk daarvan wordt afzonderlijk op een machine geplaatst. Meestal komen alle vijf op dezelfde machine terecht en denk je er nooit over na. Deze pagina gaat over de keren dat je dat wél doet.

Alleen beheerders zien dit. Resellers en eindgebruikers zien nooit, en hoeven nooit te zien, welke machine hen bedient. Dat is bewust: welke klant op welke machine staat, is een plattegrond van het platform.

Een plaatsing bekijken

Paneel — Accounts → een account → Plaatsing. Eén regel per dienst: de rol, de machine die hem beantwoordt, wat dat bepaalde, en de status. Dit scherm ziet alleen een serverbeheerder; een reseller en een klant hebben het tabblad niet.

Onder de vijf regels staat waar een dienst die niemand heeft vastgezet vandaan komt: de eigen machine van het account, het pakket, de plaatsingspool waarin dat pakket inplant, en het beleid van die pool.

Shell — dezelfde vraag, en het antwoord dat het scherm tekent:

corecp-panel bindings list --account demo --config /etc/corecp-panel/panel.yaml

ACCOUNT  WEBSITE            ROLE  NODE               STATE   SINCE
demo     (account default)  web   stck1.corecp.dev   active  2026-08-08 21:07
demo     (account default)  db    stck1.corecp.dev   active  2026-08-08 21:07
demo     shop.example.com   web   stck2.corecp.dev   active  2026-08-08 21:12

(account default) is het antwoord voor elke website van dat account die geen eigen regel heeft. shop.example.com heeft er wel één, dus zijn webserver staat op de andere machine — de rest van die website volgt nog steeds het account.

Wat het scherm laat doen

Drie handelingen, en ze staan er alle drie omdat ze op de opdrachtregel al bestonden en nergens anders te vinden waren.

Een dienst verhuizen. Op elke regel staat Verplaatsen…. Het paneel biedt alleen machines aan die de rol dragen — een machine zonder de rol wordt door de server geweigerd, en een keuze aanbieden die geweigerd wordt is een fout aanbieden. De knop blijft uit tot je bevestigt wat het kost; die bevestiging is geen formaliteit, de API eist hem ook (confirm). Daarna verschijnt de verhuizing onder Verhuizingen, met elke stap en zijn status, en die loopt door terwijl je kijkt. Landt hij, dan verandert de regel bovenin mee.

Een dienst die nog nergens is vastgelegd. Een account uit de tijd vóór §D1 heeft geen enkele binding: alle vijf de diensten komen uit op zijn eigen machine en de statuskolom zegt Niet vastgelegd. Verplaats je zo'n dienst, dan legt het paneel eerst vast waar hij nú staat en begint daarna pas de verhuizing. Het scherm zegt dat ook, in het paneel dat opengaat.

Per website vastzetten. Bovenaan staat een keuzelijst: Standaard van het account, of één van de websites. Kies een website en je ziet wat er voor díé website geldt — met Vastgezet voor deze website op de regels die een eigen rij hebben en Geërfd van het account op de rest. Losmaken haalt de eigen rij weg en er verhuist niets; de website volgt daarna weer het account. Staat de dienst op een andere machine dan de standaard, verhuis hem dan eerst.

De API eronder is er één, en dat is hem:

curl -s -b jar 'https://panel1.corecp.dev/api/v1/accounts/demo/placement' \
  | python3 -m json.tool | head -20

{
    "account": "demo",
    "home_node": "stck1.corecp.dev",
    "package": "Basic",
    "server_group": "eu-west",
    "strategy": "least_websites",
    "roles": [
        {
            "role": "web",
            "source": "account",
            "state": "active",
            "node": {"fqdn": "stck1.corecp.dev", "roles": ["web", "db", "dns"]},
            "pinned": true
        }
    ]
}

source is het woord van de resolver zelf — domain, account of account_node — en niet een tweede woordenlijst voor het scherm: wat het paneel toont en wat de opdrachtregel zegt moeten dezelfde bewering zijn. Voeg ?domain=shop.example.com toe en je krijgt hetzelfde antwoord voor één website.

Wat één machine draagt, en waar hij op leunt

De accountpagina beantwoordt "waar staat deze klant". De Plaatsing-tab van een server (Servers → de server → Plaatsing) leest dezelfde records van de andere kant, en dat is de kant waar je als beheerder staat: wat staat er op deze machine, wat leunt erop, en waar leunt hij zelf op?

Wat hij draagt. Eén regel per dienst, met drie getallen, want het zijn drie verschillende feiten en je gebruikt ze alle drie. Plaatsingen is het record: hoeveel regels deze machine noemen. Accounts is wie erachter zit. Websites is het uitgerekende antwoord: wat er werkelijk uitkomt zodra de standaard van het account en de vastgezette websites zijn toegepast. Dat laatste is niet het aantal regels, en het is wél het getal dat iemand bedoelt met "hoeveel sites staan er op stck1". Achter elk getal zit de lijst zelf.

Waar hij op leunt. Daaronder staat de omgekeerde vraag: welke ándere machine bedient de database, de mail of de backup van de accounts die hier staan. Een webmachine waarvan de databases op db1 staan is een machine die je niet alleen kunt herstarten — en dat was op geen enkel ander scherm te zien.

Verbindingen. De vier relaties die het paneel op machineniveau vastlegt: uit welke pool hij inplant, welke naamserver van hem overneemt, waar zijn backups heen gaan en via welke mailgateway hij loopt. Dat zijn dezelfde vier die het vlootdiagram tekent, uit dezelfde lezing en in dezelfde woorden — zie De vloot als één plaat.

Loopt de machine leeg, dan staat dat als balk boven alles. Dat is de ene eigenschap die de betekenis van élk getal eronder verandert: een machine die leegloopt bedient alles wat er staat gewoon door, en krijgt er niets meer bij. Leeghalen doe je per dienst, vanaf het account — er is met opzet geen knop die het in één keer voor je doet.

Beide weergaven zijn alleen voor beheerders van servers: een reseller en een eindklant krijgen ze niet.

Waar een handeling landt

Een plaatsing is geen beschrijving. Élke accountgebonden handeling van het paneel vraagt eerst welke machine het moet zijn, en dat is dezelfde vraag voor de browser, de API, de opdrachtregel en de assistent:

Bestanden en FTP ontbreken niet: die werken op de home van het account, en die home staat op de machine waar het account staat. Dát is de webrol.

Een account zonder plaatsing komt uit op zijn eigen machine. Dat is de hele compatibiliteitsbelofte, en daarom gedraagt een platform met één machine zich precies zoals het zich altijd gedroeg: er is niets gebonden, dus account.node_id is het antwoord — wat het altijd al was.

corecp-panel bindings list --account demo --role mail --config …

ACCOUNT  WEBSITE            ROLE  NODE              STATE   SINCE
demo     (account default)  mail  stck2.corecp.dev  active  2026-08-16 04:12

Vanaf dat moment landt het aanmaken van een mailbox voor demo op stck2 — het mailscherm zegt dat zelf in zijn antwoord, en de mailbox staat echt in de Dovecot daar:

curl -s -b jar 'https://panel1.corecp.dev/api/v1/accounts/demo/domains/test100.nl/mail?refresh=0' \
  | python3 -c 'import json,sys; print(json.load(sys.stdin)["node"])'

stck2.corecp.dev

Er is verder niets verhuisd. Het bestandsbeheer van hetzelfde account antwoordt nog steeds vanaf stck1.corecp.dev, want bestanden rijden mee op de webrol.

Hoe een nieuw account geplaatst wordt

1. Heeft de website een eigen plaatsing voor die dienst? Die wint.
2. Zo niet: de standaardplaatsing van het account.
3. Zo niet: het beleid van de plaatsingspool waarin het pakket van de klant inplant.

Er zijn drie beleidsvormen. Minste websites is de standaard en degene om aan te houden zolang je groeit: het is het getal dat het paneel exact kent, en het is het getal dat volgend jaar voorspelt. Laagste belasting rangschikt op de laatste meting van de machines, en een machine zónder recente meting komt ná elke gemeten machine — "we weten het niet" hoort niet te winnen van "we hebben 0,2 gemeten". Willekeurig bestaat voor het geval je geen enkel verband wilt tussen de volgorde waarin klanten binnenkomen en waar ze landen.

Je kunt altijd eerst vragen:

corecp-panel bindings plan --account demo --roles web,db --config …

ROLE  NODE              SOURCE  WHY
web   stck2.corecp.dev  policy  fewest websites (14) in server group eu-west
db    stck2.corecp.dev  policy  fewest websites (14) in server group eu-west

Dit verandert niets. Het antwoord noemt óók elke machine die is overwogen en waarom die afviel, zodat "waarom niet stck3" te beantwoorden is zonder te gokken.

Een machine noemen, of een groep noemen

Een account aanmaken op een machine die je zelf noemt, pint daarop alles wat die machine mag dragen — zijn webserver, zijn database, zijn mailopslag. Dat deed /api/v1/accounts altijd al, en dat blijft zo.

Een account aanmaken in een groep pint niets behalve de home. Elke rol gaat dan naar de machine in de pool die die rol draagt — en dát is wat een groep van enkelvoudige machines bruikbaar maakt: web hier, database daar, mail daar.

Paneel — Accounts → Account aanmaken vraagt om een nodegroep, niet om een machine. Een machine noemen kan nog steeds, onder Geavanceerd: dat is het juiste antwoord bij een herbouw of een migratie, en het was alleen de verkeerde standaard. Als het account is aangemaakt zegt het scherm op welke machine het terechtkwam en waarom — "minste websites (14) in servergroep eu-west" —, zodat "waarom daar" een jaar later nog beantwoordbaar is.

curl -s -b jar -X POST https://panel1.corecp.dev/api/v1/fleet/accounts \
  -H 'Content-Type: application/json' \
  -d '{"username":"acme","organization_id":"<nodegroep>","package_id":"<pakket>"}'

ACCOUNT  WEBSITE            ROLE  NODE              STATE   SINCE
acme     (account default)  web   stck1.corecp.dev  active  2026-08-16 05:40
acme     (account default)  db    stck2.corecp.dev  active  2026-08-16 05:40
acme     (account default)  mail  stck2.corecp.dev  active  2026-08-16 05:40
acme     (account default)  dns   ns2.corecp.dev    active  2026-08-16 05:40
acme     (account default)  dns   stck1.corecp.dev  active  2026-08-16 05:40

Beide wegen plaatsen alle vijf de rollen, en twee daarvan worden nooit op de machine gepind die jij noemde — omdat de regels verderop het voor de hand liggende antwoord verbieden:

• dns wordt opgesomd, niet gekozen. Elke machine in de pool die de rol draagt hoort bij de set, want dát is een nameserver-set, en de ondergrens van twee geldt. Een pool met één nameserver plaatst geen dns — en dat komt uit op de eigen machine van het account, precies zoals vroeger.
• backup gaat naar een machine in de pool die de data van dít account níét al draagt. Een platform zonder aparte back-upmachine plaatst er geen, en ook dat komt uit op de eigen machine van het account.

Een machine die een rol overneemt, krijgt eerst het account: een mailmachine kan geen mailbox houden voor een klant van wie zij nooit gehoord heeft. Nameservers zijn de uitzondering en blijven schoon — een zone is niet van een unix-account.

Servers die meer pools bedienen

Een secundaire naamserver en een back-upserver kunnen meer pools bedienen dan hun eigen pool. Je stelt dat in op de pagina Plaatsing van die server; nieuwe accounts in de gekozen pools krijgen de server dan in hun naamserverset of als back-updoel. Op dezelfde pagina zie je bij een webserver zonder mailrol via welke mailserver de websites hun mail versturen. Alles daarover staat in Gedeelde dienstservers en uitgaande mail.

Plaatsingspools

Een pool is de verzameling machines waarop een pakket mag inplannen — een locatie, een tier, een generatie hardware. Het is niet hetzelfde als een node-groep: een node-groep bepaalt wie een machine mag zien, een pool bepaalt wat erop landt.

Paneel — Servers → Plaatsingspools. Eén regel per pool met het beleid, hoe veel machines erin zitten en hoe veel pakketten erin inplannen. Klik er een open en je kunt hem hernoemen, het beleid kiezen, hem laten leeglopen, machines erin en eruit halen en zien welke pakketten er gebruik van maken. Onderaan het scherm staat het verschil tussen een nodegroep en een pool nog eens uitgeschreven, omdat dat de verwarring is die dit scherm bestaat om te voorkomen.

Zonder pool plant elk pakket in op de héle nodegroep. Dat is prima zolang alle machines hetzelfde doen; een pool maak je zodra dat niet meer klopt.

Shell — hetzelfde, en het is nog steeds de snelste weg als je er drie achter elkaar maakt:

corecp-panel bindings groups create eu-west --org corecp --strategy least_websites
corecp-panel bindings groups list --config …

Wil je een machine langzaam leegmaken, zet hem dan op draining. Alles wat er staat blijft bediend; er komt niets nieuws bij.

corecp-panel bindings groups set eu-west --draining --config …

Een machine in een pool zetten

Bij het koppelen kies je de servergroep in stap 1 van de wizard. Deed je dat niet, dan blijft de machine buiten elke pool staan en plant er niets op in — en dat is precies de toestand waar de wizard je na een geslaagde koppeling op wijst (zie Een server toevoegen). Er is één knop voor, op twee plekken: de vervolgstap van de wizard, en het poolscherm.

curl -s -b jar -X POST https://panel1.corecp.dev/api/v1/nodes/stck2.corecp.dev/pool \
  -H 'Content-Type: application/json' -d '{"server_group_id":"<pool>"}'

{"fqdn":"stck2.corecp.dev","server_group_id":"5a1c…","roles":["db","mail"]}

Een lege server_group_id haalt de machine weer uit elke pool. Een pool van een ándere nodegroep wordt geweigerd, met beide namen erbij: een machine plant in binnen zijn eigen groep, anders zouden er accounts landen op een machine die niemand in die groep mag aanraken.

Dit is niet hetzelfde als een machine naar een andere nodegroep verplaatsen (node.group.set). Dat laatste is een rechtenwijziging in de kleren van een inventarisbewerking; dit is een planningsbeslissing.

Welk pakket in welke pool inplant

Een pool is maar de helft van een relatie. De andere helft is het pakket dat erin inplant, en zolang je dat niet instelt gebruikt elk pakket zijn hele nodegroep.

corecp-panel bindings pool --config …

PLAN   KIND     SCHEDULES INTO
Basic  account  the whole node group
Pro    account  eu-west (least_websites)

corecp-panel bindings pool Basic --group eu-west --config …
corecp-panel bindings pool Basic --none --config …          # terug naar de groep

Hetzelfde via de API, en dat is wat de pakketbouwer gebruikt:

curl -s -b jar -X POST https://panel1.corecp.dev/api/v1/packages/<pakket>/pool \
  -H 'Content-Type: application/json' -d '{"server_group_id":"<pool>"}'

{"package":"Basic","server_group":"eu-west","strategy":"least_websites"}

Een lege server_group_id koppelt het pakket weer los. Dit is een beslissing van een beheerder en niet van een reseller: een reseller vormt een pakket, en kiezen op welke hardware dat landt is de vorm van het platform kiezen.

Paneel — Pakketten → een pakket → Plaatsing. De keuzelijst staat naast de uitleg die erbij hoort: nieuwe accounts op dit pakket landen op een machine uit deze pool, en bestaande accounts verhuizen niet mee — die staan waar ze staan tot je een dienst verplaatst. Die zin staat er omdat het de aanname is die misgaat: wie een pakket naar een nieuwe pool wijst en dan wacht op een verhuizing, wacht voor niets.

De sectie verschijnt alleen bij een serverbeheerder en alleen bij een accountpakket. Ze slaat ook meteen op — los van de Opslaan-knop van de rest van het formulier, omdat het een andere route met een ander niveau is en één knop die voor de helft van de mensen half lukt geen knop is.

Een pool waar nog een pakket naar wijst, kun je niet verwijderen — en de weigering noemt de pakketten:

2 package(s) still schedule into this server group (Basic, Pro) — point them
somewhere else first; deleting it would leave provisioning with nowhere to place

De regels die het paneel niet laat overtreden

En twee dingen waarvoor het waarschuwt in plaats van weigert, omdat het afwegingen zijn en geen fouten:

• Webserver en database op verschillende machines, met een traag pad ertussen. Elke query op elke pagina betaalt dat getal. Het paneel meet het vanaf de machine zelf — niet vanaf het paneel, want dan meet je iets heel anders — en waarschuwt boven ongeveer 2 ms.
• Een mailmachine zonder reverse-naam bij zijn adres. Grote providers filteren post van zulke adressen weg.

Web en database samen is de standaard; splitsen is een besluit, geen upgrade.

Eén machine, meerdere resellers

Een machine hoort bij één nodegroep. Een klant hoort bij een realm — het root-realm, of dat van een reseller. Dat zijn twee verschillende dingen, en ze hoeven niet gelijk te zijn: dat is precies wat gedeelde hosting is. stck1 kan in de root-groep staan en tegelijk de klanten van drie resellers bedienen.

Dat werkte een tijd niet. De machine telde mee als derde eigendomsvraag bij élke accountgebonden aanroep — mail, DNS, FTP, bestanden, back-ups, WordPress — dus zodra een klant in het realm van een reseller zat, kreeg zij 403 node_out_of_scope op haar eigen website. Eén machine kon daardoor precies één realm bedienen. Sinds 10 augustus 2026 is plaatsing weer wat het hoort te zijn: een beheerdersvraag.

Er is niets ruimer geworden. Wie je bereikt, is nog steeds bepaald door het account zelf: het moet in jouw realm staan én van jou of van een klant van jou zijn. Wat verdween is een vraag die resellers en eindgebruikers nooit hadden mogen krijgen, omdat ze het antwoord toch niet te zien krijgen (zie het kader bovenaan deze pagina).

Paneel — Fleet → machines toont de groep van een machine; Klanten toont het realm van een klant. Ze staan bewust niet op hetzelfde scherm, want het zijn niet dezelfde vraag.

Shell — op de paneelmachine, rechtstreeks uit de database, omdat er geen scherm is dat de twee naast elkaar zet:

ssh root@panel1.corecp.dev sudo -u postgres psql -d corecp_panel -c \
  "SELECT n.fqdn, o.name AS node_group FROM node n
     JOIN organization o ON o.id = n.organization_id ORDER BY n.fqdn"

       fqdn       | node_group
------------------+------------
 stck1.corecp.dev | CoreCP

ssh root@panel1.corecp.dev sudo -u postgres psql -d corecp_panel -c \
  "SELECT a.username, o.name AS realm, p.email AS owner
     FROM account a JOIN node n ON n.id = a.node_id
     LEFT JOIN organization o ON o.id = a.organization_id
     LEFT JOIN panel_user p ON p.id = a.owner_user_id
    WHERE n.fqdn = 'stck1.corecp.dev'
      AND a.username IN ('demo','test200','test300') ORDER BY a.username"

 username |      realm       |      owner
----------+------------------+------------------
 demo     | Reseller Test BV | owner@test100.nl
 test200  | Reseller Test BV | owner@test200.nl
 test300  | CoreCP           | owner@test300.nl

Drie accounts, één machine, twee realms. Zo hoort het eruit te zien — en dat is precies wat de testset van scripts/seed-fixtures.sh neerzet, zie De testset gebruiken.

Eén dienst naar een andere machine verhuizen

Verhuizen kopieert klantdata en verandert wat een website beantwoordt, dus je moet het expliciet bevestigen.

Paneel — Plaatsing → Verplaatsen… op de regel van de dienst. Dezelfde stappenlijst als hieronder verschijnt onder Verhuizingen, met een teller (4/10) en per stap zijn status. Loopt hij vast, dan staan Hervatten en Afbreken op de kaart zelf. Wat hieronder op de opdrachtregel staat, is letterlijk hetzelfde werk — het scherm start het en kijkt toe.

Shell

corecp-panel bindings move <binding-id> --to stck2.corecp.dev --confirm --wait 600

Je ziet elke stap:

move 1091ad55-… — web of shop.example.com for demo
  stck1.corecp.dev → stck2.corecp.dev, done
  STEP               STATE  DETAIL
  preflight          done   stck2.corecp.dev carries the web role and answers
  account_on_target  done   created demo on stck2.corecp.dev
  export_source      done   demo-web-20260808T210709Z.tar
  transfer           done   4823040 bytes to stck2.corecp.dev
  import_target      done   imported on stck2.corecp.dev
  verify_target      done   stck2.corecp.dev answered 200 for shop.example.com
  cutover            done   2 address record(s) now point at stck2.corecp.dev
  activate           done   stck2.corecp.dev now serves the web role
  drain_source       done   stck1.corecp.dev no longer serves shop.example.com; …
  cleanup            done   staged archives removed

verify_target haalt de site op bij de nieuwe machine, op zijn eigen naam, voordat er iets omgezet wordt. Kan die machine hem niet serveren, dan stopt de verhuizing daar en merkt de klant er niets van.

Een database verhuizen is hoe een MariaDB-hoofdversie verandert

MariaDB draait één hoofdversie per machine en werkt niet ter plekke bij. Er is dus geen "bijwerken"-knop voor de database van een klant. Hem verhuizen naar een machine met een andere reeks is de overstap: een dump aan de ene kant, terugzetten aan de andere, en daarna wijst het account naar de nieuwe machine.

Daarom ziet het verhuisscherm er anders uit op de regel Database. In de lijst met machines staat welke MariaDB-reeks elke machine draait, de huidige versie staat naast de machine waar hij nu op staat, en bij het kiezen van een bestemming zie je wat het betekent:

Draaien alle machines die de database zouden kunnen overnemen dezelfde reeks als waar hij nu op staat, dan zegt het scherm dat: er is geen versiewissel mogelijk tot er een databasemachine op de gewenste reeks bij staat.

Als hij halverwege stopt

Er gaat niets verloren en er zit niets vast. De oude machine bleef bedienen tot cutover, en de binding staat weer op active waar hij stond. Kijk naar de stap die faalde, los op wat die noemt, en ga verder:

corecp-panel bindings moves --state failed --config …
corecp-panel bindings resume <move-id> --wait 600 --config …

Hervatten, niet opnieuw proberen. Hij gaat verder bij de eerste stap die niet af is; het werk dat al gedaan is, wordt niet nog eens gedaan.

Een mailverhuizing wacht met opzet

Een mailverhuizing eindigt in paused, niet in done. Post die de oude machine al aangenomen heeft, staat op de oude machine, en elke mailserver ter wereld houdt het oude MX-record vast tot zijn TTL verlopen is. Daarom blijft de oude mailopslag vier uur leesbaar en staat de binding op draining. Hervat de verhuizing daarna en de oude sessies worden beëindigd.

paused betekent hier wachtend, zoals bedoeld. Het is geen storing.

Wat een verhuizing nooit doet

• Nooit een zone herschrijven die iemand anders host. Hosten wij de DNS niet, dan vertelt de verhuizing welk record je moet aanpassen en blijft de oude machine bedienen tot je dat doet.
• Nooit configuratiebestanden van je klanten bewerken. Betekent het splitsen van web en database dat DB_HOST in wp-config.php moet veranderen, dan zégt de verhuizing dat en laat hij het bestand met rust.
• Nooit iets weggooien dat van een klant is. De oude machine stopt met het serveren van de site; de bestanden blijven staan, en de stap noemt het commando waarmee je ze weghaalt.

Het pad tussen twee machines meten

corecp-panel bindings rtt stck1.corecp.dev stck2.corecp.dev --config …

stck1.corecp.dev → stck2.corecp.dev: 0.31 ms over 5 samples

Gemeten door de agent op de eerste machine, die verbinding maakt met de tweede — niet vanaf het paneel, dat twintig milliseconden van beide vandaan kan staan en je dan niets vertelt over het pad ertussen. Standaard poort 22, tenzij je met --port een andere noemt; de eigen poort van de agents staat bewust alleen open voor het paneel, dus die timen betekent een firewall timen.

De assistent vragen

De assistent kan beantwoorden "op welke machine staat de site van deze klant" en "welke verhuizingen lopen er". Hij kan een verhuizing niet starten, hervatten of annuleren — dat is een beheerdershandeling met een bevestiging, en niet iets om tussen twee zinnen van een gesprek te doen.