On Jan 17, 2014, at 6:31 PM, Ariel Wainer wrote:
> On 17/01/14 01:13, Charles Lepple wrote:
>>
>> Good point. I forgot that the permissions errors would happen after the
>> numeric device IDs were matched.
>>
>> I just pushed 3c13603. Tested by telling the driver to match a random USB
>> device instead of 0001:0000, and sure enough, when the driver didn't have
>> write access, the unpatched code crashed. Not sure I want to try and send
>> UPS polling commands to either a working UPS, or the mouse or keyboard, so
>> I'll leave the rest of the testing to you :-)
>
> I see that the commit belongs to the master branch :)
> It correctly informs there's a permission error now.
Oops, forgot to mention that it was merged. Once drivers start to work well
enough for testing, I like to merge them in sooner rather than later. If we
need to do any major refactoring, that would go on a branch temporarily.
>> scripts/udev/nut-usbups.rules should have an entry for 0001:0000 (although
>> the comments mention a different driver). You may have to refresh udev
>> somehow to get it to fix the permissions on the UPS, although we have had
>> reports that the rules file silently fails on non-Debian-derived systems.
>>
>
> The rule in my config was:
>
> ATTR{idVendor}=="0001", ATTR{idProduct}=="0000", MODE="664", GROUP="nobody"
>
> I have to add OWNER=nobody or change the mode to make it work, upsd is
> running under the user nobody, but I see all the rules looks the same,
> probably I'm doing something wrong.
Is that the working rule, or if not, which mode works? Also, what are the final
permissions?
The non-Debian udev problem seems to be that the entire rule was getting
skipped, but it sounds like this might be a more subtle permissions mismatch.
--
Charles Lepple
clepple@gmail
_______________________________________________
Nut-upsuser mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
