Dotaz: PowerDNS a MySQL modul!

[uniDy]

Dobrý den, konfigurace PowerDNS i PDNS-recursoru nebyla problém a běží to krásně, ale problém nastal když jsem spustil modul MySQL (launch=gmysql), poté se zdá jakoby PowerDNS přestal s recursorem komunikovat.(dig google.cz apod. vypisují chybu nenalezení) Při "launch=bind" problém není a jede. Dříve jsem používal BIND9 a byl vcelku spokojen ale záznamy se začaly hromadit a bylo nutné využít databázi, proto padla volba na PDNS. Na serveru je použita distribuce archlinuxu, a zde navíc options jako "monitor" apod, nějak nejsou, takže se to komplikuje.

Věděl by si s tím někdo rady ? Za jakékoliv nápady a pomoc předem díky!

Odpovědi

[azurIt]

PowerDNS sa odporucam zdaleka vyhnut, su s nim len problemy.

[uniDy]

No co máš třeba na mysli? Mě osobně se i systém jak je to dělané tím pdns a pdns-recursor atd. líbí a je celkem jednoduchý, zdá se mi celkem vhodný až na tuto menší komplikaci, ale každopádně sem otevřen jiným návrhům. Co by jsi použil ty jako kompletní DNS s použitím MySQL databáze???

[azurIt]

Nezvlada preklad externych CNAME zaznamov, nerobi ziadnu validaciu zon, nema ani paru o DNSSec, ... Pouzi Bind, nove verzie uz vedia ukladat data do MySQL (najdes to v Debian backports pre Lenny).

[hermelin]

S DNSSEC nemam zkusenost - ale treba zde http://doc.powerdns.com/types.html podpora pro DNSSEC zaznamy je. Druha vec je ze recursor s DNSSEC zatim pracovat neumi. Jinak vse ostatni funguje zcela bez problemu.

Problem s prekladem muze byt ze nemas nastavenou adresu recursoru V pdns.conf zkontroluj radku recursor= . Mela by obsahovat IP na kterem recursor bezi. Pokud spoustis recursor na stejnem pc tak by melo stacit napsat 127.0.0.1

[hermelin]

A jeste si pak zkontroluj allow-recursion= . Zde musis mit nastaveno kterym ip recursi povolis.

[uniDy]

Také si myslím že PDNS není špatná volba... Navíc koukal jsem na ten BIND9 a nikde jsem plnou podporu mysql nenašel, vždy se do db ukládalo jen něco, a to nepotřebuji.

Ale k věci, no tohle vše právě nastavené a také dobře mám, problém nastává až když chci DB použít, poté jakoby rekurze nefunguje. Bez modulu gmysql v launch to jede v pořádku. Proto právě nechápu co může být špatně. Podpora MySQL tam určitě je, modul tam je, a dokonce o podrobnostech balíku v repositáři archu píšu podporu MySQL, takže v tomhle bych problém neviděl, už si vážně rady nevím.

Případně: recursion=127.0.0.1:5300 (běží na jiném portu) allow-recursion= (zde jsem nepsal nic a fungovalo to bez problému, jakože povoleno odkudkoli, případně samozřejmě sem to zkoušel i s nastavenou IP a také nic)

...prostě si myslím, že jakmile použiju gmysql, přestane se vůbec na recursion ptát... cemuž prostě nerozumím!

[azurIt]

Tie zaznamy su len uplne zaklady DNSSEC, ktore su viac-menej na nic. Existje patch pridavajuci plnu podporu avsak ten funguje blbo a velmi zatazuje procesor.

Externe CNAME to naozaj nedokaze prelozit, ver mi, viem o com hovorim. Problem sa da ciastocne obist tak, ze vsetkym povolis rekurziu, co je teda dost nevhodne riesenie (povolit preklad externych CNAME len niektorym IP je vcelku na nic, nemyslis ? ). Ak by ta to zaujimalo, tak problem je v tom, ze PDNS na externych CNAME vrati odpoved NXDOMAIN, pricom by mal vracat klasicky CNAME zaznam + odpoved NOERROR a resolver by nasledne urobil dalsi preklad.

[uniDy]

Já už fakt nevím teda, jsem z vás úplný vůl Ale stále se mi čím dál víc zdá že jinou možnost než PDNS bohužel nemám. Ta MySQL je fakt podmínka a částečné využití jako to je u BINDu mi je fakt k ničemu, potřebuji to uložit kompletně do DB...

