PDA

Bekijk Volledige Versie : Bind is raar



Kurtje
23/11/04, 20:12
Bind reloading on bt1 using rndc zone: [domein.nl]
Error reloading bind on bt1: rndc: connect failed: connection refused

Dat krijg ik sinds een korte tijd, er zijn geen wijzigingen geweest verder en ik heb de foutmelding eerder nooit opgemerkt. Kan het zijn dat ergens een fout zit?

JKW
23/11/04, 20:16
Lijkt me eerder iets voor Scripting, Techniek & Beveiliging
Gerapporteerd aan de moderators

Kurtje
23/11/04, 20:18
het is op mijn dedicated server, belangrijk. Maargoed een idee zou ik op prijs stellen.

Pantsy
23/11/04, 20:33
Moved >>

Kurtje
23/11/04, 23:53
Probleem blijft zich voordoen. waar kan ik bt1 opzoeken, kan het nu nog niet vinden.. in geen enkele .conf

Digiover
24/11/04, 09:07
Voer
/path/to/bind/sbin/rndc reload zone.nl eens handmatig uit op de server.
rndc is een daemon(tje) dat met bind "praat", draait alles goed? Keys aangemaakt, enz?

Carl<n-media>
24/11/04, 16:05
Indien het een cPanel server is, probeer dan eens: /scripts/fixndc.

Kurtje
24/11/04, 19:06
/scripts/fixndc
Found key in named.conf ..
Found controls in named.conf ..
named.conf has already been fixed!


# rndc reload zone.nl
rndc: connect failed: connection refused

Digiover
24/11/04, 20:38
Je hebt BIND al eens, -manueel-, herstart, I assume?
Je rndc-key configuratie is juist (volgens mij wel, anders kreeg je een andere foutmelding)?
Welke versie van BIND draai je?

Cybafish
24/11/04, 21:26
Doe eens "cat /etc/named.conf | grep key" en "cat /etc/rndc.conf | grep key" en post de output.

Kurtje
24/11/04, 21:38
Origineel geplaatst door Digiover
Je hebt BIND al eens, -manueel-, herstart, I assume?
Je rndc-key configuratie is juist (volgens mij wel, anders kreeg je een andere foutmelding)?
Welke versie van BIND draai je?

Ja herstart.. server draait naar mijn weten versie 8, maar durf ik niet geheel zeker te zeggen.

$ cat /etc/named.conf | grep key
key "rndc-key" {
inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };


$ cat /etc/rndc.conf | grep key
cat: /etc/rndc.conf: No such file or directory

$ cat /etc/namedb/rndc.conf
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "Y8E1RbgXKxqa23elT6+Axg==";
};

options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};



Kwam nu net ook met een nieuw probleem dat ik net een nieuw domein in de server heb gezet (nieuwe DNS zone) maar hij hem niet als addon domain of parked domain wil toevoegen. Best apart.


The subdomain, sub.domain.nl has been added.

Cannot determine nameserver ip for newdomain.nl. Please make sure that it is registered with a valid domain name register.

Removed Entry from httpd.conf The subdomain, sub.domain.nl has been removed.

newdomain.nl could not be setup. The subdomain sub.domain.nl was not setup either.

Cybafish
24/11/04, 21:46
Hm? Naar mijn weten hoort de rndc.conf in /etc te staan. Doe eens "ln -s /etc/namedb/rndc.conf /etc/rndc.conf" en dan "rndc status" ?

Kurtje
24/11/04, 21:51
rndc status
rndc: connect failed: connection refused


Het is gewoon een cpanel server, zo geinstalleerd.. word hier dan ook enorm gek van.

Cybafish
25/11/04, 00:04
Welk OS?

Doe eens "rm -f /etc/namedb/rndc.conf" gevolgd door "/scripts/fixrndc", "killall -9 named" "service named start"...

Kurtje
25/11/04, 00:08
Origineel geplaatst door Cybafish
Welk OS?

Doe eens "rm -f /etc/namedb/rndc.conf" gevolgd door "/scripts/fixrndc", "killall -9 named" "service named start"...


/scripts/fixrndc: Command not found.

Hij kent dat bestand niet zo te zien?

Ah, je bedoelde /scripts/fixndc


Found key in named.conf ..
Found controls in named.conf ..
Adding key...
Restarting bind.....Waiting for named to restart..............finished.

