Názory k článku
Linux jako internetová gateway (8)

Malá připomínka. Soubor "rc.bind" je po instalaci standartně bez práv pro spuštění. To není chyba. Na Slackware se tak dají zapínat a vypínat služby, aniž zasahujete do konfiguračních souborů. S jinými službami je to podobné.

Sveho casu jsem taky pouzival BIND a SQUID, ale tyhle programy jsou urceny pro neco jineho, nez je delani cache pro par stroju v domaci siti, zerou dost prostredku a jejich nastavovani je prilis komplexni.

Rozhlidl jsem se po NETu a nasel nejake mensi a lepsi nahrady:

za SQUID je to tinyproxy, http://tinyproxy.sourceforge.net/

za BINDa pak specializovana DNS cache pdnsd
http://home.t-online.de/home/Moestl/

v Gentoo jsou oba baliky v portage, jak je tomu v jinych distribucich, to nevim..

Co se tyka DNS, at uz cache nebo auth. nameserveru, tak n edam dopustit na djbdns, viz. http://cr.yp.to . Oboji krute rychly a ve srovnani s Bindem, krute jednoduchy na konfiguraci.

Naprostý souhlas, djbdns rulez ;-) BIND je na DNS cache overkill, zbytečně komplexní, zbytečně pomalý a zbytečně děravý ;-)

Ja jsem vedel, ze korenovy name servery spravujou security lameri ;-)

Korenovy nameserver je ponekud specificka zalezitost a delat z nasazeni binda na korenovych serverch nejake zavery pro jeho nasazeni jinde asi moc nejde. Navic dnes uz neplati, ze by vsechny korenove servery pouzivaly bind.

Reagoval jsem jen na to `derave` :-) Vsechny ne, ale vetsina stale ano.

Souhlasim s vami ... djbdns je skvely a uzasne jednoduchy. Ale vyplati se umet i BINDa ;o) Konfigurace djbdns mi sice chvili dala, ale vyplatilo se to :)

Jo souhlas, umit BIND je dobry, clovek pak muze argumentovat >o]. Pouzival jsem BIND asi 3 roky.

Naprosto souhlasim, pouzival jsem bind asi mesic a hodne rychle jsme od nej museli utect. Na dvou /24 sitich pouzivam balik djbdns jako cache pro celkem cca 430PC a pres tinydns se delaji DNSka pro webhosting zhruba 120 domen... A rozhodne to neprovozujeme na masinach s P4... :-) Navic takove ty veci jako daemontools... ;-)

BTW: Titulek by mel znit spis "nechodte s kulovnici na vlka, stilejte laserem mimozemstany..." :-))

Jinak bind neni zas tak spatny... Obcas i funguje.

>> Naprosto souhlasim, pouzival jsem bind asi mesic
>> a hodne rychle jsme od nej museli utect
po mesici pouzivani je to hodne odvazne tvrzeni...o dobre nakonfigurovanem bindu se rozhodne neda rict, ze "obcas funguje"...uznavam, ze je trochu rozezranejsi, ale to pri cenach dnesnich PC neni zas takovy problem..
>> A rozhodne to neprovozujeme na masinach s P4...
my ano a vybec nam to nevadi, protoze na ni bezi i spousta ruznych veci...

S cim musim souhlasit, ze na SOHO reseni neni vycet softwaru, ktery tu autor uvedl, prilis vhodny....Misto binda dejte dnscache, misto sendmailu postfix nastaveny na smtp-relay a squid nakonfigurujte jako transparentni proxy...kdyz uz tam chcete rvat binda, tak ho alespon nakonfigurujte jako dns-forwarder, pochybuju, ze se kvuli par privatnim ip vyplati delat se slozitejsi konfiguraci...a pokud mate sit s desitkami privatnich ip, tak si rozchodte DDNS-DHCP...

az tak kruto jednoduche to nie je :-)

Pouzivam SQUID a mam s tim stale problemy, nainstaloval jsem si TinyProxy, ale nemuzu najit zadny file kterym jej spustit. Je tam jeden v /usr/local/sbin/ ale ten je mrtvej. Pouzivam Slackware 9.1. Poradi mi nekdo? Diky

No nevím, jestli Sendmail je pro malou gateway vhodná záležitost. Je pomalý, těžkopádný, dost nebezpečný a STRAŠNĚ komplikovaný!
Já bych přemýšlel nad jakýmkoliv jiným MTA, ale SendMail bych URČITĚ!!! neuvažoval.
Doma používám PostFix (http://www.postfix.org/) a jsem spokojený.

Nebezbecny uz ani tak ne, ale souhlasim s tou slozitosti a tezkopadnosti. Moznosti co sendamil nabizi urcite v SOHO nevyuzijete. Take bych doporucil postfix.

Take musim sohlasit :-)
Jenom bych jako jednoduchoucky mailer doporucil exim :-)

