Portál AbcLinuxu, 24. dubna 2024 04:06
Kazdopadne, dnes jsou tu i jine DNS servery, kdyz uz tedy nechcete BIND.
Doporucovat programy DJB a hned v uvodu z jejich prasackemu chovani k systemu udelat prednost to chce silny zaludekNemůžu si pomoct, ale v článku musí být něco napsané neviditelným písmem. Nic o tom, že je to přednost, tam totiž nevidím.
Tou prednosti se muze myslet asi trebas toto:OK, jenže to už se týká konfigurace a tu si může každý uživatel nacpat, kam chce (tzn. kdo ji chce dát, kam patří, dá ji do /etc) Co se týče způsobu, jak konfigurovat, to už je na autorovi programu. Na způsobu, kterým se konfiguruje dnscache, nevidím nic špatného, stejně tak nevidím nic špatného na způsobu, jakým se konfiguruje apt, mysql atd. - tak si to prostě autoři zvolili.
10.11.2009 09:50
Věroš | skóre: 24
| blog: Co není v hlavě
| 49.29 s.š., 16.54. v.d.
a tak nasazovat dnes qmail bez dalších patchů je na dnešním Internetu ne-úplně optimální řešení.Stejně jako je ne-úplně optimální řešení nasazovat na dnešním Internetu Linux 1.0 bez dalších patchů. Ve světě open-source se prostě program vyvíjí tak, že se k němu přidávají patche. Ano, u qmailu je to horší v tom, že autor vývoj ukončil, nicméně každý to po něm může převzít a správy patchů se zhostit - například http://www.netqmail.org
Dostal jsem se k jednomu qmail serveru, který předchozí admin nakonfiguroval a přeložil na nějakém jiném stroji a na serveru jen umístil binárky. Už jenom zjistit, které všechny patche v tom jsou byla lahůdka. On pár řádkový patch, který natvrdo šahá do pevně daného souboru kdesi úplně mimo a neloguje ani ň, se opravdu perfektně dohledává. Navíc ty patche doplňují ruznou funkcionalitu, takže pak odpovědi na otázky "co se stane když...?" nebo "proč se děje to a to?" jsou lahúdky na odpověd
Ovšem když takový systém začne mít netriviální množštví objektů v konfiguraci, pak jeho převedení do čehokoliv jiného je značně obtížné.
A ted me pripominky, v praci djbdns uzivam (ted jiz spise minuly cas) jako lokalni dnscache (postovni/web servery a nutna rychla odpoved). Bohuzel ne zridka kdy se objevili "podivne" problemy, ktere povetsinou resil restart sluzby. V logach nic nevyctu (pred kritikou prosim prvne mrknete co v logach ve skutecnosti je). U produkcniho serveru NENI MOZNE jen tak ze srandy resit chybu resetem sluzby, ale spis snazit se predejit problemu. Bind neni nejlepsi, ale porad se da docela dobre poladit, a i jako hloupa cache dovede byt vice jak dost efektivni. Avsak testnu par rad od kluku z CZNicu, a vyzkousim rychlost unboundu (jakozto rekurzivniho/cache-only serveru)
10.11.2009 19:35
the.max | skóre: 46
| blog: Smetiště
), protože pokud se do toho někdo znalý neobuje (ideální by byl fork, aby člověk pořád nemusel šaškovat s patchi), tak přestane být použitelným (a třeba datový formát tinydns a schopnost aktualizovat databázi pouhým přehráním jednoho souboru mi budou chybět…)
a donutit ho třeba spolupracovat s master serveremCo je tím myšleno?
djbdns nepoužívají, mají potřebu pořád všude prosazovat, jak je nepoužitelný. djbdns neumí IPv6 nebo DNSSEC, to jsou jeho problémy. Ale spolupracovat s jinými DNS servery samozřejmě umí, stejně jako není problém s jeho konfigurací. Pokud vám osobně nevyhovuje, je to vaše věc, ale nevydávejte to za obecně platnou věc. Někomu zase nevyhovuje Bind, ale snad nikdo nemá potřebu kvůli tomu tvrdit, že je Bind nepoužitelný.
daemontools, ne o djbdns. Taky by mne zajímalo, co je ten standard – když si vezmu třeba Apache, Postfix a ISC DHCPD, to se také každé konfiguruje a spravuje jinak.
případně to můžu spustit v popředí z příkazové řádky a dívat se, co to dělá.To jde samozřejmě i s Daemon Tools a dokonce je to jednodušší než u programů, které se spouští init skriptem. U init skriptu totiž není snadný způsob, jak něco spustit na popředí stejně, jako když to spustí tím skriptem* (mluvím o parametrech, změně UID apod.) Naopak u Daemon Tools se jednoduše najde run a ten se spustí. * respektive pokud existuje, tak jsem ho ještě neobjevil U /etc/init.d skriptu jsem narazil na problém třeba u Asterisku. Asterisk má v konzoli příkaz restart now, jenže to init skript vůbec neřeší, takže Asterisk se ukončí a už nenastartuje. Tohle Daemon Tools řeší naprosto jednoduše automatickým restartem služby.
djbdns v Debianu neřídí, je to chyba správce balíčku, ne djbdns – není problém to zařídit ani s daemontools.
Výhoda daemontools je právě ta, že program můžete spustit z příkazové řádky na popředí a dívat se, co dělá – a program běží pořád stejně, jako pod daemontools. Pokud tohle děláte s jiným programem, chová se pokaždé trochu jinak, protože o tom, zda běží na popředí nebo na pozadí rozhoduje sám program a musí se tomu přizpůsobit. A taky musí ten program tyhle volby vůbec mít. S daemontools běží každý program jakoby na popředí a nemusí mít žádný speciální režim pro odpojování se od terminálu atd.
init a /etc/inittab nejsou zrovna ideální, proto také vznikají různé náhrady, že. Že tady jsou dnes různé náhrady je fajn, aspoň je větší výběr -- ovšem DJB asi nemohl s uvolněním djbdns čekat, až někdo nějakou tu náhradu napíše. Ostatně djbdns můžete používat i s těmi dalšími náhradami, můžete si k nim klidně napsat vlastní init skripty.
Pro někoho je asi osobnost DJB důvodem k tomu, aby se obloukem vyhýbali jeho softwaru. Já jsem se s ním nikdy nesetkal, tak s jeho osobností žádný problém nemám. Ovšem to, že nemáte DJB a tím pádem ani jeho software rád, to už tady ví asi každý, takže příspěvky na téma "proč používat software od DJB, když jsou tu i alternativy" jsou opravdu zbytečné. Ano, máte pravdu, že djbdns neumí IPv6, neumí DNSSEC ani oškrábat brambory. Někomu to vadí, někdo jej třeba provozuje na počítači pouze s IPv4 stackem a servíruje z něj domény, jejichž TLD zatím není podepsaná, takže mu jeho nedostatky nevadí. Má smysl se tedy bavit o tom, co umí, co neumí, a zda je to problém nebo přínos. Ale argument "můžete přece používat i něco jiného" je zbytečný, nemyslíte?
Jen jsem odpovídal na otázku, kterou jste položil - jaký je standardní způsob zajištění toho, aby program stále běžel.Já jsem se ptal na to, jaký je standardní způsob konfigurace, logování a znovunačtení konfigurace služeb. Ale asi jsem to měl napsat jasněji. Myslel jsem např. na to, že Apache má pro znovunačtení konfigurace (a správu služeb) vlastní utilitu, jiné programy přenačtou konfiguraci po zaslání nějakého signálu, a ISC DHCPD dlouho znovunačíst konfiguraci za běhu neuměl (a nejsem si jist, zda to už dnes umí).
No a k druhé části - prosím běžte a znovu si přečtěte všechny moje příspěvky pod tímto článkem. Pak od Vás očekávám omluvu.Omlouvám se, spojil jsem si dřívější diskuse o
djbdns a tento váš komentář, který mi připadal, jako že zatracujete daemontools jen proto, že jsou od DJB. Pokud jsem to špatně pochopil a pokud srovnáváte software od DJB podle vlastností software a podle toho, co uživatel potřebuje či nepotřebuje, budou myslím vaše příspěvky o DNS na Abíčku přínosem.
Já považuju kousky od djb za excelentní příklady hezkého programování, a doporučuju začínajícím programátorům se ponořit do zdrojového kódu. Bohužel už dnes nejsou v souladu s aktuálními standardy a nejsou dlouhodobě původním autorem udržovány. Pokud mě osobně něco vadí na přístupu k DNS, tak je to neexistence podpory EDNS0 a v qmailu "optimalizace" dotazu IN MX+IN A na IN ANY. (IPv6 bude časem nutnost, tak se to vyřeší tak nějak samo, protože nika pro djbdns zůstane jen opravdu malinká.)Stagnace DJBware je problém. Dlouhou dobu to nevadilo, protože SMTP nebo DNS se rozvíjelo směrem k různým specialitám, které zdaleka nepotřeboval každý. To ale neplatí o IPv6 nebo DNSSEC (ať si o něm myslíme cokoli). Ve své době (kdy kraloval Bind a Sendmail) byly
qmail a djbdns určitě velkým přínosem a na mnoha místech se dají bez problémů používat i dnes. A je škoda, že třeba přechod na IPv6 djbdns nejspíš nepřežije.
Já jsem se ptal na to, jaký je standardní způsob konfigurace, logování a znovunačtení konfigurace služeb. Ale asi jsem to měl napsat jasněji.Většinu z toho definuje FHS - tedy alespoň místa, kde mají ležet konfigurační a logovací soubory. Standard pro logování je syslog (nikoli program, ale rozhraní), kde je na druhou stranu pravda, že ten je mnohdy nevyhovující a proto si složitější služby dělají logování vlastní. Ale chápu, co se tím snažíte říct. Myslím, že největší "odpor" vzbuzuje to, že daemontools všechno nahrnulo na jedno místo.
ISC DHCPD dlouho znovunačíst konfiguraci za běhu neuměl (a nejsem si jist, zda to už dnes umí).Já myslím, že pořád neumí... Ale ono to tolik nevadí, protože si udržuje databázi leases, kterou po startu znovu načte.
Ve své době (kdy kraloval Bind a Sendmail) byly qmail a djbdns určitě velkým přínosemVe své době jsem qmail a djbdns používal a do qmailu jsem si taky napsal pár patchů. Ve své době běžel na mail serveru v té době největšího hostingu v ČR. Pak se přešlo na postfix a ten je tam hádám doteď.
A je škoda, že třeba přechod na IPv6 djbdns nejspíš nepřežije.Tak furt se dají použít patche: http://www.fefe.de/dns/ a http://www.fefe.de/ucspi/ (teda ne že bych použití djbdns doporučoval, ale pokud není zbytí...
).
Myslím, že největší "odpor" vzbuzuje to, že daemontools všechno nahrnulo na jedno místo.V obvyklé konfiguraci s
djbdns. Jinak je na jednom místě pouze spouštěcí skript a pomocné soubory pro službu (stav, zámky apod.), vše ostatní si lze přesunout, kam chcete. Já daemontools používám třeba pro start Java serveru, konfigurace se čte z /etc a logy ukládají do /var/log.
Ale ono to tolik nevadí, protože si udržuje databázi leases, kterou po startu znovu načte.V praxi to asi moc nevadí, mně se na tom nelíbí hlavně ten princip, že je nutné kvůli rekonfiguraci na nějakou dobu přestat poskytovat příslušnou službu. A zvlášť v případě DHCP, kdy vlastně nejde o změnu konfigurace, ale pouze o změnu dat.
V obvyklé konfiguraci s djbdns.Ano... ale právě to, že to djb navrhl takhle a prohlásil za standard byl/je ten problém. Ale v zásadě si snad rozumíme.
kvůli rekonfiguraci na nějakou dobu přestat poskytovat příslušnou službuhttp://www.dt.e-technik.uni-dortmund.de/~ma/djb/dns/
Ono je vůbec zvláštní, že servery zpravidla nemožnost nabindovat se na zadaný port považují za fatální selhání a skončí. Přitom by podle mne bylo mnohem lepší nastartovat server, teprve na závěr se pokusit připojit na zadaný port, a pokud se to nepodaří, v závislosti na konfiguraci to zkoušet opakovaně.
Třeba když aplikační server startuje několik minut, bylo by lepší nastartovat novou instanci, a teprve když běží, starou vypnout a na port nabindovat novou. Volitelně se to dá rozšířit ještě o nabindování na náhradní port, ověření, že vše funguje, a teprve pak stopnutí staré instance a nabindování na správný port. Ale to už jsme od DJBDNS hodně daleko
Ty asi samy o sobě bohužel nebudou dostačovat - patche pro djbdns přidávají podporu jenom pro AAAA záznamy, zatím jsem nenašel patch, který by tinydns/dnscache umožňoval naslouchat na IPv6 adrese.je škoda, že třeba přechod na IPv6 djbdns nejspíš nepřežije.Tak furt se dají použít patche: http://www.fefe.de/dns/ a http://www.fefe.de/ucspi/
http://cr.yp.to/djbdns/ipv6mess.html
(Nicméně ten pamflet je taky už tak 8 let starý...)
tcp6 0 0 :::53 :::* LISTEN 18421/dnscache udp6 0 0 127.0.0.2:53 :::* 18822/tinydns udp6 0 0 :::53 :::* 18421/dnscache
Myslel jsem např. na to, že Apache má pro znovunačtení konfigurace (a správu služeb) vlastní utilitu
Když se do té "utility" ale podíváte, zjistíte, že nedělá v podstatě nic jiného než distribuční init scripty u jiných démonů. Konkrétně u reloadu konfigurace jediná podstatná odlišnost spočívá v tom, že Apache používá signál USR1 místo obvyklého HUP.
ISC DHCPD dlouho znovunačíst konfiguraci za běhu neuměl (a nejsem si jist, zda to už dnes umí)
IIRC stále neumí, ale to není zdaleka jediný.
Když se do té "utility" ale podíváte, zjistíte, že nedělá v podstatě nic jiného než distribuční init scripty u jiných démonů.Jasně, myslel jsem to, že někde je doporučený způsob poslat signál, někde utilita, která nakonec stejně pošle signál. Správně by to pak stejně měly odstínit distribuční skripty, které to sjednotí, a uživatel by pak nemusel pátrat, jak se která služba restartuje.
Zajímavé je, jak ti, kteří djbdns nepoužívají, mají potřebu pořád všude prosazovat, jak je nepoužitelný.
Neméně zajímavé je, jak většina fandů djbdns cítí ohromnou potřebu neustále sdělovat světu, jak je BIND neuvěřitelně špatně navržený, chybový, nebezpečný a vůbec. Obvykle se při tom nezastaví ani před manipulací s časem a zaměňováním BINDu 4 s verzemi řad 8 a 9. Každý má holt svoje…
djbdns otírat (kvůli tomu, že jim nevyhovuje), proti Bindu není napsáno nic v článku a myslím, že ne ani v diskusi. No, možná e tady jenom zatím žádný fanda djbdns neukázal.
proti Bindu není napsáno nic v článkuProti aktuálnímu Bindu.
. Přiznám se mě je tenhle "ortodoxní" a malinko zvrácenej přístup celkem sympatickej, ale já mám doma jenom malou stanici a nemusím zpravovat velký servery, takže si to můžu s čistým svědomím dovolit 
Viz qmail a spamy.Už Bernsteinův qmail-1.03 umí e-mail nechat při doručení do schránky zkontrolovat antispamem, není problém odmítat e-maily podle rbl O kousek výše jsem dával odkaz na netqmail - konkrétně patch QMAILQUEUE umožňuje s tím mailem před doručením dělat, co si zamaneš, takže antispamovou kontrolu můžeš dodělat přímo do přijímání mailu (a spam třeba úplně odmítnout), stejně tak lze jednoduše dodělat kontrolu antivirem a v podstatě cokoliv dalšího si zamaneš a implementuješ. Takže qmail a spamy - tohle je málo?
Btw.: v době, kdy qmail vznikl, nebyly AFAIK spamy tak velkým problémem, takže není moc divu, že se s nimi nepočítá.
DNS záznamy se prohledávají rekurzivně od domény, která je v hierarchii nejvýše, tzv. TLD – top level domain. V našem případě je to cz a první informace, kterou musíme získat, je, které servery slouží jako jmenné servery pro doménu CZ. Dotážeme se tedy kořenových DNS serverů a ty nám vrátí informaci, že jsou to servery a.ns.nic.cz, b.ns.nic.cz a tak dál až po písmeno f. Těchto serverů je následně potřeba se zeptat, které servery slouží jako jmenné servery pro doménu abclinuxu.cz – zjišťujeme, že jsou to ns1.dnspark.net a ns2.dnspark.net a tak dál až po číslo 5. A teprve jich se můžeme ptát, jaká je IP adresa ábíčka.Silně doporučuju pustit si wireshark nebo tcpdump, a podívat se, jak vlastně dotazování do DNS funguje, než příště napíšete do článku něco, co není pravda.
c.b.a., ale existuje doména d.c.b.a. To poslední vypadá (s ohledem na dnešní trend "zplošťování" DNS) jen jako teoretická konstrukce, ale např. u reverzního lookupu pro IPv6 je taková situace velmi častá.
de factoje právě špatně, protože resolver neví a ani nemůže vědět, kde je zone cut (tj. kde je provedena delegace na další NS), čistě teoreticky z hlediska by na abicko.abclinuxu.cz mohl odpovědět kořenový nameserver. Druhá chyba je:
DNS záznamy se prohledávají rekurzivně od domény, která je v hierarchii nejvýše, tzv. TLD – top level domain.Nejvýše v hierarchii není TLD, ale kořenová zóna. Ostatně pak dále článek pokračuje dotazováním na kořenové nameservery.
aptitude install dnscache-runRozdílně oproti článku to instaluje djbdns (ne dbndns) a daemontools (ne runit). Automaticky to provede konfiguraci dnscache (balíček dnscache-run) pro rekurzi od kořenových serverů DNS a poskytování služby pouze pro vlastní počítač (127.0.0.1), zajištění spouštění služby a její první spuštění. MartinT
Pro uživatele distribuce Debian lenny uvedu možnost snadnější instalace dnscache s plně automatickou konfigurací pro samostatný počítačTo mi tak nějak připomnělo: Nikdy nesmíš kulturní šok způsobit člověku, který právě pilotuje tisícitunový kámen!
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.