weewx-wxobs & weewx 5.01 compatibility

[MksRasp]

after upgrading weewx to the new release of v5.0.1, weewx-wxobs start to give error of permission denied, the file affected is "wxobs_weewx.inc" in "/usr/share/php" folder. we used this command: "sudo chmod 777 /usr/share/php/wxobs_weewx.inc" and it seem to cure the problem but we are not sure if it is safe and ok to change the file permission. do you support this change or have other way to make it work with newly upgraded weewx v5.01

Thank you

syslog:

pi4 weewxd[419]: INFO weewx.manager: Added record 2024-02-07 04:50:00 +03 (1707270600) to daily summary in 'weewx.sdb' pi4 weewxd[419]: INFO weewx.cheetahgenerator: Generated 8 files for report SeasonsReport in 19.54 seconds pi4 weewxd[419]: INFO weewx.imagegenerator: Generated 21 images for report SeasonsReport in 0.77 seconds pi4 weewxd[419]: INFO weewx.reportengine: Copied 5 files to /var/www/html/weewx pi4 weewxd[419]: ERROR weewx.reportengine: Caught unrecoverable exception in generator 'weewx.cheetahgenerator.CheetahGenerator' pi4 weewxd[419]: ERROR weewx.reportengine: [Errno 13] Permission denied: '/usr/share/php/wxobs_weewx.inc' pi4 weewxd[419]: ERROR weewx.reportengine: Traceback (most recent call last): pi4 weewxd[419]: ERROR weewx.reportengine: File "/usr/share/weewx/weewx/reportengine.py", line 220, in run pi4 weewxd[419]: ERROR weewx.reportengine: obj.start() pi4 weewxd[419]: ERROR weewx.reportengine: File "/usr/share/weewx/weewx/reportengine.py", line 409, in start pi4 weewxd[419]: ERROR weewx.reportengine: self.run() pi4 weewxd[419]: ERROR weewx.reportengine: File "/usr/share/weewx/weewx/cheetahgenerator.py", line 163, in run pi4 weewxd[419]: ERROR weewx.reportengine: self.init_extensions(gen_dict[section_name]) pi4 weewxd[419]: ERROR weewx.reportengine: File "/usr/share/weewx/weewx/cheetahgenerator.py", line 196, in init_extensions pi4 weewxd[419]: ERROR weewx.reportengine: self.search_list_objs.append(klass(self)) pi4 weewxd[419]: Traceback (most recent call last): pi4 weewxd[419]: File "/usr/share/weewx/weewx/reportengine.py", line 220, in run pi4 weewxd[419]: obj.start() pi4 weewxd[419]: File "/usr/share/weewx/weewx/reportengine.py", line 409, in start pi4 weewxd[419]: self.run() pi4 weewxd[419]: File "/usr/share/weewx/weewx/cheetahgenerator.py", line 163, in run pi4 weewxd[419]: self.init_extensions(gen_dict[section_name]) pi4 weewxd[419]: File "/usr/share/weewx/weewx/cheetahgenerator.py", line 196, in init_extensions pi4 weewxd[419]: self.search_list_objs.append(klass(self)) pi4 weewxd[419]: File "/etc/weewx/bin/user/wxobs.py", line 567, in init pi4 weewxd[419]: php_inc = open(self.include_file, 'w') pi4 weewxd[419]: PermissionError: [Errno 13] Permission denied: '/usr/share/php/wxobs_weewx.inc' pi4 weewxd[419]: ERROR weewx.reportengine: File "/etc/weewx/bin/user/wxobs.py", line 567, in init pi4 weewxd[419]: ERROR weewx.reportengine: php_inc = open(self.include_file, 'w') pi4 weewxd[419]: ERROR weewx.reportengine: PermissionError: [Errno 13] Permission denied: '/usr/share/php/wxobs_weewx.inc' pi4 weewxd[419]: ERROR weewx.reportengine: Generator terminated pi4 weewxd[419]: INFO weewx.reportengine: Copied 6 files to /var/www/html/weewx/wxobs

[glennmckechnie]

Ah. Ouch. That's not ideal. And it's a good question.

With the change of ownership in v5 to user weewx, it should really be moved somewhere less restricted. It doesn't feel right to allow relaxed permissions in a system directory. We should go elsewhere. There may be a better place for it in the 'new' venv layout but I haven't had the time to migrate and check.

The include file for wxobs wxobs_weewx.inc can be moved. The only caveat (besides being able to write it) is that the webserver needs to find the file and be able to read it.

At the start of wxobs/skin.conf is the following section where one option is mentioned...

[wxobs]
        # This shouldn't need changing, but if it does then /tmp is a good
        # starting point. This will most likely be used with remote servers
        # using sqlite databases, see [Remote] below
  #        include_path = '/tmp'

