PowerDNS & LDAP

Web, mail, IRC, IM, hálózatok

Sziasztok,

Azt hiszem elkelne egy kis segitseg sracok. :-)

Feltettem az egyik Gentoo-s szerveremre egy PowerDNS-t es LDAP backendet valasztottam hozza. Mindketto ugyanazon a gepen van. Az LDAP termeszetesen fel van toltve - a migrationtools altal migralt adatokkal, - ill. a struktura hozza lett igazitva a sajat dolgaimhoz.

Hiba nelkul elindul a PowerDNS, de nem oldja fel a cimeket. Bekapcsoltam a loggolast, de nem hoz letre fajlt sehol, viszont a process be van toltve a memoriaba.

Probaltam letrehozni egy logot egy fix konyvtarba, de nem jon letre. Nem sok koze van hozza, de ami meg erdekes, hogy pdns jogosultsagokkal inditom a process-t - amint az alabb lathato - de ennek ellenere root-kent indul.

# cat /etc/powerdns/pdns.conf
cache-ttl=60
config-dir=/etc/powerdns
daemon=yes
default-soa-name=mydomain.org
disable-tcp=yes
distributor-threads=1
launch=ldap
ldap-host=127.0.0.1:389
ldap-starttls=no
ldap-basedn=ou=dns,ou=hosts,ou=network,ou=system,dc=mydomain,dc=org
ldap-binddn=ou=dns,ou=hosts,ou=network,ou=system,dc=mydomain,dc=org
ldap-secret=ldapjelszo
ldap-method=tree
local-address=10.0.0.2
local-port=53
logfile=pdns.log
loglevel=4
master=yes
setgid=pdns
setuid=pdns
socket-dir=/var/run

Tudna valaki adni egy tampontot, hogy merre lehetne elindulni?

Koszi elore is. :-)

  • 2646 megtekintés

( cstamas | 2006. 06. 20., k – 21:50 )

Ha ezt akarod debugolni akkor állítsd be, hogy ne fork-oljon a powerdns és "strace -f powerdns -kapcsolók" indítsd és nézd, hol látsz gyanúsat.

Az ldap logjait is érdemes lehet tanulmányozni.

Én egyébként tinydns-t használnék, és egy programmal generálnám a data fájlt hozzá ldap -ból.

Nem kell letiltani a forkot.

egyrészt loglevel=8 is sokat segít, másrészt (emlékeim szerint) az init-script is tud infot szolgáltatni futo processzről, valamint ha nem daemon módban akarod indítani, de szeretnéd parancssorból debuggolni, akkor /etc/init.d/pdns-ize monitor, és az is elég bőbeszédű.
(strace tud futó processzt is figyelni: strace -p $PID)

a.

"Ha ezt akarod debugolni akkor állítsd be, hogy ne fork-oljon a powerdns és "strace -f powerdns -kapcsolók" indítsd és nézd, hol látsz gyanúsat."

Koszi, kozben szetbuhertam egy-ket dolgot es elinditottam a powerdns-t nem-demonkent parancssorbol, parameterekkel. Az rogton kiderult mar az elejen, hogy be sem tudott jelentkezni az LDAP-ba, mivel az "ldap-binddn=cn=Manager,dc=mydomain,dc=org" lenne a helyes ertek. Ez a gluon.hu-n is rosszul van kint. (majd jelzek a szerzonek)

# pdns_server --daemon=no --launch=ldap --ldap-basedn=ou=dns,ou=hosts,ou=network,ou=system,dc=mydomain,dc=org --ldap-binddn=cn=Manager,dc=mydomain,dc=org --ldap-method=tree --ldap-secret=password
Jun 20 19:03:08 This is a standalone pdns
Jun 20 19:03:08 Listening on controlsocket in '/var/run/pdns.controlsocket'
Jun 20 19:03:08 UDP server bound to 10.0.0.2:53
Jun 20 19:03:08 PowerDNS 2.9.20 (C) 2001-2006 PowerDNS.COM BV (Jun 15 2006, 22:54:43, gcc 4.1.1 (Gentoo 4.1.1)) starting up
Jun 20 19:03:08 PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2.
Jun 20 19:03:08 About to create 1 backend threads for UDP

Viszont tovabbra sincs nevfeloldas. Miutan elindult a PowerDNS, a kliensek hozzafordulnak, de nem tortenik meg a nevfeloldas.

