Bug 17780

Summary: linuxconf module API severely flawed; dnsconf flawed
Product: [Retired] Red Hat Linux Reporter: Need Real Name <pla>
Component: linuxconfAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 6.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:47:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2000-09-21 22:31:00 UTC
Edit /etc/named.conf to include some other file using BIND's include
directive (a reasonable thing to do if you maintain a large number of
domains and wish to segregate them into various files).  Then fire up
linuxconf - core dump.

I wasted half a day tracking this one down because I rarely use linuxconf
(usually when I'm playing in unfamiliar territory and want to see how
linuxconf does it) and it had been weeks since I made the DNS changes
before I fired up linuxconf.

Problem 1 is that dnsconf doesn't understand the include directive.  This
is understandable - it complicates things beyond the ability of a simple
utility to comprehend.  But instead of reporting back something like
"You've played with this manually so now you're on your own" it dies.

Problem 2.  The linuxconf module API is such that if one of the modules
dies then so does linuxconf, without reporting which module is having
problems.

Problem 3.  The only way to disable a module that causes linuxconf to die
with a core dump is to fire up linuxconf to disable that module.  Which is,
under the circumstances, impossible, even if you knew which module needed
to be disabled.

Overall, this means that some weeks after adding the include, I was faced
with a linuxconf that core-dumped with no explanation and no clue as to
why.  Even if I'd known that one of the modules was causing problems and
even if I'd known which module it was, I couldn't disable the module from
linuxconf.

This is a mess.  People should probably disable modules if they're going to
be playing with the related files manually, but many won't.  It would be
nice if dnsconf could handle the include directive, but realistically,
that's unlikely to happen.  But the situation where a valid statement in
named.conf disables linuxconf without explanation or any way of fixing the
problem from within linuxconf is unacceptable.

Temporary fix if you're caught out by this problem: remove the include
statements from named.conf, run linuxconf, disable dnsconf as a linuxconf
module, replace the include statements.  This fix applies to problems
related to named.  Other linuxconf modules may well have similar problems;
tracking down which module is causing the problem involves running anything
in /bin which is a soft-link for linuxconf to see which one bombs out.

Comment 1 Brent Fox 2002-06-05 16:19:34 UTC
Closing because we don't ship linuxconf anymore

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