Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Slave DNS on RHEL 6.1 not able to create zone files.

Status
Not open for further replies.

jfmays

ISP
Oct 2, 2008
35
0
0
US
Running RHEL 6.1 named. Have it running in primary mode on one server, and slave mode on the other. The slave version gets the zones from the primary version, but it is not capable of creating the slave files. So it works, but I'm aware that if the secondary ever rebooted while the primary was down, neither would work.

I believe I had the persmissions correct on the directories, but I even went beyond that and changed /var, /var/named and everything under /var/named to 777 permissions. In /etc/sysconfig/named I have set --

ENABLE_ZONE_WRITE=yes
named_write_master_zones=yes

Still get the following error --

Apr 8 12:18:14 postgres-02 named[6248]: dumping master file: /var/named/slaves/tmp-6QzqbnrkFm: open: permission denied
Apr 8 12:18:14 postgres-02 kernel: type=1400 audit(1365441494.693:264460): avc: denied { write } for pid=6251 comm="named" name="slaves" dev=dm-0 ino=131232 scontext=system_u:system_r:named_t:s0 tcontext=system_u:eek:bject_r:named_zone_t:s0 tclass=dir
Apr 8 12:18:14 postgres-02 named[6248]: dumping master file: /var/named/slaves/tmp-R9d4zgBXzF: open: permission denied
Apr 8 12:18:14 postgres-02 kernel: type=1400 audit(1365441494.703:264461): avc: denied { write } for pid=6251 comm="named" name="slaves" dev=dm-0 ino=131232 scontext=system_u:system_r:named_t:s0 tcontext=system_u:eek:bject_r:named_zone_t:s0 tclass=dir


What am I overlooking?
 
Maybe it is chroot'ed and the actual directories are under /var/named/chroot/ ?
 
Those are SELinux errors indicating that permission has been denied for the operation - meaning that there is either a missing rule or a rule mismatch between your installation and the default setups, for which I have two suggestions. One, set the context to permissive, assuming it is currently at enforcing, which will still generate AVC in the audit log but should allow it to work. This will confirm or deny whether or not SELinux is causing the problem. Two try running audit2allow on the error message which more often than not will tell you what needs to be changed inorder to fix the operation.

P.S. - I hope you have a restore path on your /var permissions as /var is used in public facing server applications and other mission critical items this is a dangerous place to use 777 permissions.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top