DHCP - 1 (instalace a konfigurace serveru)

24. 8. 2006 | Vladimír Žalud | Sítě | 37145×

Co je to DHCP, co umí, jak funguje, k čemu se používá?

V rámci nové práce jsem se dostal k nastavování DHCP serveru na W2K3. Jelikož je to až nechutně jednoduché, zajímalo mě, jaká je situace na platformě GNU/Linux.

A myslím, že Linux z toho vyšel se ctí. Většina parametrů serveru od konsorcia ISC, tím se zde totiž budeme zabývat, je dostatečně rozumně přednastavená a pro rozběhnutí DHCP na jednodušší síti je potřeba zapsat jen pár řádek do souboru dhcpd.conf. Nehledě na to, že při složitější a komplexnější síti se jednoznačně projeví flexibilita a škálovatelnost konfigurace pomocí textového souboru a jazyka dhcpd.conf.

Co nás čeká

Nekladu si za cíl kompletní referenční příručku ani o DHCP, ani o implementaci od ISC. Chci se jen podělit o svoje zkušenosti a začínající v této problematice trochu nakopnout. Vlastní zkušenosti, opravy a upřesnění jsou samozřejmě vítány. V rámci možností proberu, co je vlastně DHCP zač, kde získat software na jeho zprovoznění, jak ho uvést do chodu a co tím získáme.

Co je to DHCP, co umí a jak funguje?

O čem je řeč?

