Sziasztok!
Zentyal 7.0-t frissítettünk 7.1-re majd a 7.1-et 8.0-ra és felmerült némi kellemetlenség, hogy iszonyatosan lassú a webes felület.
A /var/log/zentyal/error.log, ami egy általa indított nginx annyit ír, hogy timeout-ra futott az Unix socket-en, amit proxy-zik.
A /var/log/zentyal/zentyal.log sok érdemit nem mond, miközben várakozik a kliens, semmi infó. Néha egy-egy alkalommal egy pillanat alatt bentvan az admin gui, de máskor hosszú másodpercekig vár, majd villanásra betölt, tehát nem az van, hogy lassan jön a response, ha egyszer megindul, akkor pörög. Ugyanez a cURL is, az is a head-ereket lehúzza, de aztán időtlen időkig vár a tartalomra, akár egy sima login oldalra is.
Amit eddig megnéztem és nem vezetett előrébb
- Redis, firewall, DNS, samba-ad-dc kikapcsolása ideiglenesen, nem oldotta meg
- zs firewall, dns stop és start, nem segített
- DNS-bejegyzések átnézése, nem segített, elvileg jók, a nslookup és host is jól adja vissza a külső és belső címeket
A log időnként ezt írja ki, ha a DNS-t próbálja módosítani
2025/07/02 10:58:49 ERROR> GlobalImpl.pm:728 EBox::GlobalImpl::saveAllModules - The following modules failed while saving their changes, their state is unknown: dns at The following modules failed while saving their changes, their state is unknown: dns at /usr/share/perl5/EBox/GlobalImpl.pm line 728
EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x563a9bd9aa10)', 'progress', 'EBox::ProgressIndicator=HASH(0x563a9bc63dd8)') called at /usr/share/perl5/EBox/Global.pm line 95
EBox::Global::AUTOLOAD('EBox::Global=HASH(0x563a9bc52050)', 'progress', 'EBox::ProgressIndicator=HASH(0x563a9bc63dd8)') called at /usr/share/zentyal/global-action line 32
eval {...} at /usr/share/zentyal/global-action line 30
A Google-keresés, AI-k nem adtak használható választ, annyit árul el a Zentyal a /var/log/zentyal/uwsgi.log-ban, hogy néha 30--40 másodpercig is vár egy kérés, aztán vagy kifut a nginx timeout, vagy nem, vagy kifut a böngészőié, vagy nem.
Van esetleg valami ötletetek, mit lehetne elkövetni, hol kéne keresni a hibát, vagy hogy lehetne újrakonfigoltatni vele a DNS-t?
Köszi előre is!
Megoldás:
Az én esetemben a /var/lib/samba/CA mappában lévő index.txt okozta a problémát. Lejárt a CA és meg kellett újítani, csak így mégtovább hízott az itt lévő, lejárt, visszavont cert-ek száma.
Az r betűvel jelzett revoke-olt sorokat kivettem, illetve azokat, amik szerinte valid-ak voltak, de a fölötte lévő CA már neméppen.
Így begyorsult a webfelület és megy rendesen minden.
Köszi mindenkinek a segítséget!
- 379 megtekintés
Hozzászólások
Én kettő dologgal szívtam eddig minden Zentyal-on.
1) A BIND DNS szerver AD user-nek lejár a jelszava, és onnantól nem megy a DNS service restart meg ilyenek. Ezt megoldani samba-tool user set-expiry szerverneve-dns --noexpiry
paranccsal lehet leggyorsabban. Mondjuk ettől a felület nem lassú, csak gyakori szívás oka.
2) Ha nem tudja bármiért lekérdezni az elérhető legfrissebb Zentyal verziószámot (mert pl. a Zentyal-nál nem működik a webszerver, ami ezt szolgáltatja) akkor a Dashboard bazi lassan jelenik meg (akkor is, ha a legfrissebb verzión van és nem is jelenítene meg semmi frissítési felhívás zöld ablakot a kép tetején). Ez egy időben annyira gáz volt, hogy meg sem jelent az admin felület (mert bedőlt az eredeti Zentyal cég és leállították a kiszolgálókat), a Perl forrásban kellett kikommentezni a check-részt mert nem volt timeout a lekérésre.
- A hozzászóláshoz be kell jelentkezni
Köszi! a másodikhoz tudsz adni kérlek egy kis hintet, hogy merre keressem? Megpróbálnám kiütni, hátha...
Egyébként ha bekapcsolom a debug-ot, a kb. 80 cert-re látok openssl x509-es olvasásból vagy 600 darabot, amikor megnyitom a webgui-t a /var/log/zentyal/zentyal.log-ban. Nem vagyok benne biztos, hogy ez normális, hogy ennyit olvassa a tanusítványokat, akár ez is lassíthatja...
TheAdam
- A hozzászóláshoz be kell jelentkezni
Persze, itt van a Zentyal Gihub-os Issue, amiben írtam a megoldásról is anno. Ebben megtalálod, hol van ez az ellenőrzés és akár ki is dobhatod teljesen, helyettesítve valami fix eredménnyel a lekérést.
A tanúsítvány olvasgatásra nincs tippem, sohasem találkoztam vele (nem néztem ilyen szemmel a debug log-ot sose). De valóban, egy csomó openssl futtatás is megfoghatja.
- A hozzászóláshoz be kell jelentkezni
Köszi ezt is! Meg fogom nézni.
Közben nyomoztam kicsit, a /var/lib/zentyal/CA/index.txt fogja meg. Ha azt kiveszem, akkor begyorsul. Csak hát elég sok cert van benne, így újra kéne index-elni, vagy hasonló...
Lehet a teljes CA-tól megpróbálom újraépíteni és kidobom a régieket, mert rengeteg tanusítvány van benne, az elmúlt 10--15 év összes termése, sok sok visszavont etc. cert.
TheAdam
- A hozzászóláshoz be kell jelentkezni
Köszi az infót! Sehol nem használtam még a beépített CA-ját, mindig külső tanúsítvány kezelést használunk, így pont ebbe nem futottunk még bele. De jó tudni!
- A hozzászóláshoz be kell jelentkezni
Zentyal volt a belépőm a Linux világába. Szerencse, hogy nem fordítottam hátat azonnal neki emiatt a spanyol borzalom miatt. A Zentyal egyetlen dologra jó, összeszedni belőle a programlistát, azt egész jól összeállítják, majd utána az egészet felépíteni egy épkézláb Ubuntu serverre.
A Zarafa SOGo váltás is elég meredek volt tőlük, miután a userek megszokták kaptak egy teljesen más webUI-t és persze jönnek tömegesen panaszkodni. Már 15 éve is sok probléma volt ezen túl is egy Zentyal upgrade után. Fogadd meg a jótanácsot és felejtsd el a Zentyal-t. Csinálj egyet magadnak inkább egy értelmes disztribúcióra. A spanyolok műszaki érzéke és mérnöki képessége sajnos a nullával egyenlő.
- A hozzászóláshoz be kell jelentkezni
Amit a Zentyal tud, azt 99%-ban el lehetne kezelgetni egy RSAT-os Windows-os masináról. OpenVPN-hez kéne még valami GUI, de gondolom két perc Google/ChatGPT megmondaná, hogy mi erre a legjobb sokcsillagos GitHub projekt. Úgyhogy ja, abszolút igazad van, hogy ez azért igen sok sebből vérzik.
Köszi mindenesetre a feedback-et, az megnyugtató, hogy ezek szerint a szoftver is hemzseg a problémáktól, nem nálunk keresendő a hiba. Frissítés után például második rebootra jött fel a desktop GUI-ja meg a belső hálózatunkra néző interfész.
TheAdam
- A hozzászóláshoz be kell jelentkezni
Alapvetően egyetértek én is, viszont szerintem annyira nem rossz, hogy kézzel rakjak össze egy ugyan ilyen rendszert a komponensekből és text konfigokban matassak mindenért (kivéve az RSAT-os user management).
Amennyiben azt az egyszerű dolgot betartja az ember, hogy minden főverzióról csak annak ténylegesen legutolsó frissítése után vált új főverzióra, akkor csak néhány kisebb szívás marad. De tapasztalatom szerint ilyen egy több feladatot ellátó Debian vagy Ubuntu rendszernél is becsúszik olykor.
Én az utóbbi években frissítettem több örökölt Zentyal rendszert 5-ről egészen 8-ig, és kisebb debaug-okkal mind működött a végére. Szerencsére a Zarafa-s 4-es és régebbi verziók kimaradtak az életemből, a neten olvasottak alapján azért ahhoz az időhöz képest sokat javult.
Az a gond, hogy mára nincs más kész és működő alternatíva, ha csak annyi kell, amit a Zentyal tud. Mármint olyan, amit nem magamnak faragok, hanem a legkisebb energiával ügyfélnél is felteszek és üzemeltetek. Minden más szereplő kiesett vagy fókuszt váltott (lásd NethServer). Egyetlen "konkurencia" a német UCS, de az teljesen más filozófia szerint épül, és nem modanám sem egyszerűbbnek, sem robosztusabbnak (de félreértés ne essék, elég jó szoftver és jó a támogatása is, csak a support előfizetés már bőven Windows Server árban van fizetendők terén). Ha csak fájl szerver, AD DC, meg levelező kell egy kis ügyfélhez nem-Windows alapon, én most is Zentyal-t teszek fel, nem UCS-t és nem kézzel épített rendszert.
- A hozzászóláshoz be kell jelentkezni
Ez a mostani ez egy 3.2-ről (vagy valami ilyesmi) indult történet, felfrissítették 4-esre, meg talán 5-re is és utána kezdtem vele el foglalkozni.
A 7-esre átállásnál volt egy fizikai vas csere is, ott a backup-ot vittük át. Visszaállásnál kijött valami hiba, egy olyan fájl meglétét hiányolta, amit ő maga hoz létre, az ellenőrzés után, ez a teljes backup folyamatot megakasztotta. Itt az volt a megoldás, hogy a Perl kódban ki kellett cserélni néhány sort a backup-ot visszaállító script-ben.
Igen, szerencsére amúgy ki lehet simogatni, meg ha mindig felfrissített környezetből indul a nagyobb frissítés, akkor ritkán törik. Ráadásul, ha ki van rendesen simítva, akkor utána ideális esetben csak működik és nem igazán igényel több törődést mint a felügyelet, meg a frissítések. Debug-olni nehéz kicsit, mert sok esetben a Zentyal oldali fórumbejegyzések igen hiányosak, illetve nagyon egyediek tudnak lenni az issue-k.
TheAdam
- A hozzászóláshoz be kell jelentkezni