Remediați eroarea „Nu se poate conecta la Kopano Core” din aplicația web Kopano

Cea mai rapidă metodă de a remedia o eroare „Cannot Connect to Kopano Core” (Nu se poate conecta la Kopano Core) în Kopano WebApp este de a determina care dintre cele trei straturi este de fapt defect: Kopano Core în sine , endpoint-ul WebApp-to-Core sau stratul PHP-MAPI pe care WebApp îl folosește pentru a comunica cu Core. Repornirea completă poate părea uneori că rezolvă problema, dar ascunde cauza și poate face ca erorile recurente să fie mai greu de diagnosticat.

Documentația oficială WebApp a Kopano precizează că WebApp depinde de php-mapi, iar DEFAULT_SERVERsetările sale controlează unde WebApp se conectează la Kopano Core. Opțiunile documentate includ socketul Unix local, HTTP pe portul 236 și HTTPS pe portul 237. Consultați documentația de configurare Kopano WebApp și Manualul de administrare Kopano Core .

Notă importantă privind versiunea: Manualele publice de administrare ale Kopano disponibile la momentul scrierii sunt mai vechi decât multe distribuții Linux actuale. Prin urmare, numele pachetelor, versiunile PHP, wrapper-ele de servicii și locațiile jurnalelor pot diferi în funcție de instalare. Modelul de conexiune și opțiunile de configurare descrise mai jos se bazează pe documentația publicată de Kopano, dar ar trebui să confirmați căile locale și versiunile pachetelor înainte de a schimba un server de producție.

Ce soluție ar trebui să încerci prima?

Începeți cu simptomul care se potrivește cel mai bine sistemului dumneavoastră, în loc să aplicați fiecare modificare deodată.

1. Kopano Core chiar rulează?

Verificați procesul serverului înainte de a edita configurația WebApp. Pe o distribuție bazată pe systemd, utilizați:

sudo systemctl status kopano-server

Dacă unitatea este defectă sau inactivă, verificați jurnalul său recent înainte de a o reporni:

sudo journalctl -u kopano-server -n 100 --no-pager

Căutați erori de conexiune la baza de date, erori de analiză a configurației, probleme de permisiuni, fișiere lipsă sau erori de pornire. Documentația principală a Kopano menționează că modificările de configurare necesită, în general, repornirea componentei afectate, de exemplu cu systemctl restart kopano-<component>. De asemenea, este documentată /etc/kopano/server.cfgca fișier de configurare obișnuit pentru kopano-server. Consultați Configurarea componentelor KC .

Alegeți această rută atunci când: serviciul este evident nefuncțional, se blochează după pornire sau alte instrumente Kopano nu pot comunica cu Core. Repararea WebApp mai întâi ar trata doar un simptom din aval.

Compromis: o repornire este cea mai rapidă încercare de recuperare, dar dacă procesul eșuează imediat din nou, aveți nevoie de ieșirea jurnalului. Pe sistemele de producție, capturați detaliile eșecului înainte de repornire, astfel încât să nu pierdeți cele mai clare dovezi.

2. WebApp indică către endpoint-ul Kopano Core corect?

În WebApp, setarea cheie este DEFAULT_SERVERîn config.php. Manualul oficial WebApp al Kopano documentează aceste exemple:

define("DEFAULT_SERVER", "default:");
define("DEFAULT_SERVER", "file:///var/run/kopano/server.sock");
define("DEFAULT_SERVER", "http://localhost:236/kopano");
define("DEFAULT_SERVER", "https://localhost:237/kopano");

Implicit documentat se mapează la socketul local file:///var/run/kopano/server.sock. Aceasta este de obicei cea mai simplă alegere atunci când WebApp și Core rulează pe aceeași mașină. Dacă rulează pe mașini separate, un socket Unix local nu poate funcționa; aveți nevoie în schimb de un endpoint HTTP sau HTTPS accesibil. Documentația Kopano privind optimizarea performanței descrie o gazdă WebApp care se conectează la un server Kopano separat prin portul 236 sau portul 237 pentru SSL. Consultați optimizarea performanței Kopano și configurarea serverului separat .

Socket Unix local: în general, opțiunea cu cea mai mică suprasarcină pe o singură gazdă și evită expunerea unui serviciu TCP doar pentru accesul local la WebApp. Costul este că socketul trebuie să existe și procesul serverului web trebuie să îl poată utiliza.

HTTP pe portul 236: mai ușor de testat pe mai multe gazde și potrivit pentru rețele interne de încredere atunci când arhitectura de securitate o permite. Compromisul este că traficul nu este criptat la nivelul de transport Kopano.

