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 Redi

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 Redis. 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
  redis     —          /etc/redis/zz-corecp-custom.conf                   health check + rollback

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.

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, Redis en de FPM-pools herstarten, want die lezen hun configuratie één keer.
De gezondheidscheck. MariaDB moet antwoorden, Redis 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 Redis hebben helemaal geen configtest — Redis 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.

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 redis
the redis drop-in is gone; redis-server runs on CoreCP's own configuration again

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.