[Openstack-devel] Bug#732387: Bug#732387: Adds user ceilometer to group nova and libvirt on every upgrade

[Gaudenz Steinlin]

Thomas Goirand <zigo at debian.org> writes:

> Hi Gaudenz,
>
> First of all, thanks for taking the time to send bug reports. I'm very
> happy to see that OpenStack gets more and more traction within the
> Debian community.
>
> On 12/17/2013 10:20 PM, Gaudenz Steinlin wrote:
>> But this is actually not respecting local admin configurations. If an
>> administrator decides (for whatever reason) that the ceilometer user
>> should not be part of these groups
>
> Well, if an admin decides this, then Ceilometer will not work anymore.
> That admin might as well just remove ceilometer-common...

Well, it won't work anymore without configuration changes to other
packages sure. But it's very well possible to configure libvirt to use
another group too.

>
>> this decision is reverted on every
>> package upgrade. This violates Debian Policy section 10.7.3 which states
>> that local modifications must be preserved.
>> 
>> The user should only be added to these groups on first install. On
>> upgrades the group membership should not be changed.
>
> The section 10.7.3 that you mention is under the chapter "Configuration
> files" and has nothing to do with managing Unix user and groups.

As these changes ultimately end up in /etc/group I would say that this
policy section applies. It does not matter if you change the file
directly or with a tool. But I agree that the question if users and
group are configuration is a bit a grey area.

As you can't lock the user database anyway this won't prevent
(mis)configuration either.

IMO you should at least add a check like the following before adding the
group:
id -Gn ceilometer | grep -qE "(^| )nova( |$)" || adduser ceilometer nova
id -Gn ceilometer | grep -qE "(^| )libvirt( |$)" || adduser ceilometer libvirt

This is only a quick  example to show the intention. Feel free to
improve it.

>
> Also, removing the unconditionality of the unix user/group management
> would make this particular maintainer script not idempotent anymore,
> which is a path that is very dangerous to take.

I don't understand what you mean here. Indempotence means that you can
call the postinst several times with the SAME arguments and this will
not have any undesired side effects (like creating something on every
call that is only needed once). I don't see how this is affected by the
proposal to only add the user to these groups on fresh installs as the
arguments to the postinst differ from fresh installs to upgrades. 

If the postinst script fails, it will be called with the same arguments
on retries, so a condition checking for a fresh install will still
execute.


>
> Also, I fail to see where else in the policy manual it is written that a
> package cannot impose a particular user to be inside a specific group.
> Please point to the correct policy manual section if you still think
> this is wrong.

I agree that we are lacking clear policy on user management in
maintainer scripts. This is a problem as every package does his own
thing. But nothing we can fix in ceilometer.

>
> Whatever your reply will be, I don't think this bug deserves a severity
> "serious" (to quote the release team: not all policy violation are RC
> bugs), so I'm downgrading the severity.

I'm fine with that. I don't think the severity matters much as long as
bugs get fixed.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20131218/32fc9e79/attachment.sig>