DHCP je obecně uznávaný standard; celý název, který zní Dynamic Host Configuration Protocol, což se běžně překládá jako "protokol pro konfiguraci síťových hostitelů", napovídá, že 'umí' konfigurovat parametry TCP/IP jednotlivých klientů serveru. Je tedy nezávislý na použitém OS (pokud ho ten samozřejmě podporuje) a celý je definován a upřesňován několika dokumenty RFC (seznam je třeba na adrese http://www.ietf.org/iesg/1rfc_index.txt). Vychází z protokolu BootP, se kterým je zpětně kompatibilní a vylepšuje ho o mnoho nových a užitečných vlastností. Server DHCP můžeme tedy klidně nasadit i pro klienty protokolu BootP, ovšem připravujeme se tím o mnoho výhod, namátkou třeba o proklamovanou dynamičnost.

Dynamičnost v tomto případě znamená, že adresy a vůbec informace distribuované serverem DHCP klientům nejsou přidělovány staticky, napořád, ale jen na určitou stanovenou dobu. Po této době klient adresu vrátí, nebo obnoví (typicky po půli pronajaté doby). Umožňuje to ekonomicky hospodařit s adresním prostorem a usnadňuje to konfiguraci hlavně u větších sítí a mobilních zařízení.

Kromě IP adresy může DHCP server přidělovat například i masku sítě, implicitní bránu, DNS servery, jméno hostitele a domény, může hostitelům vnutit chování podle určitých norem, 'změnit' jeho MAC adresu, informovat ho o SMTP, POP, time a dalších serverech, zapnout, nebo vypnout IP forwarding, bezdiskovým stanicím určí cestu k bootovacímu obrazu, apod.

V případě potřeby samozřejmě můžeme pomocí DHCP nastavit určité stroje staticky, typické je to například pro počítače poskytující určité služby: web server, SMTP server, router apod. Usnadňuje se tak nejen přístup k samotným službám, ale i vzdálená konfiguraci jednotlivých serverů.

Jak vidno, zprovozněním serveru DHCP získáme silný nastroj pro centrální správu, a notně si tak ušetříme práci.

DHCP a DNS

Trochu jsem se teď otřel o relativní problém s DHCP. Jsou-li adresy přidělovány dynamicky a v podstatě nahodile, znesnadňuje to přesné určování klientů na síti, tedy vlastně znemožňuje provoz DNS. Tento problém řeší Dynamické DNS (DDNS), což je vlastně určitá koordinace mezi DHCP a DNS. V praxi - a v menších sítích zvlášť - ovšem klienti většinou služby neposkytují a servery, které služby nabízejí, se nakonfigurují staticky jak u DHCP, tak i u DNS. DNS ale poskytuje určité pohodlí, takže se k tomu v závěru článku ještě vrátím.

Tak to by bylo nastínění možností a teď si řekneme, jak to vlastně celé funguje.

Co se děje na síti

V určité fázi startu počítače se načítají síťová nastavení. Nejsou-li k dispozici a počítač má nastaveno získání těchto informací pomocí nějakého DHCP klienta, tak tento, protože většinou nemá absolutně žádné informace, pošle na omezenou všeobecnou vysílací adresu paket DHCPDISCOVER se svou identifikací (MAC adresa, jméno, ...) a případně známými údaji. Server odpoví paketem DHCPOFFER (a klidně i více pakety), klient si pak vybere odpovídající nastavení a odpoví pomocí DHCPREQUEST. Server vše potvrdí pomocí DHCPACK, nebo zamítne prostřednictvím DHCPNAK. No a po této proceduře může klidně počítač nastavení používat. Mimochodem, klient komunikuje na UDP portu 68 a server na portu 67, což je taky dědictví po protokolu BootP. Některým klientům se budeme později věnovat.

Pozorný čtenář si jistě všiml pojmu omezená všeobecná vysílací adresa. Kdo zná základy TCP/IP, ví, že to je adresa, která, podobně jako všesměrová adresa, dojde ke všem hostitelům v síti, ale je omezená tím, že se na směrovačích do jiných sítí tyto pakety zahazují. Co z toho plyne pro DHCP? No, samozřejmě to, že aby DHCP fungovalo, musí být přístupný DHCP server na každé podsíti zvlášť. To z různých důvodů nemusí být možné nebo ideální řešení, a proto se v případě Linuxu může použít nějaký předávací agent (relay agent). Těmto se dále budeme také věnovat. Obojí, jak klient, tak relay agent, je dostupné v balíčku od ISC.

Server DHCP od ISC

Proč zrovna DHCP od ISC? Jak ho získat a co dostaneme?

Protože je to suverénně nejrozšířenější software pro tuto službu na Linuxu a myslím, že pro Open Source obecně a asi i pro Unix/Unix-like vůbec (někde jsem v souvislosti s ISC DHCP četl o referenční implementaci pro Unix). Každopádně je to právě díky ISC kvalitně spravovaný projekt s minulostí i budoucností (od tohoto konsorcia pochází rovněž DNS server BIND), takže se nemusíme bát ho nasadit. O výhodách toho, že je ještě k tomuto všemu open source, se tady asi zmiňovat nemusím.

Aktuální verze je 3.0.4 a stáhnout se dá například odsud: http://ftp.isc.org/isc/dhcp/. Instalace je provedená známou trojkombinací configure, make, make install. Tu tady detailněji popisovat nebudu; jednak jsem ji nedělal a jednak to myslím přesahuje záběr tohoto článku. O kompilaci a instalaci programů je třeba seriál Nebojíme se kompilace, takže vás odkáži na něj. Nebo všeobecně k DHCP na fórum na webu ISC.

Jak už jsem psal, já sám jsem tento program nepřekládal a jste-li začátečník, pravděpodobně to taky nebudete potřebovat. Ve většině distribucí Linuxu je běžně obsažen nebo se dá lehce stáhnout jako binární balíček. Je možné, že to nebude nejnovější verze, ale používáte-li dostatečně mainstreamovou distribuci a pravidelně záplatujete, nemáte se čeho bát. Toto je nejjednodušší a pro začátečníka nejbezpečnější způsob instalace a správy.

Instalací serveru DHCP získáme samotný program dhcpd, konfigurační soubor dhcpd.conf a databázový soubor dhcpd.leases - bez těchto souborů se nám DHCP server nerozjede. Dále jsou tu manuálové stránky, v závislosti na distribuci rovněž init skripty, nastavení /etc/sysconfig a dhcrelay agenta, klient dhclient, skript dhclient-script, soubor dhclient.conf a v neposlední řadě také program omshell, který umožňuje, jestli jsem to správně pochopil, jakousi interaktivní komunikaci a manipulaci s programovým vybavením.

V závislosti na distributorovi mohou být tyto programy dodávány zvlášť; překladem ze zdrojových kódů získáme přibližně to, co jsem popsal výše. Přesné umístění souborů záleží na distribuci, případně typu instalace. U Fedora Core 5 je to adresář /etc/ pro konfigurační soubory, adresář /usr/sbin/ (/usr/bin/ pro omshell) pro spouštěcí soubory a soubor dhcpd.leases je v adresáři /var/lib/dhcpd/ - u ostatních dister to bude podobné.

Spuštění serveru

DHCP je samozřejmě služba a ta jako taková musí běžet jako daemon. Toho musíme nakonfigurovat a spustit manuálně nebo jako součást nějakého spouštěcího skriptu. Smysluplnější u serverů je ta druhá varianta, tak se u ní trochu zastavíme.

Konstruktivně ovlivnit chování programu můžeme v zásadě třemi způsoby:

• pomocí parametrů při startu serveru
• editací souboru dhcpd.conf
• použitím už zmiňovaného omshellu

Poslední variantu jsem nikdy nepoužil, editaci dhcpd.conf si nechám na konec, takže se podíváme na start serveru. Start serveru je vlastně normální spuštění programu s parametry. Většina parametrů má ladící nebo testovací význam, pro normální provoz jsou většinou zbytečné.

Syntaxe spuštění dhcpd je:

dhcpd [-p port] [-f] [-d] [-q] [-t|-T] [-cf soubor] [-lf soubor] [-tf soubor] [-play soubor] seznam rozhraní

Význam jednotlivých přepínačů:

-p určuje alternativní port
-f spouští server na popředí
-d posílá chybové hlášení na stderr místo implicitního syslogu
-q nevypíše startovací hlášku
-t otestuje syntaxi konfiguračního souboru
-T otestuje databázový soubor
-cf alternativní konfigurační soubor
-lf alternativní databázový soubor
-tf,-play napomáhají při nalézání chyb vytvořením souboru s chybovým výstupem
seznam rozhraní určuje, pro která rozhraní má dhcpd naslouchat jako služba; máme-li více síťovek a na každé jednu podsíť, musíme to DHCP serveru říct.

Jak jsem už psal, měnit přepínače má cenu jen při testování a ladění konfigurace, případně pro zjišťování a odstraňování chyb apod. Samotné přidávání argumentů může být distribuci od distribuce rozdílné.

Například u distribucí založených na Red Hat se argumenty spouštění zapisují do /etc/sysconfig/dhcpd. Je to systémovější a také pohodlnější, protože soubory sysconfig se neaktualizují. Dále musíme systému říct, ve kterých runlevelech ho chceme spouštět (například programem /sbin/chkconfig), a nakonec ho spustit (restart, /sbin/service ručně). No a samozřejmě povolit na firewallu potřebné porty.

Naproti tomu u takového Slackware budeme muset měnit samotný spouštěcí skript (respektive ho vytvořit nebo celou konfiguraci někam dopsat). Spouštění zajistíme editací /etc/rc.d/rcX.d a restartováním runlevelu X, kde X je označení runlevelu, ve kterém chceme, aby server běžel (pravděpodobně rc.M), nebo spuštěním skriptu.

V čem je síla serveru od ISC

Srdcem samotného serveru DHCP je soubor dhcpd.conf. Dá se říct, že je tvořen volbami a jejich hodnotami, které mohou být vymezené pro určité deklarované prvky (jednotliví hostitelé, síť, apod.) nebo celý server.

V případě globálních parametrů se jednoduše zapíše požadovaná volba spolu s parametrem, někdy se pro něj použijí uvozovky, někdy je volba uvozena slovem option na samostatný nezakomentovaný řádek a zakončí se středníkem. Například:

option domain-name "foo.org";

Jestliže volbu uvozuje nějaká deklarace je syntaxe následující:

  deklarace případný-identifikátor {
      volba1;
      volba2;
      ...;}

Například:

   host tux {
      fixed-address 10.0.0.20;}

První příklad nám určil doménové jméno pro naši sít, druhý určil hostiteli tux pevnou IP adresu. Voleb v rámci jedné deklarace může být i více, deklarace se také mohou skládat z více prvků, kupříkladu dvojice subnet - netmask. Jazyk dhcpd.conf dokonce umožňuje vnořenou deklaraci v rámci jiné deklarace. Zní to trochu zmateně, ale je asi jasné, o co jde. Máme definovanou síť a v jejím rámci chceme pro některé stroje definovat pevnou IP adresu; do souboru dhcpd.conf zapíšeme něco jako:

 subnet 10.0.0.0 netmask 255.255.255.0 {
     range 10.0.0.10 10.0.0.30;
      host web {
         fixed-address 10.0.0.1;} 
    } 

V rámci sítě si definujeme rozsah adres (range) a pro hostitele web zajistíme pevnou adresu 10.0.0.1. Jak je zřejmé, volba range udává rozsah adres určených k propůjčování pomocí DHCP. Je-li deklarace range následováno přepínačem dynamic-bootp znamená to, že rozsah adres je určen pro klienty protokolu BOOTP.

Možnosti dhcpd.conf jsou nepřeberné, spousta voleb a deklarací je hodně úzce použitelná, jiné jsou naopak dost obecné. A právě tady je vidět výhoda a škálovatelnost proti W2K3 a grafickým udělátkům vůbec. Já se soustředím jen na ty základní volby, které nejspíš využijete i vy, a které nám ukáží možnosti DHCP na Linuxu.

Ještě upozorňuji, že způsob zápisu je v podstatě na vás; můžete si konfigurák rozčlenit na volby globální, volby sítě a volby hostitelů. Stejně tak můžete všechno - kromě globálních voleb - naplácat do jediné deklarace, nebo to řešit jinak. Když budete dodržovat syntaxi, je to jen a jen vaše věc (i když ta orientace v souboru potom může být všelijaká). Dobrý začátek je podívat se třeba na /usr/share/doc/dhcp-verze/dhcpd.conf.sample, kde je příklad konfiguráku, a ten můžete poupravit a použít.

Jak je to s deklaracemi

Takže se vraťme k jednotlivým deklaracím a volbám. Jen znovu opakuji, že nejsou kompletní - pro přesnější význam a více voleb se obraťte na manuálové stránky dhcpd.conf. Začneme deklaracemi:

group id;

Jak už z názvu plyne, tato deklarace umožňuje seskupit určité parametry a aplikovat je na vybranou skupinu hostitelů, může to ušetřit práci s jednotlivým vypisováním; id je v tomoto případě identifikace pro skupinu.

host id;

O tomto už byla řeč: oproti group se volby v této deklaraci budou týkat jen počítače definovaného identifikátorem id.

subnet IP adresa netmask IP adresa;

Definuje podsíť, které se následující volby týkají. Musí být tedy samozřejmě následována maskou sítě. Celá syntaxe je popsána výše.

shared-network id;

Umožňuje sdílet na jedné fyzické síti (rozhraní) různé podsítě.

range [dynamic-bootp] počáteční IP [koncová IP];

Tuto deklaraci jsem už snad dostatečně probral, jen si všimněte, že koncová IP je nepovinná.

pool;

Slouží k rozdělení parametrů pro různé segmenty stejné sítě, v manuálu je uveden příklad jednoho poolu pro známé klienty a jednoho pro neznámé klienty.

Jednotlivé volby

Deklarace nám vlastně pomohou nadefinovat určité logické celky, které můžeme posléze jemněji ladit a přizpůsobovat vlastním potřebám. Pomohou nám k tomu kupříkladu i následující volby:

authoritative;

Je to povinná volba; a je dobré vědět, že server DHCP by měl být vždy autoritativní. Opakem této volby je not autoritative;.

max-lease-time sekundy;

Maximální možná délka doby pronájmu adresy, bez ohledu na požadavky klienta v sekundách (ve výchozím nastavení server respektuje všechny klientské požadavky).

default-lease-time sekundy;

Výchozí doba trvání pronájmu adresy.

filename "/cesta/k/souboru/;"

Cesta k bootovacímu souboru pro bezdiskové stanice. Tato volba se často kombinuje s parametrem next-server, který klientovi řekne, ze kterého serveru má tyto zaváděcí údaje získat.

server-name "jméno/IP";

Definuje jméno serveru, na kterém se vzdáleně zavádí systém.

allow [denny] booting;

Povoluje/zakazuje konfigurační požadavky klienta.

server-identifier "ip adresa;"

Definuje IP adresu serveru posílaného klentům.

hardware [typ] hw adresa;

Určuje typ linkové vrstvy (nejčastěji ethernet) a hardwarovou adresu (MAC adresu).

fixed-address adresa;

Přiděluje adresu nebo skupinu adres klientovi.

option host-name "jméno;"

Jméno pro klienta.

option domain-name "jméno";

Doménové jméno pro klienta.

option broadcast-address adresa;

Určuje broadcast adresu.

option domain-name-servers jméno-serveru;

Označuje DNS server (servery).

option routers adresa;

Adresa routeru.

option lpr-servers adresa;

Tato volba udává tiskový server.

option smtp-servers adresa;

Tato zase poštovní server.

option subnet-mask maska;

Maska hostitele.

ddns-update-style ad-hoc|inerim|none;

Tento parametr musí být v konfiguračním souboru vždy přítomný. Říká, jestli je řešena synchronizace s DNS serverem.

always-reply-rfc1048;

Komunikuje s klienty podle RFC1048, týká se klientů BootP.

use-host-decl-names příznak

Volba vhodná do direktivy host. Říká DHCP, aby posílal s TCP/IP údaji i hostitelský název počítače.

Příště

Zjišťování informací o běžícím DHCP serveru, využití a konfigurace dynamického DNS (DNS) a spuštění relay agenta a klienta s popisem nejdůležitějších parametrů.

       

Komentáře

[peter]

výborný článok

[XMurder]

souhlas, výborný článek. dávám 3.

[tezkatlipoka]

Nic super obevneho jsem nenasel, ale to bude dano asi tim ze dhcpd je opravdu jednoduche, a na zakladni rozchozeni primitivni. Ale tesim se na dalsi pokracovani, tedy na DDNS. Na to jsem totiz daval nedavno tady na ABC dotaz, a stale to me to zajima. Jak donutit, aby zavedl DHCP zaznam do DNS i pro klienty s fixed-address, coz se, podle me nejen u me, nedeje. Ono to sice urcitou logiku ma, fixni zaznam v dhcp = fixni zaznam v dns, ale urcite to jde nejak obejit.

[zvovka]

Tak zrovna toto v dalším díle není, ovšem řeší to volba update-static-leases a flaginterim u DDNS-update-style. Normálně se do dhcpd.leases statičtí klienti nezaznamenávají a DNS se synchronizuje právě z toho leases souboru. Jinak volba interim se nedoporučuje;-p. Jo a už jsem to psel i redakci, ale popletli jste mi jméno, jmenuji se Žalud, né Žaludek.

[tezkatlipoka]

dve pismenka a co to udela se jmenem.

[tezkatlipoka]

interim se nedoporucuje? no ja si u ad-hoc zase precetl ze je deprecated, tak kdyz ani interim ani ad-hoc, tak uz zbyva jen to none.

[camlost]

zvláštní, toho jsem si nikdy nevšiml. naopak zatím žiju v domnění, že to funguje celkem bez problémů. ale zrovna po ruce nemám žádný linux, takže to jen tak neověřím.

[tezkatlipoka]

tak ta info od p. Žaluda (-dka) je presne, na tu volbu nenajdete skoro zadne odkazy, ale prec jen jsem nasel ze je to volba od ISC nedoporucovana, protoze DHCP pak nema poradnej zpusob jak rict aby se to vymazalo.

[zvovka]

No já jsem to našel v manuálových stránkách, ale kdo by to tam hledal že.... Taky mě to funguje bez problémů, záleží právě na tom jak jedou ti statičtí klienti, ve firmách kde jede všechno na jednom serveru, což je asi většina malých firem, je to dost bezpředmětný problém.

[tezkatlipoka]

v manualovych strankach hledaji jen zkrachovalci

Po pravde jediny duvod fixnich adres ktery mam je squid, ale i z jineho duvodu nez je tento (treba proto ze ip dnes umi zmenit kazdy, s mac je to tezsi) asi opustim s fixni IP, a prelozim squid s podporou ACL MAC.

PS jestli jsem pochopil tak tu volbu nekde pouzivas (drze tykam), zkusenosti z chodu jsou, ze to nedela problemy?

[zvovka]

No jede mi to jen doma, kde jsou slušní useři a proxy nemám.

Ohledně toho 'zaručení' adres, možná by stačilo identifikovat klienty nějakým pofidérním řetězcem, u klienta: send dhcp-client-identifier "řetězec" , ve volbě host: option dhcp-client-identifier "řetězec". Ještě třeba zakázat duplikaci a cizí klienty deny duplicate a deny unknown-clients.

No ale nevím do jaké míry to řeší tvůj (takže jsme si potykali) problém, identifikace pomocí MAC adres bude asi lepší.

[tezkatlipoka]

netusim jak donutit DHCP clienta na Windows aby posilal nejaky identifikacni retezec.

[zvovka]

Hned jak jsem to dopsal tak mi to došlo, já zase uvažuju jen v Linuxu (to je blbá vlastnost). S Linuxem by ten problém asi tak palčivý nebyl. Tak sory za OT.

Kolega mi teď tvrdil že Windows posílají s žádostí jen MAC adresu a s Active Directory i více, ale to už je definitivně OT.

Díky všem za pozitivní i slušné negativní ohlasy.

[melkors]

Sakra, proc to tady nebylo pred ctyrmi mesici, kdy mi v jedne firme teprve po instalaci FW prozradili, ze chteji, aby se na FW take provozovalo DHCP? Jsem se s tim tenkrat musel poprat sam (s netrpelivym sefem dychajicim za krk).

[neaktivni]

Super clanek, bude se hodit

[jesta.net]

Protože je to suverénně nejrozšířenější software pro tuto službu na Linuxu a myslím, že pro Open Source obecně a asi i pro Unix/Unix-like vůbec (někde jsem v souvislosti s ISC DHCP četl o referenční implementaci pro Unix). Každopádně je to právě díky ISC kvalitně spravovaný projekt s minulostí i budoucností (od tohoto konsorcia pochází rovněž DNS server BIND), takže se nemusíme bát ho nasadit.

Tak s timhle tvrzenim bych byl hoooodne opatrnej. Windows jsou taky suverene nejrozsirenejsi, a nerek bych ze to je zrovna vyhoda. V homogenosti neni sila (viz. viry pro win)

Zrovna tak BIND - ja osobne ho povazuju za takovej DNS-SENDMAIL, t.j. jeden velkej chybovej balik kterej jde naprosto proti UN*X koncepsi malejch programku ktery umej jedno, ale dobre. Je pravda ze BIND ma oproti SENDMAIL docela citelnej konfigurak, kterej se da naucit za jedno odpoledne. (co se tyce chybovosti - ted je sice "stabilni" a "bezchybovej", ale to rikali i o verzi 5 . Neobjeveni chyby neni dukaz nepritomnosti chyby. )

Moje pripominka se tyka JENOM tvojeho tvrzeni, proti ISC DHCPD nemam skoro nic - snad jenom to ze DDNS umi nejspis jenom proti BIND (coz je logicky, kamaradi ze stejny laborky), takze my, co pouzivame konkurencni dns server (DJBDNS), to musime resi jinak...

[zvovka]

DJBDNS versus ISC DHCP třeba tady. Jinak za tím co jsem napsal si stojím, je to kvalitní a dobře spravovaný software, tím že je tak rozšířený je i dobře dokumentovaný (oficiální doc, komunita, linuxový distributoři apod.) a pro začátečníka (tím i pro mě) vhodný. Navíc já jsem psal o DHCP, né o DNS. To že je skoro v každé distribuci není můj problém, ale nemyslím si že by to bylo vinou nějakého spiknutí, nebo dravého marketingu.., od alternativ já nikoho neodrazuju.

[Michal Kubeček]

Zrovna tak BIND - ja osobne ho povazuju za takovej DNS-SENDMAIL, t.j. jeden velkej chybovej balik kterej jde naprosto proti UN*X koncepsi malejch programku ktery umej jedno, ale dobre.

Vynechte, prosím, FUDy, opravdu toho není zapotřebí.

co se tyce chybovosti - ted je sice "stabilni" a "bezchybovej", ale to rikali i o verzi 5

Vy máte nějaké zkušenosti s BINDem verze 5? Tak to jste asi jediný na světě, protože ani ISC o její existenci neví… :-)

