Bug 9180 - Named secondary transfer fails.
Summary: Named secondary transfer fails.
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: linuxconf   
(Show other bugs)
Version: 6.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-02-07 16:03 UTC by David Lawrence
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 18:47:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Derek Tattersall 2000-02-07 16:03:55 UTC
User named (101.102) does not have permission to create entries in
/var/named/sec so the transfer from the master server fails.

Comment 1 Bernhard Rosenkraenzer 2000-02-07 16:24:59 UTC
Neither bind nor caching-nameserver create a /var/named/sec directory.
It was probably created by a user before you updated to b1?

Comment 2 Dale Lovelace 2000-02-11 16:23:59 UTC
Moved this bug to "All" architectures.

 Linuxconf uses the /var/named/sec directory to store secondaries. I suppose
Linuxconf creates the directory, here are the permissions:

root@bilbo sec]# pwd
/var/named/sec
[root@bilbo sec]# ls -la
total 8
drwxr-xr-x    2 root     root         4096 Feb 11 12:27 ./
drwxr-xr-x    3 root     root         4096 Feb 11 12:27 ../
[root@bilbo sec]#

  Here is the error from /var/log/messages:
Feb 11 12:28:41 bilbo named[28377]: Forwarding source address is [0.0.0.0].1039
Feb 11 12:28:41 bilbo named: named startup succeeded
Feb 11 12:28:41 bilbo named[28378]: group = 234
Feb 11 12:28:41 bilbo named[28378]: user = named
Feb 11 12:28:41 bilbo named[28378]: Ready to answer queries.
Feb 11 12:28:41 bilbo named-xfer[28382]: can't make tmpfile
(sec/test.redhat.com.Xvai9i): Permission denied

  I suppose since named runs as user named, it doesn't have permission. It looks
like named ran as root in 6.1... Should we move this bug to Linuxconf?

Comment 3 Bernhard Rosenkraenzer 2000-02-11 16:49:59 UTC
So it's a linuxconf bug... Reassigning.

Comment 4 Brent Fox 2002-06-05 16:13:24 UTC
Closing because we don't ship linuxconf anymore

Comment 5 Red Hat Bugzilla 2006-02-21 18:47:37 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.


Note You need to log in before you can comment on or make changes to this bug.