libvirt-bin Karmic upgrade fails when invalid users exist in /etc/group

Bug #463562 reported by iMac
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
adduser (Ubuntu)
Confirmed
Low
Canonical Foundations Team
libvirt (Ubuntu)
Invalid
Low
Unassigned

Bug Description

During the upgrade process, I received a:
Errors were encountered while processing:
 libvirt-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)

Manually running the upgrade process, I received additional output:

root@n8-laptop:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]?
Setting up libvirt-bin (0.7.0-1ubuntu13) ...
adduser: The user 'moose' does not exist.
dpkg: error processing libvirt-bin (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 libvirt-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)

It turns out I have a user from my home ldap (moose) in my libvirtd group along with my local user shown below:
/etc/group:
libvirtd:x:125:imac,moose,imacdonald

In this case, I removed the offending user 'moose' and proceeded without error.

This happened in my Karmic Upgrade from 9.04 up-to-date.

Revision history for this message
Chuck Short (zulcss) wrote :

Hi,

Where is the user moose coming from?

Regards
chuck

Changed in libvirt (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

So the attached patch would allow the package to upgrade/install. I'm attaching it here in case this is what we need.

However, I think that we would just be hiding a problem under the rug. As part of libvirt's package installation procedure, it needs to create the libvirtd group, and add any admin users on the system to that group. If your system's groups or users configuration is busted, libvirt's packaging can't do what it needs to do.

Hence, I think this bug is invalid.

Changed in libvirt (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
iMac (imac-netstatz) wrote : Re: [Bug 463562] Re: libvirt-bin Karmic upgrade fails when invalid users exist in /etc/group

Yes,

In this case the users are valid via LDAP, however the upgrade was being
completed when the LDAP was unavailable. It was not the libvirt group,
but the "admin" group as you noted. Once complete I re-added the users
to the admin group and authentication and authorizations via LDAP was
fine post-upgrade.

Perhaps this implementation is flawed, but it is a packaged MDS
implementation on Debian in the backend, and works well for mixed
Windows/Debian/Ubuntu environments where users and groups transcend many
different servers but have common home directory and authentication.

If you can beat NFS+LDAP for common desktops across linux/unix domains,
I am interested to know. Maybe Karmic+Eucalyptus is the end game, but
we have this for now.

Thanks for the patch,
cheers,
IMac

On Mon, 2009-11-02 at 14:55 +0000, Dustin Kirkland wrote:
> it needs to create
> the libvirtd group, and add any admin users on the system to that
> group.
> If your system's groups or users configuration is busted, libvirt's
> packaging can't do what it needs to do.

Revision history for this message
iMac (imac-netstatz) wrote :

LDAP backend; Specifically MDS packages running on Debian Lenny.

Updated/Tweaked, but similar setup to:
http://www.howtoforge.com/mandriva-directory-server-on-debian-etch

Perhaps a change to how we manage sudoers (LDAP group vs local group) is
called for, though there is little we can do for users that tweak their
own configuration using the GUI (easy add to admin).

On Mon, 2009-11-02 at 12:57 +0000, Chuck Short wrote:
>
> Where is the user moose coming from?

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Okay, well, I'm going to add a task against the adduser package. Perhaps the adduser package should handle this more gracefully.

Colin, any opinion?

Changed in adduser (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
Changed in adduser (Ubuntu):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Changed in adduser (Ubuntu):
status: Confirmed → Opinion
status: Opinion → Incomplete
Revision history for this message
Stéphane Graber (stgraber) wrote :

Reverting last status change as there was no rational for it.

Changed in adduser (Ubuntu):
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Patches

Remote bug watches

Bug watches keep track of this bug in other bug trackers.