[tezkatlipoka]

asi teoretickej predpoklad, kdyz je verze 9, byli asi i nejake predtim.

[Michal Kubeček]

Byly - ale 5 zrovna ne. A BIND verze 8 není oproti verzi 4 nová verze, ale spíš nový program.

[Filip Jirsák]

To já proti ISC DHCPD něco mám, na žebříčku nejneoblíbenějších programů, za který ale není náhrada, je u mne na prvním místě (Ale Quagga silně dotahuje.) Aspoň že nepadá… Asi nejhorší je to, že míchá konfiguraci a data do jednoho souboru. Tenhle (konfigurační) soubor pak navíc neumí znovu načíst za běhu, je nutné démona restartovat. To, že při chybě v konfiguračním souboru tiše odejde ze scény, místo aby to překousl, vynadal do logu ale běžel dál, je už jen taková třešnička na dortu. Taky je nutné povinně nakonfigurovat DDNS – u DHCP serveru naprosto logické, že…

[tezkatlipoka]

PANE!!!! mate pravdu, configurak zvlast a data zvlast by tomu sluselo. A reload taky.

[ivan]

To co pisete neni docela pravda.

1. Existuje patch, ktery umozni ukladat konfiguraci do LDAPu V budoucich verzich je slibene, ze to bude dhcpd umet nativne podobne jako bind9

