Re: [weewx-user] Attempting to switch to non-root user for rsync
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 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
>>> 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, 20
Re: [weewx-user] Attempting to switch to non-root user for rsync
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 >
> 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
>>
>> 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 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
Re: [weewx-user] Attempting to switch to non-root user for rsync
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
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 >
> 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 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
Re: [weewx-user] Attempting to switch to non-root user for rsync
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 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 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 tha
Re: [weewx-user] Attempting to switch to non-root user for rsync
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 >
> 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 >
> 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 wou
Re: [weewx-user] Attempting to switch to non-root user for rsync
Hi Leon,
Terrific explanation! Thanks very much, and I'll give it a try.
On Tuesday, May 7, 2019 at 10:39:56 AM UTC-4, Leon Shaner 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 >
> 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 >
> 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 runn
[weewx-user] Attempting to switch to non-root user for rsync
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 weewx-user+unsubscr...@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.
[weewx-user] Re: Belchertown alt radar setup
I am, and I really like the quick website updates- particularly during rain or wind events. Weewx is on a Pi, and publishes to an MQTT instance that I set up on my Debian server (spare laptop in my basement) that also hosts my Mariadb instance. For now, I have a NAT rule in my firewall allowing read access from my publicly hosted site. Another side note- I have also updated the skin to utilize the nifty new NWS alerts that you just added. I had been actively trying to figure out how to include that myself when I saw your post. I had forgotten about that until a winter weather advisory was posted this afternoon, and the alert popped up! Works great, thanks. On Monday, December 31, 2018 at 3:26:09 PM UTC-5, Pat wrote: > > Great! Just curious - are you using MQTT? > > This has no bearing on your radar image - just my own curiosity. > > On Monday, December 31, 2018 at 2:25:50 PM UTC-5, Steve Chiz wrote: >> >> Thanks Scott! Pats notes say "This URL will be used as the radar iFrame >> or image hyperlink." so, of course, I kept trying to add a URL. >> >> Wrapping the URL with an IMG and single quotes worked much better. >> >> radar_html = "" >> >> On Saturday, December 29, 2018 at 4:56:23 PM UTC-5, Scott Grayban wrote: >>> >>> It needs to be in HTML syntax... >>> >>> >>> >>> On Saturday, December 29, 2018 at 9:50:32 AM UTC-8, Steve Chiz wrote: >>>> >>>> Hi, >>>> >>>> I'm testing out the Belchertown skin (nice job Pat!), but for the life >>>> of me I can't seem to switch out the radar image. No matter what I add >>>> between the quotes of the radar_html = "" section of the [Extras], it >>>> simply gets printed out as text where the radar image used to be... >>>> >>>> Can someone please point me in the right direction? Thanks! >>>> >>> -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Belchertown alt radar setup
Thanks Scott! Pats notes say "This URL will be used as the radar iFrame or image hyperlink." so, of course, I kept trying to add a URL. Wrapping the URL with an IMG and single quotes worked much better. radar_html = "" On Saturday, December 29, 2018 at 4:56:23 PM UTC-5, Scott Grayban wrote: > > It needs to be in HTML syntax... > > > > On Saturday, December 29, 2018 at 9:50:32 AM UTC-8, Steve Chiz wrote: >> >> Hi, >> >> I'm testing out the Belchertown skin (nice job Pat!), but for the life of >> me I can't seem to switch out the radar image. No matter what I add between >> the quotes of the radar_html = "" section of the [Extras], it simply gets >> printed out as text where the radar image used to be... >> >> Can someone please point me in the right direction? Thanks! >> > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Belchertown alt radar setup
Hi, I'm testing out the Belchertown skin (nice job Pat!), but for the life of me I can't seem to switch out the radar image. No matter what I add between the quotes of the radar_html = "" section of the [Extras], it simply gets printed out as text where the radar image used to be... Can someone please point me in the right direction? Thanks! -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Adding data from homemade wireless sensors to weewx
Thanks- I'll take a look and report back if I sort anything out. And yes, mwall seems to do some terrific stuff, but a driver isn't what I need. I don't want to replace my wx station with MQTT sensors, but add some soil temperature readings, etc., from other Pis scattered around my house and yard. I'm currently parsing text files as a service, but subscribing to an MQTT topic would be much better I think. On Wednesday, January 24, 2018 at 1:58:54 AM UTC-5, Andreas Landixus wrote: > > https://github.com/Landixus/mqttpondWeewx > is not working right now, but could be that i have server and client > running on same raspberry pi > But when you test it and post errors we can investigate deeper. > > Otherwise mwall has write a driver for mqtt that works i hear: > https://github.com/morrowwm/weewxMQTT > > Am Dienstag, 23. Januar 2018 23:27:44 UTC+1 schrieb Steve Chiz: >> >> I, too, would be interested in this, as it seems like it would be a much >> better way than parsing txt or xml files as I currently do for additional >> sensors. >> >> On Thursday, January 18, 2018 at 9:04:53 AM UTC-5, Andreas Landixus wrote: >>> >>> Oh i am high interested in this service, because i want to add some >>> sensors that publish mqtt messages. >>> Please post it. >>> >>> Am Dienstag, 12. September 2017 02:39:09 UTC+2 schrieb Dan Verbus: >>>> >>>> I've got a service written that works, if you want a copy. Each sensor >>>> publishes to it's own MQTT topic and the service reads off the queue >>>> whenever it receives a loop packet and appends whatever data it finds. Let >>>> me know and I'll post it. >>>> >>>> Dan >>>> >>>> >>>> On Wednesday, June 21, 2017 at 7:37:28 PM UTC-4, Craig Thom wrote: >>>>> >>>>> Thanks. I'm using the sdr driver, so I'm leaning toward a service, >>>>> and I've already got a little experience writing one. >>>>> >>>>> On Tuesday, June 20, 2017 at 6:05:12 PM UTC-4, Neville Davis wrote: >>>>>> >>>>>> In getting the data into weewx.I have a number of different >>>>>> sensors i2C one wire and data from a web sever (json) from my >>>>>> Airconditioner...all being input to weewx. >>>>>> >>>>>> My basic method is to get data as a csv file by running scripts from >>>>>> boot ( i have 3 of these files being generated in a ramdisk) and then I >>>>>> use >>>>>> 2 methods...a driver the get all the weather data and a weewx service to >>>>>> get the data from the aircon. The following is a screen shot of the >>>>>> current >>>>>> conditions. >>>>>> >>>>>> >>>>>> >>>>>> On Monday, June 19, 2017 at 10:43:33 PM UTC+10, Craig Thom wrote: >>>>>>> >>>>>>> Thanks. My question is really about getting the data into weewx, >>>>>>> but I'll worry about that later. >>>>>>> >>>>>>> After another message about the sensors themselves, I've decided to >>>>>>> go with low power 915MHz radio using the mysensors org protocol. I >>>>>>> should >>>>>>> be able to get many months from 3xAA batteries. The parts are coming >>>>>>> from >>>>>>> China, so I've got a month or two to think about getting them into >>>>>>> weewx. >>>>>>> It will probably be after the eclipse, since I'll be spending >>>>>>> increasing >>>>>>> time testing the hardware and software to photograph it. >>>>>>> >>>>>>> So sensors through mysensors hub to MQTT broker, and then somehow >>>>>>> into weewx. In August. >>>>>>> >>>>>>> On Wednesday, June 14, 2017 at 11:28:27 AM UTC-4, Paul Bartholdi >>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> It could be good to have a look at "http://www.yoctopuce.com";. The >>>>>>>> company is based in Geneva, Switzerland, but send products worldwide, >>>>>>>> with >>>>>>>> typical Swiss high quality. They have extremely low power hub
[weewx-user] Re: Adding data from homemade wireless sensors to weewx
I, too, would be interested in this, as it seems like it would be a much better way than parsing txt or xml files as I currently do for additional sensors. On Thursday, January 18, 2018 at 9:04:53 AM UTC-5, Andreas Landixus wrote: > > Oh i am high interested in this service, because i want to add some > sensors that publish mqtt messages. > Please post it. > > Am Dienstag, 12. September 2017 02:39:09 UTC+2 schrieb Dan Verbus: >> >> I've got a service written that works, if you want a copy. Each sensor >> publishes to it's own MQTT topic and the service reads off the queue >> whenever it receives a loop packet and appends whatever data it finds. Let >> me know and I'll post it. >> >> Dan >> >> >> On Wednesday, June 21, 2017 at 7:37:28 PM UTC-4, Craig Thom wrote: >>> >>> Thanks. I'm using the sdr driver, so I'm leaning toward a service, and >>> I've already got a little experience writing one. >>> >>> On Tuesday, June 20, 2017 at 6:05:12 PM UTC-4, Neville Davis wrote: In getting the data into weewx.I have a number of different sensors i2C one wire and data from a web sever (json) from my Airconditioner...all being input to weewx. My basic method is to get data as a csv file by running scripts from boot ( i have 3 of these files being generated in a ramdisk) and then I use 2 methods...a driver the get all the weather data and a weewx service to get the data from the aircon. The following is a screen shot of the current conditions. On Monday, June 19, 2017 at 10:43:33 PM UTC+10, Craig Thom wrote: > > Thanks. My question is really about getting the data into weewx, but > I'll worry about that later. > > After another message about the sensors themselves, I've decided to go > with low power 915MHz radio using the mysensors org protocol. I should > be > able to get many months from 3xAA batteries. The parts are coming from > China, so I've got a month or two to think about getting them into weewx. > It will probably be after the eclipse, since I'll be spending increasing > time testing the hardware and software to photograph it. > > So sensors through mysensors hub to MQTT broker, and then somehow into > weewx. In August. > > On Wednesday, June 14, 2017 at 11:28:27 AM UTC-4, Paul Bartholdi wrote: >> >> Hello, >> >> It could be good to have a look at "http://www.yoctopuce.com";. The >> company is based in Geneva, Switzerland, but send products worldwide, >> with >> typical Swiss high quality. They have extremely low power hubs usb --> >> Ethernet, gsm or WiFi, which can put all the boards asleep and wake up >> only >> on command from central PC. Boards include barometer, temperature(s), >> humidity, light and many other possibilities not so much related to >> weather >> station. Software exists for most high level languages (C, C++, Java, >> Python, shell (bash) etc.). >> MQTT looks very interesting, but I had no time yet to play with it. >> To interface other programs with weewx data, I simply interrogate the >> database (mysql). >> Hope this helps. Paul >> >> On Tuesday, June 13, 2017 at 3:53:48 PM UTC+2, Craig Thom wrote: >>> >>> tl;dr What's the best way of getting home brew wireless sensor data >>> into weewx? >>> >>> I plan to build a soil moisture (and temperature) sensor for my >>> garden bed. I'll likely build another for leaf wetness and UV index, >>> because the sensors are cheap and it will be fun. >>> >>> The question is how best to get this data to weewx. I am already >>> using the SDR driver for my Acurite 5-in-1 and additional sensors. >>> >>> I could use a 433MHz transmitter. I think, though, I'd have to >>> decide on how to make a packet, then modify rtl_433 to recognize that >>> packet, then modify SDR.py to use that new rtl_433 packet. This seems >>> pretty complicated. >>> >>> Or, since these sensors will be within range of wifi, I could use an >>> ESP2866. This is attractive because the microcontroller for reading >>> the >>> sensor and processing the data is in the same package. I really like >>> this >>> idea. >>> >>> But how do I get the data to weewx? >>> >>> Because the sensor will be running on batteries (and maybe solar >>> cells for the UV/leaf wetness one), I do not want to turn on the wifi >>> radio >>> except when absolutely necessary, so weewx will not be able to initiate >>> contact. >>> >>> My first thought was to use ftp, so the sensor connects to an FTP >>> server on my network, probably on the RPi running weewx, and dumps a >>> file. >>> Then I could write a service within weewx to check for that file, read >>> it, >>> and add the da
