Los het probleem op dat de Cockpit-webconsole geen verbinding maakt op SUSE Linux Enterprise Server.

Als de Cockpit-webconsole geen verbinding kan maken met een SUSE Linux Enterprise Server (SLES)-host, probeer dan eerst https://SERVER_IP:9090de verbinding tot stand te brengen en controleer vervolgens of de cockpit.socketverbinding actief is en of de firewall de Cockpit-service toestaat in de zone die wordt gebruikt door de netwerkinterface van de server. Bij een standaardinstallatie lossen deze controles de meest voorkomende oorzaken op: een onjuiste URL of poort, een inactieve socket, ontbrekende Cockpit-pakketten of een geblokkeerde inkomende verbinding.

Deze handleiding is van toepassing op SLES-systemen die systemd gebruiken en waarop Cockpit beschikbaar is vanuit de geconfigureerde productrepository's. De huidige SUSE SLES 16 Cockpit-handleiding beschrijft de installatiepatronen en de onderstaande opdrachten voor socketactivering. De beschikbaarheid en namen van pakketten kunnen variëren afhankelijk van het SLES-servicepack, de module en de ondersteuningsrechten. Controleer daarom op een oudere SLES 15-host of Cockpit wordt aangeboden door de ingeschakelde SUSE-repository's voordat u een installatiefout als een servicefout beschouwt.

Begin met het symptoom.

Gebruik de foutmelding in de browser om de oorzaak te achterhalen. Een time-out of "site kan niet worden bereikt" wijst meestal op een routeringsprobleem, firewallregels of een niet-actieve listener. Een geweigerde verbinding betekent vaak dat er geen verbindingen worden geaccepteerd op het geselecteerde adres en de geselecteerde poort. Een Cockpit-aanmeldingspagina betekent dat de webservice bereikbaar is; een latere authenticatiefout duidt op een probleem met een ander account of beleid. Een certificaatwaarschuwing betekent dat de HTTPS-onderhandeling de server heeft bereikt, maar dat de browser het certificaat of de naam ervan niet vertrouwt.

Stel bijvoorbeeld dat een beheerder geen toegang heeft tot een server met het adres 192.0.2.25. Test dit https://192.0.2.25:9090vanaf een machine die wel beheerdersrechten zou moeten hebben. Cockpit gebruikt normaal gesproken HTTPS op poort 9090. Het invoeren van alleen het IP-adres kan een andere service openen, en het gebruik van http://kan leiden tot een omleiding of een browserwaarschuwing in plaats van het verwachte inlogscherm.

1. Controleer de URL en de bereikbaarheid.

Controleer het huidige adres van de server via de SLES-console of een betrouwbare inventaris en vermeld daarbij expliciet de poort:

https://192.0.2.25:9090

Test vanaf de client of TCP-poort 9090 bereikbaar is. Voer op een Linux-beheerwerkstation met netcat het volgende commando uit:

nc -vz 192.0.2.25 9090

Een succesvolle TCP-verbinding bewijst alleen dat de poort bereikbaar is; het bewijst niet dat inloggen zal werken. Een time-out suggereert dat de actieve firewallzone van de server, eventuele firewalls in het upstream-netwerk, routering en VPN-toegang gecontroleerd moeten worden. Een weigering suggereert dat de listener op de SLES-host gecontroleerd moet worden. Als netcat niet beschikbaar is, test dan vanuit een browser of gebruik een ander goedgekeurd TCP-connectiviteitstool in plaats van een niet-goedgekeurd hulpprogramma op een productiehost te installeren.

2. Controleer of Cockpit is geïnstalleerd en of de bijbehorende socket actief is.

Maak verbinding via SSH of een lokale console en inspecteer de socket. Cockpit gebruikt normaal gesproken systemd-socketactivering: systemd luistert namens Cockpit naar een inkomende verbinding en start de webservice op aanvraag. Daarom is de belangrijkste eenheid om te inspecteren meestal de socket cockpit.socket, en niet een continu draaiende service cockpit.service.

sudo systemctl status cockpit.socket
sudo ss -ltnp | grep ':9090'

Zoek naar een actieve/luisterende socket en een listener die is gekoppeld aan poort 9090. Als de unit ontbreekt, is Cockpit mogelijk niet geïnstalleerd. Op een SLES-release waarvan de ingeschakelde repositories het Cockpit-patroon bieden, beschrijft SUSE de installatie als volgt:

sudo zypper refresh
sudo zypper in -t pattern cockpit

Als Zypper meldt dat het patroon niet kan worden gevonden, controleer dan het product, het servicepack, de ingeschakelde modules, de repositorystatus en de ondersteuningsrechten met uw SUSE-beheerder. Voeg geen ongerelateerde repository van derden toe alleen om de opdracht te laten slagen. Nadat u hebt bevestigd dat Cockpit is geïnstalleerd, schakelt u de socket in en start u deze:

sudo systemctl enable --now cockpit.socket
sudo systemctl status cockpit.socket

Deze --nowoptie start de socket direct en maakt hem ook beschikbaar voor toekomstige opstartpogingen. Als systemd een defecte eenheid meldt, controleer dan de exacte foutmelding voordat u deze herhaaldelijk opnieuw opstart.

sudo journalctl -u cockpit.socket -b --no-pager
sudo journalctl -u cockpit.service -b --no-pager

3. Sta Cockpit toe om de actieve firewallzone te passeren.