[hermelin]

Ja to mam nastavene tak ze mi recursor bezi na vnitrnim a loop rozhrani. Na venkovnim bezi Pdns klasicky a mam nastavene ty dva parametry viz. vyse.

A externi CNAME nemam problem napr:

powerdns # dig www.google.cz

; <<>> DiG 9.4.3-P5 <<>> www.google.cz
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33641
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.cz.                 IN      A

;; ANSWER SECTION:
www.google.cz.          86400   IN      CNAME   www.google.com.
www.google.com.         284600  IN      CNAME   www.l.google.com.
www.l.google.com.       300     IN      A       74.125.43.104
www.l.google.com.       300     IN      A       74.125.43.105
www.l.google.com.       300     IN      A       74.125.43.147
www.l.google.com.       300     IN      A       74.125.43.103
www.l.google.com.       300     IN      A       74.125.43.106
www.l.google.com.       300     IN      A       74.125.43.99

;; Query time: 79 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Sep 19 12:26:17 2010
;; MSG SIZE  rcvd: 175

[uniDy]

A já jsem idiot... no comment pls ... vůbec mě nenapadlo, že by mohl být problém s připojením do db, byl jsem si jistý, že to je správně, zkoušel sem nastavovat i různé možnosti jako je socket a port atd. Ale teď jsem narazil na problém, který fakt nechápu, když tam socket MySQL nezadám, volá špatnou adresu, tak jsem ho nastavil na: gmysql-socket/var/run/mysqld/mysqld.sock kde skutečně je a ejhle PDNS hlasí, že i tu se na socket připojit nemůže, můžete mi to někdo vysvětlit ?

[uniDy]

AD: oprava gmysql-socket=/var/run/mysqld/mysqld.sock (chybělo "=")

[uniDy]

Proč nemůžu editovat příspěvky ? v pdns.conf to mám správně chyba byla jen tu, jen osvětluju, protože to vyznívá jako bch měl chybu i confu s tím = :)))

[uniDy]

No ať zkouším co zkouším, PowerDNS nechce použít mysqld.sock a vypisuje:

gmysql Connection failed: Unable to connect to database: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

a to v případě když zadám jako host=localhost v případě host=127.0.0.1 vypisuje:

Sep 19 12:47:41 uniTEK pdns[4313]: gmysql Connection failed: Unable to connect to database: Can't connect to MySQL server on '127.0.0.1' (111) Sep 19 12:47:41 uniTEK pdns[4313]: Caught an exception instantiating a backend, cleaning up

Prostě stručně řečeno, vůbec tomu nerozumím

[azurIt]

Len si uvedom, ze ty povolujes rekuziu vsetkym na svete resp. ak povolujes len sebe, tak tie extrene CNAME funguju len tebe. Ak stale nechapes, o com pisem, tak to neries. PowerDNS je bordel, ktory sa navyse uz hadam ani nevyvija.

[uniDy]

I bych souhlasil, ale bohužel mě tlačí dostupné možnosti...

[azurIt]

Ked si budes chciet nastavit e-maily na Google cez CNAME zaznamy (takto to Google doporucuje), tak si na mna spomen ;)

[flem]

Bert Hubert s dalsimi na tom maka, staci se podivat do mailing-listu: http://mailman.powerdns.com/pipermail/pdns-dev/

http://mailman.powerdns.com/pipermail/pdns-users/

dokonce je podporuji externi firmy, sponzoring ..je to v mailinglistu. Kdyz nekoho zajimaji veci kolem dnssecu, at projde mailingisty -user a -dev od dubna do zari a hneda v thredu dnssec

[flem]

Ohledne resolvingu externich CNAME: http://mailman.powerdns.com/pipermail/pdns-users/2010-July/006847.html

Ohledne powerdnssec: http://wiki.powerdns.com/trac/wiki/PDNSSEC (je to vyvojova vetev, kdo to potrebuje, muze zkusit..funguje, ale zatim neni v distribucich)