2. Kouknete se na na omapi rozhrani a prikaz omshell. Provozuji DHCP server pro stovky klientu a zaznamy pridavam za behu serveru prave pres omapi rozhrani.

Me zase napriklad na ISC DHCPD vadi, ze si master a slave mezi sebou nevymenuji informace o fixed hostech. Musite je zadavat duplicitne na oba servery. Misto toho aby se slave serveru reklo "hele ty jsi slave" vem si veskerou konfiguraci od mastera, tak musite udrzovat dva podobny, ale ne uplne stejny konfiguraky na dvou serverech.

[Filip Jirsák]

To jsem rád, že už se v tomto směru něco děje. I když je to stále ještě dost daleko od toho, že bude mít dhcpd server interface a přes knihovny bude umět data načítat z textového souboru, SQL databáze, LDAP apod.

Ty úpravy přes omapi se promítnou zpět i do konfiguračního souboru? Nebo jak je zajištěno, aby se neztratily během restartu serveru?

[ivan]

Ty zmeny se ukladaji do souboru dhcpd.leases. Maji stejnou syntaxi jako v konfiguraku. Akorat je tam navic slovo "dynamic;" dhcpd univtr obsahuje jednu hash tabulku o velikosti cca 9000 zaznamu. V te hash tabulce jsou ulozeny vsechny "objekty" konfigurace, "network, pool, fixed-host, lease" a pomoci omapi rozhrani muzete, tyhle objekty pridavat, cist, modifikovat a odebirat. Bohuzel to ale neumi uplne vsechno, napriklad nemuzete pres omapi rozhrani pridat zaznam fixed-host s vendor specific options.

