USB permissions not set at install time (udevd name changed?)

Confirmed that this affects xenial as well.

Patch for xenial: https://launchpadlibrarian.net/300873279/nut_2.7.4-0ubuntu6~xenial~libusb1~gb0e1758_2.7.4-0ubuntu7~xenial~libusb1~gb0e1758.diff.gz

I haven't tested the patch for trusty, but I assume it would be similar since the udevd binary has the same name.

Uploaded to PPA: https://launchpad.net/~clepple/+archive/ubuntu/nut/+packages

Hi,
I beg your pardon that nobody found the time to look at this since I initially triaged it.
Especially since here even a suggested fix was provided we want to encourage and help.
I'm currently trying to clear out bugs that are dormant for too long, so lets take a look.

Status on the checked program:
Trusty to Artful : /lib/systemd/systemd-udevd is the binary
Due to changes in the nit system they are started differently, but that actually doesn't matter.
On Debian the name matches what Ubuntu has - so the issue as well as the fix applies to Debian as well.

IMHO - it isn't so important that the files are there.
The requiremend is
1. udevadm available
2. udev running
So a much better check could anyway be something like:
  systemctl is-active udev && which udevadm > /dev/null

For all but trusty that should be much better and we will find a pendant there once SRU'ing.
I'll prepare something for Debian and we can think on Fix and SRU once that has settled.
I'll link the Debian bug here soon ...

Hmm when prepping the changes to Debian I found it waiting in the suggested form for release already in reference to the Ubuntu bug.

[1]: https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/?id=d31c6dcb

So since it is accepted already no need to push my new way of thinking how to better check for the service. The benefit is that this way it also applies to Trusty as-is.

Also we carry Delta anyway - so it wouldn't be fixed by a sync.
Next steps:
1. Pull [1] into Artful
2. Prep SRUs back to X/Y/Z/T

[1]: https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/?id=d31c6dcb

As a sync would be preferred for 1. of comment #5 I did:
- Poll Debian on the status of the release of the already queued changes [1].
- Link the Debian bug up here and waiting for a reply now.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868007

This bug was fixed in the package nut - 2.7.4-5ubuntu4

