Basically, it was my lack of understanding on how the .rules files work. I 
appreciate the explanation of the granular permissions as it helped me 
understand the 'why'. I am not worried about others plugging USB devices 
into the pi, so I went ahead and edited the 99-usb.rules and added my newly 
created weewx user to the plugdev group. I am successfully running weewx as 
non-root, thanks again!  WeeWx still complains that my key verification 
fails, but I can directly ssh successfully to my remote host as the weewx 
user without a password, so I'm close. 

Oh, and thanks for updating the wiki. I had run the "lsusb", I just wasn't 
entirely sure what to do with the output. The edit makes it more clear.

On Tuesday, May 7, 2019 at 11:28:35 AM UTC-4, Leon Shaner wrote:
>
> Steve,
> Hope it works!  =D
>
> I just updated the wiki.  That section now reads:
>
> First find the idVendor and idProduct of your weatherstation with lsusb 
> command 
> then add a rules file in /etc/udev/rules.d/ with this content:
>
> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"
>
> Name the udev rules file something descriptive, such as an abbreviation of 
> your weatherstation model or just weewx.rules, a la 
> /etc/udev/rules.d/weewx.rules (extension must be .rules and filename 
> should be simple, no spaces or special characters other than '-' and/or '_' 
> and should not contain more than one period '.').
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 7, 2019, at 10:39 AM, Leon Shaner <[email protected] <javascript:>> 
> wrote:
>
> Steve,
>
> In my first reply, I failed to answer your first question.
>
> Yes, if you use the first form with idVendor, idProduct explicitly filled 
> in, you can call the UDEV rules file anything you like, as long as the 
> extension is .rules and you place it in the /etc/udev/rules.d directory.
>
> I used a more generic /etc/udev/rules.d/99-usb.rules in my example, 
> because my example is very generic, not tied to weewx, but would work for 
> weewx provided weewx user is in the plugdev group.
>
> The (optional) number prefixes on the UDEV .rules files establish an order 
> of precedence with later rules overriding earlier rules.  Really it's 
> ordered lexicographically, so files that start with letters, such as 
> weewx.rules will be evaluated after (take precedence over) the files that 
> do start with numbers.
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 7, 2019, at 10:31 AM, Leon Shaner <[email protected] <javascript:>> 
> wrote:
>
> Hey, Steve,
>
> That first wiki looks pretty complete.
> Did you in fact try the "lsusb" command to get the values you need for the 
> first form of the udev rules?
> Using the first form with the idVendor and idProduct for your weather 
> station is preferred.
>
> As an alternative, and if it's just you with physical access to the host 
> and USB devices, e.g. you aren't too worried about other people connecting 
> USB devices and accessing them as non-root, you can also just do this:
>
> File:  /etc/udev/rules.d/99-usb.rules
> Contents:
> SUBSYSTEM=="usb", GROUP="plugdev", MODE="0660"
>
> Then be sure to put the wxuser and any other users in the "plugdev" group 
> in /etc/group, a la:
>
> plugdev:x:46:steve,pi,weewx
>
> (Or whatever usernames you care to be allowed to access USB ports).
> (Your GID may differ from 46)...
>
> Notice that for perms, above, I put 0660.  I can't think why "others" / 
> "nobody" should even need to read the USB ports.  Anybody that needs to 
> read(or write) USB ports should be in the "plugdev" group.
>
> You could of course put GROUP="weewx" in my example above, but then any 
> user would need to be in the weewx port to use any USB device, even those 
> unrelated to weewx.  The "plugdev" group is commonly used for other USB 
> devices, such as auto-mounting removable media, so that is why I chose it 
> in my example.  If you used my example and put GROUP="weewx" it would 
> likely break auto-mounting of removable media (maybe you don't care; maybe 
> you don't use the usbmount service, etc.).
>
> Note that changes in /etc/group take a log out / log in to take effect.
> Check group membership via "id -a" ...
>
> Of course the explicit method, per the wiki, using the idVendor and 
> idProduct values for your specific USB device avoids any conflict, because 
> then assigning group weewx would only ever happen to that one device that 
> exactly matches the idVendor and idProduct values from "lsusb" output.
>
> Hope that helps!  =D
>
> Regards,
> \Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On May 7, 2019, at 9:37 AM, Steve Chiz <[email protected] <javascript:>> 
> wrote:
>
> I've been trying to use the wiki to resolve this on my own, but can't seem 
> to sort it out. This page suggests I create a rules file, but no indication 
> on what that file should be named...  weewx.rules?  
> https://github.com/weewx/weewx/wiki/systemd 
>
> I hunted up an older page 
> https://github.com/weewx/weewx/wiki/Run-as-a-non-root-user that cites an 
> example for Vantage (name the file vpro.rules) but what about other 
> devices? In any event, the contents of the rules file is different than the 
> more recently edited page. Which should I use? 
>
> SUBSYSTEM=="usb", ATTR{idVendor}=="your_value", 
> ATTR{idProduct}=="your_value", ACTION=="add", GROUP="weewx", MODE="0664"
>  or 
> SUBSYSTEM=="usb", ATTRS{interface}=="CP2102 USB to UART Bridge Controller", 
> MODE: = "664", GROUP = "wxuser"
>
> I get that one page is about systemd specifically, which I am using, but both 
> address the need to run weewx as a non-root user. If someone could point me 
> to some documentation on how to switch from running weewx as root to a 
> non-root user, that would be great! I probably should have set it up that way 
> initially, regardless of rsync, as running as root always seems like a risky 
> idea.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/0130621D-4F28-4F79-8036-1EF1743D9A95%40isylum.org
>  
> <https://groups.google.com/d/msgid/weewx-user/0130621D-4F28-4F79-8036-1EF1743D9A95%40isylum.org?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/1930a35f-381f-4abd-8720-a00eb894f69d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to