Het serveradvies lezen

Elke CoreCP-server controleert zichzelf. Zo'n vijftig controles: draait alles, is er ruimte, klopt de firewall, verloopt er een certificaat, en — nieuw — is dit IP-adres ergens geblokkeerd, draaien er PHP-versies die geen beveiligingsfixes meer krijgen, staat er iets open dat niemand bedoeld heeft.

De uitkomst staat op één scherm: Servers → de server → Adviseur openen.

De drie kleuren, en wat ze betekenen

Vroeger was een controle goed of fout. Dat werkte niet: verreweg de meeste bevindingen zijn geen storing, maar ook niet niets. Daarom zijn er drie:

Kritiek betekent niet dat de server plat ligt. Het duidelijkste voorbeeld: staat het IP-adres van je server op een spamblokkeerlijst, dan is dat kritiek — je e-mail komt nergens meer aan — terwijl elke website op die machine gewoon draait. Andersom kan een volle schijf zowel kritiek zijn als de server onderuit halen. De adviseur zegt hoe erg het is; of de machine bedient is een andere vraag, en die staat op het serverdashboard.

Er is geen rapportcijfer. Bewust niet: "je server is 82% gezond" beantwoordt geen enkele vraag die je echt hebt. Je krijgt een lijst met bevindingen, ergste eerst.

Het scherm

Van boven naar beneden:

• De kop — de naam van de server, en in één woord hoe hij ervoor staat. Daaronder één zin: "2 kritiek punt(en), 4 die aandacht vragen", met erbij wanneer er voor het laatst gekeken is.
• Nu controleren — de knop rechtsboven. Zie hieronder.
• De categoriebalk — Alles · Beveiliging · Prestaties · Configuratie · Software, met per categorie hoeveel punten daar aandacht vragen. Klik erop en de lijst eronder krimpt tot die categorie. De filter zit in het adres, dus je kunt "de beveiligingspunten van stck1" gewoon in een ticket plakken.
• Vraagt aandacht — alleen de punten die aandacht of erger zijn, ergste eerst, met per punt de knop die je naar het scherm brengt waar je het oplost. Is er niets, dan staat er een groene regel dat alles in orde is.
• Alle controles — de volledige lijst, inclusief de groene. Die staan er met opzet bij: als je net iets hebt opgelost wil je de regel groen zien worden, en dat kan niet op een scherm dat alleen problemen toont.

De knop bij een bevinding heet Oplossen als hij naar een scherm in het paneel gaat, en Openen als hij het paneel verlaat — bij een blokkeerlijst is dat het aanmeldformulier van die lijst zelf, en dat is niet van ons.

Nu controleren

Drie van de controles kunnen niet vanaf de machine zelf beantwoord worden:

• staat mijn IP-adres op een blokkeerlijst — dat is een vraag aan Spamhaus;
• krijgt deze PHP-versie nog fixes — dat is een vraag aan een levensduur-register op internet;
• hoe goed doet de PHP-cache het — daarvoor moet elke PHP-werker op de machine iets uitrekenen.

Die drie zijn te traag — en te onbeleefd tegenover de andere kant — om bij elke paginaweergave opnieuw te stellen. Ze worden dus op een schema gemeten (elk uur draait er een taak op de server) en het scherm leest de uitkomst. Daarom staat er bij zulke regels "— measured 12 minutes ago": dat is hoe oud de meting is.

Klik je op Nu controleren, dan meet de server ze opnieuw, nu. Dat duurt een paar seconden. Doe dat vooral nadat je iets hebt opgelost — bijvoorbeeld nadat je je adres van een blokkeerlijst hebt laten halen — anders kijk je naar de oude uitkomst.

Wie alleen mag meekijken, ziet die knop niet: opnieuw meten laat de server het internet op, en dat is een beheerdershandeling.

De nieuwe controles, en waar ze op letten

Een paar dingen die de adviseur bewust niet doet:

• Een PHP-werker die sinds zijn herstart nog geen 500 verzoeken heeft gehad, krijgt geen oordeel over zijn cache. Dat cijfer zegt dan niets, en een oranje regel die niets zegt leert mensen oranje te negeren.
• Een blokkeerlijst die je vraag weigert (dat gebeurt bij een openbare DNS-server) wordt niet als "je staat op de lijst" gerapporteerd, maar als "ik kon het niet vragen, en dit is waarom". Dat verschil is belangrijk: het andere zou je naar een afmeldformulier sturen voor een blokkade die er niet is.
• Heeft de server meer PHP-werkers dan er in één meetronde passen (twaalf), dan wisselt hij elke ronde van groep. Na een paar uur is iedereen een keer geweest, en onder de lijst staat hoeveel er nog wachten.

