V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Důvod, proč nejsou programy DJB nasazovány, je dost možná to, že se na první pohled odlišují od toho, na co je člověk běžně zvyklý. Součásti programu jsou rozházeny leckde, málokdy ale tam, kde byste je čekali (takový qmail se ve výchozím nastavení celý instaluje do /var, včetně konfigurace i spustitelných souborů). Běžné konfigurační soubory najdete málokdy, spíš spoustu souborů, které obsahují pár řádků a většinou žádné komentáře. O konfiguraci programů od DJB se navíc občas říká, že je sice přátelská pro strojové zpracování, ale nepřátelská pro správce.
Tato odlišnost je dost možná odrazující a leckterý správce systému se radši podívá po něčem, co je mu více povědomé. A to je škoda, protože dbjdns má rozhodně co nabídnout – na prvním místě je to bezpečnost. D. J. Bernstein napsal djbdns v době, kdy BIND – nejčastěji nasazovaný DNS server – proslul vážnými bezpečnostními chybami. DJB si byl bezpečností svého díla dostatečně jist na to, že nabídl odměnu 1000 dolarů tomu, kdo v něm jako první najde bezpečnostní chybu. Tato odměna byla vyplacena po deseti letech.
Navíc, když se s djbdns sžijete, zjistíte, že na první pohled složitá a podivná konfigurace je vlastně ve skutečnosti poměrně jednoduchá a přímočará.
Pokud jste se tedy nezalekli hned v úvodu a nebojíte se zkoušet a případně nasadit software, ve kterém se co deset let objeví bezpečnostní chyba, čtěte dále.
Hned ze začátku bych chtěl upozornit na to, že tento návod vzniká na stroji se standardní distribucí Debianu – přestože se budu snažit o co největší univerzálnost, některé detaily mi mohou uniknout a v ostatních distribucích se lišit. Pokud na něco takového přijdete, upozorněte v diskuzi.
djbdns je kolekce několika programů, v tomto článku se zmíníme o dvou z nich – dnscache a tinydns. dnscache je server zajišťující funkci, ehm, DNS cache, tinydns je plnohodnotný jmenný server. Mohou běžet nezávisle na sobě, ale také spolupracovat, obojí si v článku ukážeme na příkladech.
Začněme ale malou odbočkou. Programy D. J. Bernsteina bývají spouštěny pomocí Daemon Tools, což je kolekce softwaru pro spouštění, monitoring a restartování služeb, my ale místo nich použijeme náhradu, která je s Daemon Tools kompatibilní – Runit, který si teď ve stručnosti popíšeme. (Ti, kdo Runit znají, mohou tuto část článku klidně přeskočit, protože se zde s největší pravděpodobností nic nového nedozví.)
K instalaci použijte způsob nejvhodnější pro vaši distribuci, u mě to bude:
apt-get install runit
Základem runitu je program runsvdir-start, poinstalační skript balíčku automaticky zajistí jeho spuštění a restart v případě, že je ukončen, tímto záznamem v /etc/inittab:
#-- runit begin SV:123456:respawn:/usr/sbin/runsvdir-start #-- runit end
(Pokud vaše distribuce toto za vás neudělala, doplňte příslušný záznam ručně.)
runsvdir-start spouští program runsvdir, který následně prohledá adresář /etc/service (v různých distribucích se může lišit, vizte manuálovou stránku), a pro každý (pod)adresář nebo symbolický odkaz na adresář spustí proces runsv. runsv následně v adresáři, pro který byl spuštěn, hledá soubor run a spustí ho, pokud je to možné. Když run doběhne, runsv ho spustí znovu. (Tím je zajištěno, že pokud služba z nějakého důvodu spadne, je automaticky restartována). Pokud je automatické spouštění služby nežádoucí, stačí v adresáři, kde se nachází run, vytvořit soubor down – když runsv tento soubor najde, službu nespustí. (V takovém případě je službu možné spustit ručně a runsv ji bude po ukončení restartovat, jako kdyby soubor down neexistoval.)
Runit může zajišťovat i logování, při startu služby se v jejím adresáři hledá podadresář log, pokud je nalezen, je v něm spuštěn soubor run podobně jako v samotném adresáři služby. runsv v takovém případě zajistí přesměrování standardního výstupu služby na standardní vstup procesu, který zajišťuje logování, což obvykle bývá svlogd nebo jeho ekvivalent z Daemon Tools multilog.
K řízení běhu procesů spouštěných pomocí runsv slouží program sv, parametrem je příkaz a cesta k adresáři, ve kterém se nachází run. Mezi příkazy, které lze runsv zaslat, patří:
status – vypíše stav služby (běží/neběží, srovnání s výchozím stavem apod.) a jejího logování.
up – pokud služba neběží, spustí ji a po ukončení ji restartuje
down – pokud služba běží, zašle jí signál TERM a následně CONT. Po zastavení služba není restartována.
once – pokud služba neběží, je spuštěna, ale není restartována, když se ukončí.
Příkazů je více, mezi jinými je možné pomocí sv službě zasílat unixové signály STOP, CONT, HUP, ALRM, INT, QUIT, USR1, USR2, TERM a KILL. Podrobnější informace najdete v manuálové stránce.
runsvdir prohledává adresář se službami opakovaně v pětivteřinových intervalech. Pokud něco přibude, automaticky je spuštěn další proces runsv a příslušná služba nastartována (nebo ne, podle přítomnosti down). Pokud nějaký adresář či odkaz na něj zmizí, příslušný proces runsv je ukončen a služba, kterou monitoroval, také.
Runit má i další možnosti jak co se řízení služeb, tak co se logování týče, nicméně detailní popis překračuje rámec tohoto článku a informace popsané výše nám budou pro obsluhu DNS serverů postačovat. Zájemci si mohou prostudovat dokumentaci.
K čemu je dobrá DNS cache, snadno pochopíme, když se například podíváme na to, co se děje, když váš prohlížeč vyhledává IP adresu serveru, na kterém běží třeba abclinuxu – abicko.abclinuxu.cz. 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.
Tohle všechno trvá řádově vteřiny, během kterých prohlížeč pouze čeká a uživatel kouká na prázdnou stránku. Jedním úkolem DNS cache je tedy zapamatovat si informace, které vrátily dotazované servery, příště se jich neptat, ale místo toho hned vrátit záznam, který byl vrácen dříve. Samozřejmě se počítá s tím, že záznamy se mohou měnit, takže cache se po nějakém čase, který je pro každý záznam stanoven hodnotou TTL (time to live), opět zeptá nadřazeného serveru.
Jenom pro srovnání – dotaz na adresu ábíčka po resetu dnscache (je tedy nutné provést celý postup uvedený výše):
$ time host -t a abicko.abclinuxu.cz abicko.abclinuxu.cz A 195.70.150.7 real 0m1.439s user 0m0.000s sys 0m0.000s
A to samé, tentokrát jsou ale záznamy uloženy v cache:
$ time host -t a abicko.abclinuxu.cz abicko.abclinuxu.cz A 195.70.150.7 real 0m0.003s user 0m0.000s sys 0m0.000s
Jak je vidět, rozdíl je několik řádů.
Druhým úkolem DNS cache je omezit vytížení jmenných serverů – jak kořenových, tak těch, kterých se ptáme na konkrétní záznamy. Pokud by se několik miliard počítačů, které na světě jsou, opakovaně ptalo na to samou informaci – zbytečně, většinou se nemění – muselo by těchto serverů být podstatně víc.
DNS cache je možné provozovat jak na routeru sloužícím pro nějakou síť – počítače v této síti se beztak pravděpodobně ptají na to samé, tak proč si kvůli tomu vytěžovat linku do Internetu – tak na osobním počítači – tuto možnost pravděpodobně ocení lidé, jejichž připojení k Internetu má dlouhou dobu odezvy už na prvním skoku (například uživatelé GPRS) nebo kteří pochybují o spolehlivosti DNS cache svého poskytovatele.
djbdns instalujeme opět způsobem obvyklým pro naši distribuci, u mě:
apt-get instal dbndns
Poznámka: dbndns je v Debianu fork djbdns rozšířený o podporu IPv6 – djbdns standardně IPv6 nepodporuje, ale jsou k dispozici patche. Co se konfigurace týče, jsou dbndns a djbdns víceméně kompatibilní a informace uvedené zde platí pro obojí stejně.
Na rozdíl od mnoha služeb instalovaných v Debianu se u djbdns nevytváří konfigurace automaticky a služba není spuštěna. Aby nebylo nutné konfiguraci vytvářet úplně ručně, je k dispozici program dnscache-conf, který ji předpřipraví:
dnscache-conf dnscache dnslog /etc/dnscache 0.0.0.0
Parametry jsou v tomto případě v uvedeném pořadí jméno uživatele, pod kterým bude služba spuštěna, jméno uživatele, pod kterým bude spuštěno logování (oba uživatelé musí existovat), v jakém adresáři má být konfigurace uložena a IP adresa, na které má dnscache naslouchat (pokud konfigurujete pro samostatný počítač, použijte 127.0.0.1). Adresář /etc/dnscache je připraven tak, aby ke spuštění služby stačilo prosté vytvoření symbolického odkazu v /etc/service. Než to ale uděláme, podíváme se, jaká konfigurace byla připravena, a uděláme pár změn.
Obsah souboru /etc/dnscache/run je následující:
#!/bin/sh exec 2>&1 exec <seed exec envdir ./env sh -c ' exec envuidgid dnscache softlimit -o250 -d "$DATALIMIT" /usr/bin/dnscache '
Jako první vidíme přesměrování standardního chybového výstupu na standardní výstup, aby bylo logováno obojí (vizte výše – runsv zajišťuje pouze logování standardního výstupu). Následně je na standardní vstup nasměrován obsah souboru seed – dnscache při startu ze standardního vstupu čte 128 bytů a předává je funkci dns_random_init. To vše pro naše účely postačuje.
(Pokud nemáte k dispozici nebo z nějakého důvodu nemůžete použít program dnscache-conf, budete soubor seed muset vytvořit ručně, například příkazem: dd if=/dev/urandom of=/etc/dnscache/seed bs=128 count=1)
Na třetím až pátém řádku vidíme spuštění programu envdir – envdir upraví prostředí pro běh programu podle adresáře, který mu je předán jako parametr – zde ./env – a následně spustí program, který po tomto parametru následuje. Tímto programem je shell, který spouští envuidgid – envuidgid mění proměnné prostředí $UID a $GID, program tedy neběží pod rootem ale pod jiným systémovým uživatelem (dnscache). Stejně jako envdir i envuidgid spustí to, co je uvedeno za jeho parametrem.
S pozměneným prostředím a pod jiným uživatelem je spuštěn softlimit, což je program, který omezuje využívání zdrojů procesem – posledním parametrem je opět jméno programu, který má softlimit spustit. V našem případě je počet otevřených popisovačů souboru omezen na 250 a datový segment procesu na velikost uvedenou v proměnné prostředí DATALIMIT. softlimit již spouští samotný program dnscache.
Toto předpřipravené uspořádání nám nevyhovuje, protože envdir, envuidgid a softlimit jsou programy z kolekce Daemon Tools, kterou jsme neinstalovali. V principu nám nic nebrání ji doinstalovat, ale to není potřeba, protože runit nám poskytuje prostředky, jak dosáhnout téhož – jako náhradu programů envdir, envuidgid a softlimit nám nabízí jediný program chpst. Uvedené řádky tedy nahradíme a výsledná podoba souboru run je:
#!/bin/sh exec 2>&1 exec <seed exec chpst -e ./env /bin/sh -c ' exec chpst -U dnscache -o250 -d "$DATALIMIT" /usr/bin/dnscache '
Proč se chpst spouští dvakrát? Pokud bychom všechno chtěli vyřídit jedním příkazem:
exec chpst -e ./env -U dnscache -o250 -d "$DATALIMIT" /usr/bin/dnscache
nebude v době spuštění chpst nastavena proměnná prostředí DATALIMIT. Tu musíme nejprve nastavit prvním spuštěním chpst, v takto upraveném prostředí spustíme nový shell a v něm teprve bude DATALIMIT obsahovat potřebnou hodnotu.
chpst (stejně jako envdir) nastavuje proměnné prostředí tak, že prohledá zadaný adresář, podle každého souboru v něm vytvoří proměnnou prostředí (její jméno je stejné jako jméno souboru) a hodnotu této proměnné nastaví podle prvního řádku v souboru. Pokud před spuštěním chpst daná proměnná prostředí existuje, je změněna; pokud existuje, ale soubor odpovídajícího jména je prázdný, proměnná je zrušena. Pro dnscache se nastavují tyto proměnné:
a2x5l5:/etc/dnscache# ls env/ CACHESIZE DATALIMIT IP IPSEND ROOT
CACHESIZE obsahuje velikost cache, kterou bude dnscache používat. Velikost cache se za běhu nemění, přednastavená hodnota je 1000000. DATALIMIT omezuje velikost datového segmentu pro proces, výchozí hodnota je 24000000. IP obsahuje IP adresu, kterou jsme zadali při volání dnscache-conf, na této adrese dnscache naslouchá. V příkladu výše je uvedena adresa 0.0.0.0, což znamená, že dnscache bude naslouchat na všech síťových rozhraních.
IPSEND obsahuje IP adresu, ze které dnscache odesílá odchozí pakety. Pokud je nastavena na 0.0.0.0 (výchozí), použije se primární IP adresa. ROOT nastavuje kořenový adresář, do kterého se dnscache po startu uzavře. V našem případě je to /etc/dnscache/root.
Adresář /etc/dnscache/root obsahuje další konfiguraci dnscache v podadresářích ip a servers. Adresář ip obsahuje nastavení toho, odkud dnscache přijímá požadavky. Pokud máme dnscache pouze pro svůj stroj, bude tento adresář obsahovat soubor 127.0.0.1 (aby to bylo zřejmé – soubor se bude jmenovat 127.0.0.1, na obsahu nezáleží). Jestliže dnscache má sloužit i pro naši síť, vytvoříme navíc soubor, jehož jméno je síťová část IP adresy – například pro síť 192.168.253.0/24 to bude soubor 192.168.253 (jméno nesmí končit tečkou.) Nastavení provedená vytvořením/smazáním souboru se projevují bez restartu dnscache.
Zde stojí za to poznamenat, že toto nastavení v root/ip omezuje nastavení uvedené v proměnné prostředí IP. Pokud tedy budeme mít v IP 0.0.0.0, bude sice dnscache naslouchat na všech síťových rozhraních, ale na požadavky, které přijdou z adresy, která není povolena v /root/ip, nebude odpovídat. (Pokud tedy náš router má na rozhraní zapojeném do Internetu adresu například 1.2.3.4 a z 5.6.7.8 přijde nějaký požadavek, dnscache neodpoví, i když na daném rozhraní naslouchá.)
Druhý adresář v root je servers. V příkladu uvedeném na začátku celý proces překladu jména serveru na jeho IP adresu začínal dotazem na kořenové DNS servery. Jejich IP adresy jsou uloženy v servers/@, na každém řádku jedna IP adresa:
198.41.0.4 192.228.79.201 192.33.4.12 128.8.10.90 192.203.230.10 192.5.5.241 192.112.36.4 128.63.2.53 192.36.148.17 192.58.128.30 193.0.14.129 199.7.83.42 202.12.27.33
To je pro samotnou dnscache všechno, zbývá nám tedy prozkoumat pouze adresář /etc/dnscache/log, ve kterém je nastaveno logování; obsahuje adresář main a soubor run:
#!/bin/sh exec setuidgid dnslog multilog t ./main
V run vidíme dvě věci, které se nám nemusí líbit. První je, že se zde opět používají programy z Daemon Tools (setuidgid a multilog), a druhá, že se loguje do adresáře main, který máme v /etc. Vzhledem k tomu, že logovat chceme raději někam, kam logy patří, a Daemon Tools nahrazujeme Runitem, použijeme raději něco jako toto:
#!/bin/sh exec chpst -u dnslog svlogd -t /var/log/multilog/dnscache
Logování zajišťuje program svlogd spuštěný pod uživatelem dnslog. Parametr -t zajistí, že před každý vypisovaný řádek bude přidána časová značka TAI64N (tuto značku je do čitelné podoby možné konvertovat programem tai64nlocal – zde se závislosti na Daemon Tools nevyhneme). Pokud chcete raději čas (v UTC) logovat přímo v čitelné podobě, použijte -tt. Adresář /var/log/multilog/dnscache musíme vytvořit ručně a jako vlastníka nastavit dnslog, aby do něj svlogd mohl zapisovat. Konfigurace logování je uložena v souboru config přímo v adresáři, kam se loguje. Jednoduché nastavení je například toto:
a2x5l5:/var/log/multilog/dnscache# cat config s8388608 n2
Toto nastavení říká, že maximální velikost aktuálního logu (current) je 8 MB. Po dosažení této velikosti svlogd daný soubor přejmenuje („odrotuje“) a začne logovat do nového souboru. n2 určuje, že se mají uchovávat 2 staré soubory s logy. Pokud svlogd v adresáři po rotaci logu vidí víc než n starých logů, nejstarší smaže. svlogd podporuje i další nastavení, například pro automatickou rotaci logu v pravidelných intervalech, zpracování logů při rotaci a jiné, zájemci si mohou nastudovat v manuálové stránce.
Adresář main (/etc/dnscache/log/main) můžeme smazat.
Nyní máme vše připraveno, přesuneme se tedy do adresáře /etc/service a nastartujeme službu:
a2x5l5:/etc/service# ln -s /etc/dnscache .
Dáme runsvdir několik vteřin na to, aby si všimlo nového symbolického odkazu, a poté se přesvědčíme, že dnscache i logování běží:
a2x5l5:/etc/service# sv status dnscache run: dnscache: (pid 28913) 3s; run: log: (pid 28912) 3s
Ještě zbývá upravit /etc/resolv.conf na 127.0.0.1 na počítači, na kterém dnscache běží, případně na IP adresu routeru na počítačích v naší síti a tím jsme hotovi.
Druhá a závěrečná část tutoriálu popíše konfiguraci samotného DNS serveru (tinydns). Vše bude vysvětleno na příkladech, ve kterých jako figurant poslouží adresa abclinuxu.cz. Nakonec si předvedeme, jak v domácí nebo pracovní síti s pomocí tinydns vytvořit vlastní doménu nejvyšší úrovně a tu používat pro přístup k počítačům.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
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?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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!