Jinak ten patch roste tady. Rozchozeni je trochu komplikovanejsi, ale pouzivam to na jedne mensi instalaci uz dele nez rok a zatim bez problemu.

[Ondrej 'SanTiago' Zajicek]

> (Ale Quagga silně dotahuje.)

Nezkousel jste BIRD?

[Filip Jirsák]

Díky za tip, ta sestava autorů vypadá slibně, vyzkouším to. Mimochodem, ať to nemusí někdo další hledat, adresa projektu je bird.network.cz.

[Dan Ohnesorg]

Bird jsme provozvali asi pul roku bez problemu, bohuzel neumi IPv6 na OSPF, takze jsme museli jit do quaggy.

[Peto]

Neslo by spracovat problematiku DHCP a DNS krmeneho cez LDAP? Uz ma prestava bavit zakazdym aktualizovat vsetky konfiguraky vzdy ked treba pridat do siete novy pocitac, a restartovat sluzby.

Mame fungujucu LDAP domenu a idealne by bolo, keby si DHCP aj DNS bralo informacie odtial.

[hynx]

dakujem za tento clanok, akurat toto teraz potrebujem

[Miloš]

Nemůžu souhlasit s vysvětlením volby authoritative; - s touto volbou se řeší různé situace v případě výskytu více DHCP serverů v jedné síti.
V takové situaci, si klient vezme IP od "authoritative" DHCP serveru, když tam takový neni, vezme jí i od "non authoritative".

