Hogyan - BIND reconfigure

Linux-haladó

hello

Tud valaki megoldást arra hogy a named process újraolvassa a named.conf fájlt újraindítás nélkül és ne csak a zónákat?
Próbálkoztam az 'rndc reconfig' és 'rndc reload' parancsal de ezek hatástalanok akkor hogy az options{...} blokkban történik változás.
Ahhoz eddig mindig újra kellett indítani a named processzt amit most szeretnék elkerülni.

Szóval ismer valaki valamit, trükköt, 'varázslatot' :) amivel rálehet venni hogy újratöltse a config fáljt?
Olyasmi kéne mint a 'squid -k reconfig'.
Kutattam a neten de az rndc reconfigure túl nem találtam mást.

u.i.
Például ha egy 'empty-zones-enable no;' sort hozzáadunk a options{...} blokhozz az újraindításig nem jut érvényre :(

Előre is köszönöm a válaszokat.

  • 4742 megtekintés

( Zahy v | 2014. 01. 28., k – 10:33 )

Nincs véletlenül bekapcsolva a chroot-olás annál a bindnál? Mert ugye akkor a named.boot-ot (nojó, named.conf-ot) is csak a chroot könyvtárból tudja kiolvasni :-)

( stra | 2014. 01. 28., k – 10:48 )

man named:
SIGNALS
    SIGHUP
        Force a reload of the server.

tehát: 

# kill -HUP $(pidof named)

De Zahy iránya lesz a jó, mert az rndc reconfig alapesetben működőképes az options változása esetén is.

( jupiter2005ster v | 2014. 01. 28., k – 15:38 )

+1 valóban chrootolva van.

A kill HUP pid alias reload fura, mert nem tolta be a chroot környzetbe. ha szerkesztettem a chroot környezetben hogy ugyan úgy nézzen ki mint a 'nem chroot' környezetben, úgy már oké volt.

--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

???

Tudtommal a named processz az, akinek fel kene olvasni a named.conf nevu konfig fajlt, es nem az rndc-nek. De ha a named chrootolva van, akkor nem nagyon lathatja az eredetit. Ezen nem valtoztat az, hogy a vezerlo csatornan az rndc szolni tud - leven nem azt mondja, hogy X opcio valtozott, hanem azt, hogy olvasd ujra a konfigot (hatha megvaltozott az X opcio). Eleve az rndc nem olvashat konfigot (*), hisz egyaltalan nem biztos, hogy azon a gepen futtatom, mint amelyik gepen levo named-et piszkalom vele (meg a neve is jelzi: Remote NameD Control - vagy valami hasonlo)

(olvas konfigot, mert van sajatja: rndc.conf, de annak nem sok koze van a named.conf-hoz)

Szerintem abból származhat a félreértés, hogy quash szerint chroot paranccsal indul a bind, úgy kerül a megfelelő környezetbe...

Magyarán, hogy nem találkozott még a -t opcióval -> ha chroot-tal indítom, akkor nem lát mást konfigot már induláskor sem, csak a saját kis környezetéhez tartozót, míg ha a -t opcióval tolom át más könyvtár alá, akkor induláskor még eléri a /etc-t, de miután elindult, már nem.
(persze csak tipp)