Bind i pDNS maji sve vyhody i nevyhody po kazde strance. pDNS ma by default spoustu backendu (mysql,ldap..), bind ma porad ldap jenom kdyz si to clovek zkompiluje. DNSSEC sice bind ma, ale jsou tam problemy jak je implementovane, musi se to hodne predelat, pDNS to dela cele hezky pomalu a poradne. PDNS umi podepisovat za behu, bind jenom offline. Rozdilu je celkem dost, kdyz pominu ty vykonove, kde pDNS je lepsi nez BIND, tak proste kazdy by si mel vybart podle toho co potrebuje a co od toho ocekava. Rozhodne pouziti backendu typu sql/ldap je lepsi pak pro pDNS nez pro bind, kdyz ale nekdo chce hlavne dnssec a nechce kompilovat, tak radeji sahne na disktribucni bind9.

[uniDy]

díky! a měl bys něco i k problému ? ohledně té chyby u mysqld.sock ??? viz. výše...

[Vantomas]

Strelim jen od boku, co pristupova prava na mysql socket z uzivatele pod kterym bezi pdns? Nebezi nejaky apparmor nebo selinux treba?

[uniDy]

Ne, nic takového tu neběží, a ty práva taky mě to napadlo tak sem na socket povolil přistup všemu, furt stejné, je to fakt divný...

[flem]

Nezkousis to na squeeze? Kdyz tak google... http://www.google.cz/#hl=cs&source=hp&q=gmysql+Connection+failed%3A+Unable+to+connect+to+database%3A+Can%27t+connect+to+MySQL+server+on+%27127.0.0.1%27+%28111%29++pdns+Caught+an+exception+instantiating+a+backend%2C+cleaning+up&aq=o&aqi=&aql=&oq=&gs_rfai=&fp=fe939a4f9b00b48d

[uniDy]

Ne to ne... No googluju co to dá, ale nějak reálného řešení jsem se nedogoogloval, i když sem pár podobných případů našel...

[uniDy]

Google už mi nenajde ani jedinný odkaz, který bych nepročítal

[flem]

http://www.bing.com/ :)

[azurIt]

Ohledne resolvingu externich CNAME: http://mailman.powerdns.com/pipermail/pdns-users/2010-July/006847.html

Tomuto hovoris riesenie ? ;) Pozeral si vobec akymi obklukami to robia ? Preco v Binde to moze fungovat samo od seba a v pDNS nie ? Navyse to funguje len s najnovsou verziu rekurzoru.

[p.]

A presne takto to aj funguje. Pokial mas na mysli to, ze mam domena.cz a chcem urobit v tejto zone zaznam "pokus IN CNAME stroj.domena.sk." a pokusim sa zo sveta resolvnut pokus.domena.cz tak to vrati CNAME a potom moze ten stroj z ktoreho robim request robit dalsi request na A zaznam toho stroj.domena.sk. Prave som to otestoval a funguje to bez problemov so pdns server+recursor co su v debian/lenny. Samozrejme pokial som sa pokusil urobit resolving napr. www.abclinuxu.cz, tak to odmietlo s tym, ze recurzia nie je povolena. V minulosti v niektorej z verzii to bol tusim problem, ale uz nie je. Pokial mas na mysli nieco ine, tak skus opisat konkretny priklad.

[azurIt]

Funguje to len pre domeny, ktore maju zaznamy u teba. Skus "pokus IN CNAME www.abclinuxu.cz.". A nemam s tymto problem len ja, je to vseobecne znama chyba. Skusane na pDNS z Debian Lenny a aj Debian Lenny backports.

[p.]

Tak som to skusil. Resolvovane z uplne cudzej siete, nez bezia nameservery, alebo by bola definovana nejaka vynimka pre tuto siet. Dalej moje.domena.cz. je domena, v ktorej som definoval "pokus IN CNAME www.abclinuxu.cz" (i ked to nieje spravne, kedze www.abclinuxu.cz. je tiez len CNAME, ale nevadi) a bolo to definovane konkretne na servery hlavnins.moje.domena.cz., ktory ma samozrejme v skutocnosti verejne IP. Na stroji z ktoreho som resolvoval som vyblokoval prijem odpovedi cez iptables zo zaloznych NS a este pre istotu snifoval tcpdumpom, aby bola istota, ze odpoved na 100% prisla od hlavnins.moje.domena.cz. (resolver, ktory resolvoval na tomto stroji v cudzej sieti bezi na localhoste a nema nastaveny ziadny forwarder, takze kontaktoval root nameservery, potom .cz servery atd.). Ako vidis z vypisu nizsie, tak bolo ziskane CNAME bez problemov. Pokial som urobil ping pokus.moje.domena.cz., tak pri analyze bolo vidiet, ze bol ziskany CNAME a potom lokalny resolver urobil dalsi resolving www.abclinuxu.cz. atd. Takze k IP sa do nakoniec dopracovalo. Dole nizsie este pre istotu dalej posielam vypis toho, ze hlavnins.moje.domena.cz. neumoznuje rekurziu pre cudzie domeny (je tam zobrazeny warning), nez pre ktore je autoritativny NS. Je to teda to co si mal na mysli? Alebo je treba otestovat nieco dalsie?

