Bug 150910 - redhat-config-bind crash on startup
Summary: redhat-config-bind crash on startup
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: redhat-config-bind
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Radek Vokál
QA Contact:
Depends On:
Blocks: 163853 189875
TreeView+ depends on / blocked
Reported: 2005-03-11 22:17 UTC by Ian Laurie
Modified: 2011-02-18 09:17 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-02-18 09:17:34 UTC

Attachments (Terms of Use)

Description Ian Laurie 2005-03-11 22:17:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20050104 Red Hat/1.4.3-3.0.7

Description of problem:
redhat-config-bind crashes on startup.  When run from the command line:

server# redhat-config-bind
Traceback (most recent call last):
  File "/usr/sbin/redhat-config-bind", line 95, in ?
    cfg = ConfNamed.ConfNamed("/etc/named.conf",ROOTDIR)
  File "/usr/share/redhat-config-bind/ConfNamed.py", line 324, in __init__
    current[-1].setOpt(val[0],join(val[1:],' '))
IndexError: list index out of range

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Launch redhat-config-bind

Actual Results:  Crashes with the above errors.

Expected Results:  Should not crash.

Additional info:

Comment 1 Jason Vas Dias 2005-03-11 22:26:06 UTC
Yes, redhat-config-bind-2.0.0-14.2 has many such problems.

Please download the latest version, system-config-bind-4.0.0-4, from:
which does NOT have this problem. 

system-config-bind-4.0.0-4 is being readied for inclusion in RHEL-4-U2
(I'm just completing the user guide and manual at the moment, and it
lacks non-English locale translations currently) and will be making
its way through our QA process - but it does at least work better than
redhat-config-bind-2.0.0-14.2 .

Comment 3 Ian Laurie 2005-03-12 03:22:38 UTC
Jason,  On my RHEL-3-U4 Box:

server# system-config-bind
Traceback (most recent call last):
  File "/usr/sbin/system-config-bind", line 29, in ?
    import Debug
  File "/usr/sbin/../share/system-config-bind/Debug.py", line 9, in ?
    import datetime
ImportError: No module named datetime

I suspect this is a dependancy issue of some kind?

Comment 4 Ian Laurie 2005-03-12 03:34:57 UTC
OK, it seems to work on a RHEL-4 box.

Comment 8 Jason Vas Dias 2005-06-03 01:37:52 UTC
A version which fixes these problems, redhat-config-bind-4.0.0-16,
is now submitted to RHEL-3 and should be in RHEL-3-U6 . Meanwhile,
it can be downloaded from: 

Comment 9 Ian Laurie 2005-06-06 08:53:02 UTC
Still causes me grief (also I notice no icon in the menu):