Jun 20 22:38:27 Not authoritative for 'proxy.mydomain.org', sending servfail to 10.0.0.13 (recursion was desired)

"Én egyébként tinydns-t használnék, és egy programmal generálnám a data fájlt hozzá ldap -ból."
Igazabol pont ezt szeretnem elkerulni. Nincsen sok kliens amit ki kellene szolgalnia, viszont szeretnem az osszes konfiguraciot egyben tartani, hogy ha pl. uj gep jon, vagy barmit valtoztatnom kell, esetleg egy aldomenben melyebbre kell tennem, akkor ne kelljen vacakolni 15 fele kulonbozo formatummal, meg scriptekkel amik generalnak ezt-azt. :-) Most van idom vegigjarni, menet kozben mar nem lesz.

"Az ldap logjait is érdemes lehet tanulmányozni."
Fu, ezt jo, hogy mondod, meg fogom nezni. :-)

---------------------
Ригидус а бетегадьбол

hello,

Viszont tovabbra sincs nevfeloldas.
saját (auth) vagy külső domainre nincs feloldás? A kérés alapján (még ha csak példa is) azt gondolnám, h ez saját domain, de a PDNS szerint nem, mivel recursort akar használni, ami a konfig alapján nincs beállítva. (recursor was desired)

A PDNS eljut az LDAP-ig?

a.

"A PDNS eljut az LDAP-ig?"
Igen, koszi. :-)
A kapcsolat letrejon es keres is benne. Nem talaltam az ldap debugjaban hibara utalo jelet, de meg mindig ugyanazt dobalja vissza a pdns.

"A kérés alapján (még ha csak példa is) azt gondolnám, h ez saját domain, de a PDNS szerint nem, mivel recursort akar használni, ami a konfig alapján nincs beállítva."
1. Tehat nem is a belso cimek kozott keres?
2. Ez azt jelenti, hogy ha kulso cimeket is szeretnek feloldani, akkor kell hozza recursor is?

---------------------
Ригидус а бетегадьбол

hello,

Igen, koszi. :-)
jólvanna' :), csak kérdeztem.

Tehat nem is a belso cimek kozott keres?
ezt nem értem, mire gondolsz.

...hogy ha kulso cimeket is szeretnek feloldani, akkor kell hozza recursor is?
ha a klienseknek teljes DNS szolgáltatást szeretnél (pl: intranet DNS szerver), akkor igen, kell recursor is.

Azért lehet zavaró, mert a bind-nél ez ugyebár egybe van gyúrva, a konfigban szabályozhatod, de itt külön program van rá, ami lehet másik DNS szerver is. Maga a PDNS nem végez rekurzív kérést, csak saját adatbázis alapján a neki dedikált domainekre válaszol.

És ez a Te bajod is: a kért domain-t nem ismeri fel.

(ne kérdezd, h miért, ldap-pt még nem használtam hozzá, SQL-t nemrég löttem össze, azzal megy jól)

a.

>> Tehat nem is a belso cimek kozott keres?
> ezt nem értem, mire gondolsz.
Arra, hogy a belso zona (mydomain.org) ala vannak felveve a host nevek es a hozzajuk tartozo aliasok. Ha egy belso cimet elkezdek tallozni, akkor a fenti hibauzenetet kapom. Tehat ezek szerint nem is keres az adott zonaban?

Maga a PDNS nem végez rekurzív kérést, csak saját adatbázis alapján a neki dedikált domainekre válaszol.
Hat nem vagyok egy DNS-guru, ugyhogy picit most elvesztettem a fonalat. :-/
Az mar vilagos, hogy a recursor kell ahhoz, hogy zonan kivul keressen, de pl tud-e olyat, hogy osszemerge-dzsel ket azonos nevu kulso-belso zonat? Mondjuk van egy mydomain.org zona a benti dns szerveren, amin a belso cimek vannak es belulrol akarom csak latni oket, ill. van egy szinten mydomain.org kivul egy http,ftp,mail szerveren amit pedig barhonnet szeretnek elerni, viszont nem akarom kulon ezert felvinni az osszes kinti zonat is a bentire. (mert eddig csak igy ment)

Koszi ismet. :-)

---------------------
Ригидус а бетегадьбол

Tehat ezek szerint nem is keres az adott zonaban?
nagyon úgy néz ki.

