Eigen serverinstellingen

Vroeg of laat heeft een machine één instelling nodig die CoreCP niet zelf beheert: een innodb_buffer_pool_size die bij het geheugen van déze server past, een nginx-timeout voor de trage importer van een klant, een maxmemory-beleid voor de o

Geschreven voor: Beheerder

Vroeg of laat heeft een machine één instelling nodig die CoreCP niet zelf beheert: een innodb_buffer_pool_size die bij het geheugen van déze server past, een nginx-timeout voor de trage importer van een klant, een maxmemory-beleid voor de objectcache. Zo'n instelling hoort in een dropin: in de include-map van de dienst zelf, geschreven vanuit /etc/corecp zoals al het andere, en toegepast met een vangnet eronder.

In het paneel: Servers → de server → Snelle acties → Eigen serverinstellingen, of rechtstreeks op /nodes/<server>/dropins.

Welke diensten er een aannemen

root@web1:~# corectl dropin list
Config drop-ins:
  apache    —          /etc/apache2/conf-available/zz-corecp-custom.conf  config test
  mariadb   6 lines    /etc/mysql/conf.d/zz-corecp-custom.cnf             health check + rollback
  nginx     —          /etc/nginx/conf.d/zz-corecp-custom.conf            config test
  php       —          /opt/corecp/php/84/etc/conf.d/zz-corecp-custom.ini config test
  valkey    —          /etc/valkey/zz-corecp-custom.conf                  health check + rollback
  fpm       —          /opt/corecp/php/84/etc/fpm.d/zz-corecp-custom.conf config test
  sysctl    —          /etc/sysctl.d/zz-corecp-custom.conf                config test

Het bestand heet altijd zz-corecp-custom.*. Dat is geen versiering: een include-map wordt op alfabet gelezen en het laatste bestand wint — zo verslaat jouw instelling de corecp.cnf van CoreCP zelf en alles wat een add-on ernaast gezet heeft.

De PHP-dropin rendert één keer per geïnstalleerde serie, in de ini-scanmap van elke interpreter. Een instelling die wél voor PHP 8.4 gold en niet voor 8.3 zou een supportvraag zijn die niemand kan reproduceren.

php of fpm — welke van de twee?

Er zijn twee PHP-doelen en het verschil is de moeite waard, want kies je het verkeerde dan gebeurt er níéts en zegt niemand iets.

php is het php.ini-doel: instellingen die de interpreter leest als hij start. Alles wat met OPcache te maken heeft hoort hier, want OPcache pakt zijn geheugen op het moment dat PHP opstart — een waarde die later per verzoek wordt meegegeven komt te laat aan en doet niets.
fpm is de poolconfiguratie: hoeveel verzoeken een werkproces afhandelt voordat het wordt vervangen, hoe lang de master op een werkproces wacht bij een herstart, wat de máchine als geheel aan processen aankan.

corectl dropin set php-fpm betekent sinds deze ronde het poolbestand; vroeger was het een tweede naam voor php, wat niet is wat er staat.

De fpm-dropin wordt als laatste regel in het poolbestand van elk account ingevoegd, dus hij wint van de standaardinstellingen van CoreCP zelf — dat is de hele afspraak van een dropin. Wat hij níét mag zetten is wat CoreCP per account regelt: de socket, de gebruiker, de kooi (open_basedir) en pm.max_children, want dat laatste is de werkerslimiet van het pakket van die klant. Op een LiteSpeed-server draait lsphp in plaats van FPM; daar rendert dit doel niets.

sysctl — de kernel

Gewone sysctl.d, als laatste in het alfabet zodat hij wint van de bestanden van de distributie en van CoreCP's eigen hardening. Twee dingen zijn goed om te weten:

Een instelling die deze kernel niet kent wordt geweigerd voordat het bestand geschreven wordt. systemd-sysctl markeert namelijk het hele bestand als mislukt zodra er één onbekende regel in staat, dus één typefout zou stilletjes al je andere instellingen kosten.
De gezondheidscontrole leest elke waarde terug. Er is geen dienst om te vragen of hij tevreden is, dus het enige eerlijke bewijs is vergelijken wat de kernel meldt met wat je gevraagd hebt — en datzelfde bewijst dat een terugdraaiing is geland.

