Van cPanel migreren

cPanel is de grootste migratiebron die er is, dus CoreCP leest zijn archieven rechtstreeks — hetzelfde cpmove-archief dat pkgacct schrijft, én de volledige accountbackup die een klant zelf in zijn eigen cPanel kan maken zonder iemand om toe

Geschreven voor: Beheerder

cPanel is de grootste migratiebron die er is, dus CoreCP leest zijn archieven rechtstreeks — hetzelfde cpmove-archief dat pkgacct schrijft, én de volledige accountbackup die een klant zelf in zijn eigen cPanel kan maken zonder iemand om toestemming te vragen.

Alleen beheerders. Een import maakt unix-gebruikers aan, laadt databases en publiceert DNS op een hele machine.

Wat er meekomt


Het account	Naam, unix-wachtwoord (de hash, dus het wachtwoord blijft werken), schijfquota, shell, en of het geschorst was
Websites	Het hoofddomein, de subdomeinen en de addon-domeinen, elk met de PHP-versie waarop cPanel ze serveerde
Bestanden	De hele home-map, op de plek waar cPanel hem had staan — zie Waar de bestanden terechtkomen
Databases	Elke database met zijn gegevens, zijn gebruikers en hun wachtwoorden
Mail	Mailboxen met hun wachtwoord-hashes, forwarders, catch-alls, autoresponders en alle berichten
DNS	De zone, met de records die naar de oude server wezen verplaatst naar deze
Certificaten	Het geïnstalleerde certificaat en zijn sleutel, als het archief ze bevat
DKIM	De sleutel zelf, opnieuw gepubliceerd onder de eigen selector van CoreCP, zodat handtekeningen tijdens de omschakeling blijven kloppen
Cron	De crontab van het account

Wat niet, en wat je eraan doet

Niets hiervan verdwijnt stilletjes. Elke regel hieronder staat met naam en toenaam in het rapport van de import die hem tegenkwam:

	Wat je doet
PostgreSQL	CoreCP heeft geen PostgreSQL-rol. Zelf dumpen en terugzetten, of laten staan waar het staat.
Mailman-mailinglijsten	CoreCP heeft geen lijstbeheerder. Verhuis de lijsten vóór de cutover naar een dienst die dat doet.
Mailfilters	De mail komt gewoon aan; hij wordt alleen niet meer op de server in mappen gesorteerd. Bouw de regels na in de mailclient van de klant, of wacht op server-side filters.
Extra FTP-logins	CoreCP heeft nog geen FTPS-rol. De eigen SFTP-login van het account werkt, en dat is wat alles zou moeten gebruiken.
Apache-configuratie in het archief	CoreCP rendert zijn eigen webserverconfiguratie. Een eigen directive moet je opnieuw als CoreCP-instelling maken.
Reseller-pakketten	Maak de reseller en zijn hostingpakketten hier eerst aan en importeer daarna — dan landen de accounts bij de juiste eigenaar.
cPanel's eigen extra's	FrontPage, cPanel's eigen cron-hulpjes, zijn statistieken. Die gaan met cPanel mee weg.

Waar de bestanden terechtkomen

cPanel serveert het hoofddomein uit ~/public_html en CoreCP serveert elk domein uit ~/domains/<domein>/public_html. De bestanden worden niet verplaatst. Een site die zijn eigen map ergens met een volledig pad noemt — en dat doen ze bijna allemaal ergens — zou daardoor breken. Het pad van CoreCP wordt aangemaakt als een link naar dat van cPanel, dus allebei werken en er staat maar één kopie op schijf. Het rapport zegt dat per website.

De uitzondering is mail: cPanel bewaart de maildirs ín de home-map en CoreCP bewaart ze in ~/imap, dus de berichten verhuizen daarheen. Ze blijven níet óók in de home staan — dan zou elk bericht dubbel meetellen in de schijfquota van de klant.

Route 1 — een backupbestand

Dit is de route als je het archief al hebt: iemand heeft het gestuurd, of de oude server bestaat niet meer.

Paneel → Migraties → Nieuwe migratie → Bronpaneel: cPanel / WHM → Backup uploaden. Het bestand wordt rechtstreeks naar de doelserver gestreamd en daar versleuteld bewaard; het paneel bewaart geen kopie, want een cPanel-archief bevat elke wachtwoord-hash en elke DKIM-sleutel van de oude server.