HTTPS pe portul 237: potrivit atunci când aveți nevoie de transport criptat între WebApp și Core. Introduce cerințe de configurare și validare a certificatelor. Documentația specială de configurare Kopano prezintă WebApp utilizând un protocol HTTPS DEFAULT_SERVERși, în anumite scenarii, certificate client. Consultați Configurațiile speciale Core Kopano .

3. Dacă utilizați un socket Unix, există acesta și poate serverul web să îl acceseze?

Pentru o implementare pe aceeași gazdă, verificați socket-ul în sine:

ls -l /var/run/kopano/server.sock
file /var/run/kopano/server.sock
ss -xl | grep kopano

Dacă fișierul lipsește, nu creați un fișier obișnuit cu acel nume. Socketul este creat de serverul Kopano care rulează. Prin urmare, un socket lipsă indică de obicei pornirea Core, o cale de socket modificată sau o nepotrivire de configurație.

Dacă socketul există, verificați proprietarul și modul său. Utilizatorul serverului web trebuie să poată accesa socketul prin calea directorului său. În funcție de distribuție, contul serverului web poate fi www-data, apache, sau un alt utilizator specific serviciului. Evitați rezolvarea erorilor de permisiuni cu moduri largi, cum ar fi chmod 777;, care cresc expunerea și pot fi suprascrise data viitoare când serviciul recreează socketul.

O abordare mai bună este să aliniați WebApp cu locația socketului produsă de Kopano și apoi să utilizați permisiunile de grup sau de serviciu prevăzute de distribuție. Dacă serverul dvs. a fost personalizat, comparați configurația Core cu endpoint-ul WebApp înainte de a schimba proprietarul.

4. Ce se întâmplă dacă Core este sănătos, dar WebApp încă spune că nu se poate conecta?

Verificați PHP-MAPI în continuare. Kopano precizează explicit că WebApp depinde de php-mapi. Verificarea configurației WebApp poate testa, de asemenea, disponibilitatea PHP și PHP-MAPI. Consultați documentația WebApp Config.php .

O verificare rapidă a CLI este:

php -m | grep -i mapi

Totuși, acest test are o limitare importantă: interfața liniei de comandă PHP poate să nu utilizeze aceeași configurație ca Apache PHP, PHP-FPM sau o altă integrare de server web. Un rezultat CLI pozitiv dovedește doar că mediul CLI vede modulul.

Verificările ulterioare utile includ:

php --ini
php -i | grep -i mapi

Apoi comparați aceasta cu configurația PHP utilizată de serverul web sau de pool-ul FPM. Dacă pachetul lipsește sau versiunile sunt incompatibile, instalați setul de pachete Kopano Core/PHP-MAPI corespunzător din repozitoriul destinat distribuției dvs. și versiunii Kopano. Nu combinați versiuni PHP-MAPI fără legătură doar pentru a face extensia să apară în php -m.

Alegeți această rută când: kopano-server este sănătoasă, endpoint-ul este corect și accesibil, dar WebApp eșuează în timpul verificărilor conexiunii sau configurației pe partea PHP.

Compromis: reinstalarea sau actualizarea pachetului poate fi soluția corectă atunci când fișierele binare nu corespund, dar schimbă mai mult sistemul decât remedierea unui singur endpoint. Confirmați mai întâi versiunile pachetului și programați actualizările de producție în mod corespunzător.

Ar trebui să repornești serverul Apache, PHP-FPM sau Kopano?

Reporniți componenta a cărei configurație sau modul s-a modificat efectiv.

• Dacă ați modificat /etc/kopano/server.cfg, reporniți kopano-server.
• Dacă ați instalat sau activat o extensie PHP, reporniți stratul de servire PHP utilizat de WebApp, cum ar fi Apache sau serviciul PHP-FPM relevant.
• Dacă ați modificat doar fișierul de configurare PHP al WebApp, o repornire completă a Kopano Core este de obicei inutilă, cu excepția cazului în care endpoint-ul Core în sine s-a modificat.

Comanda exactă pentru serviciul web variază în funcție de distribuție și de pachetul PHP. Exemple ar putea fi systemctl restart apache2, systemctl restart httpd, sau o unitate PHP-FPM versionată. Folosește numele serviciului prezent pe gazdă, în loc să copiezi o comandă orbește.

Dar serverele Core la distanță și firewall-urile?