bind 61356 0.0 0.4 2260 1764 ?? Ss 11:10PM 0:00.00 /usr/sbin/named
-u bind -c /etc/named.conf

named started ok
Nov 24 23:10:13 bt1 named[61355]: starting (/etc/named.conf). named 8.3.7-REL F
ri Oct 22 17:53:25 CEST 2004 butd@ns01.budgettrends.nl:/usr/obj/usr/src/u
sr.sbin/named
Nov 24 23:10:13 bt1 named[61355]: limit files set to fdlimit (1024)
Nov 24 23:10:13 bt1 named[61355]: /etc/named.conf:14: Ignoring BIND 9 inet contr
ol clause
Nov 24 23:10:13 bt1 named[61355]: /etc/namedb/jens.hosting-masters.nl.db:22:www.
jens.hosting-masters.nl: CNAME and OTHER data error
Nov 24 23:10:13 bt1 named[61355]: master zone "jens.hosting-masters.nl" (IN) rej
ected due to errors (serial 2004102703)
Nov 24 23:10:13 bt1 named[61355]: /etc/namedb/thugwars.hosting-masters.nl.db:22:
www.thugwars.hosting-masters.nl: CNAME and OTHER data error
Nov 24 23:10:13 bt1 named[61355]: master zone "thugwars.hosting-masters.nl" (IN)
rejected due to errors (serial 2004111002)
Nov 24 23:10:13 bt1 named[61355]: /etc/namedb/wouters-planet.hosting-masters.nl.
db:22:www.wouters-planet.hosting-masters.nl: CNAME and OTHER data error
Nov 24 23:10:13 bt1 named[61355]: master zone "wouters-planet.hosting-masters.nl
" (IN) rejected due to errors (serial 2004110903)
Nov 24 23:10:13 bt1 named[61356]: Ready to answer queries.
Nov 24 23:10:13 bt1 named[61356]: check_hints: A records for B.ROOT-SERVERS.NET
class 1 do not match hint records
Done
All fixed


Nieuwe account toegevoegd en zie ergens tussendoor dit staan

Bind reloading on bt1 using rndc
Error reloading bind on bt1: rndc: connect failed: connection refused

OS FreeBSD..

Cybafish
25/11/04, 00:12
En hij doet het nu nog steeds niet?

Doe eens "named -v" trouwens..

[edit] nvm zie het al


....named 8.3.7-REL F....

Misschien je bind even updaten?

Kurtje
25/11/04, 00:15
Origineel geplaatst door Cybafish
En hij doet het nu nog steeds niet?

Doe eens "named -v" trouwens..


named -v
named 8.3.7-REL Fri Oct 22 17:53:25 CEST 2004
butd@ns01.budgettrends.nl:/usr/obj/usr/src/usr.sbin/named

Cybafish
25/11/04, 00:20
Ik zou sowieso eens de hosting-masters.nl zone opschonen, die geeft nogal wat gezeur ;) Verder zie ik dat hij bij het opstarten aangeeft dat hij de BIND 9 inet controls skipt, dat zou dus best de oorzaak kunnen zijn. Wat staat er in en rondom regel 14 van je named.conf?

Mail je named.conf anders even; a.trouwborst@futureflex.nl.

Kurtje
25/11/04, 00:21
ik zal alle files even verzamelen voor je, bedankt dat je de moeit neemt om me even te helpen.

--edit
mail away

DelTa
25/11/04, 00:31
Origineel geplaatst door Kurtje


Het is gewoon een cpanel server, zo geinstalleerd.. word hier dan ook enorm gek van.

Dat heb je als je onervaren een hosting server probeert te beheren... ;)

Wat je overigens zou kunnen proberen is bind restarten en de logs dan bekijken, dus:

#service named restart
<Indien die een error geeft, post de output anders even hier>

#tail -f /var/log/messages
<zoek hier errors, meestal staat er een regelnummer bij of een duidelijke error om het probleem te identificeren..>

Kurtje
25/11/04, 00:33
Origineel geplaatst door DelTa


Dat heb je als je onervaren een hosting server probeert te beheren... ;)

Wat je overigens zou kunnen proberen is bind restarten en de logs dan bekijken, dus:

#service named restart
<Indien die een error geeft, post de output anders even hier>

#tail -f /var/log/messages
<zoek hier errors, meestal staat er een regelnummer bij of een duidelijke error om het probleem te identificeren..>

