[SRU] upsd doesn't start NOT 221737

2008/4/26, Wayne Steenburg <email address hidden>:
> Public bug reported:
> ...
> Can't chdir to /var/run/nut: Permission denied

good catch.
Chuck: this (--ingroup nut) is part of the default debian settings...
has this been changed in Ubuntu (ex: to the benefit of dialout)?

-- Arnaud

Marking as triaged. 'adduser nut nut' fixes the problem. This should probably be SRU'd as it renders upsd unusable.

I wish to nominate this for an SRU.

Statement of Impact:

Nut doesnt start upsd when the computer has booted. This prevents the user from using their UPS.

Statement of how this has been addressed:

I have added Jamie's workaround for 'adduser nut nut' in the nut.postinst file. This will be fixed as well when intrepid opens for development. I have attached the debdiff to this bug report as well.

TEST CASE:

1. Install nut from the repository.
2. Rename the example configuration files in /etc/nut. (ie: remove the .sample from the filename)
3. Run the command: sudo upsdrvctl start

There should not be any regressions.

+ # Make sure that the nut group actually exists
+ adduser nut nut

First, the comment and command do not match. This will *not* create a nut group. Second, this is missing a test whether both the user and the group have a system ID (100 <= id < 500). Third, this call looks really weird in the first place. How is this system user created? The standard way to do this is "adduser --system nut --group --no-create-home", which will take care of properly creating the system group as well.

OH duh...

Chuck, that looks much better already. However, the changelog says "nut group", whereas the patch puts the nut user into dialout. Which one is right and intended?

On Tue, 2008-04-29 at 07:41 +0000, Martin Pitt wrote:
> Chuck, that looks much better already. However, the changelog says "nut
> group", whereas the patch puts the nut user into dialout. Which one is
> right and intended?

This comment suggests that a fix to the problem is adding the user "nut"
to the group "dialout". Do I understand correctly?

I had done this already to handle permissions on the port my UPS was
attached to. That is, the owner.group for /dev/ttyS0 is root.dialout and
so to get nut to work one has to do an "adduser nut dialout".

Doing an "adduser nut nut", which fixes the problem, seems to me to be a
hack, not a proper fix. I ask again, when the code was built, was the
argument "-with-user=nut" given to configure?

both!

the aim is to keep nut in the nut group (which is the base for the
framework to operate) and to add it to the dialout group to solve the
need of user action for accessing serial devices.

as I state in the README.Debian, USB devices access is already handled
via udev...

-- Arnaud

I rejected the latest upload, too, since the changed call to adduser looks invalid to me:

- adduser --quiet --system --ingroup nut --ingroup dialout --home /var/lib/nut --no-create-home nut
+ adduser --quiet --system nut --ingroup dialout --home /var/lib/nut --no-create-home nut

It specifies two non-option arguments now (nut nut), which isn't valid according to the manpage, and the semantics is unclear, too. Also, the user won't be in group nut any more.

The changelog is inconsistent, too:

+ * debian/nut.preinst
+ - Make sure the nut user is acutally in the nut group or upsd wont start.
+ (LP: #222761)

Please document the dialout change, too, and fix the adduser calls to put them in both groups. I suggest to make 'nut' the primary group and add a second "adduser nut dialout", and wrap both commands into a "getent passwd nut" check, and only do the two adduser calls if the user didn't exist before.

Please test your changes...

$ sudo adduser --quiet --system nut --home /var/lib/nut --no-create-home nut
adduser: Specify only one name in this mode.

I guess you want

  adduser --quiet --system --group --home /var/lib/nut --no-create-home nut

Now the adduser call does not create a group 'nut' any more, as advertised in the changelog (without --group, adduser puts it into 'nogroup').

Accepted into -proposed, please test and give feedback here

For those who were having problems can you enable hardy-proposed in your /etc/apt/sources.list and try it out?

Thanks
chuck

I reproduced the initial problem using nut-2.2.1-2.1ubuntu7. I verified that using the package in -proposed, nut-2.2.1-2.1ubuntu7.1, corrects the issue, but *only* if the -proposed package is a new installation of the nut package. Upgrading to the nut package in -proposed from the version released in Hardy does not fix the issue; this is because the nut user and group already exist in the passwd database, and thus adduser does not get invoked. Similarly, removing the nut package entirely and then attempting to install the fixed package leaves the user with the same problem because on package removal the nut user and group are not removed.

I'm assuming this is insufficient and am tentatively rejecting the fix, as the committed fix doesn't actually address the issue for people currently attempting to use the package.

My test system does not have a UPS attached so I haven't actually verified that the nut package otherwise works.

I believe I have addressed these issues in the most recent upload.

Thanks
chuck

         if [ -z `getent group nut` ]; then
                 addgroup --quiet --system nut
-# else
-# printf "error: user \"nut\" already exists... see /usr/share/doc/nut/README.Debian\n" && exit 1
+ else
+ printf "skipping: user \"nut\" already exists... see /usr/share/doc/nut/README.Debian\n"
         fi
 }