server# redhat-config-bind
Traceback (most recent call last):
  File "/usr/sbin/redhat-config-bind", line 204, in ?
  File "/usr/sbin/redhat-config-bind", line 104, in __init__
    self.bind=BIND(self, argv)
  File "/usr/sbin/../share/redhat-config-bind/BIND.py", line 88, in __init__
  File "/usr/sbin/../share/redhat-config-bind/BIND.py", line 188, in load
    self.zoneTree = ZoneTree(self)
  File "/usr/sbin/../share/redhat-config-bind/ZoneTree.py", line 1035, in __init__
  File "/usr/sbin/../share/redhat-config-bind/ZoneTree.py", line 1043, in load
    s.store.append(svr,[s.server_pic, _('Server Controls'), '',
  File "/usr/sbin/../share/redhat-config-bind/DNS.py", line 986, in __init__
  File "/usr/sbin/../share/redhat-config-bind/DNS.py", line 879, in __init__
    raise ACL.Undefined(s,v)

As I have "hand crafted" bind files, could it be my coding causing this?

Comment 10 Jason Vas Dias 2005-06-06 17:41:57 UTC
Thanks for reporting this problem - it has exposed an error in the code that is
checking for undefined ACLs .
BIND versions < 9.3.1 have a named-checkconf that does not report
errors where an undefined ACL is referenced, yet these prevent 
named from running (ISC bug #13101), so r-c-b tries to detect and warn 
the user about them. 
However, it seems the checking was getting the case insensitivity
wrong, so if you had named an ACL with uppercase letters, this was not
checked correctly :( . It also wasn't warning for undefined ACLs in  
"controls inet ... allow { ... }"  but would exit with an error.
So either you had referenced an undefined ACL in your controls allow { ... }
ACL, or an ACL with uppercase letters.
This is now fixed with redhat-config-bind-4.0.0-17: it now performs the
undefined ACL check case-insensitively, and will exit with a GUI error
dialog if a genuinely undefined ACL is reference in a controls "allow" ACL .
Please try out the new version, available from:

Comment 11 Ian Laurie 2005-06-09 08:55:35 UTC
New version "works" in that it doesn't crash, but it looks like it
isn't processing any "include" statements, would that be right?

I have the following code:

include "/etc/rndc.key";
controls {
    inet port 953 allow { localhost; } keys { rndckey; };

On launch I get the error:

named.conf "controls" statement contains a reference to undefined ACL "rndckey".

However if I paste the contents of the include file in named.conf it starts OK.
As the rndc command works I would guess the file is getting included correctly
by the bind package, but not by redhat-config.bind.

Comment 12 Jason Vas Dias 2005-06-09 15:30:45 UTC
This is very strange - I can't reproduce the last problem - I have exactly
the same in my named.conf:

   include "/etc/rndc.key";
   controls {
      inet port 953 allow { localhost; } keys { rndckey; };

Where my rndc.key file contains:
  key "rndckey" {
        algorithm       hmac-md5;
        secret "RXKDbL4YU1pYv0djmAhqXcpM9rnataxk8BVaVBDaoultmOWLL2k9LboIeuu0";

redhat-config-bind starts up fine and displays the "rndckey" key record OK in
the GUI .

Do your rndc.key file contents look any different (aside from the "secret") ? 

Yes, redhat-config-bind DOES process include statements OK. But, as named does,
it prefixes any path given in "include"s with the chroot directory - do you
have $ROOTDIR defined in /etc/sysconfig/named ? 

If so, /etc/rndc.key should be a link to $ROOTDIR/etc/rndc.key - I've verified
that if $ROOTDIR is defined, redhat-config-bind loads $ROOTDIR/etc/rndc.key
regardless of whether the link exists or not. 

If there was a problem reading an include file, you'd get a dialog stating
"Initialisation Error:
 /etc/named.conf:...: open: /etc/rndc.key: file not found
" . I've verified this works too. 

Are you sure you have ONLY redhat-config-bind-4.0.0-17 installed ? 
 # rpm -e redhat-config-bind; rpm -ivh redhat-config-bind-4.0.0-17.noarch.rpm
Does the problem persist after this ? (If so, this could be an RPM upgrade 

I've also verified that different spellings of the include directive also work:
 '  InCludE
works for me too.

So I'm a bit at a loss to explain this problem.

If possible, please tar up and email me all your named conf files - I'll ensure
they remain confidential :
  # . /etc/sysconfig/named
  # tar -cpf - $ROOTDIR{/etc/named.conf,/etc/rndc*,/var/named} | 
    gzip > /tmp/named.tar.gz
and email the named.tar.gz file to jvdias@redhat.com - thank you!


Comment 13 Ian Laurie 2005-06-09 21:39:18 UTC
Jason, I am also "ROOTDIR=/var/named/chroot" and /etc/rndc.key is a link to

Thus I've sent you the whole /var/named structure.

If you need anything else pls let me know.

Comment 14 Jason Vas Dias 2005-06-10 17:00:58 UTC
Many thanks for the information - it exposed the bug, which was a
problem when a non "{}" named.conf entity was the FIRST entry in 
named.conf. This is now fixed with redhat-config-bind-4.0.0-18,
available at: http://people.redhat.com/~jvdias/redhat-config-bind .
I've found now problems with this version so far - please try it
out and let me know of any issues. Thank you, Jason.

Comment 15 Ian Laurie 2005-06-10 21:37:27 UTC
Jason, seems to work fine.  I intend to play and explore with it 
over the weekend..... after backing up the hand crafted files :)
I'll report the outcome later.

Please note there is still no icon inserted in the menu structure.
Very minor cosmetic issue, but its the only entry in 
"System Settings:Server Settings" without one.  My FC3 box has an
icon (though its a bit weird having a black rather than transparent
background).  Still using that icon would be better than nothing
while a better icon is created (just make the background transparent).

Thank you for your speedy attention to these start-up issues, it is
much appreciated.

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