Een actieve listener kan nog steeds onbereikbaar zijn als de hostfirewall de verbinding verbreekt. SLES gebruikt firewalld voor firewallbeheer in de huidige versies. Identificeer eerst de actieve zone en de daaraan toegewezen interface:

sudo firewall-cmd --get-active-zones

Voeg vervolgens de genoemde Cockpit-service toe aan de zone die de beheerinterface bevat. Vervang dit publicdoor de daadwerkelijke zone die op uw host wordt weergegeven:

sudo firewall-cmd --zone=public --add-service=cockpit --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --query-service=cockpit

Het laatste commando zou moeten rapporteren yes. Als de netwerkinterface zich in een andere zone bevindt, publiczal het openen van de service in die zone de regels van die interface niet corrigeren. De Cockpit-documentatie van SUSE gebruikt de cockpitfirewalld-service; het openen van de genoemde service heeft de voorkeur boven het openstellen van al het verkeer of het uitschakelen van de firewall. Controleer ook cloudbeveiligingsgroepen, perimeterfirewalls, VPN-beleid en netwerk-ACL's als de hostregel correct is, maar de client nog steeds een time-out krijgt.

Als uw SLES-image een andere firewallbeheerconfiguratie gebruikt, volg dan het beleid voor dat systeem in plaats van blindelings firewalld-opdrachten toe te passen. Verwijder geen firewallregels en schakel de firewall niet uit op een op afstand beheerde productieserver: dit kan services blootleggen en uw huidige beheerproces verstoren.

4. Maak onderscheid tussen een verbindingsfout en een certificaat- of inlogprobleem.

Zodra de inlogpagina is geladen, werkt de netwerkverbinding met Cockpit. Cockpit verwacht normaal gesproken HTTPS-verbindingen voor browsers en presenteert een TLS-certificaat. Een waarschuwing voor een zelfondertekend certificaat of een naamconflict betekent niet dat de socket niet werkt. Controleer voor een labhost de certificaatvingerafdruk via een vertrouwd kanaal voordat u de waarschuwing accepteert. Installeer voor beheerde systemen een certificaat waarvan de onderwerpnaam overeenkomt met de hostnaam die beheerders gebruiken en waarvan de certificaatketen door hun browsers wordt vertrouwd.

Als de inlogpagina verschijnt maar de inloggegevens worden geweigerd, controleer dan de gebruikersnaam, het wachtwoord, de accountstatus en het authenticatiebeleid van de server. Cockpit authenticeert doorgaans via systeemaccounts; het is geen aparte gebruikersdatabase. Plaats geen wachtwoorden in commando's of logbestanden tijdens het oplossen van problemen. Als de pagina laadt maar de interface blanco blijft of de verbinding na het inloggen wordt verbroken, controleer dan de ontwikkelaarsconsole van de browser en recente Cockpit-logbestanden. Een reverse proxy kan ook problemen veroorzaken als deze geen WebSocket-verbindingen ondersteunt of onjuiste protocol- of hostinformatie doorstuurt.

5. Controleer de logbestanden en proxy-instellingen wanneer de basiscontrole is geslaagd.

Leg een kort logvenster vast tijdens een nieuwe verbindingspoging:

sudo journalctl -u cockpit.socket -u cockpit.service --since "10 minutes ago" --no-pager

Zoek naar bindfouten, permissie- of certificaatfouten en berichten die overeenkomen met het tijdstip van de test. Als de server lokaal luistert maar een externe client geen verbinding kan maken, onderzoek dan het netwerkpad en de firewalld-zone voordat u de Cockpit-configuratie wijzigt. Als directe toegang werkt, maar toegang via een proxy mislukt, vergelijk dan tijdelijk via een toegestane directe route en controleer vervolgens de WebSocket-upgradeondersteuning en de doorgestuurde headers van de proxy. Vermijd het wijzigen van de oorsprong of TLS-instellingen van Cockpit als eerste stap; onjuiste proxy-vertrouwensinstellingen kunnen de beveiliging verzwakken.

Controleer de reparatie.

Controleer na het één voor één doorvoeren van de wijzigingen de volgende resultaten:

• systemctl status cockpit.socketGeeft aan dat de socket actief is en luistert.
• De SLES-host heeft een listener op de verwachte poort, normaal gesproken TCP 9090.
• De firewallregel is aanwezig in de zone die is toegewezen aan de beheerinterface.
• De klant kan de server bereiken via https://SERVER_IP:9090en ziet de Cockpit-aanmeldingspagina.
• Na authenticatie blijft de pagina verbonden en bevat het recente logboek geen overeenkomende opstart- of verbindingsfouten.

Als de socket actief is en lokale controles slagen, maar externe TCP-tests nog steeds een time-out geven, ligt de resterende fout waarschijnlijk buiten Cockpit zelf, bijvoorbeeld bij een upstream firewall, netwerkroute, DNS-record of VPN-regel. Als de service faalt op een verder ondersteund SLES-systeem, sla dan de status van de unit en de logboekuitvoer op en raadpleeg de SUSE-documentatie of het ondersteuningskanaal voor de exacte servicepackconfiguratie in plaats van correcties toe te passen die bedoeld zijn voor een andere distributie.

Officiële referenties

• SUSE: SUSE Linux Enterprise Server beheren met Cockpit
• Cockpit-project: Opstarten en activering van systemd-sockets
• Cockpit-project: TCP-poort en -adres
• Cockpit-project: HTTPS en certificaten
• Cockpit Project: Veelgestelde vragen over probleemoplossing
• SUSE: SLES 15 SP5 firewallconfiguratie en firewalld-zones