Chuck, can you please explain how that changes the behavior? As far as I can see, this patch just triggers an additional warning message to appear (which is not good packaging, anyway; it will hardly be noticed). Steve, what was "the problem" when you tested upgrade? Did the upgrade fail (i. e. did addgroup error out because the group already existed), or was the problem that an already existing nut user isn't in some important group?

The nut user and group should *not* be removed on purging the package, BTW. That's common and good Debian practice for daemons which create files or processes owned by that system user. Otherwise the uid/gid would be recycled on next adduser, and existing files/processes would get owned by that new user.

2008/6/13 Martin Pitt <email address hidden>:

> if [ -z `getent group nut` ]; then
> addgroup --quiet --system nut
> -# else
> -# printf "error: user \"nut\" already exists... see
> /usr/share/doc/nut/README.Debian\n" && exit 1
> + else
> + printf "skipping: user \"nut\" already exists... see
> /usr/share/doc/nut/README.Debian\n"
> fi
> }
>
> Chuck, can you please explain how that changes the behavior? As far as I
> can see, this patch just triggers an additional warning message to
> appear (which is not good packaging, anyway; it will hardly be noticed).
> Steve, what was "the problem" when you tested upgrade? Did the upgrade
> fail (i. e. did addgroup error out because the group already existed),
> or was the problem that an already existing nut user isn't in some
> important group?
>

seconded. iirc, this fallback (nut already exist) should result in simply
checking if nut is already part of the dialout group (ie using a test -z
"getent group dialout | grep nut") and adding it if it's not.

The nut user and group should *not* be removed on purging the package,
> BTW. That's common and good Debian practice for daemons which create
> files or processes owned by that system user. Otherwise the uid/gid
> would be recycled on next adduser, and existing files/processes would
> get owned by that new user.
>

irrc, I've removed the call to check_and_delete_user in {nut,nut-cgi}.postrm
for the uid/gid recycling, I've thought before about asking for fixed ones.
the only question is: a generic one (ups, power, ...) or a specific one
(nut)?

-- Arnaud

On Fri, Jun 13, 2008 at 06:32:27AM -0000, Martin Pitt wrote:
> Steve, what was "the problem" when you tested upgrade? Did the upgrade
> fail (i. e. did addgroup error out because the group already existed),
> or was the problem that an already existing nut user isn't in some
> important group?

The latter. If you installed the nut package from Hardy 8.04 and then
updated it to the package in -proposed, attempting to start upsdrvctl
would still fail with the same permission denied error. If the first
version of the package installed is the one in -proposed, then upsdrvctl
starts successfully. That's fine for going forward, but it leaves
people who have attempted to use the released package with their problem
unaddressed by the update. If that's sufficient for releasing an update,
then go ahead, I was just attempting to report the results I found.

Thanks.

--
Steve Beattie
<email address hidden>
http://NxNW.org/~steve/

Arnaud Quette [2008-06-13 7:35 -0000]:
> seconded. iirc, this fallback (nut already exist) should result in simply
> checking if nut is already part of the dialout group (ie using a test -z
> "getent group dialout | grep nut") and adding it if it's not.

Please do "if groups nut | grep -qw dialout", that's a little more
robust.

I rejected the current upload, since consensus now seems to be that the current patch is not sufficient (and not necessary either).

With no other fixes available at this point, I'm copying nut 2.2.1-2.1ubuntu7.1 to hardy-updates so that users who install the package fresh from 8.04.1 will have a working setup. This bug is still verification-failed and I'm not closing it, because we should still be trying to deliver a working upgrade for users who already have the package installed; re-targeting to 8.04.2 for that.

I've uploaded a new version of nut to hardy-proposed which fixes several serious issues with the maintainer scripts, this one chief among them. Martin, please review and tell me if you think this is adequate.

I'll also check over the package's state in jaunty and prepare an upload if necessary; I probably won't prepare a separate SRU for intrepid unless there's specific demand.

Steve, that patch looks good to me, thank you! Please also apply it to jaunty, and send it to Debian.

Accepted into hardy-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package nut - 2.2.2-10ubuntu3