Další drobnost je že instalaci ze zdrojáků bych nedoporučil začátečníkovi, ale ani pokročilému (leda že by potřeboval nějakou novou funkci, ale i to lze jinak).

No když už máme ten článek pro začátečníky, tak by bylo super tam hodit nejmenší fungující konfigurák, aby bylo na čem stavět . Abych teda jenom nekecal, ...

authoritative;
server-identifier 10.10.4.2;
default-lease-time 50400;
max-lease-time 50400;
ddns-update-style none;

option domain-name "muj-intranet.domena.cz";
option domain-name-servers 10.10.4.2;

subnet 10.10.4.0 netmask 255.255.255.0
{
 option routers 10.10.4.1;
 option subnet-mask 255.255.255.0;
 option broadcast-address 10.10.4.255;
 range 10.10.4.129 10.10.4.254 ;
}

host kopirka
{
 option host-name "kopirka";
 hardware ethernet 00:80:77:7e:39:44;
 fixed-address 10.10.4.8;
}

[zvovka]

Ad authoritative;: měl jsem napsat, že server by měl být autoritativní, protože je-li neautoritativní nechová se korektně třeba ke klientům s neskončenou zápůjčkou a že not autoritativ; je volba implicitní.

K tomu konfiguráku: už se mi tam zdálo toho kódu moc, tak jsem dal jen odkaz na sample soubor, ale asi tam opravdu měl být, ten váš je dobrý.

