** Description changed:

+ [Impact]
+ 
+  * Installing nut provides rules to set up the devnodes accordingly, but 
+    on an install the trigger to run those is missed to be executed due to 
+    an error in postinst.
+ 
+  * Fix is a backport from Debian repo 
+    (https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/id=d31c6dcb) 
, which works in artful already
+ 
+ [Test Case]
+ 
+  * Plug in a usb controlled UPS of your choice
+  * Install nut-server
+  * The device node created should be mode 664 and group "nut", but it is 
+    not.
+  * Install the proposed package with the fix
+  * that should trigger the rules to run and it should now be created with 
+    proper permissions.
+ 
+ [Regression Potential]
+ 
+  * The postinst trigger never worked, now it will work. If on a system the 
+    rules fail to execute there might be an issue, but since the are only 
+    triggered (async udev) the install will not fail due to that. I think 
+    in the worst case they are just still not executed.
+  * Vice versa once they are executed correctly the changed permission 
+    could be an issue for odd setups that relied on the broken permission, 
+    but I explained in the Regression potential section of bug 1099947 that 
+    is released together why I think that is no issue.
+ 
+ [Other Info]
+  
+  * n/a
+ 
+ ----
  1) $ lsb_release -rd
  Description:  Ubuntu 14.04.3 LTS
  Release:      14.04
  
  2) nut-server: 2.7.1-1ubuntu1; udev: 204-5ubuntu20.15
  
  3) On a fresh install of Ubuntu 14.04 (amd64), I installed the nut-
  server package while the UPS was already connected via USB. After
  installation, the permissions described by /lib/udev/rules.d/52-nut-
  usbups.rules should have changed the group of the corresponding
  /dev/bus/usb/*/* node to 'nut'.
  
  4) The owner/group for the /dev/bus/usb node remained root:root.
  Manually running 'udevadm trigger --subsystem-match=usb --action=change'
  changed the group to 'nut'. (From past experience tracking down related
  udev+nut bugs, unplugging and re-plugging the USB cable would yield
  similar results.)
  
  However, that udevadm command is included in the postinst for nut-
  server, and it is guarded with a pidof check for 'udevd':
  
  # ask udev to check for new udev rules
  [ -x /etc/init.d/udev ] && pidof udevd > /dev/null \
-       && udevadm trigger --subsystem-match=usb --action=change
+       && udevadm trigger --subsystem-match=usb --action=change
  
  This most likely needs to be amended to include the current process
  name, 'systemd-udevd'. I checked the control files, and unless the udevd
  process name has changed back, I believe this will affect vivid, wily
  and xenial as well as trusty. (I will let someone else add those later
  tags if that turns out to be the case.)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1540008

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1540008/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to