Description of Problem:
With redhat-config-nfs-0.9.4-3, there are a couple of odd things going on.
First, if you attempt to remove shares, they don't actually get removed. The
/etc/exports file doesn't get updated, the share continues to be exported.
If you don't have nfs running, and remove the lone share and attempt to quit,
you will get prompted that the nfs service isn't running and would you like to
start it. Clicking 'yes' results in the following traceback:
Traceback (most recent call last):
File "/usr/share/redhat-config-nfs/mainWindow.py", line 256, in
File "/usr/share/redhat-config-nfs/mainWindow.py", line 160, in processData
nfsDataObject = self.exportsStore.get_value(iter, 3)
TypeError: iter must be a GtkTreeIter
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Can you attach the /etc/exports file?
Did you start from scratch or was there an existing /etc/exports file?
At the start, I have this in /etc/exports:
and nfs is not running:
[root@kokopelli root]# service nfs status
rpc.mountd is stopped
nfsd is stopped
rpc.rquotad is stopped
I launch redhat-config-nfs and get the display showing the above export. I
click on it, then click 'Delete'. The export is deleted from the display and I
click "Apply" and get the message that the nfs service isn't running, would I
like to start it. Clicking either 'yes' or 'no' results in the traceback and
/etc/exports is left unmodified.
I start the nfs service and repeat the steps above. This time when I click
apply I don't get prompted to start the service (as it's already running) but I
do still get the traceback.
Can you reproduce this for me? I am unable to reproduce it on my machines.
Oh wait, I can reproduce it. The bug is caused when the list store is empty,
and the program tries to retrieve data from an empty list. I will fix now.
Should be fixed in 0.9.9-2. I will rebuild it later tonight. There's a few
other bugfixes I'd like to get in to 0.9.9-2.
Fix confirmed with redhat-config-nfs-0.9.9-2.