[J]

Ciste nahodou, nemela by deklarace hosta byt uvnitr subnetu ktery pouziva ? A taky mam pocit, ze option host-name je ponekud nadbytecny, dhcp umi pouzit a poslat primo polozku z host.

[Radek Hladik]

Upozornil bych na skvělý dnsmasq, který slouží jako DNS forwarder, ale umí dělat i DHCP server. Pro malé sítě je to ideální spojení (fuj, to zní jak z ňáký reklamy ), protože spolehlivě funguje, umí nabízet záznamy z /etc/hosts, když někomu přes DHCP přidělí adresu, tak si jí automaticky zařadí do DNS, umí všechny možný nastavení fixních nastavení,...

Radek

[MaT]

Přidávám se k doporučení. Na jedné staré 486, co mi funguje jako router, spokojeně používám dnsmasq už několik let...

[Michal Hocko]

Taktiez pouzivam uz vyse roka dnsmasq a nemal som vobec ziadne problemy. Ide sice iba o domacu siet, v ktorej je par pocitacov. Pametam si, ze ked som siet konfigroval, tak ma dhcpd dost vydesilo zlozitostou konfiguraku. Pre cloveka, ktory ho nikdy nevidel moze pripadat dost zlozito. Ak to porovnam s dnsmasq, tak tam som bol schopny po precitani konfiguraku a za/od komentovani niektorych riadkov uz iba /etc/init.f/dnsmasq start a svistal som.

Proti dhcpd samozrejme nic nemam. Potom, ako som videl niektore fungujuce konfiguracie, ktore obsahovali uz len pridelovacie pravidla, to vyzeralo tiez jednoducho (takze priliz vela volieb moze byt tiez na skodu a suhlasim, ze to ide tak trochu proti *NUX logike - vela malych specifickych programov).

[pasmen]

Dobra volba je option static-routes net gateway. Pokud mate vice VPNek a chcete, aby na sebe klienti videli, tak se to hodi. Jde to udelat rucne, ale...