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 On Wednesday, May 8, 2019 at 7:59:55 AM UTC-4, Steve Chiz wrote: > > 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]> 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]. >>> 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/e72540aa-9f4f-4366-87b8-3e2c125c6fe4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
