[Kipróbáltuk] mi is - Zentyal 4.0

Ha már trey kipróbálta, hogy milyen király cucc is a Zentyal 4, én is adtam neki egy esélyt egy éles projektben.

Trey odáig jutott, hogy sikerült bekonfigurálni egy domaint, és ebbe beléptetni egy gépet. Állat, nagyjából itt is erre van szükség + mailkezelés. Nagyon más igények nem voltak.

Szóval, Zentyal szervert feltelepít, elindít, örül. Tulajdonképpen működik is, látszólag van domain, beledobáltuk a usereket. Beállítottuk az emailezést, tűzfalat, DNS-t, fasza minden. Ideje megnyomni a save changes gombot.

Nem kellett volna. 

2014/12/06 12:54:09 ERROR> GlobalImpl.pm:735 EBox::GlobalImpl::saveAllModules - The following modules failed while saving their changes, their state is unknown: (itt egy csomó modul felsorolva)  at The following modules failed while saving their changes, their state is unknown: (és megint, ugyanazok)  at /usr/share/perl5/EBox/GlobalImpl.pm line 735
EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x47d9b90)', 'progress', 'EBox::ProgressIndicator=HASH(0x21f3958)') called at /usr/share/perl5/EBox/Global.pm line 95
EBox::Global::AUTOLOAD('EBox::Global=HASH(0x4804a98)', 'progress', 'EBox::ProgressIndicator=HASH(0x21f3958)') called at /usr/share/zentyal/global-action line 32
eval {...} at /usr/share/zentyal/global-action line 30

Mindezt egy stock telepítésen, mindenféle egyedi konfiguráció/szoftver nélkül. Őszintén szólva így szombat délután különösebben kedvem sincs utánajárni, hogy egy dobozból frissen elővett szoftver miért nem működik. Illetve ha egyszer nem működik, akkor mi a rákért nem lehet kiírni, hogy mi a probléma. (v.ö. ha én fejlesztek valamit, akkor lekezelem a kivételeket)

Zentyal - never again.

Nem fizetett társadalmi célú hirdetésünket olvasták.

Nem az üzenet értelmességét vitatom (illetve de, azt is); a fő probléma az, hogy egy hivatalos forrásból felhúzott Zentyal a legelső telepítési próbálkozásra elhasal. Továbbá aggályosnak látom azt is, hogy hiba esetén nem sikerül megjelölnie a hibás modult, hanem egy az egyben kiírja az _összes_ bekapcsolt modult (a log kivételével), mint hibásnak jelölt.

A hibaüzenettel annyi bajom van csak, hogy értelmes helyeken a hiba helyét/okát írjuk ki. Nem, az "xy fájl yz sora" nem a hiba helye. Ez gyakori tévedés az OSS projektekben, ami azon a tévképzeten alapul, hogy az end-user majd forráskódszinten fogja kijavítani a hibát. Ezt kulturált helyen ilyesmi üzenettel szokás megoldani: "hiba van a user modulban, ne írj szóközt a username-be, te hülye"*

Egy szervertől, ami ne adj' Isten kritikus feladatot lát el, nem ez a viselkedés az elvárt.

(* szerk: nem, nem tettem szóközt a username-be, ez csak egy példa)

Igazad van. Itt tart az info. (Lásd ékezetek használata.) Legtöbb esetben aki csinálja az adott appot nem is gondolja, hogy vannak elvetemült userek illetve feltételeznek olyan állapotokat amelyek nem is biztos, hogy rendelkezésre állnak. Tekinthetjük ezt a teszt hiányának.

Nekem amúgy ez egy barátságos üzenet, mert esélyt kapok a megoldásra.

Pedig jogos a felvetés, nem tűnik trollkodásnak. Egy ideális világban ez úgy nézne ki, hogy a felhasználó kap egy emberi nyelven írt hibaüzenetet, majd a szakértő (aki lehet ugyanaz a személy, vagy éppen valaki más) megnézi a technikai részleteket az Event Logban.

szerk: aha, véletlenül egy elég régi cikket linkeltem, de a koncepció nem sokat változott.

