Sziasztok!
Keresek olyan Zentyal / Mail szerver / Tűzfal szerver szakértőt , aki felülvizsgálná egy szerver konfigurációját!
A történet röviden, hogy már második alkalommal próbálok átállni egy 3.4.10 Zentyal Linuxról , 7.0.9-es Zentyal Linuxra. Mind a 2 Develop kiadás.
Első alkalommal pppoe kapcsolat nem épült fel, ezt már megoldódott, és napokig teszteltem helyileg a szerver webmail és mail kapcsolatát, helyi kapcsolattal tökéletes volt a kommunikáció és elvileg a domain szolgáltató által kiállított tanúsítvány is jó, de ma ismét kudarcba fulladt az átállás, mert az adatok migrálását követően a szerver először tanúsítvány hibára hivatkozva nem adott imap kapcsolatot, majd pár perc múlva nem is volt elérhető a rajta futó redmine projekt naplóval együtt.
Tűzfal szabályok ugyanazok, mint a régi szerveren , mégsem működik semmi wan oldali kapcsolatról befele, internetet viszont ad kifele.
Legközelebb 02.04 vasárnap esedékes a csere, addigra szeretném rendeberakni a szervert, hogy már csak adatokat kelljen költöztetni.
Legyen szíves jelentkezni , komment vagy privát üzenet formájában aki tud ebben segíteni távoli elérés (anydesk, vagy ami szimpatikus használatával )nekem óradíj, vagy projekt alapú díjazással, mert én már konkrétan belefáradtam idegileg.
- 485 megtekintés
Hozzászólások
Előre leszögezem: Nem vagyok Zentyal szakértő.
3.4.10: kb. 2014. március
7.0.9: kb. 2021. január
Ez szerintem így túl nagy ugrás egyszerre. Nem fog működni vagy ordas nagy szívás lesz az upgrade.
- A hozzászóláshoz be kell jelentkezni
Szia! Időm nem sok van, de dobj egy PM-et, és folytassuk emailben. Van jó pár Zentyal telepítés a kezem alatt, és a PPPoE problémád megoldója is én voltam. ;) Én is küzdök jó pár éve ezzel a csodabogárral. :)
- A hozzászóláshoz be kell jelentkezni
Mi üzemeltetünk pár Zentyal szervert, és ezen tapasztalatok alapján biztosan nem lehet ekkorát frissíteni, nemhogy in-place upgrade-del, még konfig másolással sem friss telepítésbe. Ha ez egy vadiúj telepített rendszer és kézzel lett ugyan olyanra bekonfigurálva, akkor lehet/érdemes hibát keresni, de ha akár csak az van, hogy az új telepítésű rendszerre rá lett töltve a régi konfig, akkor kár bele egy perc munka is.
Ráadásul nekem fura, hogy előző topic-ban írtad, hogy 7.1 helyett 7.0.9 lett, mert a 7.1 nem működött jól. Alig van változás a 7.1-ben érdemben, van ahol újonnan van, van, ahol frissítve, és működik. Nem lehet valami hardver gond magával a géppel?
A Zentyal minden konfigot template-ekből rak össze. Tehát a valódi konfig állományok átírása tiszavirág életű, az első szolgáltatás újraindításnál megy a levesbe minden kézi változás. Így pl. saját tanúsítvány használatához érdemesebb egy módosított template-et használni az érintett szolgáltatásokhoz, mint a gyári tanúsítványokat cserélgetni sajátra, pláne a végső konfigot kézzel módosítani. Ez nem tudom hogyan van most megoldva most - a tanúsítvány hiba miatt kérdezem.
A tűzfala egyszerű IPTables, szóval ott könnyű listázni milyen szabályok élnek, és azok összecsengenek-e a webfelülettel (teljes tiszta telepítésnél, vagy 1 főverziónyi frissítés után még sose volt vele gondunk).
Én javaslom még az átállás előtt átgondolni, hogy a router funkció váljon le a Zentyal-ről egy külön hardver eszközre. Régen mi is sokszor tettünk az ügyfélhez integrált (pl. Zentyal) vagy szoftveres (pl. OPNsense) tűzfal/router megoldást (virtuális gépre egyetlen szerverre), hogy olcsóbb legyen hardverileg, de leszoktunk róla, mert mikor valaminek baja van, akkor sokszor nem lehet bejutni a rendszerbe a szintén elérhetetlenné váló router miatt. Kis céghez is teszünk külön router-t, abba dugjuk a szerver BMC-jét, és ha megáll az egész, akkor is egy VPN-en belépve bele tudok nézni - az nagy előny havi pár 10 ezret fizető kis ügyfélnél, hogy nem kell azonnal személyesen oda menni amíg van áram és internet.
Ha tudok segíteni, engem is kereshetsz.
- A hozzászóláshoz be kell jelentkezni
A régi szerveren 3.4.10 van, az megmarad backupnak , később HDD csere után, de van egy új telepítésű 7.0.9 egy "új" szerveren, ahova kézzel vittem át a fiókokat, azaz manuálisan rögzítettem, illetve a tűzfalszabályokat és minden egyebet, szóval nem distr-upgraderől van szó, annyi a különbség, hogy a 7.0.9-en már nem önaláírt cert van, hanem a domain szolgáltató által adott cert, amiben nem vagyok biztos, hogy működik, mert maga a szolgáltató sem tudta igazán, hogy ennek , hogyan kellene működnie:S Kaptam 2 cert (root , domain ) tartalmat és oldjam meg alapon leráztak kb.
- A hozzászóláshoz be kell jelentkezni
Ha tippelnem kellene, amit írsz abból az derül ki, hogy a régi gépet azért kell cserélni elsősorban, mert a levelezés nagyon bánatos lett mostanra a 2014 óta megváltozott elvárások miatt (TLS verzió, cert jósága, SPF, DKIM, satöbbi)...
A legjobban azzal jársz, ha Let's Encrypt certet állítasz be. Az frissül 60 naponként, nem lehet elfelejteni, és mindenki elfogadja.
Csak úgy senki nem ad működő certet sima állományban átküldve. Pláne nem kell egy jó cert-hez root cert-et is kapnod... Szerintem az egy ugyan úgy önaláírt valami lehet (tipp), azért nem jó.
Zentyal tűzfalnál külön van belső hálózatból elérésre és kintről elérésre szabály. Bentről sem lehet bármit elérni a szerveren csak úgy, azért mert bentről jön a kérés. Ha valamit mindenhonnan el kell érni, akkor mindkét helyen engedni kell. Ha bentről is el kell érni valamit a külső FQDN-nel (pl. ki-be hurcolt gépeken előnyös), akkor vagy kell kézzel IPTables-be hairpin NAT (nem javaslom, nem mindennel kompatibilis), vagy split DNS-sel belül a benti címet visszaadni az adott FQDN-re.
- A hozzászóláshoz be kell jelentkezni
Próbáltam egy teszt szerveren a Lets Encryptet, nem igazán szerette a Zentyal, még ha a stubokat is módosítottam, akkor is random megbolondult főleg az apple eszközökön.
Amit ezt a szolgáltató most adott az RapidSSL-es tanusítvány, amelyre a chrome azt mondta, amikor lokálban hívtam meg a SOGo-t, hogy a www.domainem.hu és a domainem.hu nevekere érvényes, akkor jól gondolom, hogy ha a szerveremet mail.domainem.hu-nak hívják, akkor arra nem lesz alkalmas?
A certet úgy állítottam elő, hogy a key file tartalma bekerült egy domainem.key-be, a root és a domain ssl pedig egymás után egy domainem.pem fileba, é rzrkrz hivatkoztattam meg a dovecottal és a postfixxel, bár a dovecotnak volt még egy dh.pem fileja is, azt hagytam alapon, mert ilyet nem kaptam a szolgáltatótól.
- A hozzászóláshoz be kell jelentkezni
A Let's Encrypt műszakilag és tartalmilag egy pont ugyan olyan certet ad, mint a RapidSSL legolcsóbb variánsa, csak a tartományt hitelesíti, műszaki ellenőrzéssel. Olyan persze van, hogy az acme.sh kliens default a ZeroSSL-t használja már nem a Let's Encrypt szervert, de ez mindegy, ízlés kérdése (és váltható könnyen). Olyan is van, hogy bármelyik új ACME kompatibilis kliens default ECDSA tanúsítványt állít elő (újabban), nem a "megszokott" RSA-t, és ez bizonyos kliensek esetén gond lehet. De ez odafigyeléssel és probléma esetén utána olvasással mind könnyen átugorható.
Valószínű azért tudta odaadni a szolgáltató az a certet, mert gondolom a cég weboldala náluk van hosztolva és ahhoz kellett a cert. Jól gondolod, a mail.valami.hu FQDN-hez nem lesz jó az a cert.
A DH.pem egy helyben generált kulcs, ott csak az a fontos, hogy kellően hosszú legyen (az újabb Dovecot verziók 512 bitnél hosszabbat követelnek meg, de új telepítéskor megfelelőt generál a rendszer, frissítéskor érdekes csak ez).
Arra is figyelj, hogy a mail.valami.hu-ra szóló cert-en felül a mail.valami.hu a Zentyal-ra mutasson és a Zentyal publikus címének PTR rekordjában a mail.valami.hu szerepeljen (ez elég fontos jó pár éve), amit a fix IP címet adó (internet-) szolgáltató tud kérésre beállítani. Valamint a Zenytal SMTP HELO-ban mail.valami.hu-ként mutatkozzon be. Meg persze mindenképp legyen SPF rekord és legyen jó a tartalma (a Zentyal IP címére engedélyező legyen). Ha ezek nem stimmelnek, nem fog a levelezésen a szerver csere segíteni semmit.
Ezen felül ha a SOGo-t kintről is elérhetővé teszed, oda is tedd be az Apache konfigba a certet (vagy a reverse proxy-ra, ha azt használsz a SOGo elé).
- A hozzászóláshoz be kell jelentkezni
Csak egy javaslattal élnék, mert én már leszoktam a Zentyal-ról. Nem éri meg a sok szívás, elég sokféle képen láttam már összefosni magát, hogy elegem legyen.
Annyi energiával amit beleölsz, simán meg lehet tanulni magát a smaba-t, postfix-et és mondjuk a mikrotik kezelését. A proxmox pedig igen stabil és azon nagyon könnyű a konténer kezelés.
Szerintem nem véletlen a konténer technológia ilyen elterjedése, mert az integrált vackokkal rengeteg gond van és ha valami beszarik oda az egész. Ha minden külön van, sokkal könnyebb a dolgod és alig kell nagyobb vas hozzá.
Több kis cégem van amik nagyjából így néznek ki, mikrotik mögött egy proxmox, azon konténerek (ha kell akkor akár windows virtuális gép is mehet rá könyvelő, akármilyen szir-szar spéci igényre) azon külön samba, postfix/dovecot és Proxmox Mail Gateway. Ha valaki akar webmail-t meg webes fájlelérést akkor NextCloud még külön. A mikrotiken wireguard ha kell.
Ez nagyjából egy kis cég minden igényét lefedi. Nem sokkal több energia mint küzdeni a szar Zentyal-al, viszont sokkal tisztább és szárazabb érzés :)
A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.
- A hozzászóláshoz be kell jelentkezni
Nem vitázni szeretnék a tapasztalataiddal, de a véleméynem az, hogy nem triviális jó Samba AD-t csinálni kézzel és szintén nem triviális ezen LDAP-t integrálni a levelezéssel és a webmail szoftverrel. Ráadásul ezt jól megcsinálni mindennel ami kell hozzá, szerintem jóval több munkaóra, mint amennyit egy alap Zentyal-t javítani kell az idők során (ha normálisan meg van csinálva az elején).
A Zentyal-nak vannak bajai, de én pl. még nem láttam "összedőlni". Néha frissítéskor kellett valami szerelni, de érzésre azt meg kellett volna tenni vanilla Ubuntu esetén is, nem Zentyal-specifikus volt a probléma.
A Zentyal legnagyobb baja, hogy nem tudni pontosan a projekt jövőjét. Most nyáron szűk másfél év kihagyás után jöttek javítások és egyéb életjelek, de ez nem elég megnyugtató. Annyi biztos, hogy az alapjául szolgáló Ubuntu 20.04 még bő egy évig teljes kürű, 6 évig pedig extended support keretében frissül, így nem kell gyorsan kidobni a meglévő telepített rendszereket.
Ha valaki továbblépne a Zentyal-ról, de nem akar kapásból a full kézi telepítésre váltani, annak ott az Univention Corporate Server. Ez egy elég jó rendszer, szintén elérhető Core verzióban ingyenes üzleti használati lehetősséggel, de a Zentyal-hoz képest pilótavizsgás már, és a legtöbb helyre, ahová a Zentyal való, nem kell az UCS plusz tudása. Ellenben aktívan fejleszett, támogatott, jól dokumentált.
- A hozzászóláshoz be kell jelentkezni
Nincs egy szent igaz út, egyébként sem az IT-ben meg pláne :D
Lehet, hogy nekem nem volt szerencsém és én fogtam ki minden nyűgöt, de jó sokat reszeltem Zentyal-t. Ezzel szemben például a postfix még egyszer sem szívatott meg, az valami egészen bombabiztos. A Proxmox sem szokott szórakoztatni, a NextCloud-ot snap-ból használom, ott megoldják a fejlesztők a nyűgöket.
Amit írsz, az egyik legnagyobb bajom volt a Zentay-al, a fejlesztés kiszámíthatatlansága. Már nem rémlik, de talán a 3 és 4 között is volt egy jó év szünet, valami pénzügyi gondjuk volt és ezek szerint ez jelenleg is tart. Mármint, hogy vagy fejlesztik, vagy nem.
Lehet, hogy unortodox, de a kis cégeknél szerintem nincs szükség LDAP-ra. Nem integrálom az AD-t a postfix-el, sem NextCloud-al. Néhány fős cégnél semeddig sem tart a Thunderbird beállítása, sem a Nextcloud-ba felvenni egy külső levelező fiókot. Pár perces munkáért, cserébe rengeteg konfigtól lehet megszabadulni és rengeteg hibaforrástól. Ha meg kicsit többen vannak, ott a powersell.
Én még nem láttam olyat, hogy egy helyi felhasználós sql/ldap nélkül használt postfix hanyatt essen. A samba szintúgy. Ezen kívül semmilyen licenc limit nem lesz soha többet. Amit tud, az a tiéd.
Az UCS-t én is nézetem, de amíg azt megtanulod annyiból tényleg összeraksz egy saját cuccot. Cserébe mindenről tudod mi hol van és miért történik.
Ahol a cég meg eléri azt a szintet, az ki tud fizetni normális megoldásokat is.
Persze mindenki úgy csinálja ahogy akarja, vagy ahogy hagyják :D
A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.
- A hozzászóláshoz be kell jelentkezni
Én magam üzleti szempontból tartom szerencsésebbnek a "kész" rendszerek használatát. Ugyanis töredéke idő beüzemelni és üzemeltetni a kézi verzióhoz képest, akármennyire van otthon az ember a kézzel építésben. És pont a kis cégek akarnak/tudnak aránylag keveset fizetni, ahol igenis számít, mennyi időt töltök el vele, hogy felállítsam, tutujgassam a rendszert. Mondom ezt úgy, hogy 10 évvel ezelőttig FreeBSD alapon, forrásból fordított, kézzel konfigurált rendszereket csináltunk. Csak ez a módszer az időnk rovására ment beüzemelés terén, ráadásul emiatt nem is csináltunk integrációkat (mert cmacerés és minek, ügyfél nem kérte), ami aztán üzemeltetés közben ütütt vissza.
Az meg, hogy nincs LDAP integráció, nyilván elmegy, maguk a felhasználók nem igénylik (sőt), mert a biztonság növelése mindig a kényelmetlenség növekedésével is jár, amit el akarnak kerülni. De jön/van a NIS2, és le fog gyűrűzni a legkisebb cégekig, itthon is, és akkor muszáj lesz ezt mind megvalósítani úgy is. Akkor meg még egy kör komolyabb meló mégis megcsinálni az integrációt, és majd nagyon nem akarják kifizetni külön.
Ráadásul a felhasználói élmény is jobb SSO-val, meg az üzemeltetés is sokkal egyszerűbb, ha 5 szolgáltatáshoz nem tartozik 5 user/pass adatbázis. Jön egy új user, felveszem, beteszem a megfelelő csoportokba, kész, mindene működik, be tud lépni ahová jogosult. Ellenben integráció nélkül "jajj, elfelejtettem oda is fiókot csinálni", "valóban, nem küldtem át annak a jelszavát", "nem sikerül belépnem! biztos a levelezés jelszavát ütöd be, nem a tartományét?". Szóval nekünk rengeteg support időt és energiát spórol az LDAP/AD használat a kis cégeknél is.
- A hozzászóláshoz be kell jelentkezni