root@web1:~# corectl dropin set sysctl --file - <<'EOF'
vm.swapiness = 10
EOF
corectl: this kernel has no sysctl called vm.swapiness (line 1). systemd-sysctl
reports one unknown key as a failure for the whole file, so the rest of this
drop-in would not be applied either

Er een schrijven

De tekst gaat nooit over de commandoregel — een configuratieblok bestaat uit meerdere regels, en /proc/<pid>/cmdline is voor iedereen leesbaar. Dus komt hij uit een bestand of van standaardinvoer:

root@web1:~# cat > /tmp/tuning.cnf <<'EOF'
[mysqld]
innodb_buffer_pool_size = 2G
max_connections = 300
EOF

root@web1:~# corectl dropin set mariadb --file /tmp/tuning.cnf --note "8 GB machine, 2026-08"
drop-in mariadb applied (/etc/mysql/conf.d/zz-corecp-custom.cnf)

--note wordt een commentaarregel bovenaan, zodat de reden naast de instelling blijft staan in plaats van in een ticket.

Wat er gebeurt als je toepast

De verboden lijst. Elke regel wordt gelezen vóór er iets geschreven wordt.
In één keer op zijn plek. Eerst een tijdelijk bestand, dan een rename — geen dienst leest ooit een half geschreven bestand.
De configtest van de dienst zelf, als hij er een heeft: nginx -t, apachectl configtest, en voor PHP de ini-parser zelf, gericht op het kandidaat-bestand. Faalt hij, dan gaat het vorige bestand terug en heeft de draaiende dienst het nieuwe nooit gezien.
Doorvoeren. nginx en Apache herladen; MariaDB, Valkey en de FPM-pools herstarten, want die lezen hun configuratie één keer.
De gezondheidscheck. MariaDB moet antwoorden, Valkey moet PONG zeggen, de webserver moet draaien.
Het automatische terugdraaien, als stap 5 faalt: het vorige bestand gaat terug, de dienst wordt opnieuw gestart, en de wijziging wordt als geweigerd gemeld. De tekst die je stuurde wordt niet bewaard — een bestand in /etc/corecp dat de machine niet draait zou precies de tweede waarheid zijn die deze motor wil voorkomen.

MariaDB en Valkey hebben helemaal geen configtest — deze familie servers heeft er nooit een gehad, en mysqld --validate-config bestaat pas vanaf MariaDB 13.1 terwijl Ubuntu 26.04 met 11.8 komt (we hebben het gemeten: op 11.8 wordt de vlag stil genegeerd). Voor die twee zijn stap 5 en 6 het hele vangnet — en daarom staan ze er voor élke dienst en niet alleen voor de diensten zonder validator: een configuratie die schoon test en een daemon die daarna toch niet start is geen theorie.

root@web1:~# corectl dropin set mariadb --file /tmp/too-big.cnf
[corecp] the health check for mariadb failed after the drop-in was placed — rolling back
[corecp] rolled back: mariadb is running on its previous configuration
error: the drop-in was placed and mariadb did not stay healthy (…), so it was rolled
back automatically. mariadb is running again on the previous configuration; the
refused text is not saved

Wat er nooit in mag

corectl weigert deze bij naam, en zegt wat er kapot zou gaan:

Klasse	Waarom
`socket`	CoreCP rendert de sockets waarmee diensten elkaar bereiken. Er één verplaatsen laat de andere helft wijzen naar een pad waar niets luistert.
`identity`	De gebruiker en groep waaronder een dienst draait bepalen welke bestanden hij mag lezen. CoreCP zet die per account en per pool.
`bind-address`	Adressen komen van de IP-manager en de firewall. Een bind hier is voor allebei onzichtbaar, en het gebruikelijke resultaat is een database die vanaf internet bereikbaar is.
`datadir`	Waar de data staat is wat de backups, de restores en de schijfboekhouding lezen. Een server die zijn datamap verplaatst heeft blijft draaien en wordt leeg geback-upt.
`include`	Nog een include brengt de configuratie ergens waar de state van deze machine niets over zegt.
`logpath`	De statistieken, de logviewer en de logrotatie lezen de paden die CoreCP rendert. Een verplaatst log is een log dat niemand roteert.