Hm, já sice exim používám, ale ne jako jednoduchoučký ultrabezpečný SMTP (což tedy, přiznejme si to, zrovna není), ale právě kvůli featurám, které do qmailu musíte dohackovávat neoficiálními patchi a v postfixu ... možná jsem jen nepřišel, jak na to, zatímco v eximu jde všechno samo ;-)

Kolego,
Já za bezpečný nepovažuju program, co měl za poslední rok víc než 15 (no, jedna byla platformně závislá a jedna k exploitu chtěla instalaci IMPu - aby mi ti nebylo spíláno do amatérů :o)) závažných a potvrzených chyb. Navíc ve většině instalací jede pod rootem. SOHO sítě by měly existovat bez zásahu administrátora a většího nebezpečí pro uživatele dlouho. Takže není potřeba si dělat další bezpečnostní problémy se sendmailem.
S Postfixem souhlasím, protože ho máme jako front MTA a od instalace přede dvěma roky s ním nebyly závažné problémy. Bezpečnostně krom jedné DOS na kterou zatím nebyl oznámen exploit je to taky docela čistý program. Jede CHRootnutě a pod svým velmi neprivilegovaným uživatelem.

Doporucuji se divat pozorneji:

http://www.securityfocus.com/bid/8333/exploit/

dalsi chyby a exploity na ne si snad najdete sam.

DoS na <= 1.1.12 funguje az moc spolehlive. A je to potom radost hledat a likvidivat ve spoolu e-mail co ho zpusobuje :(

Postfix az tak jednoduchy na konfig nie je, ak z neho chcete dostat maximum ....

Pod Slackware jsem mel se Squid problem treba s t-zones.cz (redirect na https) - vam to funguje? Poradi pripadne nekdo, jak to zprovoznit?

pohoda ... je to tim, ze nektere sity pouzivaji ... eee ... ja to nekde najdu. v patek, nebo v sobotu je solution zde. tedka jsem out, ale poradim ;o) popr. zaslu na email ... tohle jsem taky resil a staci prehodit jednu pomennou

2 someone:
hehe, tak tohle samy se deje i me na routeru doma. Ale co je jeste zajimavejsi, ze v praci mam na chlup stejnou konfiguraci squida a tam to funguje.. Nechapu.. Kdyby nekdo vedel proc squid nektery stranky (www.t-zones.cz, www.mojebanka.cz,www.icq.com) nezobrazi, moc by me to zajimalo.

Jojo, na Mandrake mi to experimentalne bezelo, zkusil jsem vzit kompletni konfiguraci na Slack a nic. (Ani u mnou prelozene verze, ani u neciho baliku do Slacku.) Svedl jsem to na volby kompilace a zatim odlozil.

Reseni:
echo "0" > /proc/sys/net/ipv4/tcp_ecn

pripadne do sysctl.conf pridat:
net.ipv4.tcp_ecn = 0

diky, diky, diky.. :o)))

tak kvoli tomuto som zrusil squid z routra :D, nikde som nenasiel riesenie, idem ho teda nahodit s5 a uvidime ci to pojde

tak tak ... holt, nepamatuju si to z hlavy a jsem out of home, ale je to tak ;o)

Ups, diky moc. Koukam, ze je to i Squid FAQ.
http://squid.bilkent.edu.tr/Doc/FAQ/FAQ-14.html
No, odkazovana hall of shame tcp_ecn vypovida dostatecne - .cz akorat t-zones a ge :)

zde je slibeny odkaz. sice jsem mel nekde lepsi, ale tady je taky neco napsaneho :
http://www.squid-cache.org/mail-archive/squid-users/200111/0069.html

zde jeste neco, co jsem si asi odnekud poznamenal:
>squid fix - stranky nelze zobrazit pres proxy server
> #used to accept connections from broken solaris machines
echo 0 > /proc/sys/net/ipv4/tcp_ecn

have a nice day :)

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.

-djz

" 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.

- jak už zde padlo, pro tento účel ruce pryč od BINDu, z vyjmenovaných alternativ hlasuju pro pdnsd (o djbdns jsem slyšel, že prý moc nehledí na rfcčka, proto jsem ho nezvolil a nemám s ním zkušenosti - ale třeba je dobrý taky :-) (a rozhodně musím pomluvit maradns, padá a blbne ostošest)

- "O tom, co squid je, snad stačí napsat, že je to proxy server." ... ehm, ehm, drobná nepřesnost, leč podstatná, vzhledem k tomu, že se o tom v tomtéž odstavci mluví a že v takovéto síti jinou výhodu Squidu nevidím - citované napsat nestačí, Squid je CACHING proxy server (ano, existuji i proxy, které nekešují...)

- "Výsledkem je značné snížení zátěže linky." ... ehm, ehm, to je teda hodně subjektivní, co znamená "značné" ... výtěžnost Squidu se obvykle udává do 20% (nebijte mě, pokud si to nepamatuju přesně, ale je to v tomto řádu), přičemž s růstem počtu obsluhovaných počítačů roste (nikoliv lineárně!) ... my máme na síti asi 30 počítačů a výtěžnost Squidu je asi 10% ... myslímže u nonstop připojení bez omezených dat (kde není potřeba šetřit úplně každý bajt) se v malé síti nasazení Squidu vůbec nevyplatí, člověk si tím jen zadělá na spoustu problémů ...