Vanaf de terminal

Alles wat op het scherm staat, staat ook in corectl — het scherm leest letterlijk dit:

# De hele lijst, met ernst en categorie per regel
corectl doctor

[ ok ] config   operating system     Ubuntu 26.04 LTS
[warn] software pending updates      5 pending upgrade(s)
[CRIT] config   ip reputation        185.117.226.120 on zen.spamhaus.org (XBL …)
...
Node is healthy. 1 critical, 2 to look at (corectl doctor --json).

Let op de laatste regel: "Node is healthy" én een kritiek punt tegelijk. Dat is precies het verschil hierboven — de machine bedient, en er is iets mis.

# Alleen wat aandacht vraagt
corectl doctor --json | python3 -c '
import json,sys
for c in json.load(sys.stdin)["checks"]:
    if c["severity"] != "ok":
        print(f"{c[\"severity\"]:5} {c[\"name\"]:20} {c[\"detail\"]}")'

# Opnieuw meten — respecteert de intervallen, dus dit doet vaak niets
corectl advisor refresh
nothing was due — every measurement is still fresh (--force to re-measure)

# Opnieuw meten, nu, alles. Dit is wat "Nu controleren" doet.
corectl advisor refresh --force
measured: ip reputation, runtime support, opcache (573ms)

De uurtaak die de metingen doet:

systemctl list-timers corecp-advisor.timer
journalctl -u corecp-advisor.service --since -1d

Boven één machine: het platform en een account

De adviseur die hierboven staat, kijkt naar één server. Dezelfde controlelijst bestaat op twee niveaus erboven, en die twee zijn paneelvragen: een machine kan niet melden dat hij zwijgt, en hij weet niet welke namen een klant heeft gepubliceerd, welk pakket er onder een account hangt of welk releasekanaal een golf verwacht.

Op de voorpagina: het platform

Het paneel bevraagt elke gekoppelde server (node.doctor), telt de uitkomsten op en zet daar de dingen bij die alleen het paneel weet:

Daaronder staan de bevindingen van de machines zelf, met de naam van de machine erbij — twee servers met hetzelfde probleem zijn dus twee regels, en je ziet meteen welke.

Elke regel klikt door naar zijn eigen lijst. Is er precies één machine mis, dan opent de knop díe machine; zijn er meerdere, dan opent hij de gefilterde lijst (/nodes?state=degraded). Een getal dat een probleem meldt en nergens heen gaat, is een doodlopende weg.

Op een account: de hosting van één klant

Klanten → het account → Overzicht. Bovenaan staat hetzelfde aandacht-paneel, en eronder de volledige controlelijst van dat account:

En daar staat, met dezelfde controlenaam als op de server zelf, IP-reputatie tussen: staat een adres van de machine op een blokkeerlijst, dan zie je dat op die machine én op elk account dat erop draait. Het is één bevinding, op twee schermen — want de klant wiens mail terugkomt moet kunnen zien waaróm, zonder een serverscherm te openen. De knop naar het afmeldformulier krijgt hij niet: dat is een beheerdershandeling.

Wat een klant niet ziet, zijn de regels van de machine die alleen de beheerder aangaan — een verlopend agentcertificaat bijvoorbeeld. Een melding over iets wat je niet kunt zien en niet kunt oplossen, is ruis.

DMARC op p=none is oranje, niet rood

De meest voorkomende regel, en de bewuste keuze erachter. p=none betekent: "beste ontvanger, controleer mijn mail wel, maar doe er nog niets mee — stuur me alleen rapporten." Dat is de juiste eerste sport van de ladder; zo hoor je te beginnen. Het is alleen de verkeerde sport om op te blijven staan.

Dus: oranje, met een knop naar Mailbeveiliging, waar je hem naar quarantine en daarna naar reject zet. Nooit rood — iemand rood geven omdat hij het in de goede volgorde doet, leert alleen maar rood negeren.

Nu controleren, en wat er wel en niet vanzelf gebeurt

