De testset gebruiken

Op dit platform staat een complete, echte testset klaar: één reseller met een eigen paneeladres, drie websites op drie geregistreerde domeinen, een WordPress onder toolkitbeheer, mailboxen die echt mail versturen en ontvangen, DNS-zones, FTP, SSH, een klantbackup, een servicebinding en één livemigratie die tot vlak vóór de omzetting is uitgevoerd. Er hoort een login bij élk niveau, zodat je het paneel kunt bekijken zoals een beheerder, een reseller, een eindklant en een gedelegeerde het zien.

De set wordt gebouwd en hersteld door één script en gecontroleerd door één acceptatiescript. Beide zijn idempotent: je mag ze zo vaak draaien als je wilt.

Wat er klaarstaat

Het eigen paneeladres van de reseller is <https://panel.reseller-test.corecp.dev>. Dat is een echt white-label paneel: eigen naam, eigen kleur, eigen certificaat. Meld je daar aan als reseller en je zit in het realm van die reseller; meld je met dezelfde login aan op panel1.corecp.dev en je bent een gewone reseller in het root-realm. Dat verschil is precies wat een realm is.

Waar de wachtwoorden staan. Nergens in de documentatie en nergens in git. Ze staan op de paneelserver in /etc/corecp-panel/fixtures/logins.env (alleen leesbaar voor root). In datzelfde bestand staat TOTP_ADMIN=: het base32-geheim van de tweede factor van de beheerder, dat je in een authenticator-app zet.

ssh root@panel1.corecp.dev 'cat /etc/corecp-panel/fixtures/logins.env'

De set bouwen of herstellen

bash scripts/seed-fixtures.sh

Het script maakt alleen wat er nog niet is en zegt per regel wat het deed: + is nieuw, = stond er al, ! verdient een blik. Een tweede run over een complete set maakt niets meer aan.

Eén onderdeel opnieuw doen kan ook:

bash scripts/seed-fixtures.sh --list          # de namen van de stappen
bash scripts/seed-fixtures.sh --only mail     # alleen de mailstap
bash scripts/seed-fixtures.sh --only migration

Ben je het wachtwoordbestand kwijt, dan zijn de logins onbruikbaar geworden. Dan — en alleen dan:

RESET_LOGINS=1 bash scripts/seed-fixtures.sh

Dat vergeet de zes fixture-personen en maakt ze met nieuwe wachtwoorden opnieuw aan. Het raakt niets anders: de hostingaccounts, de websites, de mailboxen en de migratie blijven staan en krijgen hun eigenaar terug.

Controleren dat de set klopt

bash scripts/e2e-r2-fixtures.sh

Exit 0 is groen. De run controleert dat het bouwscript idempotent is, dat elke login werkt en in het juiste realm landt, dat test300.nl een werkende WordPress onder toolkitbeheer toont, dat een testbericht echt aankomt, dat inloggen-als voor elk niveau werkt, en dat dit document en de overdrachtsnotities elke login en elke bewaarplaats noemen.

Het permanente demo-account

test100.nl draait op het account demo. Dat is jouw blijvende testaccount en de fixtureset heeft het niet aangemaakt en verwijdert het nooit. Wat de set eraan toevoegde is één ding: het paneel weet nu dat het account bestaat en het heeft een eigenaar gekregen (owner@test100.nl) in het realm van de reseller. Alles wat er stond, staat er nog.

Wat er per onderdeel klaarstaat

WordPress. <https://test300.nl/> draait onder toolkitbeheer: alle zes kritieke hardeningsmaatregelen plus acht omkeerbare aanbevolen maatregelen, en een staging-kloon op <https://staging.test300.nl/>. De onomkeerbare maatregelen (nieuwe salts, een andere tabelprefix) staan bewust uit — dat is een keuze van de eigenaar van een site, niet van een testset.

ssh root@stck1.corecp.dev 'corectl wp sites; corectl wp harden test300.nl --account test300'

Mail. Mailboxen info@test100.nl, info@test200.nl en info@test300.nl, een forwarder verkoop@test200.nl → info@test200.nl en een afwezigheidsbericht op info@test300.nl. Er is echt mail verstuurd naar de twee testadressen; wat de ontvangende kant ermee deed staat op de node:

ssh root@stck1.corecp.dev 'cat /var/lib/corecp/fixtures/external-mail-report.txt'

DNS. Drie zones op stck1.corecp.dev, met ns2.corecp.dev als tweede nameserver. DNSSEC staat uit en dat blijft de standaard: ondertekenen vraagt een DS-record bij de registrar, en een functie die een handmatige stap buiten ons systeem nodig heeft, staat standaard uit.

dig +short test200.nl @ns1.corecp.dev
dig +short test200.nl @ns2.corecp.dev

FTP en SSH. Elk account heeft een FTP-login <account>-fixture; de wachtwoorden staan als FTP_<account>= in het credentialbestand. Er is één SSH-sleutelpaar voor alle drie de accounts; de privésleutel staat op panel1 in /etc/corecp-panel/fixtures/fixture_ed25519 en de toegang staat op sftp.

ssh root@stck1.corecp.dev 'corectl ftp list --account test200; corectl sshkey list --account test200'

Klantbackup. Elk account heeft één backup die het zelf heeft gemaakt, op de bestemming local (~/backups):

ssh root@stck1.corecp.dev 'corectl userbackup list --account test200 --dest local'

Servicebinding. test200.nl heeft een eigen plaatsing per rol (web, db en mail op stck1) in plaats van de accountstandaard. Eén rol op een ándere machine zetten kan op deze vloot niet: er is precies één db-node, en de webrol verplaatsen naar ns2 zou de site op een machine zonder PHP en zonder database zetten. De DNS-rol is al de tweetrapsopstelling die het ontwerp vraagt.

ssh root@panel1.corecp.dev 'corecp-panel bindings list --config /etc/corecp-panel/panel.yaml' | grep test200

Livemigratie. Er staat één voorbeeldmigratie klaar, uitgevoerd tot en met de groene controlelijst en dáár gestopt. De volgende stap is die van jou: DNS omzetten en dan pas de cutover bevestigen. Het adres van de migratie staat in prompts/HANDOVER/run-notes.md; in het paneel vind je hem onder Migraties → Live.

Inloggen-als

De beheerder mag als elk niveau inloggen, de reseller alleen binnen het eigen realm. Je vindt het bij een klant onder Leden of via de klantpagina. Let op één ding dat geen storing is: als je een supportsessie verlaat en meteen een volgende wilt starten, vraagt het paneel opnieuw om je tweede factor. Het verlaten maakt namelijk een nieuwe beheerderssessie, en die heeft nog niets recents bewezen — dat is de sudo-modus die zware handelingen achter een verse bevestiging zet.

Een supportsessie kan bewust minder dan de klant zelf: wachtwoorden, e-mail, tweede factoren, passkeys, secrets en ledenbeheer blijven dicht.