<div>

; <<>> DiG 9.5.1-P3 <<>> -t cname pokus.moje.domena.cz. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59981 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; QUESTION SECTION: ;pokus.moje.domena.cz. IN CNAME

;; ANSWER SECTION: pokus.moje.domena.cz. 604800 IN CNAME www.abclinuxu.cz.

;; AUTHORITY SECTION: moje.domena.cz. 604765 IN NS hlavnins.moje.domena.cz. moje.domena.cz. 604765 IN NS ns.zaloznins.cz. moje.domena.cz. 604765 IN NS nss.zaloznins.cz.

;; ADDITIONAL SECTION: hlavnins.moje.domena.cz. 604765 IN A 10.0.0.1

;; Query time: 12 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Sep 22 12:53:18 2010 ;; MSG SIZE rcvd: 137

---

; <<>> DiG 9.5.1-P3 <<>> -t cname www.abclinuxu.cz. @hlavnins.moje.domena.cz. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47101 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available

;; QUESTION SECTION: ;www.abclinuxu.cz. IN CNAME

;; Query time: 12 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Wed Sep 22 12:56:32 2010 ;; MSG SIZE rcvd: 34

</div>

[azurIt]

Sorry, ale fakt ma ziadnymi vypismi nepresvedcis. pDNS to proste nezvlada, staci, ked si to pohladas aj na nete, ma s tym problem vela ludi. Objavilo sa tu akesi pseudo riesenie (vid. prispevky), ktore je teda viac ako hrozne. To je uz lepsie povolit rekurziu vsetkym :) a najlepsie pouzit iny DNS server.

[p.]

Zacnem asi tym, ze vela ludi nerozumie tomu, ze pDNS ma oddelene riesenie pre autoritativny nameserver a pre rekurzor (co nie je tvoj pripad, narazam len na to, ze si pisal, ze s tym CNAME ma dost ludi problem). Tym chcem povedat tolko, ze dost ludi to nevie tym padom spravne nakonfigurovat, kedze to ma trosku inu logiku nez bind. Pre spravnu funkcnost sa doporucuje, aby autoritativny NS so zonami, pre ktore je autoritativny, bezal na verejnej IP a na porte 53. Pokial je v sieti klientami ziadana rekurzia inych domen, tak sa taktiez doporucuje, aby rekurzol bezal zvlast na verejnej IP na porte 53. Ak niekto z vnutornej siete bude chciet resolvovat zony, ktore spravuje autoritativny NS, tak sa pristupuje k resolveru a ten to resolvne normalne ako kazdu inu zonu (s tym, ze kontaktuje autoritativny NS prislusnej zony). Ak pristupuju klienti z inych sieti, tak pouzivaju svoj resolver a tiez skoncia nakoniec na tom autoritativnom NS, ziskaju CNAME a tym svojim resolverom potom urobia resolving na IP. Taktiez dost ludi testuje DNS zaznamy utilitou "host", ktora ma podivne spravanie a z toho tiez usudzuju, ze to nefunguje. Fakt je ten, ze host utilita "externy" CNAME poskytovany pDNS resolvnut nevie a ani nikto neriesi preco to nevie (pretoze to ta utilita robi divne). Ak si to clovek vyskusa pomocou dig, tak zisti, ze to funguje. Inak vacsinou vznikaju problemy tym, ze ludia mixuju autoritativny NS s rekurzorom a chcu po autoritativnom NS, aby robil rekurziu toho CNAME zaznamu, co je chyba (a pravdepodobne to aj host utilita robi takto). Komplikacie vznikaju tiez (ako je to aj v tejto diskusii ukazane odkazom do mailinglistu ohladne CNAME), ked autoritativny NS bezi niekde na privatnom rozsahu v nejakej privatnej sieti a resolver nevie standardnou cestou urobit resolving a tak sa tam musia vymyslat "hacky" (ano na binde je to jednoduhsie, kedze tam je logika taka, ze resolver je sucastou auth servera). Asi tolko k tomu. Ked nechas mail adresu alebo iny kontakt, poslem ti zonu, na ktorej bezi pDNS ako autoritativny NS a kludne si to vyskusaj. A uvidis, ze ten externy CNAME ti vrati bez problemov ale rekurziu nepovoli.