Druk daarna éérst op Proefdraaien. Dat schrijft niets en drukt het hele plan af: welke websites, op welke PHP-versie, welke databases onder welke naam, welke mailboxen, en alles wat niet meekomt. Lees het. Dan pas Nu migreren.

Op de commandoregel is het dezelfde operatie:

corectl import cpanel /root/cpmove-bob.tar.gz --dry-run
corectl import cpanel /root/cpmove-bob.tar.gz --report /root/bob.json

Route 2 — live ophalen van de oude server

CoreCP belt de oude machine zelf. Twee manieren, en welke je hebt hangt af van wat de klant je kan geven.

Met root op de bron (WHM)

De node draait cPanel's eigen pkgacct, streamt het resultaat rechtstreeks naar binnen en verwijdert het daarna op de bron.

# Wat laat deze server toe? Schrijft niets.
corectl import cpanel-server root@oude-host.example --mode pkgacct --check

# Eerst één account.
corectl import cpanel-server root@oude-host.example --mode pkgacct --accounts bob

# Daarna de rest.
corectl import cpanel-server root@oude-host.example --mode pkgacct --parallel 2

Dit is het normale geval voor een klant die weggaat bij andermans shared host: hij heeft zijn eigen account en verder niets. CoreCP logt via SSH in als dat account en vraagt cPanel om dezelfde volledige backup die de klant zelf in zijn controlepaneel kan maken.

corectl import cpanel-server bob@oude-host.example --mode user --check
corectl import cpanel-server bob@oude-host.example --mode user

Nergens is root nodig. Twee dingen zijn goed om vooraf te weten:

cPanel schrijft het archief in de home-map van de klant zelf, dus zijn quota moet ruimte hebben voor een tweede kopie van zijn account. --check meet dat en weigert liever dan zijn schijf vol te zetten. CoreCP verwijdert het archief zodra het gelezen is.
De backupfunctie van het account kan door de beheerder van de bron zijn uitgezet. Is dat zo, dan zegt --check het en is de route het archief: vraag om een cpmove-bestand en gebruik route 1.

Laat je --mode weg, dan kiest CoreCP: root@… betekent pkgacct, elke andere login betekent user.

Het rapport

Elke import eindigt in een verificatierapport, en dat is geen logboek maar een lijst van resources met OK, WARN of FAIL ernaast, ná afloop gecheckt tegen de draaiende server.

OK — het staat er en het werkt.
WARN — het staat er en er moet iemand iets doen: een mailbox waarvan de wachtwoordvorm niet mee kon, een verlopen certificaat, een database die hernoemd is.
FAIL — het archief had het en het staat er niet. Alleen dat maakt het rapport rood.

Lees het vóórdat je de klant vertelt dat zijn site verhuisd is. Het is ook waar de lijst "wat niet is meegekomen" staat, dus het is wat je hem stuurt.

Databases houden hun naam, tenzij het niet kan

CoreCP leest de eigenaar van een database uit zijn <account>_-prefix, dezelfde conventie die cPanel gebruikt. Een database bob_shop die in het account bob wordt geïmporteerd houdt dus exact die naam, en het configuratiebestand van de site blijft werken.

Hernoemen gebeurt alleen als het moet: als je onder een andere accountnaam importeert, of als de bron een database zonder prefix had. Het rapport zegt het, en het zegt het ding dat ertoe doet — het configuratiebestand van de website noemt nog de oude naam. Bij een WordPress-site is dat DB_NAME in wp-config.php.

Twee keer doen is veilig

Hetzelfde archief nog een keer importeren verandert niets aan wat er al staat: geen dubbele mailbox, geen dubbele forwarder, geen verdubbelde rijen. Dat is opzet — een onderbroken migratie herhaal je, je maakt hem niet ongedaan.

Vóór de cutover

Verlaag de TTL op de DNS van de bron een dag van tevoren, dan gaat de omschakeling snel.
Proefdraaien, en het plan lezen.
Migreren, en het rapport lezen.
De site controleren op de nieuwe server voordat de wereld hem ziet — met een hosts-regel op je eigen machine die het domein naar de nieuwe node wijst.
De DNS omzetten (of de nameservers).
Nog één keer importeren na de omschakeling, voor wat er tussentijds is veranderd: hetzelfde commando, en herhalen is veilig.
Pas dán zeggen tegen de oude provider dat hij mag stoppen.