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. On Tuesday, May 7, 2019 at 8:35:05 PM UTC-4, Thomas Keffer wrote: > > 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 > <https://github.com/weewx/weewx/wiki/Run-as-a-non-root-user>*. In that > example, /home/weewx/run is used as a writable directory for user 'weewx'. > > -tk > > On Tue, May 7, 2019 at 5:25 PM Steve Chiz <[email protected] <javascript:>> > wrote: > >> 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. >> >> On Tuesday, May 7, 2019 at 6:46:51 PM UTC-4, Leon Shaner wrote: >>> >>> 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) >>> >>> On May 7, 2019, at 5:42 PM, Steve Chiz <[email protected]> wrote: >>> >>> Guess I spoke too soon. After a reboot, weewx won't start. IOError: >>> [Errno 13] Permission denied: '/var/run/weewx.pid' >>> >>> On Tuesday, May 7, 2019 at 4:37:44 PM UTC-4, Steve Chiz wrote: >>>> >>>> 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]> 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]> 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]> 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]. >>>>> 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]. >>>>> 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/d5d19e8c-4052-4cff-a28e-0c1935167fd9%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/weewx-user/d5d19e8c-4052-4cff-a28e-0c1935167fd9%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/a7d1904a-8a0b-432a-94c0-0dbfd26f7abb%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/a7d1904a-8a0b-432a-94c0-0dbfd26f7abb%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]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/ba5ca8c8-1e91-4134-b813-39f6cae6cdd4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