[azurIt]

Len dodam, ze na testovanie nepouzivam utilitu 'host' ale standardny 'nslookup', ktory je na to priamo urceny a pokial potrebujem presnu a celu odpoved, tak samozrejme 'dig'. Podla toho, co popisujes, pouzivas riesenie z toho mailing listu. Netvrdim, ze nefunguje, neskusal som ho pretoze uz len ked si to precitam, pride mi to extremne zlozite. Bolo by ale vhodne teda poupravit moje tvrdenie - pDNS zrejme zvlada externe CNAME avsak pomerne komplikovanym sposobom. Vcelku nechapem, naco je to takto dobre, ked to ide aj jednoduchsie. Mozes niekde hodit nejaku kratku a jasnu ukazku, ako presne to mas nastavene ?

[p.]

Skus si to s digom a povedz mi, ci Ti to nefunguje, najlepsie posli vypis toho digu (host a nslookup nerobia veci uplne OK - preto aj v mailingliste kam si pisal patch dostanes skor/neskor (mozno) odpoved, aby si to vyskusal cez dig a nie cez nslookup). Mam to vyskusane a normalne to funguje, konfiguracia je standardna, ziadne hacky apod. nie su pouzite. Dolezite je mat domenu spravne zaregistrovanu na NICe, mat spravne nastavene servery co su registrovane na NICe, aby bola cela cesta resolvnutelna a bude to fungovat.

[azurIt]

Prepac ale naozaj to robi problemy a nie len pre nslookup. Neviem ake velke DNS servery prevadzkujes ale ja proste viem o com hovorim (v tych nasich su tisicky domen).

[Radek Hladik]

To je jak tvrzeni vyhnout se Bindu, ma bezpecnostni problemy. Kdyz jsem PowerDNS nasazoval (nejaky ten patek nazad), tak jsem mel na serveru BIND a pravidlne mi ho nekdo shazoval, pripadne se pres nej dostaval do systemu. Pri treti reinstlaaci celeho serveru jsem se zamyslel nad tim, co je tak tezkeho na jednoduche sluzbe typu: "www.abclinuxu.cz?" "1.2.3.4" a zacal se rozhlizet jinde. PowerDNS je uzasny a jediny problem jsem mel, ze pri komunikaci s PostgreSQL se neminil znova pripojit, pokud mu nekdo prerusil spojeni do DB. Oprava byla otazkou copy/paste asi 10 radek v prehlednem kodu. Od te doby zadny problem a dokonce jsem si napsal pro PowerDNS jednoduchy modul pro praci s tinydns formatem a to, svete div se, v PHP!

Poznamka: Ano vim, alespon z druhe ruky, ze uz je na tom BIND s bezpecnosti vyrazne lepe.

[the.max]

cat /etc/powerdns/recursor.conf 
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/net-dns/pdns-recursor/files/recursor.conf,v 1.2 2007/06/08 22:28:14 swegener Exp $

# Drop uid
setuid=nobody

# Drop gid
setgid=nobody

# Don't log queries
quiet=on

# Local IP address to bind to
local-address=127.0.0.1
#local-address=0.0.0.0
#local-address=212.80.88.3

# Local port to bind to
local-port=5300

# Change root for safety
chroot=/var/lib/powerdns

v pdns.conf je toto:

launch=gmysql
gmysql-host=127.0.0.1
gmysql-user=jmeno
gmysql-password=heslo
gmysql-dbname=jmano_db

local-address=11.22.33.44, 127.0.0.1 # 11.22.33.44 nahradit za verejnou IP

local-ipv6=xxxx:xxxx:xxxx::xxxx # doplnit IPv6, pripadne zakomentovat

recursor=127.0.0.1:5300, 77.48.100.254 # druha IP je DNSkoo u providera pro pripad ze by nesel recursor, coz se mi jednou po aktualizaci stalo

