Using the test set

This platform carries a complete, real test set: one reseller with a panel address of their own, three websites on three registered domains, a WordPress under toolkit management, mailboxes that really send and really receive, DNS zones, FTP, SSH, a customer backup, a service binding, and one live migration carried to the point just before the switch. There is a login for every level, so you can look at the panel the way an administrator, a reseller, an end customer and a delegate each see it.

The set is built and repaired by one script and checked by one acceptance script. Both are idempotent: run them as often as you like.

What is waiting for you

The reseller's own panel address is <https://panel.reseller-test.corecp.dev>. It is a real white-label panel: its own name, its own colour, its own certificate. Sign in there as the reseller and you are inside that reseller's realm; sign in with the same login on panel1.corecp.dev and you are an ordinary reseller in the root realm. That difference is exactly what a realm is.

Where the passwords are. Not in this documentation and not in git. They live on the panel server in /etc/corecp-panel/fixtures/logins.env, readable by root only. The same file holds TOTP_ADMIN=: the base32 secret of the administrator's second factor, which you add to an authenticator app.

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

Building or repairing the set

bash scripts/seed-fixtures.sh

The script makes only what is missing and says what it did, line by line: + is new, = was already there, ! deserves a look. A second run over a complete set makes nothing.

One part at a time works too:

bash scripts/seed-fixtures.sh --list          # the step names
bash scripts/seed-fixtures.sh --only mail     # just the mail step
bash scripts/seed-fixtures.sh --only migration

If the credential file is lost, the logins are unusable. Then, and only then:

RESET_LOGINS=1 bash scripts/seed-fixtures.sh

That forgets the six fixture people and makes them again with new passwords. It touches nothing else: the hosting accounts, the websites, the mailboxes and the migration stay where they are and get their owner back.

Checking that the set is sound

bash scripts/e2e-r2-fixtures.sh

Exit 0 is green. The run checks that the seeder is idempotent, that every login works and lands in the right realm, that test300.nl serves a working WordPress under toolkit management, that a test message really arrives, that signing in as somebody else works for every level, and that this document and the handover notes name every login and every hiding place.

The permanent demo account

test100.nl runs on the account demo. That is your standing test account; the fixture set did not create it and never removes it. What the set added is one thing: the panel now knows the account exists, and it has an owner (owner@test100.nl) inside the reseller's realm. Everything that was on it is still on it.

What is waiting, part by part

WordPress. <https://test300.nl/> is under toolkit management: all six critical hardening measures plus eight reversible recommended ones, and a staging clone at <https://staging.test300.nl/>. The irreversible measures (new salts, a different table prefix) are deliberately off — those are a site owner's decision, not a test set's.

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

Mail. Mailboxes info@test100.nl, info@test200.nl and info@test300.nl, a forwarder verkoop@test200.nl → info@test200.nl, and an out-of-office reply on info@test300.nl. Mail was really sent to the two standing test addresses; what the far side did with it is on the node:

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

DNS. Three zones on stck1.corecp.dev, with ns2.corecp.dev as the second nameserver. DNSSEC is off and stays the default: signing needs a DS record at the registrar, and a feature that needs a manual step outside our systems is off unless somebody asks for it.

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

FTP and SSH. Every account has an FTP login <account>-fixture; the passwords are in the credential file as FTP_<account>=. There is one SSH key pair for all three accounts; the private half is on panel1 at /etc/corecp-panel/fixtures/fixture_ed25519 and access is set to sftp.

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

Customer backup. Every account holds one backup it took itself, on the local destination (~/backups):

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

Service binding. test200.nl has a placement of its own per role (web, db and mail on stck1) instead of the account default. Putting one role on a different machine is not possible on this fleet: there is exactly one db node, and moving the web role to ns2 would put the website on a machine with no PHP and no database. The DNS role already is the two-node set the design asks for.

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

Live migration. One example migration is waiting, carried through to a green checklist and stopped there. The next step is yours: switch DNS, and only then confirm the cutover. Its address is in prompts/HANDOVER/run-notes.md; in the panel you find it under Migrations → Live.

Signing in as somebody else

An administrator may sign in as any level; a reseller only inside their own realm. You find it on a customer under Members or from the customer page. One thing that is not a fault: leave a support session and start another one straight away, and the panel asks for your second factor again. Leaving mints a new administrator session, and a new session has proved nothing recently — that is sudo mode putting heavy operations behind a fresh confirmation.

A support session can deliberately do less than the customer themselves: passwords, e-mail, second factors, passkeys, secrets and member management stay closed.