@@PRODUCT@@

Diagnosegegevens opsturen

Als er iets mis is met het paneel zelf, vraagt degene die meekijkt altijd om ongeveer hetzelfde: wat zegt doctor, wat staat er in de configuratie, wat is er op dit moment ongezond, welke taken liepen er, welke versies draaien er op de serve

Geschreven voor: Beheerder

Als er iets mis is met het paneel zelf, vraagt degene die meekijkt altijd om ongeveer hetzelfde: wat zegt doctor, wat staat er in de configuratie, wat is er op dit moment ongezond, welke taken liepen er, welke versies draaien er op de servers, en wat staat er in het logboek. Dat waren zes losse commando's en zes keer knippen en plakken — en juist bij dat plakken gaat het mis, want in een logregel staat zomaar een verbindingsreeks mét wachtwoord.

Sinds deze ronde is het één commando.

corecp-panel support bundle --config /etc/corecp-panel/panel.yaml

Je krijgt één .tar.gz, alleen leesbaar voor root, met daarin de doctor-uitvoer, de configuratie, wat er nu ongezond is, de recente taken, de serverlijst, de laatste auditregels en het logboek van het paneel.

Alles over één melding

Heb je een support-ID uit een foutmelding (zie Het support-ID bij een foutmelding), geef het dan mee. Het pakket bevat dan ook de auditregels en de logregels van precies die aanvraag:

corecp-panel support bundle --config /etc/corecp-panel/panel.yaml \
    --request-id Rk5t2wQfMz0 --out /root/support-Rk5t2wQfMz0.tar.gz

Wat er níét in zit

Twee lagen zorgen daarvoor, en de tweede is de belangrijkste.

De eerste laag haalt eruit wat op een geheim lijkt — een privésleutel, een adres met een wachtwoord erin, een token, een veld dat wachtwoord, token of secret heet. Op elke plek waar iets weg is, staat een merkteken zoals [redacted:named-value], zodat je ziet dát er iets stond. Twee dingen blijven juist wél staan, expres: certificaten (die zijn openbaar, en "welk certificaat staat hier" is nu net de vraag) en paden naar geheimen — secret_key_file: /etc/corecp-panel/secret.key is geen sleutel maar een wegwijzer, en zonder die wegwijzer kan niemand zien waar het paneel kijkt.

De tweede laag stelt een andere vraag: staat er echt materiaal van deze machine in? Hij leest de sleutelbestanden waar de configuratie naar wijst — de databaseverbinding, de hoofdsleutel, de vlootsleutel, het relaywachtwoord — en zoekt naar precies die bytes. Hij hoeft dus niet te raden hoe een geheim eruit ziet; hij heeft ze in handen. Dat is het verschil met een controle die zichzelf nakijkt: die zou "schoon" zeggen over een geheim in een vorm waar niemand een regel voor had geschreven.

Vindt die tweede laag iets, dan wordt het bestand niet geschreven. Je krijgt te horen in welk bestand het zat en om welk sleutelmateriaal het ging — nooit de waarde zelf. Het pakket wordt in het geheugen opgebouwd en raakt de schijf pas als de toets is gehaald, want een bestand dat even bestond met een sleutel erin is een bestand dat inmiddels ergens in een back-up staat.

Controleren vóór je het verstuurt

corecp-panel support verify /root/support-Rk5t2wQfMz0.tar.gz \
    --config /etc/corecp-panel/panel.yaml

Dit draait dezelfde toets op het bestand dat je gaat versturen, in plaats van op de belofte dat de machine die het schreef het gecontroleerd heeft. In het pakket zelf staat in manifest.json wat er is weggehaald en waarnaar er is gezocht — inclusief sleutelbestanden die niet leesbaar waren voor degene die het commando uitvoerde. Dat laatste is met opzet zichtbaar: een controle waarvan je de dekking niet ziet, kun je niet wegen.

Waarom er geen knop in het paneel zit

Wat in het pakket zit is de eigen staat van het paneel: de configuratie, het logboek, het auditspoor. Wie een shell op die machine heeft, kan dat allemaal al lezen. Wie alleen een beheerderswachtwoord heeft, kan dat niet — en hoort dat niet alsnog te kunnen door op een knop te drukken.

Zie ook

  • Het support-ID bij een foutmelding — waar het kenmerk vandaan komt.
  • Als het paneel wegvalt — het scenario waarin de machine er niet meer is.