Attempting to switch to non-root user for rsync

[Steve Chiz]

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.

[Leon Shaner]

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)

--
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 weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Leon Shaner]

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)

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/0130621D-4F28-4F79-8036-1EF1743D9A95%40isylum.org.

[Steve Chiz]

Hi Leon,

Terrific explanation! Thanks very much, and I'll give it a try.  

To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.com.
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 weewx...@googlegroups.com.

[Leon Shaner]

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)

[Steve Chiz]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/aaab2dd1-376f-4f89-82a6-8ff03d032c9e%40googlegroups.com.
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 weewx...@googlegroups.com.

[Steve Chiz]

Guess I spoke too soon. After a reboot, weewx won't start. IOError: [Errno 13] Permission denied: '/var/run/weewx.pid'

[Leon Shaner]

Steve,

Probably a leftover.

I expect this should do it:

$ sudo chown weewx /var/run/weewx.pid

I would expect that file to be deleted on host reboot, except of course it is pronounced reboot, but spelled:

$ sudo shutdown -r now

If you use actual "reboot" then it skips shutdown scripts, so it's a big no-no.

What about the other files, did you change their owner, too, such as for the DB?

Regards,

\Leon

--

Leon Shaner :: Dearborn, Michigan (iPad Pro)

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d5d19e8c-4052-4cff-a28e-0c1935167fd9%40googlegroups.com.

[Steve Chiz]

I've tried a dozen things since then, all to no avail. I found an old post from Tom regarding commenting out the username lines to run as root again, and that is what I did to get the weewx.service to start.

Running the chown returned a file not found, so I assume one or more hard reboots (shutdown -r) deleted that file. I removed the commenting on the user name and this is the result. Oh, for a troubleshooting guide...

I did not make any database owner changes as I use mariadb.

May  7 20:18:47 WeeWx1 weewx[773]: engine: Locale is 'en_GB.UTF-8'
May  7 20:18:47 WeeWx1 weewx[773]: engine: pid file is /var/run/weewx.pid
May  7 20:18:47 WeeWx1 weewxd[773]: Traceback (most recent call last):
May  7 20:18:47 WeeWx1 weewxd[773]:   File "/usr/bin/weewxd", line 64, in <module>
May  7 20:18:47 WeeWx1 weewxd[773]:     weewx.engine.main(options, args)
May  7 20:18:47 WeeWx1 weewxd[773]:   File "/usr/share/weewx/weewx/engine.py", line 841, in main
May  7 20:18:47 WeeWx1 weewxd[773]:     daemon.daemonize(pidfile=options.pidfile)
May  7 20:18:47 WeeWx1 weewxd[773]:   File "/usr/share/weewx/daemon.py", line 77, in daemonize
May  7 20:18:47 WeeWx1 weewxd[773]:     if pidfile: file(pidfile,'w+').write("%s\n" % pid)
May  7 20:18:47 WeeWx1 weewxd[773]: IOError: [Errno 13] Permission denied: '/var/run/weewx.pid'

I am changing permissions back to root/ftp and calling it a day. Thanks for your help.

[Thomas Keffer]

Rather than put the PID file in /var/run (which could have permission problems), put it somewhere else where your user has write permissions. See steps #3 and #4 in Run as a non-root user. In that example, /home/weewx/run is used as a writable directory for user 'weewx'.

-tk

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/a7d1904a-8a0b-432a-94c0-0dbfd26f7abb%40googlegroups.com.

[Steve Chiz]

Well that added some confusion, but sort of helped as I figured out what you meant. I can't run Step#3, as I had removed the rc script based on the systemd wiki page "its almost certainly a bad idea to have both the rc script and a weeex.service file installed."

That did prompt me to edit the weewx.service file and move the location- pidfile=home/weewx/run instead of var/run. As you noted, var/run would be difficult for non-root writes. Makes perfect sense to move it out of there. The systemd wiki page says 'make sure the paths match', but offers no info as to what they should look like, if not the default.  Maybe home/weewx/run should be the default.

The wiki also says to make sure that there are permissions to the weewx database, but I'm using mariadb and those credentials did not change. Now however, I see that there are other databases involved- that are not mentioned. The weewx user has no permissions to forecast.sdb, for example, which I find no reference to in either wiki page. Again, the read only error makes perfect sense and must come up every time someone tries to move from the root user, but I found no mention of it. Are there other internal databases that weewx creates/uses that I need to be aware of? The error log also reflects issues with items in usr/share/weewx/user and lack of write access.

Am I the only one who has tried to hammer this out with such difficulty? I'm no noob, but I'm feeling pretty ignorant after struggling with this for so long.

[Steve Chiz]

Looks like the forecast.sdb database is generated by the the [forecast] report, and has the same issue with non-root /var writing. I created a /home/weewx/db folder, much like I did with for the PID earlier with home/weewx/run to get past the first error, and edited the wseewx.config accordingly. As I had mentioned previously I was writing the archive to mariadb, and was unaware that the forecast has its own database. For others who might be stuck, find it here: " SQLITE_ROOT = /" in the [Database types].

Finally running as non-root! And at the bottom of the log I was happy to see that my rsync worked straight away.

May  8 15:16:33 WeeWx1 weewx[1402]: rsyncupload: rsync'd 258 files (1,190,946 bytes) in 2.39 seconds