Onervaren valt ook wel mee, geen ervaring met bind in zoverre. Voorheen altijd gebruik gemaakt van PDNS op een Debian machine (wat nog NOOIT een probleem heeft gegeven), maar zit nu helaas vast aan deze ... naja rommel.

tail had ik al gedaan, geen enkele fout..

en het service commando kent deze machine niet schijnt..

service: Command not found.

Cybafish
25/11/04, 00:36
Delta, als je het topic had gelezen i.p.v. direct semi-flames te sturen dan had je geweten dat bind al lang en breed is gerestart en dat de output daarvan ook al gepost is ;)

Kurtje
25/11/04, 00:36
Origineel geplaatst door Cybafish
Delta, als je het topic had gelezen i.p.v. direct semi-flames te sturen dan had je geweten dat bind al lang en breed is gerestart en dat de output daarvan ook al gepost is ;)

het is laat ;)

DelTa
25/11/04, 00:37
Origineel geplaatst door Kurtje


tail had ik al gedaan, geen enkele fout..

en het service commando kent deze machine niet schijnt..


Tail na de reboot gedaan?

probeer anders:

/etc/rc.d/init.d/named restart
of
/sbin/named restart

Ik weet helaas niet de exacte path's in FreeBSD.. ;)

Kurtje
25/11/04, 00:42
Origineel geplaatst door DelTa


Tail na de reboot gedaan?

probeer anders:

/etc/rc.d/init.d/named restart
of
/sbin/named restart

Ik weet helaas niet de exacte path's in FreeBSD.. ;)
Ook gedaan, geen echte fouten wat betreft het boven omgeschreven probleem.

DelTa
25/11/04, 01:00
Origineel geplaatst door Kurtje

Ook gedaan, geen echte fouten wat betreft het boven omgeschreven probleem.

Heb je 1 van de volgende 2 geprobeerd:

1- Vergeet niet om eerst de named.conf te backuppen!!
named config rebuild dmv /scripts/rebuildnamedconf >> /etc/named.conf

2- in rndc.conf en named.conf "rndc-key" te vervangen door "rndckey" en vervolgens:

#/scripts/fixndc; service named restart; /scripts/fixndc; service named restart; rndc reload

Mocht het dan nog niet werken, graag de output van named na de named restart in /var/log/messages posten..

Kurtje
25/11/04, 01:04
Origineel geplaatst door DelTa


Heb je 1 van de volgende 2 geprobeerd:

1- Vergeet niet om eerst de named.conf te backuppen!!
named config rebuild dmv /scripts/rebuildnamedconf >> /etc/named.conf

2- in rndc.conf en named.conf "rndc-key" te vervangen door "rndckey" en vervolgens:

#/scripts/fixndc; service named restart; /scripts/fixndc; service named restart; rndc reload

Mocht het dan nog niet werken, graag de output van named na de named restart in /var/log/messages posten..

die output staat hierboven al. Dat is het enige aan output.

ik heb stap 1 al gedaan, geen resultaat.

Cybafish
25/11/04, 01:05
En stap twee heeft weinig nut, tenzij in named.conf rndckey had gestaan ;)

DelTa
25/11/04, 01:13
Origineel geplaatst door Cybafish
En stap twee heeft weinig nut, tenzij in named.conf rndckey had gestaan ;)

Op Fedora Core2 maakt het wel uit, over FreeBSD weet ik het helaas niet zeker..

Evt. wil ik gratis een kijkje nemen naar wat er loos is, aangezien ik bijna zeker weet dat je ergens een stap bent vergeten of niet goed kijkt ;)

Heb je trouwens de keys gecontroleerd?

Cybafish
25/11/04, 01:19
Ja, het is al opgelost. Uiteraard heb ik alles nagelopen delta wat je aanvoerde, ben ook niet van gisteren.

Even bind geupgrade met de ports en de boel werkt weer.

Kurtje
25/11/04, 01:19
Origineel geplaatst door DelTa


Op Fedora Core2 maakt het wel uit, over FreeBSD weet ik het helaas niet zeker..

Evt. wil ik gratis een kijkje nemen naar wat er loos is, aangezien ik bijna zeker weet dat je ergens een stap bent vergeten of niet goed kijkt ;)

Heb je trouwens de keys gecontroleerd?

Ja daar was ik al 20x doorgelopen, ben er al 2 dagen zoet mee geweest. Bleek een oude (rotte) bind in de weg te zitten terwijl bind 9 wel geinstalleerd was (maar waar?)

