dig -x 123.45.1.1 je dost jednoduchý. DAEMON_OPTIONS v článku zabraňují sendmailu naslouchat na jiném rozhraní, než na loopbacku (čili není možné sendmail kontaktovat přes síť a není tedy možné přijmout mail z jiného počítače). Výhody a nevýhody na konci článku jsou pěkně zmatené, protože sendmail se o opětovné doručení pokusí vždy a nastavením konfigurace nezabráníte vypnutí počítače :-) Čekal jsem (podle úvodu) trochu více :-(
Vychadzam z predpokladu, ze znacnu cast kapacity linky zahltia surfujucu uzivatelia.
A dalej z toho, ze vacsina ich surfuje v ceskom a slovenskom priestore.
Takze staci do proxy servera squid nasadit redirektor squirm (o ktorom som sa dozvedel prave tu na Zive.cz, dakujem :-) a s pravidlami cca. na jednu stranu ste schopni odfiltrovat vsetky vymenne bannery v cechach, na slovensku (+ hotmail, ktory je tu casto pouzivany).
Takze miesto vyrusujucej reklamy maju uzivatelia iba decentny viacmenej cierny obrazok, ktory sa im natahuje z lokalneho servera.
Ked pocitate iba 1-2 bannery na stranku (SME.sk ich ma kludne aj 4-5, zive.sk podobne ) a banner ma aspon par kilo.. hm.. tak usetrite bandwidth a stranky sa natahuju rychlejsie.
A navyse zabranite uzivatelom klikat na rozne haluze, ktore ich odtrhaju od roboty :-)))
(resp. nezabranite im na to kliknut, ale po kliknuti ich presmerujete .. znova na ten cierny obrazok.)
Zatial sa nikto nestazoval. (ok, tak jeden clovek)
Podobne mozete odfiltrovat aj tie uplne neuzitocne pocitadla pristupov (http://dot.idot.cz)
a zase sa to trosku zrychli.
ph@ais.sk
Taky bych se primlouval za popis konfigurace neceho rozumejsiho nez je bind+sendmail. Co takhle djbdns (dnscache, tinydns)+qmail+squid+iptables(treba pro jednoduchost shorewall) na lokale + popis jak to upravit na fw pro malinkou domaci/firemni minisiticicku (pripadne nejaky jednoduchy traffic shaping). To by bylo myslim uzitecnejsi. S ohledem na to, ze by to mel zvladnout uplny zacatecnik (jako ja po 3 mesicich skusenosti s Linuxem :-). Takovou kucharku bych povazoval za velmi hodnotny clanek. Sam jsem tuto kombinaci (ne komplet vsechno [LEAF Bering s qmail]) jednou rozchazel a zustalo spoustu nezodpovezenych otazek.
Tahle kombinace (bind+sendmail) je aspon soucasti instalace a tenhle clanek netvrdi, ze je to jedine, nebo nejlepsi reseni.
Proste popisuje nastaveni postavene na programech, ktere jsou na instalacnich CD a neni treba neco stahovat z Netu.
Clanek je prece pro lidi, kteri maji limitovanou linku, ne??
Myslim, ze stahnuti souboru o velikosti cca 2 disket neni zadny problem ani pro dialup. Napr. ten LEAF Bering je standartne jedna 1.68MB disketa a s qmailem a par djbtools je to na tu druhou :-) No a pro "standartni" distribuce si stahnes zdrojaky a ty nejsou vetsi. Tady se opravdu nejedna o xMB baliky, ale datovy tok ekvivalenti chvilky brouzdani na dnesnim netu zapraseneho reklamnimi banery.
Nepochybne je na vzdalenou zpravu LEAFu pouzito SSH a to v implementaci OpenSSH a nepochybne jiz ten, kdo se o LEAF stara aplikovat patche na docela skarede nove objevene chyby ve verzich OpenSSH starsich nez 3.5. Ono to neni jen o malickosti programku, ale o celkove koncepci, kdyz uz se o tu bezpecnost kazdy otira...
No v dnesni dobe, kdy chteji soudit chytry lidi, kteri poukazali na bezpecnostni problemy nekterych 'taky-bezpecnostnich' technik je mozny vsechno ... :)
Mam na mysli kauzy v USA (ElcomSoft), v Britanii, v Dansku .... jen se bojim, az tahle moda dojde k nam, to pak asi budou lidi, kteri umi myslet, pod prisnym dohledem a nebo ve veznicich :|
Ak mas na druhej strane (niekde na nete) neaku masinu ktora ti dokaze robit dekompresiu tebou odosielanych dat a komprimovat tie co lezu k tebe, nevidim v tom ziaden problem (kompresny pomer je ale zavisly na algoritme a hlavne tom co prenasas, takze ak budes prenasat napriklad mp3ky, tak to uz tazko zkomprimujes, ked to uz raz skomprimovane je)
Diky za kritiku, lepsi zaporna nez zadna. V pokracovani se budu vic snazit (-:. Vyber softu vysvetlim jednoduse, vyjmenovany soft pouzivam a jsem s nim spokojeny, nicmene jste me vesmes presvedcili, ze bych se mohl zabyvat i alternativami. Pokusim se o to. Jeste jednou diky.
OT: Zdar, neviete ako povolit resolving externych domen iba pre privilegovane IP adresy z lokalnej siete? Konkretne mam malu lokalnu siet, v ktorej sedi bind a je master pre fiktivnu zonu (neexistujucu na Internete). Chcel by som, aby vsetkym strojom v sieti zodpovedal na dotazy o tejto domene. Pre resolvovanie mien v *.com, *.org, atd. sa musi vytocit dial-up a toto urobil iba pre niektore privilegovane stroje/IP adresy. Vdaka za lubovolny RTFM pointer...
Moznosti je nekolik, uvadim jednu, jinak doporucuji dokumentaci bindu, klicova slova acl, allow-recursion, allow-query, zone. Take doporucuji v sekci options volbu dialup a heartbeat-interval. Tyto umoznuji zajistit vykonavani dotazu "ven" v davkach.
/etc/named.conf:
options {
allow-recursion {
192.168.1.13;
192.168.1.26;
... dalsi "privilegovane" adresy
};
...
};
Ano, jsem pro, aby se vytahla na svetlo Smartcache, ktera beha i na Widlich, a jako kafova aplikace bude jiste nasaditelnejsi na mnohem vice masin, nez bind, qmail atd. A kdyz uz se tu diskutuje dial-up, chtelo by to otestovat i ty rozhrani SNTP<->web.mail ;)
to zere taky kapacitu linky strasne.
Bind9 je uplne prepsan s ohledem na bezpecnost. Myslim, ze je opravdu skvely. Jako cache-only DNS je mozna o neco vetsi nez specializovane konkurencni servery, ale je myslim plne vyhovujici. HLAVNE narozdil od DJBDNS ma format zon v normalnim tvaru.
Prirucka BINDu je vyborne napsana. Neni soucasti archivu...
Sendmail ve verzi 8.12.X je take dost predelan. Je v nem oddelena cast naslouchajici od casti posilajici lokalni postu z duvodu bezpecnosti. Vyzaduje take striktne prava adresaru mspool, souboru .forward apod.
Dokumentace je psana dost necitelne, ale kdyz uz to jednou pochopite, tak uz to nikdy nezapomenete a zjistite, ze to je trapne jednoduche...
V clanku se pise "v případě výpadku jmenných serverů poskytovatele budeme zcela odříznuti od světa, tento problém by vyřešila změna v /etc/named.conf z forward only; na forward first; (nebude fungovat při ochraně portu 53)"
veta "nebude fungovat pri ochrane portu 53" je ponekud nepresna. pokud svuj DNS cache server provozujete jen v roli trochu chytrejsiho DNS klienta a nehostujete zadne svetu pristupne zony, zakazte vsechny prichozi DNS dotazy, povolte vsechny odchozi a hotovo.
je jedno, zda se pakety posilaji jen jednomu serveru nebo se vykona serie dotazu na ruzne servery, vsechno to jsou odchozi dotazy. vy si zrejme chcete "chranit port 53" proti prichozim dotazum, coz muzete pohodlne rozlisit pomoci iptables.