Thema: (Gelöst) Zonentransfer Slave-Zone (rename: slave/it.xxx: permission denied)

Struktur:

|-----|DNS-Server [1] SuSE10.0|
| | master: zone: it.home
| | slave: opi.clan -> forwarder 10.1.1.2
|
.1
-+-------------------------- 192.168.222.0/24
|
|
_|______
| Router |
----------
|
|
-+--------------------------- 10.1.1.0/24
.2
|
|-----|DNS-Server [2] SuSE10.1|
| master: zone: opi.clan
| slave: it.home -> forwarder 192.168.222.1

Szenario:
DNS-Server [1] holt sich problemlos die zone slave/opi.clan von DNS-Server [2].
Beim Request der slave-zone [it.home] des DNS-Server [2] bei DNS-Server [1] kommt folgende Fehlermeldung:

*******
[2] named[3108]: dumping master file: rename: slave/it.home: permission denied
[2] named[3108]: transfer of 'it.home/IN' from 192.168.222.1#53: failed while receiving responses: permission denied

*******

Rechtevergabe für /var/lib/named/xxx ist default und [named] läuft als user: named.
In /var/lib/named/slave werden anstelle von [it.home] temp-Dateien des Abbildes der [it.home] von [named] angelegt, in der Form: tmp-xxyddadddwA
Diverses Suchen in Foren, sowie komplettes Deinstallieren/Neuinstallieren des Dienstes mit Löschung der gesamten Dateistruktur von /var/lib/named brachte kein Erfolg.

Hat Jemand ein gleiches Problem festgestellt und evtl. eine Lösung für mich ?


================================================== ==================
2006-06-01 | Problem gelöst |


Lösung:

Option von <named> ändern auf [chrooted no]

================================================== ==================

Ich habe das gleiche Problem.
Mein Secoundary soll 5 Zonen transferieren, kann aber die Dateien nicht umbenennen.

Aber ich habe den Lösungsansatz nicht verstanden.
Ich nutze SUSE 10.1 und habe DNS Pri und Sec mittels YaST konfiguriert.
Was ist mit: "Option von <named> ändern auf [chrooted no]" gemeint ?
Änderung in /etc/rc.d/named oder /etc/named.conf oder wie oder was ?!

Gruß, Snail.

Hallo zusammen,
die Anmerkung ist eigentlich zu Zonentransfer Slave-Zone (rename: slave/it.xxx: permission denied) gedacht, aber das ist ja schon geschlossen.

Ich hatte nämlich letztens auf meinem Serverchen nach einer Neuinstallation von suse 10.2 (vorher 9.3) ein ähnliches Problem (bei dyn. DNS / dhcp). Obwohl anscheinend sämtliche Rechte für das Verzeichnis wie auch für die einzelnen Dateien in Ordnung waren, gab es immer ein permission denied beim Anlegen oder Aktualisieren der Journal-Datei (.jnl). Irgendwann fand ich dann in einer google groups-Recherche in einem lapidaren Nachsatz die Ursache: Der AppArmor-Prozess hat die Bearbeitung unterbunden. In der yast-appArmor-Konfiguration die Rechte für das Verzeichnis gesetzt und gut war's.