inmiddels opgelost door de hulp van Ad :)

DelTa
25/11/04, 01:33
Origineel geplaatst door Cybafish
Ja, het is al opgelost. Uiteraard heb ik alles nagelopen delta wat je aanvoerde, ben ook niet van gisteren.

Haha :D

Volgens een phpinfo op je website draai je een zeer onveilige (oude) Red Hat 9 kernel met zeker 3 bekende root exploits.. (Just a note..)


Origineel geplaatst door Cybafish
Even bind geupgrade met de ports en de boel werkt weer.

Dat doet inderdaad wel eens wat wonderen ;) (Er is overigens ook een bind reinstall script)

Cybafish
25/11/04, 08:37
Onder FreeBSD gebruik ik liever zo min mogelijk de standaard cPanel scripts, reden daarvoor lijkt me evident. Overigens nog nooit gehoord van patchen? Wel opvallend trouwens dat je me voor paal probeert te zetten omdat jij het probleem niet kon oplossen?

Mikey
25/11/04, 12:08
Origineel geplaatst door DelTa
Volgens een phpinfo op je website draai je een zeer onveilige (oude) Red Hat 9 kernel met zeker 3 bekende root exploits.. (Just a note..)


Misschien zelf patchen en een bepaalde kernel toch blijven draaien ? Tevens zijn de meeste root exploits allemaal local gedoe....

DelTa
07/12/04, 03:22
Origineel geplaatst door Cybafish
Onder FreeBSD gebruik ik liever zo min mogelijk de standaard cPanel scripts, reden daarvoor lijkt me evident. Overigens nog nooit gehoord van patchen? Wel opvallend trouwens dat je me voor paal probeert te zetten omdat jij het probleem niet kon oplossen?

Tegenwoordig draait alles van CPanel perfect op FreeBSD.. Wordt goed getest, altijd ge-update maar goed..

Patchen?? Mag je me toch wel even vertellen waar die patch vandaan komt.. En waarom je de image niet gelijk van naam hebt veranderd..

Waarom dan niet gelijk vanuit de source? Of via fedora-legacy (2.4.20-37.9 ipv de .31) Of progeny ($5/m heb je de updates)

Ik probeer jou niet voor paal te zetten omdat ik het zelf niet kan oplossen, heb tenslotte toegegeven dat ik geen FreeBSD expert ben.. ;)

Vond dit alleen een "slimme" opmerking van jou:


Origineel geplaatst door Cybafish
Uiteraard heb ik alles nagelopen delta wat je aanvoerde, ben ook niet van gisteren.

Je kernel helaas ook niet..


Origineel geplaatst door Mikey


Misschien zelf patchen en een bepaalde kernel toch blijven draaien ? Tevens zijn de meeste root exploits allemaal local gedoe....

Dus?? Local exploits mag je negeren? Zullen je klanten niet graag horen denk ik..

Cybafish
07/12/04, 11:29
Tegenwoordig draait alles van CPanel perfect op FreeBSD.. Wordt goed getest, altijd ge-update maar goed..

Patchen?? Mag je me toch wel even vertellen waar die patch vandaan komt.. En waarom je de image niet gelijk van naam hebt veranderd..

Waarom dan niet gelijk vanuit de source? Of via fedora-legacy (2.4.20-37.9 ipv de .31) Of progeny ($5/m heb je de updates)

Ik probeer jou niet voor paal te zetten omdat ik het zelf niet kan oplossen, heb tenslotte toegegeven dat ik geen FreeBSD expert ben..

*zucht* gaan we weer

"Tegenwoordig" draait alles van cPanel verre van perfect op FreeBSD, de hosters die hier ervaring mee hebben zullen je dit allemaal vertellen. Er zijn gewoon teveel problemen geweest en er ontstaan ook nog teveel problemen om te zeggen dat cPanel perfect draait op FreeBSD, dat is gewoon de reinste onzin.

Wat betreft de patches; die zijn er genoeg. Klik anders even hier (http://www.google.nl/search?hl=nl&q=kernel+patches&btnG=Google+zoeken&lr=) en je weet waar ik het over heb. Welke ik toepas laat ik even in het midden, dat is namelijk jouw zorg niet :)

Local exploits, tja, of je ze wel/niet mag negeren.... ze zijn i.i.g. nagenoeg onschadelijk bij het gebruik van webservers op de manier die wij toepassen.