Remedierea problemei Cockpit Web Console care nu se conectează pe serverul SUSE Linux Enterprise

Dacă consola web Cockpit nu se conectează la o gazdă SUSE Linux Enterprise Server (SLES), încercați mai întâi https://SERVER_IP:9090, apoi verificați dacă cockpit.socketascultă și dacă firewall-ul permite serviciul Cockpit în zona utilizată de interfața de rețea a serverului. Într-o instalare standard, aceste verificări rezolvă cele mai frecvente cauze: o adresă URL sau un port greșit, un socket inactiv, pachete Cockpit lipsă sau o conexiune de intrare blocată.

Acest ghid se aplică sistemelor SLES care utilizează systemd și au Cockpit disponibil din repozitoriile de produse configurate. Ghidul actual SLES 16 Cockpit de la SUSE documentează instalarea modelelor și comenzile de activare a socketurilor mai jos. Disponibilitatea și numele pachetelor pot varia în funcție de pachetul de service SLES, modul și dreptul de asistență, așadar, pe o gazdă SLES 15 mai veche, confirmați că Cockpit este oferit de repozitoriile SUSE activate înainte de a trata o eroare de instalare ca o eroare de serviciu.

Începeți cu simptomul

Folosește eroarea din browser pentru a restrânge cauza. O expirare sau mesajul „site-ul nu poate fi accesat” indică de obicei rutare, reguli de firewall sau un listener care nu este activ. O conexiune refuzată înseamnă adesea că nimic nu acceptă conexiuni la adresa și portul selectate. O pagină de conectare în Cockpit înseamnă că serviciul web este accesibil; o eroare de autentificare ulterioară este o problemă separată a contului sau a politicii. Un avertisment privind certificatul înseamnă că negocierea HTTPS a ajuns la server, dar browserul nu are încredere în certificat sau în numele acestuia.

De exemplu, să presupunem că un administrator nu poate deschide un server a cărui adresă este 192.0.2.25. Testați https://192.0.2.25:9090de pe o mașină căreia ar trebui să i se permită să îl administreze. Cockpit utilizează în mod normal HTTPS pe portul 9090. Tastarea doar a adresei IP poate deschide un serviciu diferit, iar utilizarea [URL] http://poate duce la o redirecționare sau la un avertisment al browserului în loc de vizualizarea de conectare așteptată.

1. Verificați adresa URL și accesibilitatea

Confirmați adresa curentă a serverului din consola SLES sau dintr-un inventar de încredere și includeți portul explicit:

https://192.0.2.25:9090

Din client, testați dacă portul TCP 9090 este accesibil. Pe o stație de lucru de administrare Linux cu netcat instalat, executați:

nc -vz 192.0.2.25 9090

O conexiune TCP reușită dovedește doar că portul este accesibil; nu dovedește că autentificarea va funcționa. O expirare sugerează verificarea zonei firewall active a serverului, a oricărui firewall de rețea din amonte, a rutării și a accesului VPN. Un refuz sugerează verificarea listener-ului de pe gazda SLES. Dacă netcat nu este disponibil, testați dintr-un browser sau utilizați un alt instrument de conectivitate TCP aprobat, în loc să instalați un utilitar neaprobat pe o gazdă de producție.

2. Confirmați că Cockpit este instalat și că socket-ul său este activ

Conectați-vă prin SSH sau o consolă locală și inspectați socket-ul. Cockpit utilizează în mod normal activarea socket-ului prin systemd: systemd ascultă o conexiune primită în numele Cockpit și pornește serviciul web la cerere. Din acest motiv, unitatea cheie de inspectat este de obicei cockpit.socket, nu un . care rulează continuu cockpit.service.

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

Căutați un socket activ/de ascultare și un listener legat la portul 9090. Dacă unitatea lipsește, este posibil ca Cockpit să nu fie instalat. Pe o versiune SLES ale cărei depozite activate furnizează modelul Cockpit, SUSE documentează instalarea acestuia cu:

sudo zypper refresh
sudo zypper in -t pattern cockpit

Dacă Zypper raportează că modelul nu poate fi găsit, verificați produsul, pachetul service, modulele activate, starea depozitului și drepturile de asistență cu administratorul SUSE. Nu adăugați un depozit terț fără legătură doar pentru ca comanda să aibă succes. După ce confirmați că Cockpit este instalat, activați și porniți socket-ul său:

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

Opțiunea --nowpornește socketul imediat și îl activează pentru porniri viitoare. Dacă systemd raportează o unitate defectă, verificați eroarea exactă înainte de a o reporni în mod repetat:

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

3. Permiteți Cockpit să treacă prin zona activă a firewall-ului

Un ascultător activ poate fi totuși inaccesibil dacă firewall-ul gazdă întrerupe conexiunea. SLES folosește firewalld pentru gestionarea firewall-ului în versiunile actuale. Mai întâi identificați zona activă și interfața atribuită acesteia:

sudo firewall-cmd --get-active-zones

Apoi adăugați serviciul Cockpit denumit la zona care conține interfața de administrare. Înlocuiți-l publiccu zona reală raportată pe gazdă:

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

Comanda finală ar trebui să raporteze yes. Dacă interfața de rețea se află într-o altă zonă, deschiderea serviciului în publicnu va remedia regulile acelei interfețe. Documentația SUSE Cockpit utilizează cockpitserviciul firewalld; deschiderea serviciului numit este preferabilă deschiderii întregului trafic sau dezactivării firewall-ului. Verificați, de asemenea, grupurile de securitate în cloud, firewall-urile perimetrale, politicile VPN și ACL-urile de rețea dacă regula gazdă este corectă, dar clientul tot expiră.

Dacă imaginea SLES utilizează o configurație diferită de gestionare a firewall-ului, urmați politica pentru sistemul respectiv în loc să aplicați comenzile firewalld orbește. Nu goliți regulile firewall-ului și nu dezactivați firewall-ul pe un server de producție administrat de la distanță: acest lucru poate expune serviciile și poate întrerupe calea curentă de gestionare.

4. Separați o eroare de conexiune de o problemă de certificat sau de conectare

După ce se încarcă pagina de conectare, calea de rețea către Cockpit funcționează. Cockpit se așteaptă în mod normal ca conexiunile browserului să utilizeze HTTPS și prezintă un certificat TLS. Un avertisment pentru un certificat autosemnat sau o nepotrivire de nume nu înseamnă că socketul nu funcționează. Pentru o gazdă de laborator, verificați amprenta printr-un canal de încredere înainte de a accepta avertismentul. Pentru sistemele gestionate, instalați un certificat al cărui nume de subiect corespunde cu numele de gazdă utilizat de administratori și al cărui lanț este de încredere pentru browserele lor.

Dacă apare pagina de conectare, dar acreditările sunt respinse, verificați numele de utilizator, parola, starea contului și politica de autentificare a serverului. Cockpit se autentifică, în general, în funcție de conturile de sistem; nu este o bază de date separată pentru utilizatori. Nu introduceți parole în comenzi sau jurnale în timpul depanării. Dacă pagina se încarcă, dar interfața rămâne goală sau se deconectează după conectare, verificați consola pentru dezvoltatori a browserului și jurnalele recente ale Cockpit. Un proxy invers poate cauza, de asemenea, erori dacă nu acceptă conexiuni WebSocket sau transmite mai departe informații greșite despre protocol sau gazdă.

5. Revizuirea jurnalelor și a setărilor proxy după ce se trec de elementele de bază

Capturați o scurtă fereastră de jurnal în timp ce efectuați o nouă încercare de conectare:

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

Căutați erori de legare, erori de permisiune sau certificat și mesaje care se aliniază cu timpul de testare. Dacă serverul ascultă local, dar un client la distanță nu se poate conecta, investigați calea de rețea și zona firewalld înainte de a modifica configurația Cockpit. Dacă accesul direct funcționează, dar accesul printr-un proxy eșuează, comparați temporar printr-o rută directă permisă, apoi examinați suportul pentru actualizarea WebSocket al proxy-ului și anteturile redirecționate. Evitați modificarea setărilor de origine sau TLS ale Cockpit ca prim pas; setările incorecte de încredere a proxy-ului pot slăbi securitatea.

Verificați reparația

După ce faceți o modificare pe rând, verificați aceste rezultate:

• systemctl status cockpit.socketarată socketul activ și în ascultare.
• Gazda SLES are un ascultător pe portul așteptat, în mod normal TCP 9090.
• Regula firewall este prezentă în zona atribuită interfeței de administrare.
• Clientul poate accesa serverul la https://SERVER_IP:9090și vede pagina de conectare în Cockpit.
• După autentificare, pagina rămâne conectată și jurnalul recent nu conține nicio eroare de pornire sau conexiune corespondentă.

Dacă socketul este activ și verificările locale reușesc, dar testele TCP la distanță tot expiră, este probabil ca eroarea rămasă să fie în afara Cockpit-ului, cum ar fi un firewall în amonte, o rută de rețea, o înregistrare DNS sau o regulă VPN. Dacă serviciul eșuează pe un sistem SLES acceptat în alte moduri, salvați starea unității și jurnalul de ieșire și verificați documentația SUSE sau canalul de asistență pentru configurația exactă a pachetului service, în loc să aplicați corecții destinate unei alte distribuții.

Referințe oficiale

• SUSE: Administrarea serverului SUSE Linux Enterprise folosind Cockpit
• Proiect Cockpit: Pornire și activare socket systemd
• Proiect Cockpit: Port și adresă TCP
• Proiect Cockpit: HTTPS și certificate
• Proiect Cockpit: Întrebări frecvente despre depanare
• SUSE: Configurarea firewall-ului SLES 15 SP5 și zonele firewalld