Een gewone paginaweergave stuurt niets het paneel uit. De vlootuitvraag, de DNS-opzoekingen en het opvragen van je website lezen een cache van vijf minuten. Alleen Nu controleren gaat er echt op uit — anders zou een dashboard dat iemand op een muur laat staan elke halve minuut de websites van klanten opvragen.

Een certificaat dat niet klopt telt trouwens niet als "de site ligt eruit": daar is de certificaatregel voor. De adviseur probeert het dan één keer opnieuw zonder de controle, puur om te weten óf er een server achter zit.

Vanaf de terminal, op het paneel

# De hele vloot: de opgetelde regels, daaronder wat elke machine zelf meldt
corecp-panel advisor platform --config /etc/corecp-panel/panel.yaml

the platform: crit · 3 machine(s), 1 unreachable · measured 2026-08-13T21:04:11Z
SEVERITY  CHECK                              CATEGORY  DETAIL
CRIT      platform.config.node-unreachable   config    1 machine answered before and does not now: ns2.corecp.dev
CRIT      node.config.blocklist.stck1-…      config    stck1.corecp.dev: 185.117.226.120 on zen.spamhaus.org
WARN      platform.software.channel-drift    software  stck2.corecp.dev follows edge, wave wave-2 expects stable

# Inclusief de controles die geslaagd zijn
corecp-panel advisor platform --all

# Eén klant. Op paneel-id, op node/gebruikersnaam, of op een unieke naam
corecp-panel advisor account test300

# Opnieuw meten in plaats van uit de cache lezen
corecp-panel advisor account test300 --refresh

En de ronde die vanzelf draait, met de hand:

# Meten, doorgeven wat veranderd is, en zeggen hoeveel dat er waren
corecp-panel advisor run --json
{"changed":1}

# Nog een keer, op een vloot waar niets veranderd is
corecp-panel advisor run --json
{"changed":0}

Die tweede nul is het punt. Een bevinding die niet verandert, meldt zich één keer en daarna niet meer — anders is het geen waarschuwing maar behang.

Eén bevinding, één bericht

De adviseur mailt nooit zelf. Twee bevindingen gaan door naar het meldingssysteem, en precies twee:

• een adres van een server op een blokkeerlijst;
• een website die niet meer antwoordt.

Die twee hadden nog geen eigenaar. Certificaten, backups en quota hebben er wél een — die krijgen al een systeemmail met eigen drempels en demping — dus die laat de adviseur met rust. Hij tóónt ze, hij meldt ze niet. Anders zou één verlopend certificaat een mail en een belletje worden, en dat is precies de dubbele stroom die hiermee verdwenen is.

De twee die wél doorgaan, sturen geen mail: ze schrijven een auditregel, en dat is de bel, de pushmelding en Telegram — elk met de voorkeuren van de lezer zelf erop.

# Welke controle door welk kanaal gaat, in één tabel
corecp-panel health kinds --config /etc/corecp-panel/panel.yaml

ID                      AUDIT ACTION            CATEGORY  MAIL KIND  PAGES  WHAT
health.node.blocklist   node.health.blocklist   fleet     -          no     An address of a node is on a blocklist
health.site.down        domain.health.down      account   -          no     A website is not answering
health.cert.expiring    cert.health.expiring    account   cert.expiring  no  A certificate is expiring

Een streepje in MAIL KIND en no in PAGES: dat is hoe "geen dubbele melding" er van buiten uitziet.

Als er iets niet klopt

Een adres van een blokkeerlijst laten halen zonder eerst te weten waaróm het erop stond, is trouwens verspilde moeite: een gehackte site of een doorgestuurde mailstroom zet je er binnen een dag weer op, en opnieuw op de lijst komen kost veel meer tijd dan het wachten.

Zie ook

• De firewall van een server — waar Open poorten naartoe verwijst.
• Het PHP-beleid van een server — waar OPcache en Ondersteuning runtimes naartoe verwijzen.
• Serverinstellingen en diensten — waar het meeste van Configuratie naartoe verwijst.
• E-mail die wij je sturen — wanneer een kritiek punt je ook echt bereikt.
• Mailbeveiliging en DNSSEC — waar de SPF-, DKIM- en DMARC-regels van het accountadvies naartoe verwijzen.
• Zorgen dat je e-mail aankomt — dezelfde drie records, uitgelegd zonder jargon.