bind je opravdu na DNS cache překomlikovaný, stejně tak sendmail. mě se na dvou firewallech s debian/woody (velmi pohodlná distribuce GNU/linux) velmi osvědčilo pdnsd jako DNS cache. pokud se týká mail transportu, velmi doporučuji qmail. je sice nutné jej kompilovat a není uveřejněn pod licencí GPL, ale jinak následují samé výhody. je superbezpečný, nenáročný na provoz a jeho konfigurace je až ostudně jednoduchá. navíc bez potíží podporuje formát mailboxu Maildir, který má oproti formátu /var/spool/mail/<user> několik výhod, namátkou: při přístupu ke zprávě není nutné procházet jeden veliký soubor, ale pouze adresář. riziko nevratného poškození zpráv při havárii systému je výrazně nižší, při použití journalling filesystému dokonce nulové.
děkuji za tip na tinyproxy.
Tak ja zas qmail neodporucam vobec... Standardne ma niekolko bugov, ktore sa tvaria ako feature:-) Autor na qmail vylozene kasle (zije este vobec? :-) ) a spolieha sa na milion patchov, ktore ho ako tak vylepsuju,opravuju a ktore medzi sebou obcas nie su kompatibilne...Maildir podporuje takmer lubovolny MTA, staci mu zamenit MDA (napr na maildrop). Problemy so soft-updatami na freebsd...nutnost linkovat s nejakou "syncdir" kniznicou (i na linuxe), ktora ho samozrejme trochu spomali.
Pouzivat software, ktory sa konfiguruje patchovanim :-( je podla mna strata casu a nervov ... Raz vam aj tak dojde trpezlivost a budete sa ho chciet zbavit.
Je to len moj nazor, ale na zaklade praktickych skusenosti...
Momentalne by som jednoznacne uprednostnil postfix.
Ad djb> jiste ze jeste zije :-) Na qmail nekasle a uz vubec nespoleha na zadny miliony patchu, ale jen ma opravnene spravny pocit ze jeho dilo vypada presne tak jak chtel aby vypadalo a nechce ho prznit blbostma :-). Co se patchu tyce ano, jako snad ke kazdemu programu existuje tuna vylepseni a patchu od ruznych lidi - nektere vylozene zbytecne, nektere uchylne napsane a nektere primo hruzostrasne a nektere jednoduche elegantni ktere pridaji jenom nejakou doplnujici funkci. Co je na tom spatneho?
Co ma standardne za bugy? Co se bezpecnosti tyce tak nema zadnou chybu natoz aby se maskovala jako feature...
co se soft updates tyce je to problem bsd - jsou tu jaksi pozdeji nez tu byl qmail tak jeho autor nejak nemohl tusit ze to nepojede. BSDckari by si to radeji meli opravit nez s tim nepojedou i jine programy ktere jsou napsany vic prasacky. Kdyby bylo vsechno psano alespon tak jak qmail...
Jaka zpomalujici knihovna? Co je to za nesmysl? Naopak - qmail v podstate nepotrebuje zadnou knihovnu coz je dobre protoze jde staticky zkompilovat i s necim rozumejsim nez je posledni dobou vic a vic vydechlejsi a nabubrele glibc - binarka je stejne nakonec mensi a navic jede jeste rychleji spousteni pac staticka binarka, takze o pomalosti nemuze byt rec.
Qmail se nekonfiguruje patchovanim - qmail se konfiguruje pomoci konfiguracnich souboru. Ty jsou pro nekoho kdo tomu rozumi naprosto intuitivni snadne a logicke, zatimco nekomu jinemu zase sedet nemusi.
Nebo raz dojde trpelivost a zrusis i ten posledni postfix ktery pouzivas abys tam nainstaloval rozumejsi MTA :-)? Vidis, ze takhle jednoduse se to rict neda. Je to o zvyku: pokud ti at uz z jakehokoliv duvodu nevyhovuje qmail neznamena to ze je za kazdou cenu spatny. Co se uprednostnovani tyce, radeji pouzivam budto to, co uz funguje takze neni radno do toho sahat nebo to co je pro dane pouziti vyhodnejsi. Jisteze si dovedu predstavit situaci kdy bych nenasadil nic jineho nez sendmail stejne jako jinou situaci, kdy zase exim. Jinak volim qmail z duvodu jednoduche a elegantni konfiguraci a dokonale funkcnosti.
" nektere vylozene zbytecne, nektere uchylne napsane a nektere primo hruzostrasne a nektere jednoduche elegantni ktere pridaji jenom nejakou doplnujici funkci."...
Do ktorej kategorie teda patri patch riesiaci tzv."silly qmail syndrom" (aka ext-todo patch), ktory je mimochodom nekompatibilny s BIG-TODO patchom (neskor bolo vyriesene spolocnym patchom)? Oba su nevyhnutne pre vacsie instalacie qmailu a riesia dost zasadne vykonnostne "issues" a nie len nejake kozmeticke veci. Co sa tyka je "spomalujucej kniznice", to som sa nepresne vyjadril. Na bsd sa ten problem riesi dost tazkopadnym patchom, pridavajucim par fsyncov a videl som aj zvlast kniznicu pre tento ucel (http://untroubled.org/syncdir/). A kazdne flushovanie bufrov pri fsync predsa spomaluje, ci nie?
Preco iny sw tento problem nema? Lebo sa nespolieha na nieco, co na 100% neplati. Jedna sa o > 5 rokov stary problem.Ak by bol problem iba na strane Linuxu/BSD, uz je davno vyrieseny. Toto a aj tie vyssie spomenute problemy uz mal autor davno riesit sam a nestavat sa k tomu dost arogantnym sposobom, ze ten kod je 100%, ze je vsetko ok a tak to ma byt.
Mimochodom, keby bolo pisane vsetko ako zdrojaky qmailu, to by sme teda dopadli.Neviem, ci som tam videl jeden komentar...Kod je to totalne zhusteny a neprehladny. Pravdepodobne pred vypustenim src pouzil 'grep -v vsetky_komentare' :-) Co takto smtp-auth ,tarpitting, bounce patch, atd ? Jednoducho qmail zaspal dobu a to radsej nespominam ani styl jeho "logovania".
Dovolim si tvrdit, ze "mail is a modern SMTP server which makes sendmail obsolete" je dost nadnesene.
Samozrejme, ze qmail ma aj svoje vyhody, ako je najma bezpecnost a nizka systemova rezia pre jeho beh, ale ako hovorim, podla mna uz zdaleka nema tak navrch, ako to bolo kedysi.
Tu konfiguraciu patchovanim som samozrejme myslel obrazne :-)
Aby som to zhrnul - qmail sa tvari, ze je vykonny a vhodny na velke servery a prave v tomto nasadeni ma aj niekolko zavaznych problemov, ktore je nutne riesit externymi patchmi uz dlhe roky.