Ha használtál BIND-ot, akkor ott volt ugyebár a named.conf(.*), ami leírta, mely zónákért felel maga a szerver, ill voltak a zóna fileok, amik leírták a zónát.
Én MySQL backend-el használom a PDNS-t, ott van két releváns tábla: a domains, és a records, értelemszerűen a domains-ben vannak a domainek felsorolva, és ezek azonosítói kulcsok a records-ban az egyes rekordokhoz. Hogy LDAP-ban hogy megy, ezt nem tudom.

de pl tud-e olyat, hogy osszemerge-dzsel ket azonos nevu kulso-belso zonat?
Speciel a PDNS tud, kis trükivel. Van egy speciális backend, a PIPE, ami egy nagyon egyszerű protokollra épül, és te is írhatsz saját backend kezelő progit. Ebben megadhatod, hogy bizonyos kritériumok alapján honnan kérdezzen a backended (persze a lekérdezéseket már neked kell megírnod, elveszted a kész modulokat)
Van példa a doksiban erre vonatkozólag.

viszont nem akarom kulon ezert felvinni az osszes kinti zonat is a bentire.
ez nem biztos, h menni fog, ezt inkább BIND-al csinálnám, ott talán menne egyszerűbben, itt nem biztos. (valaki nemrég írta valahol, hogy ott vannak 'view'-k, amik erre valók, ill. acl-eket már használtam hasonló célra)

Nekem is hasonló feladatra kell majd, de én hajlandó vagyok két adatbázist karbantartani (egy webes felületről), mert áttekinthetőbb lesz SZVSZ így, mintha trükköznék. A szerveren pedig két PDNS instancia fut, egyik a külső kéréseket szolgája ki, másik a belsőket.

a.

ps: a doksiban szintén le van írva, hogy lehet tök egyszerűen virtual-servereket létrehozni. :)

"ez nem biztos, h menni fog, ezt inkább BIND-al csinálnám, ott talán menne egyszerűbben, itt nem biztos. (valaki nemrég írta valahol, hogy ott vannak 'view'-k, amik erre valók, ill. acl-eket már használtam hasonló célra)"
Uhh, hat ez volt az egyik oka annak, hogy lemondtam a bind-rol. Probaltuk itt a HUP-on osszehozni a dolgot, de nem talaltunk ra megoldast. A masik gond meg az volt, hogy a google-lel sem tudtam mit kezdeni, mivel azt sem tudtam, hogy pontosan mit keressek. (Koszonhetoen neked, most mar ezt is tudom: bind view acl. :-D)
Mindenesetre most mar nem szandekozom a celvonal elott hatraarcolni a bind fele.

Kozben haladtam a fenti dologgal is es kezd tisztulni a kep, hogy kb. hogyan is mukodik ez. Sajnos a pdns es a gentoo dokumentacioja is eleg feluletes e teren, szamomra nem derult ki egyertelmuen, hogy pl. hogyan mukodik a recursor es a pdns azonos szerveren, mivel mindketten hallgatozni akarnak az 53-as porton mint dns szerverek. Vagyis, ha barmelyiket elinditom, utana a masik mar nem hajlando elindulni. Szoval, mielott szetturnek mindent a kiserletezessel inkabb kerdezek. :-)

Hogyan lehetne mindkettot futtatni azonos szerveren?

Koszi ismet. :-)

---------------------
Ригидус а бетегадьбол

Mindenesetre most mar nem szandekozom a celvonal elott hatraarcolni a bind fele.
helyes :)

Hogyan lehetne mindkettot futtatni azonos szerveren?
Írták az alias-t is, én úgy csináltam, hogy a recursor-t a 127.0.0.1:8053-on futtatom, és ezt adom meg recursornak a PDNS-ben.

Így a recursor-hoz nem fér hozzá más, csak a pdns, ahol viszont lehet konfolni, hogy ki intézhet rekurzív kérést.

De IMHO még mindíg azt mondom, hogy neked más volt a problémád, ha a kezelni kívánt domainre recursor-t keresett...

a.

Koszi szepen mindkettotoknek! :-)