Dacă WebApp și Kopano Core sunt separate, verificați mai întâi rutarea și listener-ul configurat înainte de a da vina pe WebApp. Documentația Kopano descrie accesul HTTP pe portul 236 și accesul SSL pe portul 237. Prin urmare, o implementare la distanță adaugă mai multe moduri de eroare pe care o implementare locală Unix-socket nu le are: reguli firewall, asociere listener, DNS, certificate TLS, proxy-uri inverse și politică de rețea intermediară.

Pentru un punct final HTTP, puteți cel puțin verifica dacă un ascultător TCP este accesibil de la gazda WebApp:

nc -vz core.example.net 236

Pentru HTTPS, verificați separat punctul final TLS cu un instrument adecvat politicii dvs. de certificare. O conexiune TCP reușită nu dovedește că autentificarea WebApp sau operațiunile MAPI vor avea succes, dar o conexiune eșuată dovedește că PHP-MAPI nu poate ajunge la serviciul configurat prin adresa și portul respectiv.

Dacă utilizați un proxy invers, rețineți că documentația Kopano necesită ca calea proxy și maparea backend-ului să fie consecvente cu URL-ul utilizat de WebApp. Manualul oficial Core menționează, de asemenea, considerații HTTP/1.1 pentru proxy-ul traficului Kopano. Consultați Configurarea componentei Kopano Core .

O comandă diagnostică practică care minimizează modificările inutile

1. Verificați kopano-serverstarea. Dacă eșuează, reparați mai întâi Core.
2. Citiți jurnalele Core. Erorile bazei de date sau de configurare trebuie rezolvate înainte ca WebApp să se poată conecta.
3. Verificați DEFAULT_SERVER. Confirmați că se potrivește cu un socket local sau cu endpoint-ul HTTP/HTTPS la distanță corect.
4. Testează socketul sau listener-ul de rețea propriu-zis. Aceasta diferențiază eșecurile de transport de problemele PHP.
5. Verificați PHP-MAPI în runtime-ul web. Nu vă bazați doar pe mediul CLI PHP.
6. Reporniți doar serviciile afectate. Apoi, retestați WebApp și verificați jurnalele dacă eroarea persistă.

Această ordine este mai sigură decât începerea cu reinstalări de pachete, deoarece păstrează dovezile și face ca fiecare test să fie semnificativ. De asemenea, evită greșeala opusă: repornirea repetată a WebApp sau Apache atunci când Kopano Core în sine nu poate porni.

Când este schimbarea parametrului DEFAULT_SERVER o soluție greșită?

Nu modificați DEFAULT_SERVERdoar pentru că pagina de conectare afișează o eroare de conexiune. Dacă valoarea curentă indică corect instanța Core dorită, modificarea acesteia poate ascunde problema inițială sau poate trimite utilizatorii către backend-ul greșit.

De exemplu, înlocuirea default:cu http://localhost:236/kopanonu este în mod inerent o actualizare. Aceasta modifică transportul de la socketul local implicit documentat la TCP. Acest lucru poate fi util pentru depanare sau pentru o topologie care necesită TCP, dar modifică și securitatea și suprafața operațională. Pentru o configurație pe aceeași gazdă, remedierea socketului lipsă sau inaccesibil este adesea mai ușoară decât deschiderea unui alt listener.

Ce ar trebui să faci dacă eroarea persistă?

În acel moment, adunați dovezi de ambele părți ale conexiunii:

• valoarea exactă DEFAULT_SERVER, cu acreditările sau secretele eliminate;
• systemctl status kopano-serverși intrări recente în jurnalul serverului Kopano;
• informații despre proprietatea socketului sau despre ascultătorul la distanță;
• versiunea PHP și extensia MAPI încărcată în runtime-ul de servire web;
• jurnalul de erori WebApp/PHP în legătură cu o încercare de conectare eșuată.

Documentația WebApp a Kopano precizează că înregistrarea erorilor PHP este activată prin setările PHP config.phpși avertizează împotriva afișarii directe a erorilor, deoarece acest lucru poate corupe răspunsurile JSON. Acest lucru face ca jurnalele de pe server să fie o sursă de diagnosticare mai bună. Consultați setările oficiale de înregistrare WebApp înainte de a crește gradul de prolixitate.

După ce identificați dacă eroarea este cauzată de pornirea Core, transport, permisiuni, PHP-MAPI sau rețeaua la distanță, aplicați cea mai mică soluție care abordează acel nivel. Aceasta este mai fiabilă decât tratarea erorii „Cannot Connect to Kopano Core” ca o singură eroare cu un singur remediu universal.