Snad to pomuze,me to takhle beha jiz nekolik let.

[uniDy]

No jinak mám samozřejmě ty ip, a nejede mi to pod nobody ale nově vytvořeným uživatelem, ale souhlasí to, podobné návrhy na konfiguraci je plný internet, ale kde je můj problém s navázáním spojení na mysql, to fakt nevím

[flem]

ZKus pridat toho uzivatele pod kterym bezi to pdns do skupiny pod kterou bezi mysql...

[uniDy]

Bez rekace, tím to nebude...

launch=gmysql gmysql-host=127.0.0.1 gmysql-port=3306 gmysql-user=powerdns gmysql-dbname=powerdns gmysql-password=powerdns

Sep 19 14:49:36 uniTEK pdns[9246]: gmysql Connection failed: Unable to connect to database: Can't connect to MySQL server on '127.0.0.1' (111) Sep 19 14:49:36 uniTEK pdns[9246]: Caught an exception instantiating a backend, cleaning up Sep 19 14:49:45 uniTEK pdns[9246]: gmysql Connection failed: Unable to connect to database: Can't connect to MySQL server on '127.0.0.1' (111) Sep 19 14:49:45 uniTEK pdns[9246]: Caught an exception instantiating a backend, cleaning up Sep 19 14:49:57 uniTEK pdns[9246]: gmysql Connection failed: Unable to connect to database: Can't connect to MySQL server on '127.0.0.1' (111) Sep 19 14:49:57 uniTEK pdns[9246]: Caught an exception instantiating a backend, cleaning up

Jsem prostě na mrtvém bodě....

[flem]

co vypise telnet 127.0.0.1 3306 ?

[uniDy]

[unitek@uniTEK ~]$ telnet 127.0.0.1 3306 Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused

hm...

[flem]

Tak nejdriv rozbehej ten mysql server..a pak res pdns.

[uniDy]

No ale von jaksik jede... používají ho webovky je na něm phpmyadmin atd... proto tomu nerozumím...

[Vantomas]

V configu mysql my.cnf v sekci [mysqld] je nastavena bind-address jaka?

[uniDy]

no žádná... pokud vím neměla by tam ani být...

[Vantomas]

No treba v Debianu je tam by default bind-address = 127.0.0.1, aby se na server dalo pripojit pouze z localhostu (a klient se musi pripojovat na 127.0.0.1, jinam se pripojit neda), nevim jak to je v distribuci u tebe, jestli tam nahodou nejaky chytry nastroj nenastavil treba verejnou adresu a pak se klienti musi pripojovat na tuto.

Protoze je divne, ze se neda pripojit z localhostu telnetem na mysql. Jedine moznosti uz jsou jedine prave bud bind-address nebo firewall, ktery to blokuje nebo vycerpani limitu aktivnich spojeni na mysql.

[uniDy]

Našel jsem tam zajímavou direktivu, která dle popisu, moc jsem to nepochopil, to "nějak" blokuje po zakomentování:

Sep 19 15:36:09 uniTEK pdns[12105]: gmysql Connection failed: Unable to connect to database: Lost connection to MySQL server at 'reading initial communication packet', system error: 0

Sep 19 15:36:09 uniTEK pdns[12105]: Caught an exception instantiating a backend, cleaning up

Takže úplně tomu rozumím , jeden problém za druhým... jakoby někdo nechtěl aby to fungovalo

[Vantomas]

https://bbs.archlinux.org/viewtopic.php?pid=438684 ?

[uniDy]

jo jo našel jsem to také vypadá to slibně, paráda, chyba pryč. Backend je naloadován

Off: jen takový menší offtopic dotaz pro ty co PDNS solidně znaj, má možnost vytvořit jakýsi split-horizon???

[flem]

pDNS ted do toho vubec netahej. Nejdriv si rozbehej to, aby ses pomoci mysql klienta pripojil v shellu userem/heslem co chces pouzit pro pDNS na mysql bezici na 127.0.0.1. Kdyz tak zaloz nove vlakno o tom, ze nedari se ti pripojit na mysql z localhostu na localhost.

[uniDy]

Podle postřehů má arch naprosto každý .config file jiný než jinde Ale byla to moje blbost měl jsem si ho prolítnou pořádně už na začátku...