Kozben sikerult megoldani, a pdns fut a 127.0.0.1-en ahogy eddig, a recursor-t pedig 127.0.0.2-n futtatom es a "forward-zones"-ban ez van megadva. Nem akartam elallitgatni a portokat, hogy esetleges kesobbi csomagszures konfigolasanal a halozat atlathato maradjon. (en szokatam szurni a 127.0.0.254 feletti IP-ket is mivel ez egy A osztalyu halozat)

En szemely szerint portokat csak akkor merem atteni, ha mar vegkepp nincs mas valasztas. :-)

A merge-dzselt dns dolog pedig nem jott ossze sajnos. Ha mukodesre tudtam birni akkor csak FQDN-t lehetett vele feloldani, mivel a kulso cimeket kiegeszitette volna a resolver +1 domainnel. Pl: a google.com eseten google.com.mydomain.org.

Koszi ismetelten. :-)
---------------------
Ригидус а бетегадьбол

A merge-dzselt dns dolog pedig nem jott ossze sajnos.
mármint a pipe-backend?

Ha mukodesre tudtam birni akkor csak FQDN-t lehetett vele feloldani
persze, mert ahogy korábban írtm/írtuk, a PDNS _csak_saját_domaint_old_fel, minden másra a recursor van.

Ha a google-t akarod "hamisítani", azaz más címet visszaadni a kliensnek, mint az valójában, akkor hozz létre egy google.com domaint, amit te kezelesz a PDNS-el.
(vagy nem értem a problémádat)

a.

"mármint a pipe-backend?"
Nem, azt nem probaltam, mert talaltam egy masik modszert ra.

"persze, mert ahogy korábban írtm/írtuk, a PDNS _csak_saját_domaint_old_fel, minden másra a recursor van."
Ez okes, ez tiszta sor volt vegig.

En valami ilyesmit szerettem volna megoldani:

belso dns rekordok: 

laptop.mydomain.org
desktop.mydomain.org
gateway.mydomain.org

kulso dns rekordok: 

www.mydomain.org
mail.mydomain.org
ftp.mydomain.org

Ha nevfeloldas kell, akkor pedig dontse el, hogy melyik dns szervernek kell azt feloldani es ha egyik sem tudja, csak akkor menjen tovabb a recursor fele. Ebben a fenti felallasban felvittem a rekordokat es sikerult ugy megcsinalni, hogy minden cimet csak egy helyen kellett karbantartani. A problemak viszont akkor kezdodtek amikor beallitottam a /etc/resolv.conf-ban a "domain mydomain.org"-t, hogy fel tudjon oldani mondjuk egy olyan non-FQDN gepnevet is, mint pl: laptop, desktop, mail, stb.

A belso cimekkel ment is szepen, de amikor bongeszni akartam, akkor is belso cimkent akarta feloldani az url-eket, mert a kliens gepek allandoan hozzacsaptak az _osszes_ cim vegere, hogy ".mydomain.org". Ugyhogy tok mindegy volt neki, hogy mi van a recursorral, mert esze agaban sem volt odaig eljutni, csak ping-pongozott a ket "mydomain.org" zonaju szerver kozott.

Most ugy megy a dolog, hogy a kulso .mydomain.org cimeket is felvittem belul, igy kint-bent vannak karbantartva.

---------------------
Ригидус а бетегадьбол

( Bojtosarpad | 2010. 07. 06., k – 12:54 )

Elég régi a topic, de most így előre kerülhet :)

Belőttem sikeresen egy ldap-powerdns párost.
A forward zónák tökéletesen működnek, még egy másik bind is képes az egész zónát axfr-rel leszedni.

Ugyan ez nem érvényes a reverse zónáimra. A bind ilyenkor csak az 0.1.10.in-addr.arpa zónát szedi le, de az alatta lévő ptr rekord bejegyzéseket nem. Ha külön kérdezem le az ip-t akkor az simán feloldódik.
Próbáltam tree és simple móddal is, de semmi változás.
Gugliban értelmes infót nem kaptam, szóval van valakinek ötlete miért van ez így?

szerk.:
Van egy olyan sejtésem, hogy ez nem is fog menni:
"Distributing zones can only be done directly via ldap replication in this case, because for a full zone transfer the
reverse records are missing"

Nekem pedig axfr-rel kell más ns-nek átadni a zónát. Úgy látom erre lesz jó a bind backend, azzal megy, épp most teszteltem.
Köszi a választ, magamnak :) De ha tud valaki jobbat, akkor ne fogja vissza magát!