---------------
nut (2.7.4-5ubuntu4) artful; urgency=medium

  * d/p/fix-snmp-driver-compile-options.patch: fix cflags/ldflags
    mismatch (LP: #1711092).
  * d/libnutclient0.symbols: fix symbols in regard to gcc-7 (LP: #1711091).

 -- Christian Ehrhardt <email address hidden> Wed, 16 Aug 2017 12:44:26 +0200

Uploaded SRU changes for review - branches are linked

Hello Charles, or anyone else affected,

Accepted nut into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nut/2.7.2-4ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Charles, or anyone else affected,

Accepted nut into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nut/2.7.1-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Charles, or anyone else affected,

Accepted nut into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nut/2.7.4-5ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Chris and Christian, thanks for working on this!

For xenial, looks like this debian/ patch might have gotten dropped (other half of the 52--nut-usbups.rules renaming), which might be causing the build failure: https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/?id=b0b61548a47b153b1ce6205bb9ce47edbb32910f

Hmm, I'm sure this built in a ppa for me - I'll look back into that in a few days (after Feature Freeze buzz) and report back.

Hi Charles,
thanks for your immediate feedback. In retrospective I had the change applied differently when testing and cherry picked it the same way as in later relases on the actual MP for upload.
It is very charming and heart warming that you come back so fast on a bug dormant by us for so long.

The other SRU that was combined with this on Xenial seems fixed on Xenial via other updates.
So I removed that part completely to refresh this upload - it is now building fine.

I'll upload that as new MP and hope to get an ack and sponsoring into unapproved today.
From there the SRU Team will pick it up and we will get an update here to re-consider.

I beg (all) your pardon for that hiccup on the way to finally fix this.

Re-verified that it builds now fine on all arches for Xenial.

I took a Xenial VM Guest and also pre-verified that

0. on a correct (manual) trigger I'd see in udevadm monitor the root hub and the device to show up as event
=> ok, working

1. on install of the old nut-server package there is no trigger
=> issue confirmed, no trigger

2. on install of the new SRU there is the trigger that would fix up permissions on install as intended
=> now working correctly re-emitting the events (and only usb events)

I'm moving that into the test steps, as it allows one wirthout special HW to *somewhat* test he SRU.

ok, MP for the SRU open now at
https://code.launchpad.net/~paelzer/ubuntu/+source/nut/+git/nut/+merge/329504

The other issue we wanted to fix in the same SRU is also fixed in Trusty by another (yet unknown fix, maybe to udev). The rules there are no more later overwritten - so I have to refresh the SRU upload to trusty as I only want/can SRU a verifiable fix.

I beg (all) your pardon for this hickup, but the lack of special HW made me unable to pre-verify that. Fortunately this issue over there while effectively hitting peopl with special HW - it can be verified without (as described in the test steps).

This would conflict with the SRU policy so I prepared an updated version to upload "over" it into proposed and let that then be verified and migrate.
That said - preparing a new upload for Trusty (Xenial and Zesty uploads are good already).

New MP to consider is at:
https://code.launchpad.net/~paelzer/ubuntu/+source/nut/+git/nut/+merge/329714

While we still wait for acceptance of 2.7.2-4ubuntu1.2 in Xenial and review,sponsoring and acceptance of 2.7.1-1ubuntu1.2 for Trusty we can test the Zesty upload already.

$ sudo udevadm monitor
[in another console install the fixed nut-server package]
KERNEL[134.190774] change /devices/pci0000:00/0000:00:01.2/usb1 (usb)
UDEV [134.192149] change /devices/pci0000:00/0000:00:01.2/usb1 (usb)
KERNEL[134.192328] change /devices/pci0000:00/0000:00:01.2/usb1/1-0:1.0 (usb)
UDEV [134.193343] change /devices/pci0000:00/0000:00:01.2/usb1/1-0:1.0 (usb)

Working correctly now -> verified (for zesty)

Fixed Trusty reviewed and uploaded for SRU consideration as well now.
I'll reset the state of the Trusty&Xenial Tasks so it shows up in the SRU Teams process again to accept those over the ones currently in proposed.

This bug was fixed in the package nut - 2.7.4-5ubuntu2.1

---------------
nut (2.7.4-5ubuntu2.1) zesty; urgency=medium

  * debian/nut-server.postinst: The udevd process is called systemd-udevd for
    quite sometimes already, properly detect whether it's running or not, this
    should fix the devices permissions for USB UPS's (LP: #1540008)

 -- Christian Ehrhardt <email address hidden> Thu, 17 Aug 2017 15:26:30 +0200

The verification of the Stable Release Update for nut has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

I've accepted the Trusty and Xenial SRUs but something with our tooling broke and this bug was not commented on.

I uninstalled NUT on xenial, rebooted, confirmed that ownership was root:root, enabled xenial-proposed, and installed nut-server 2.7.2-4ubuntu1.2. The ownership was successfully changed to root:nut.

Thanks Brian for accepting, I worked on hacking the changes files to be correct for this special case with rbasak - but given your comment it seems it didn't work out :-/

Thanks Charles for confirming Xenial.
Zesty already migrated (lacking the extra hop to unroll the no more needed part for another bug).

That leaves Trusty to be verified - I did so today, to get this migrating somewhat together.
Attaching a full log of that test ...

Per former comment setting Trusty and the general verification tag to done.

This bug was fixed in the package nut - 2.7.1-1ubuntu1.2

---------------
nut (2.7.1-1ubuntu1.2) trusty; urgency=medium

  * Drop d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: this issue
    seems fixed via other updates and is no more reproducible (LP 1099947).

nut (2.7.1-1ubuntu1.1) trusty; urgency=medium

  * debian/nut-server.postinst: The udevd process is called systemd-udevd for
    quite sometimes already, properly detect whether it's running or not, this
    should fix the devices permissions for USB UPS's (LP: #1540008)
  * d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: make udev
    rule apply correctly (LP 1099947).

 -- Christian Ehrhardt <email address hidden> Mon, 28 Aug 2017 08:48:47 +0200

This bug was fixed in the package nut - 2.7.2-4ubuntu1.2

---------------
nut (2.7.2-4ubuntu1.2) xenial; urgency=medium

  * Drop d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: this issue
    seems fixed via other updates and is no more reproducible (LP 1099947).
    Also fixes a FTBFS on the ongoing SRU of 2.7.2-4ubuntu1.1.

nut (2.7.2-4ubuntu1.1) xenial; urgency=medium

  * debian/nut-server.postinst: The udevd process is called systemd-udevd for
    quite sometimes already, properly detect whether it's running or not, this
    should fix the devices permissions for USB UPS's (LP: #1540008)
  * d/p/Fix-USB-permission-issues-related-to-Linux-udev.patch: make udev
    rule apply correctly (LP 1099947).

 -- Christian Ehrhardt <email address hidden> Thu, 24 Aug 2017 09:47:35 +0200