---------------
nut (2.2.2-10ubuntu3) jaunty; urgency=low

  * debian/{nut-cgi,nut}.preinst: don't call adduser or addgroup *at
    all*, these operations should be handled in the postinst. Since
    this is the only custom action at all for nut-cgi, remove that
    preinst completely.
  * debian/{nut-cgi,nut}.postinst: add nut to the dialout
    and nut groups unconditionally, to handle the upgrade from the hardy
    release. LP: #222761, LP: #287781.
  * debian/control: nut needs Pre-Depends: debconf instead of Depends:,
    because we use debconf unconditionally in the preinst.
  * reinstate debian/nut-hal-drivers.postinst, which was lost in a
    merge; and fix it up to use udevadm trigger --action=change, the
    safe way to install udev rules.
  * have nut-hal-drivers Depend: on udev so it can use the above.
  * fix up nut postinst to also use 'udevadm trigger --action=change'

 -- Steve Langasek <email address hidden> Fri, 30 Jan 2009 01:06:53 +0000

I reproduced the problem with the original version of nut in the hardy release, 2.2.1-2.1ubuntu7, and confirmed that upgrading to the version in hardy-proposed, 2.2.1-2.1ubuntu7.2, corrected this issue. I also verified that things work properly when:

  - upgrading via 2.2.1-2.1ubuntu7 (release) -> 2.2.1-2.1ubuntu7.1 (updates) -> 2.2.1-2.1ubuntu7.2 (proposed)
  - installing 2.2.1-2.1ubuntu7.1 (updates) and upgrading to 2.2.1-2.1ubuntu7.2 (proposed)
  - freshly installing 2.2.1-2.1ubuntu7.2 (proposed)

Note that I (still) don't have a ups, so all I was able to verify was that upsdrvctl started up enough to get to the point that it failed when trying to talk to the (non-existent) serial device.

Thanks.

2009/2/18 Steve Beattie <email address hidden>

> I reproduced the problem with the original version of nut in the hardy
> release, 2.2.1-2.1ubuntu7, and confirmed that upgrading to the version
> in hardy-proposed, 2.2.1-2.1ubuntu7.2, corrected this issue. I also
> verified that things work properly when:
>
> - upgrading via 2.2.1-2.1ubuntu7 (release) -> 2.2.1-2.1ubuntu7.1 (updates)
> -> 2.2.1-2.1ubuntu7.2 (proposed)
> - installing 2.2.1-2.1ubuntu7.1 (updates) and upgrading to
> 2.2.1-2.1ubuntu7.2 (proposed)
> - freshly installing 2.2.1-2.1ubuntu7.2 (proposed)
>
> Note that I (still) don't have a ups, so all I was able to verify was
> that upsdrvctl started up enough to get to the point that it failed when
> trying to talk to the (non-existent) serial device.
>

the dummy-ups driver is there to help you!
configure ups.conf with the following:
[myups]
driver = dummy-ups
port = test.dev

Copy the below file as /etc/nut/test.dev and relaunch your tests:
http://svn.debian.org/wsvn/nut/trunk/data/evolution500.dev?op=file&rev=0&sc=0

cheers,
Arnaud

This bug was fixed in the package nut - 2.2.1-2.1ubuntu7.2

---------------
nut (2.2.1-2.1ubuntu7.2) hardy-proposed; urgency=low

  * debian/{nut-cgi,nut-hal-drivers,nut}.preinst: don't call adduser or
    addgroup *at all*, these operations should be handled in the postinst.
    Since this is the only custom action at all for nut-cgi and
    nut-hal-drivers, remove those two preinsts completely.
  * debian/{nut-cgi,nut-hal-drivers,nut}.postinst: add nut to the dialout
    and nut groups unconditionally, to handle the upgrade from the hardy
    release. LP: #222761
  * debian/control: nut needs Pre-Depends: debconf instead of Depends:,
    because we use debconf unconditionally in the preinst.

 -- Steve Langasek <email address hidden> Fri, 23 Jan 2009 00:29:21 +0000

A problem remains: Was having considerable difficulty installing NUT. Same symptoms as above. That is:

user@host:~$ sudo upsdrvctl start

resulted in:

Can't chdir to /var/run/nut: Permission denied
Driver failed to start (exit status=1)

After considerable difficulty I was convinced that I had compromised the installation at which time I used Synaptic to remove NUT and then re-install. Once again encountered the same issue. After much searching/surfing I discovered this bug report. After executing

sudo usermod -G nut nut

NUT would run.

Configuration: Karmic, Belkin F6C900-UNV w/ USB interface.