- ke konfiguraci Squidu - pokud má člověk nějaký nadbytečný velký disk, klidně i pomalý, nemohu souhlasit s autorem, kdo z malých sítí má připojení do Inetu 10 Mbps a výše, aby se mohla projevit rychlost disku? ... takže pokud máte diskovou kapacitu navíc, velmi se hodí nastavit Squidu maximální velikost cacheovaného objektu (klidně i do řádu stovek MB) a používat ho i jako ftp proxy ... to byste nevěřili, kolikrát za den je windowsí bfu schopen stáhnout jeden a ten samý driver atp. :-)

- jako smtp používám ke vší spokojenosti postfix, je ale pravda, že zatím jsem po něm žádné šílenosti nechtěl, takže mě ani nemohl zklamat ...

- při nastavování poštovního serveru na Internetu doporučuju nahlédnout na stránky http://www.ordb.org/

- k tématu pošty by se opravdu hodilo popsat i příjem a nějaký IMAP (nebo POP), imho uživatele sednuvšího k počítači spíše zajímá, jak dlouho bude muset čekat, než se mu zprávy načtou, navíc se mu příjmem pošty z Inetu zatěžuje linka, kdyby chtěl zároveň browsit ...

Není Squid NETRANSPARENTNÍ kešující proxy server?

Defaultně jo, ale není problém ho nastavit jako transparentní.

U nastaveni squida je chyba:

"coredump_dir /var/lib/squid/cache

Na posledním řádku nastavujeme, kam se bude cache ukládat."

coredump_dir nastavujeme kde squid bude zanechavat core. Na nastaveni umisteni cache slouzi cache_dir, ktery ma take podstatne vice argumentu.

sendmail ruleZ

Prepacte ze tak mimo ale co tu preboha robia reklamy na M$ OFFICE? Pozehnan bud viera nasa!

Zdravim

K celemu serialu mam sice sve vyhrady, ale i tak je prinosny, chyby jsou opraveny v diskuzi.

Ale co si neodpustim.. Nechat konfigurak bindu tak jak je defaultni je blbost nejvetsiho kalibru. V konfiguraku jsou uvedeny nadrazene DNS. Kazdy normalni clovek ten konfigurak edituje a nastavi tam svoji nejblizsi vyssi DNS (typicky DNS providera). Defaultne tam jsou hlavni svetove DNS, coz pak sice funguje vzdycky ale co to dela s tema pretizenejma hlavnima svetovejma DNS. Autorovi vzkazuji aby si neco zjistil o hierarchii DNSek.

Zdenek

A ktereze to jsou ty "hlavni svetove DNS"? Vzkazuju autorovi prispevku, aby si zjistil neco o terminologii DNS.

to honza: No ja uz si to nepamatuju, rikal jsi toho strasne moc. Jsou to tusim top level DNS. Kazdopadne jsou od toho aby spravovaly top level domeny (neboli domeny narodni urovne). Vubec by na ne nemely chodit dotazy z nekdo.nekde.mojesit.cz.

I kdyz uznavam ze jsem ten prispevek mohl napsat trochu slusnejc.

Zdenek

Zdravim,
zda se, ze se tu vyskytuje spousta odborniku na dnscache a tinydns :) - trapi me jedna vec:
kdyz mam dnscache + tinydns, jak ma byt na tomto stroji nastaveny resolv.conf ? Ma tam byt 127.0.0.1 ? Maji tam byt DNS providera( kdyz uz vlastne jsou v dnscache) ?

Diky...

Na dotaz jak ma byt nastavene... se da odpovedet tak akorat nastav si to jak chces :-) Ale za rozumne reseni (rozumne v tom smyslu, ze tam ani tinydns ani
dnscache nebudou jako zbytecna okrasa...) je nastavit na tom stroji (a pripadne na vsech k nemu pripojenych) resolv.conf na adresu dnscache ktera je nastavena jako forwardonly na nadrazeny nameserver a navic smeruje mistni domey ktere spravuje tinydns prave na nej. Dotazy ktere jsou v cache zodpovi dnscache, co je mistni domena tinydns a pak teprv prijde na radu nadrazene dnsko pokud je to cokoliv jine.

Nastavovat na stroji kde je dnscache resolv.conf na adresu providera je prece blbost ne? To bys mohl dnscache rovnou smazat :-)

-djz

ano, nyni je mi to jiz zjevne. dik :)

Dobry den, mam takovyto problem. Mam server, ktery funguje jako proxy, mail server a firewall. Je to Suse 9 CZ. Problem mam takovy, ze po restartu bezi vsechno v pohode a tak po hodine se vetsina sluzeb nekolikanasobne zpomali. Citelne je to poznat na mailu a treba na direct connectu. Nevite cim by to mohlo byt zpusobeno ?