Voor fpm en sysctl komen daar klassen bij, want wat zij niet mogen verplaatsen is iets anders:

Klasse	Doel	Waarom
`account-limit`	fpm	Hoeveel werkprocessen een pool mag draaien is de limiet uit het pakket van die klant. Eén getal hier geeft élk account op de machine dezelfde limiet, terwijl het paneel het pakket blijft tonen.
`cage`	fpm	De kooi waarin een pool draait — zijn root, zijn werkmap, `open_basedir`, de tijdelijke mappen — wordt per account uit de home van dat account gerenderd.
`section`	fpm	Dit bestand wordt ingevoegd ín een pool die al bestaat, en FPM maakt bij elke sectiekop een nieuwe pool aan — ook bij dezelfde naam. Een kop hier laat de hele PHP van de machine weigeren te starten. Poolinstellingen schrijf je zónder kop; `[global]` is voor de master zelf.
`network-plane`	sysctl	Welke adressen deze server beantwoordt komt van de IP-manager en de firewall. Een kernel die stilletjes geen IPv6 meer spreekt laat elk gepubliceerd AAAA-record wijzen naar een machine die niet meer luistert.
`isolation`	sysctl	De PHP-pool van elk account draait in een systemd-sandbox die deze namespaces nodig heeft. Op nul zetten verhardt de machine niet, het zorgt dat geen enkele website meer start.
`identity`	sysctl	De naam van deze server staat op zijn certificaat en is hoe het paneel hem bereikt.

root@web1:~# corectl dropin set mariadb --file /tmp/bad.cnf
error: this drop-in sets 2 thing(s) a drop-in may not set:
  line 2: datadir = /srv/elsewhere — where the data lives is what the backups, …
  line 3: bind-address = 0.0.0.0 — the addresses a service answers on come from …

Dit is geen beveiligingsgrens — een beheerder met een root-shell kan elk bestand op de machine bewerken. Het is de grens tussen een instelling die CoreCP niet modelleert en een tweede, onzichtbare waarheid voor een instelling die hij wél modelleert. Dezelfde controle draait bij elke reconcile, dus een met de hand bewerkt bestand op de machine wordt gemeld en niet uitgerold, in plaats van stil toegepast.

Terug

De vijf vorige versies blijven op de machine staan, onder /etc/corecp/rendered/dropins/<dienst>/:

root@web1:~# corectl dropin history mariadb
Kept versions of the mariadb drop-in (newest first):
  1   4 lines    112 bytes  [mysqld]
  2   6 lines    168 bytes  [mysqld]

Restore one with: corectl dropin rollback mariadb --version <n>

root@web1:~# corectl dropin rollback mariadb --version 1
drop-in mariadb applied (/etc/mysql/conf.d/zz-corecp-custom.cnf)

De dropin helemaal weghalen zet de dienst terug op de configuratie van CoreCP zelf, en bewaart de tekst als versie:

root@web1:~# corectl dropin remove valkey
the valkey drop-in is gone; valkey-server runs on CoreCP's own configuration again

De controle na een wijziging

Onder een drop-in staat hoe de server controleert dat de wijziging werkt, in je eigen taal: bijvoorbeeld "de server antwoordt na de herstart op SELECT 1". Is die controle een opdracht, zoals nginx -t, dan staat de opdracht er zelf.

Klanten hebben dit niet

Er is geen dropin per account, en die komt er ook niet. Een klant verandert PHP via het PHP-beleid — een lijst met plafonds, waarbij elke waarde gecontroleerd wordt voordat hij gerenderd wordt — en zijn database via de gebruikerslimieten (MAX_USER_CONNECTIONS en verwanten). Ruwe configuratietekst van een account zou een regel zijn die niemand gecontroleerd heeft, in een bestand dat de dienst van alle andere accounts leest.

Dropins zijn server-admin en hoger, in het paneel en op de API. Een reseller die bij de routes komt krijgt 403 van de router, niet van een controle die iemand toevallig geschreven heeft.