( itanczos | 2015. 01. 30., p – 16:13 )

Sajnos valóban nagyon ingatag a zentyal beállítási "varázslója"! :(
Napok óta küzdök én is egy hasonló hibával, jelen esetben a mail modul nem tud elindulni és a beállításait elmenteni.
Mivel nagyon összetett a webes felület mögött működő perl nyelven íródott konfiguráció generátor, komolyabb perl és zentyal ismeret nélkül lehetetlen küldetés a probléma kibogozása... :(
Sokszor egy figyelmeztetés típusú üzenetet kaptam a samba modul mentésénél (valamilyen megosztási jogosultságot állítottam), aztán nem működött helyesen a samba azon része sem, amihez semmi köze nem volt a módosításnak!

Kétségkívül nagyon jó megoldás LENNE, ha valóban jó LENNE a háttérben működő motor! Ez alatt főként a hiba ellenőrzést és hiba feltárást értem!

Valahogy olyan érzésem van, mintha ez egy kiswindows lenne, amit egy kismicrosoft cég fejleszt, profit orientált módon, amelyet mi, mint béta teszterek próbálunk használni, majdnem nulla támogatással!

Ezért szerintem éles környezetben nagyon rizikós használni! Mert bármikor elakadhatnak a fogaskerekek a háttérben!
Ez viszont kétségkívül a fizetős verzió felé lökdösi a céget vagy rendszergazdát!

Egyszóval, biztonságos használatra csakis a fizetős verziót lehet(ne) ajánlani, ami nekem kicsit bántja a csőrömet... :(
Mert, ha már fizetnem kell, még ha csak fele annyit is, mint az MS megoldásért, legalább tutira működne! Ne kelljen már attól félnem, hogy egy-két beállítástól megálljon a rendszer! Mert hiába van akkor már fizetős felhasználóként support-om, ha a hiba működési kiesést eredményez!

Szóval, már 3.0 megjelenésétől nézegettem és próbálgattam. Slapic összes oktató előadását megnéztem, de nem boldogulok vele, majd 10 éves linux-os tapasztalat után... Akkor tényleg rendszergazda barát?!?!

Ami a jelenlegi problémám előtt nagyon felbosszantott, hogy a httpproxy modulban egyik napról a másikra letiltották a működést , ha nincs WAN csatoló. Simán, főverzió váltás és figyelmeztetés nélkül! Vagyis a cégnél működik a squid, majd másnap, egy automata frissítés után reggel sekép-sehang a böngészőkben! :o
Mert 4.0-ról 4.0.1-re frissült a modul. Szerintem ez egy éles környezetben elég gáz!

Lehet, hogy itt megkapom végre a választ, ezért leírom mi nyomja a lelkem :)

Zentyal kisvállalatoknak szerepkörrel, a cél ez lenne. De nem tudom megoldani.
A kérdés, ennyire nem fogtam fel semmit az elmúlt években elolvasott, megtekintett, meghallgatott oktató anyagokból, vagy tényleg
nem (vagy csak korlátozottan) alkalmas a feladatra?

A kitűzött feladat az, hogy van egy szerver vas azon Zentyal ami samba megosztásokat és levelezést biztosít. A Zentyal lan-ban van, a lan-t egy soho router biztosítja.
1. Telepítjük a zentyal-t aminek a domain neve lan végződésű kell legyen, mert egyébként így tud mérvadó névszerverként is (! 192.168.xx.xx) működni.
2. Az elsődleges virtuális levelező tartományunk lan-os végződésű lesz, tehát alap esetben csak házimunkára lesz alkalmas.
3. Felvehetünk valós domain is, és ahhoz virtuális levelező tartományt, viszont az már a nem fog együttműködni a csoportmunkához szánt openchange-dzsel.

Itt jön a kérdésem, mert a fenti állításaim, ha igazak, akkor ez a rendszer eléggé korlátozott felhasználásra javalt. Ha nem igazak, akkor valaki sötétítsen fel, hogyan máskép?

A példa és az érthetőség kedvéért részletezném:

Adott egy soho router tűzfallal, legyen egy miktorik.
Van egy szerver (a szóban forgó lanban), ami dhcp-zik, a nagyjakab.hu domain-t fenntartja és a levelezését biztosítja a külvilág felé.
Sőőt egy samba ad-t is biztosít. A samba nincs a nagyvilág felé kiengedve, lehetne ugyan, de nem tesszük. (mert csak)

Itt jön a zentyal képbe, ami elviekben ezeket biztosítani tudná (?)

Ha telepítjük a zenytal-t akkor ugyebár ok-okozati összefüggéseket szem előtt tartva és a samba ad kedvéért kisjakab.lan beállításával telepítjük.
tesszük azért is, mert a zentyal a belső hálón lévő címét a példa kedvéért 192.168.1.2-t fogja a kisjakab.lan-hoz rendelni.

A kisjakab.hu -t pedig felvesszük a publikus IP-vel.

Ilyenkor a Sogo csoportmunka szervernek kelleni fog egy virtuális levelező tartomány, ami alap esetben a kisjakab.lan lesz.
Ezzel nem tudunk kifelé menő levelezést bonyolítani, mert a lan végződésű.

Felveszünk tehát még egy levelező tartományt ami már kisjakab.hu, ezzel tudunk rendesen levelezni, de itt meg a csoport munka nem fog működni.

Vagy nagyon nagyon rosszul tudom és van egy olyan rejtett képessége a zenytalnak, amire nem jöttem rá.

Mert egy csomószor telepítettem, rengeteg fórumot olvastam, és azt látom aki ezt megkérdezi, azzal többé nem állnak szóba :)

Tehát a mondandóban rejlik a kérdés, lehet e (na nem a kecskével!) a zentyallal valódi kisvállalati csoportmunka szervert készíteni, vagy ez csak egy álom?

Fizikálisan egy szerver jut a felsoroltakra.

háát amennyire én látom, fordítva ülsz a lovaon :))

