Bug 132637

Summary: RHEL3: update to FreeWnn-1.11-36.3 fails when wnn group exists
Product: Red Hat Enterprise Linux 3 Reporter: David Juran <djuran>
Component: FreeWnnAssignee: Jens Petersen <petersen>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: thomas.duffy.99
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-14 04:22:33 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:
Bug Depends On:    
Bug Blocks: 170445    

Description David Juran 2004-09-15 12:21:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20040803

Description of problem:
Updating to FreeWnn-1.11-36.3 does not work since although the user
wnn does not exist, the group wnn is there. Therefor, when trying to
update to FreeWnn-1.11-36.3, the the preinstall script fails with
useradd: group wnn exists - if you want to add this user to that
group, use -g.

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

How reproducible:
Always

Steps to Reproduce:
1. rpm -Uvh FreeWnn-1.11-36.3.i386.rpm


Additional info:

Comment 1 Suzanne Hillman 2004-09-15 18:48:38 UTC
What version of FreeWnn did you have before? And did you try updating
via RHN?

You might want to contact support about this problem - if you have an
up-to-date entitlement - by going to http://www.redhat.com/support or
calling 800-REDHAT1.

Comment 2 David Juran 2004-09-15 19:20:30 UTC
I believe I had 1.11-36, and yes, I updated via RHN. For me, I solved
the problem. I just wanted you to know there might be an issue with
the preinstall script.


Comment 3 Suzanne Hillman 2004-09-15 21:03:58 UTC
Ah, ok. Thanks for letting us know!

Comment 4 Jens Petersen 2004-09-29 04:48:34 UTC
It is quite strange though since for me (fc3t3pre at least)
deluser wnn removes the wnn group too, so I don't see how this
could happen.

David, is it possible you could try again: ie downgrade FreeWnn
and then upgrade to see if the problem is reproducible? :)

Comment 5 Suzuki Takashi 2004-10-07 09:22:14 UTC
I encountered the same problem.

In my environment, the group wnn exists in NIS.
After I temporarily removed `nis' for group from nsswitch.conf, 
`up2date FreeWnn' succeeded.


Comment 6 Jens Petersen 2004-10-07 11:28:40 UTC
Thanks for that valuable information.

David, are you using nis too?

Comment 7 David Juran 2004-10-08 08:46:26 UTC
Yes, I am running NIS, but the group wnn is specified in the local
/etc/group file. Anyway, here is a slightly more structured rundown of
the situation...
To start with, I have not FreeWnn installed, but my /etc/group
contains an entry
wnn:x:49:
This is the case on all my 60 kickstart-installed RHEL3 servers, so I
dont't find it likeley that it has been added manually.
If I just try to install FreeWnn-1.11-36, I get an error from the
pre-install script, about the group already existing. So I remove this
group manually and then install FreeWnn-1.11-36.
Now the entry
wnn:x:2028:
have been created in /etc/group
Then I update to FreeWnn-1.11-36.3 and now it works and I get the entry 
wnn:x:203:

So if just the preinstall and uninstall scripts would be modified to
handle the case of the group already existing, I think it would solve
the problem (-.


Comment 8 Jens Petersen 2004-10-15 05:29:13 UTC
Was FreeWnn installed at some point in the past incidently?

If you "userdel wnn" does the wnn group remain on your boxes?

Comment 9 David Juran 2004-10-15 08:44:14 UTC
Yes, we have "Unsupported Development Libraries" as part of our
kickstart, so it is FreeWnn is installed initially.
And userdel wnn will remove the group wnn.
However the group was still there after I did 
rpm -e FreeWnn


Comment 10 Jens Petersen 2004-10-24 12:25:37 UTC
*** Bug 136551 has been marked as a duplicate of this bug. ***