uncommenting (removing the #) from the include_path = '/tmp' will move the include file to the /tmp directory where 'weewx' should be able to write it, and your webserver should be able to read it - with the default 0755 permissions on creation.

What the include file does...

If you are using mysql then it contains the information to access the database. Password etc. If you are using sqlite3 then it tells you the database path and name.

If someone were able to read that files contents then they would still need access to your system to be able use them.

/tmp should satisfy the first requirement - visibility only to the weewx user.

Now. I haven't checked if the /tmp solution still works - I did way back when I coded it; but who knows what else has changed along the way. If it does work then I'll rejig the code to make that the default location.

Get back to me if it doesn't and I'll attempt to find some time to look at it with fresh eyes.

[MksRasp]

uncommenting include_path = '/tmp' did not solved the issue. when we tried it , the page was like this

[MksRasp]

the file wxobs_weewx.inc created automatically in tmp folder with 644 permission, we tested the file with 755 permission but it did not work. -weewx was restarted just to be sure but it made no different -when the file first created it was owned by weewx, we changed that to root but it did not make different too ! any suggestion

thank you

[glennmckechnie]

That's a puzzle, until I realize that you are probably running apache2 as your webserver?

For the record, the following works with lighttpd

I've installed WeeWX version 5.0.1 into Description: Debian GNU/Linux 12 (bookworm) and have it running the simulator. For the webserver I've installed lighttpd with the fastcgi-php module and php-sqlite3

After I get the latest weewx installed and running with the simulator, I then install the wxobs master, or the latest release (v0.7.8) using the new command... sudo weectl extension install master.zip

I get the /usr/share/php error you mention so I then edit the skins/wxobs/skin.conf file and uncomment the include_path = '/tmp' line. On the next report generation cycle weewx, reads the include file in its new location and wxobs runs as intended.

the new tmp file has 0644 permissions

root@toshibabeard:/tmp# ls -al /tmp/wxobs_weewx.inc -rw-r--r-- 1 weewx weewx 76 Feb 8 10:36 /tmp/wxobs_weewx.inc

That doesn't work for apache2; although ...

Apache2 won't allow /tmp to be used. Apparently it's outside its list of allowed directories, and I don't want to go creating exceptions. I know my limits.

What does work is to change the skin.conf entry to include_path = /var/lib/weewx That directory contains the actual sqlite database, so in one way it fits. It might be considered a little risky if you don't trust wxobs to always do the right thing though?

Another alternative is to place it within the user directory ie:- include_path = '/etc/weewx/bin/user'.

Maybe the best approach is to manually create a location such as ...

mkdir /etc/weewx/wxobs-tmp
chown weewx.weewx /etc/weewx/wxobs-tmp

and change that wxobs/skin.conf entry to ...

include_path = '/etc/weewx/wxobs-tmp'

These all work and are owned / writable by the user weewx. Most importantly, a default install of apache2 can read our include file placed in it.

[MksRasp]

the new instruction did the job. let us hope that weewx will not delete this folder during the next upgrade.

thank you

[glennmckechnie]

A note on this otherwise closed issue.

A cleaner fix is available, if or when you may need it. (no need to apply it, but it's there if you need it.)

I've been able to spend some time on the code and have settled on a fix that should work - works for me on a new install - to solve this permissions problem. It keeps the locations and method that php & apache 2 (also nginx and lighttpd ) use internally, just as we did before. It requires minimal intervention so should be straightforward.

It requires a manual step when doing the initial install but shouldn't be a deal breaker for anyone that's familiar with sudo, or the root user. The fix is clearly documented in the README, repeated in the wxobs/skin.conf and the wxobs index.php error page also detects it and outlines the solution to fix it. The code will also fix a path problem that has emerged with an internal change in later WeeWX 5.x versions.

[MksRasp]

we started clean install of weewx-wxobs by doing: 1-uninstalled weewx-wxobs and made sure no traces of it are left on the system but we kept the php folder but made sure the mode is 0755 and the owner and group is root. 2-installed weewx-wxobs v.8 and followed the new instruction on readme file. 3-stoped and started weewx then this appeared in the log:

ERROR user.wxobs: Error when accessing /usr/share/php/wxobs_weewx.inc : [Errno 13] Permission denied: '/usr/share/php/wxobs_weewx.inc' ERROR user.wxobs: See wxobs/skin.conf Section "Include File issue"

5-switched the owner and group of wxobs_weewx.inc from root.root to weewx.weewx using this command sudo chown weewx.weewx /usr/share/php/wxobs_weewx.inc 6-stopped and started weewx the errors are gone and wxobs if functioning ok. I am not sure what went wrong but I have done this to three different raspberry pi with the same error and cured it by command mentioned above.

[glennmckechnie]

Thanks for following up on this.

In most installations the /usr/share/php directory should exist, but just in case it is missing we check and fix it if required

The 2nd part is to copy that include file /tmp/weewx_wxobs.inc into the directory. That file should have the correct owner and permissions already and ... the penny drops!

I now realize what is happening. Mea Culpa.

the copy command should include the -p switch ( -p same as --preserve=mode,ownership,timestamps) I do these file transactions using mc , it must have the -p enabled by default, and I didn't give a thought to you guys using a different set of tools.

I shall fix the notes. Now!

Thank you for following through on this. You have fixed a rather obvious (they usually are in hindsight ) that I really didn't see happening. It did work for me, but I was using the wrong tools :-(

cheers Glenn