először szépen beállítottad az összes lokális hálózati biszbaszt, és az működik is, mint levelezés, dhcp, dns, grouppok, userek, fájl megosztás chat, webszerver, nyomtató meg mitt'omén, és van biztonsági mentésed is, átgondolod hogy mit akarsz elérni az internetről. pl http(s), imap, pop stb.

ezeknek megcsinálod az átjáróját a routeren, ellenőrzöd hogy van e alapértelmezett átjáró a szervereden amire válaszolni tud majd.
remélhetőleg a szerver tűzfala már nyitva van az adott portokon, mivel ugyanazokat a portokat használjuk a lokális eléréshez is.

a http szerveren a megfelelő virtualhost(ok)nál hozzáadod az alias nevét amiről el fogod érni az oldal(aka)t a netről (****.hu)
a sogo mint .lan, mind .hu elérhető lesz.

ha szükséges akkor a levelező szerveren is csinálsz aliast a hostnévre, így mindenki akinek .lan-os fiókja volt, hirtelen lesz .hu-s fiókja is.

a dns szervernél pedig a .hu-s domainra csinálsz egy cname-et ami a .lan-ra mutat.
nem veszed fel a publikus ip-t, mert azonnal összezavarja a loopbacket, ami amúgy is vacakolni szokott linux alatt. hacsak nincs szervered valahol a hálón, de az már egy másik történet.

ezután addig molyolsz, amíg minden nem működik :))
levelező szervernél ellenőrzések, vírusirtó, meg ilyesmi..
oszt ennyi :)

1-2 hét az egész :)

vagy meghagyod a routeren a levelező szervert, és csinál belőle relay-t.
a webszerverhez meg csinálsz átjárót.
1000 megoldás van. ezek némelyikénél közvetlenül bele kell nyúlni a zentiál beállító fáljaiba, ami gondot okozhat a későbbiekben, van amelyikhez nem..

( apostroph3 | 2016. 10. 10., h – 09:06 )

melyik szerver szoftvernél volt jellemző, hogy mindent beállítunk, aztán mikor azzal kész vagyunk (2-3 heti/napi/órai munka) akkor mentünk? windows?