|
tschortsch
Anmeldungsdatum:
21. Juli 2008
Beiträge: 11
|
Hallo ich hab nun einen DDNS server eingericht laut dem DDNS Allerdings versteh ich den Absatz nicht ganz: Weiterhin müssen in /var/cache/bind symbolische Links auf die Zonendateien angelegt werden. Der Grund dafür ist folgender: Der Bind-Server möchte gerne für jede Zone, die er dynamisch verwaltet, ein Journal auf der Festplatte anlegen, dass genau so heißt wie die Zonendatei, aber mit der Endung .jnl, also z.B. /etc/bind/db.olymp.gr. Die Berechtigung dazu, nach Belieben Dateien in /etc/bind anzulegen, sollte dem Server aber nicht gestattet werden. Leider genügt es nicht, mit touch entsprechende leere Dateien zu kreieren, da dort noch ein paar binäre Headerinformationen hineingehören. Um dieses Problem zu lösen, muss der Server dazu gebracht werden, die .jnl-Dateien in /var/cache/bind anzulegen, wo er Schreibrechte besitzt. Im übrigen sind Daten, die sich laufend ändern, in der /var-Hierarchie sowieso besser aufgehoben. MIr ist schon klar dass ich da nen symbolischen link erzeugen muss aber von wo/wohin versteh ich nicht ganz. Die Ausgabe von cat /var/log/syslog:
| Sep 22 23:03:20 xen0 named[10710]: loading configuration from '/etc/bind/named.conf'
Sep 22 23:03:48 xen0 named[10710]: client 127.0.0.1#56706: updating zone 'woodis.at/IN': adding an RR at 'gatewalker.woodis.at' A
Sep 22 23:03:48 xen0 named[10710]: client 127.0.0.1#56706: updating zone 'woodis.at/IN': adding an RR at 'gatewalker.woodis.at' TXT
Sep 22 23:03:48 xen0 named[10710]: journal file /etc/bind/db.woodis.at.jnl does not exist, creating it
Sep 22 23:03:48 xen0 named[10710]: /etc/bind/db.woodis.at.jnl: create: permission denied
Sep 22 23:03:48 xen0 named[10710]: client 127.0.0.1#56706: updating zone 'woodis.at/IN': error: journal open failed: unexpected error
Sep 22 23:03:48 xen0 dhcpd: Unable to add forward map from gatewalker.woodis.at. to 192.168.10.110: timed out
Sep 22 23:03:48 xen0 dhcpd: DHCPREQUEST for 192.168.10.110 from 00:16:36:4c:eb:5b (gatewalker) via intern
Sep 22 23:03:48 xen0 dhcpd: DHCPACK on 192.168.10.110 to 00:16:36:4c:eb:5b (gatewalker) via intern
|
vielen dank schon mal,
tschortsch
|
|
otzenpunk
Anmeldungsdatum:
17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
tschortsch schrieb: MIr ist schon klar dass ich da nen symbolischen link erzeugen muss aber von wo/wohin versteh ich nicht ganz.
ln -s /etc/bind/db.woodis.at /var/cache/bind
|
|
tschortsch
(Themenstarter)
Anmeldungsdatum:
21. Juli 2008
Beiträge: 11
|
Das hab ich jezt mit beiden datenbacken gemacht aber im log steht dann folgendes: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 |
Sep 24 09:17:12 xen0 named[10710]: client 127.0.0.1#52416: updating zone 'woodis.at/IN': adding an RR at 'gatewalker.woodis.at' A
Sep 24 09:17:12 xen0 named[10710]: client 127.0.0.1#52416: updating zone 'woodis.at/IN': adding an RR at 'gatewalker.woodis.at' TXT
Sep 24 09:17:12 xen0 named[10710]: journal file /etc/bind/db.woodis.at.jnl does not exist, creating it
Sep 24 09:17:12 xen0 named[10710]: /etc/bind/db.woodis.at.jnl: create: permission denied
Sep 24 09:17:12 xen0 named[10710]: client 127.0.0.1#52416: updating zone 'woodis.at/IN': error: journal open failed: unexpected error
Sep 24 09:17:12 xen0 dhcpd: Unable to add forward map from gatewalker.woodis.at. to 192.168.10.110: timed out
Sep 24 09:17:12 xen0 dhcpd: DHCPREQUEST for 192.168.10.110 from 00:16:36:4c:eb:5b (gatewalker) via intern
Sep 24 09:17:12 xen0 dhcpd: DHCPACK on 192.168.10.110 to 00:16:36:4c:eb:5b (gatewalker) via intern
Sep 24 09:17:16 xen0 named[10710]: client 127.0.0.1#56190: updating zone 'woodis.at/IN': adding an RR at 'gatewalker.woodis.at' A
Sep 24 09:17:16 xen0 named[10710]: client 127.0.0.1#56190: updating zone 'woodis.at/IN': adding an RR at 'gatewalker.woodis.at' TXT
Sep 24 09:17:16 xen0 named[10710]: journal file /etc/bind/db.woodis.at.jnl does not exist, creating it
Sep 24 09:17:16 xen0 named[10710]: /etc/bind/db.woodis.at.jnl: create: permission denied
Sep 24 09:17:16 xen0 named[10710]: client 127.0.0.1#56190: updating zone 'woodis.at/IN': error: journal open failed: unexpected error
Sep 24 09:17:16 xen0 dhcpd: Unable to add forward map from gatewalker.woodis.at. to 192.168.10.110: timed out
Sep 24 09:17:16 xen0 dhcpd: DHCPREQUEST for 192.168.10.110 from 00:16:36:4c:eb:5b (gatewalker) via intern
Sep 24 09:17:16 xen0 dhcpd: DHCPACK on 192.168.10.110 to 00:16:36:4c:eb:5b (gatewalker) via intern
|
stimmt das dann so? ode rmuss ich da noch irgendwo rechte vergeben?
|
|
xabbuh
Anmeldungsdatum:
25. Mai 2006
Beiträge: 6411
|
Hallo, wie sieht der Inhalt von /etc/dhcpd3/dhcpd.conf und /etc/named.conf.options aus?
|
|
tschortsch
(Themenstarter)
Anmeldungsdatum:
21. Juli 2008
Beiträge: 11
|
/etc/dhcp3/dhcpd.conf (eine datei /etc/dhcpd3/dhcpd.conf hab ich nicht da ich nur den ordner dhcp3 hab und nicht dhcp3d): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142 |
#
# Sample configuration file for ISC dhcpd for Debian
#
# Attention: If /etc/ltsp/dhcpd.conf exists, that will be used as
# configuration file instead of this file.
#
# $Id: dhcpd.conf,v 1.1.1.1 2002/05/21 00:07:44 peloy Exp $
#
# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
#ddns-update-style interim;
# option definitions common to all supported networks...
#option domain-name "domain.org";
#option domain-name-servers ns1.domain.org;
default-lease-time 600;
max-lease-time 7200;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.
#subnet 10.152.187.0 netmask 255.255.255.0 {
#}
# This is a very basic subnet declaration.
#subnet 10.254.239.0 netmask 255.255.255.224 {
# range 10.254.239.10 10.254.239.20;
# option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
#}
# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.
#subnet 10.254.239.32 netmask 255.255.255.224 {
# range dynamic-bootp 10.254.239.40 10.254.239.60;
# option broadcast-address 10.254.239.31;
# option routers rtr-239-32-1.example.org;
#}
# A slightly different configuration for an internal subnet.
#subnet 10.5.5.0 netmask 255.255.255.224 {
# range 10.5.5.26 10.5.5.30;
# option domain-name-servers ns1.internal.example.org;
# option domain-name "internal.example.org";
# option routers 10.5.5.1;
# option broadcast-address 10.5.5.31;
# default-lease-time 600;
# max-lease-time 7200;
#}
# Hosts which require special configuration options can be listed in
# host statements. If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.
#host passacaglia {
# hardware ethernet 0:0:c0:5d:bd:95;
# filename "vmunix.passacaglia";
# server-name "toccata.fugue.com";
#}
# Fixed IP addresses can also be specified for hosts. These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP. Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
#host fantasia {
# hardware ethernet 08:00:07:26:c0:a5;
# fixed-address fantasia.fugue.com;
#}
# You can declare a class of clients and then do address allocation
# based on that. The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.
#class "foo" {
# match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
#}
#shared-network 224-29 {
# subnet 10.17.224.0 netmask 255.255.255.0 {
# option routers rtr-224.example.org;
# }
# subnet 10.0.29.0 netmask 255.255.255.0 {
# option routers rtr-29.example.org;
# }
# pool {
# allow members of "foo";
# range 10.17.224.10 10.17.224.250;
# }
# pool {
# deny members of "foo";
# range 10.0.29.10 10.0.29.230;
# }
#}
#===================================================================
#DDNS eintrag
ddns-update-style interim;
ddns-domainname "woodis.at."; #diese Domain wird dynamisch aktualisiert
ignore client-updates;
update-static-leases off;
include "/etc/dhcp3/ddns.key";
zone woodis.at. { #Forward-Zone
primary 127.0.0.1; #Der DNS-Server, der aktualisiert wird
key DHCP_UPDATER;
}
zone 10.168.192.in-addr.arpa. { #Reverse-Zone
primary 127.0.0.1;
key DHCP_UPDATER;
}
#DDNS ende
subnet 192.168.10.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option domain-name-servers 195.3.96.67, 195.3.96.68;
option broadcast-address 192.168.10.255;
option routers 192.168.10.1;
range 192.168.10.100 192.168.10.110;
}
|
und hier /etc/bind/named.conf.options 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26 | options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.
// query-source address * port 53;
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
195.3.96.67; # AON provider
195.3.96.68; # AON provider
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
include "/etc/bind/ddns.key";
|
|
|
xabbuh
Anmeldungsdatum:
25. Mai 2006
Beiträge: 6411
|
Wenn ich das richtig sehe, müsste der Symlink so angelegt werden:
sudo ln -s /etc/bind/woodis.at.jnl /var/cache/bin/woodis.at.jnl Das ist deswegen notwendig, da Bind die Dateien gerne in /etc/bind ablegen würde, dort aber keine Schreibrechte besitzt.
|
|
otzenpunk
Anmeldungsdatum:
17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
xabbuh schrieb: Wenn ich das richtig sehe, müsste der Symlink so angelegt werden:
sudo ln -s /etc/bind/woodis.at.jnl /var/cache/bin/woodis.at.jnl Das ist deswegen notwendig, da Bind die Dateien gerne in /etc/bind ablegen würde, dort aber keine Schreibrechte besitzt.
Nein. So ein Symlink ändert auch nichts daran, dass Bind in /etc/bind die Dateien ablegen will. Man muss erreichen, dass er das stattdessen in /var/cache/bind tut, und da er aber immer dasselbe Verzeichnis benutzt, wo die eigentlichen Zonendateien auch liegen, müssen diese dorthin verlinkt werden. Eigentlich sollte die directory-Zeile in der options-Datei das bewirken. Keine Ahnung, warum das gerade nicht der Fall ist. Wurde vielleicht in der Haupt-named.conf irgendwas verändert, so dass der include-Befehl für die options-Datei gar nicht mehr ausgeführt wird?
|
|
xabbuh
Anmeldungsdatum:
25. Mai 2006
Beiträge: 6411
|
otzenpunk schrieb: Nein. So ein Symlink ändert auch nichts daran, dass Bind in /etc/bind die Dateien ablegen will. Man muss erreichen, dass er das stattdessen in /var/cache/bind tut, und da er aber immer dasselbe Verzeichnis benutzt, wo die eigentlichen Zonendateien auch liegen, müssen diese dorthin verlinkt werden. Eigentlich sollte die directory-Zeile in der options-Datei das bewirken. Keine Ahnung, warum das gerade nicht der Fall ist. Wurde vielleicht in der Haupt-named.conf irgendwas verändert, so dass der include-Befehl für die options-Datei gar nicht mehr ausgeführt wird?
Der Einwand bezgl. der directory-Option klingt logisch. Aber: Welchen Sinn hat denn ein Symlink von /var/cache/bind nach /etc/named? Umgekehrt würde ich den Sinn ja noch verstehen, da man so verhindern könnte, das Programme in /etc schreiben. Ein Symlink in diese Richtung verhindert das aber doch nicht, sondern zwingt Bind ja indirekt dazu in /etc zu schreiben?!
|
|
otzenpunk
Anmeldungsdatum:
17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
xabbuh schrieb: Ein Symlink in diese Richtung verhindert das aber doch nicht, sondern zwingt Bind ja indirekt dazu in /etc zu schreiben?!
Von der Richtung des Links unterscheiden wir uns doch gar nicht. Man kann das auch ganz ohne Symlinks machen, indem man einfach die Zonendateien nach /var/cache/bind verschiebt oder kopiert. Ich finde es aber einfach übersichtlicher, wenn unveränderliche Konfig-Dateien in /etc residieren, deswegen verlinke ich sie. Das Problem ist aber, dass Bind die Journal-Dateien immer dort anlegen will, wo auch die Zonendateien liegen. Wenn man ihm beibringen könnte, die Zonendateien in /etc zu suchen und die Journale trotzdem nach /var zu schreiben, wäre es das beste. Geht aber leider nicht.
|
|
xabbuh
Anmeldungsdatum:
25. Mai 2006
Beiträge: 6411
|
otzenpunk schrieb: xabbuh schrieb: Ein Symlink in diese Richtung verhindert das aber doch nicht, sondern zwingt Bind ja indirekt dazu in /etc zu schreiben?!
Von der Richtung des Links unterscheiden wir uns doch gar nicht.
Entweder reden wir gerade aneinander vorbei oder ich habe ein ziemlich großes Brett vor dem Kopf. Mit ln -s /etc/bind/db.woodis.at /var/cache/bind sorgst du letztendlich dafür das /var/cache/bind ein Symlink auf /etc/bind/db.woodis.at ist. Die eigentlichen Schreibzugriffe finden also in /etc/bind statt. Wäre der Link genau andersherum, also ein Symlink je Journal von /etc/bind/*.jnl auf /var/cache/bind, so wären die Inhalte unterhalb von /etc/bind statisch und die Schreibvorgängen fänden in /var/cache/bind statt. Man kann das auch ganz ohne Symlinks machen, indem man einfach die Zonendateien nach /var/cache/bind verschiebt oder kopiert. Ich finde es aber einfach übersichtlicher, wenn unveränderliche Konfig-Dateien in /etc residieren, deswegen verlinke ich sie.
In dem Punkt sind wir uns, denke ich, einig.
|
|
otzenpunk
Anmeldungsdatum:
17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
xabbuh schrieb: Mit ln -s /etc/bind/db.woodis.at /var/cache/bind sorgst du letztendlich dafür das /var/cache/bind ein Symlink auf /etc/bind/db.woodis.at ist. Die eigentlichen Schreibzugriffe finden also in /etc/bind statt.
Nein. Da /var/cache/bind ein existierendes Verzeichnis ist (oder sein sollte), heißt das dass ein Link /var/cache/bind/db.woodis.at erzeugt wird, der auf /etc/bind/db.woodis.at zeigt. D.h. Bind findet seine Zonendaten unter /var/cache/bind/db.woodis.at (über den Symlink) und legt deswegen das Journal als /var/cache/bind/db.woodis.at.jnl an.
|
|
xabbuh
Anmeldungsdatum:
25. Mai 2006
Beiträge: 6411
|
Danke für die Erklärung. Da habe ich dann wohl tatsächlich das Brett vor dem Kopf gehabt.
|