Saratoga template update problem [Resolved]

Ask a Question
, ,
1

Downloaded updates (since 9 March) and uploaded them (to Swanston Grove Weather) after customisation. Some of the changes were to remove references to DS forecasts, and I thought I’d run the new check-fetch-times.php, which checked UV forecast OK but gave:

Error: Unable to write to ./cache/AW-forecast-0-uk2-en.txt file.

Cache directory has permissions 775, and other things are written there OK. We have had a problem with double headers from my proxy server before, but that seems to be taken into account in check-fetch-times. . .

And Aeris forecast appears to be working on the web page!

So what have I done now?

EDIT: I note that AW-forecast.php says the cached file is called AW-forecast-json.txt, but I don’t have one of them either :confused:

2

The AW-forecast.php is having the same issue with your cache directory:

<!-- AW-forecast.php (ML) Version 1.03 - 27-Dec-2022 on PHP 7.2.1 -->
<!-- temps in C -->
<!-- autoSetTemplate using narrow aspect. -->
<!-- loading from https://api.aerisapi.com/forecasts/?p=55.8983,-3.2077&format=json&filter=daynight,precise&limit=14&client_id=pMEv1Q5BisGq9AayV4u6b&client_secret=tXT0sXdZaPyB0vnIwBcO6EY1uJtEP9JszsKQMqsq. -->
<!-- curl fetching 'https://api.aerisapi.com/forecasts/?p=55.8983,-3.2077&format=json&filter=daynight,precise&limit=14&client_id=pMEv1Q5BisGq9AayV4u6b&client_secret=tXT0sXdZaPyB0vnIwBcO6EY1uJtEP9JszsKQMqsq' -->
<!-- HTTP stats:  RC=200 dest=192.168.252.254 port=3128 (from sce=192.168.252.43)
      Times: dns=0.000 conn=0.000 pxfer=0.032 get=0.010 total=0.042 secs -->
<!-- RC=200 Connection established, bytes=29023 -->
<!-- unable to open ./cache/AW-forecast-json-0-uk2-en.txt for writing. -->

so the file permissions are not quite right on the ./cache/ directory.

3

Don’t begin to understand permissions. . . nor do I have full control, but:

./cache/ already at 775, but using FileZilla set to 777 (which is ridiculous) and ran check-fetch-times again - success! Got AW-forecast-json-0-uk2-en.txt and AW-forecast-0-uk2-en.txt :slightly_smiling_face:

Checked permissions again and cache had reverted to 775. . . but check-fetch-times still worked to give the txt file and the json txt file is being updated as I refresh the page. So looks like chicken and egg: there has to be an existing file or it won’t get updated/overwritten.

I now (and Wim may) remember I had a similar problem with PWS Dashboard easyweathersetup: I couldn’t write a new settings1 file unless there was a settings1 file already.

Will report on the other windspeed problem tomorrow. . .

Thanks, Ken.

4

It’s probably a file/directory ownership problem. The 775 permission means

First 7 - the file/directory owner has full permissions read, write and execute
Second 7 - members of the group that own the file/directory have full permissions (rwx)
Third 5 - everyone else has read and execute access to the file/directory but not write

So if the file is owned by root:root (user: group) and the web server is running as user apache or www (as is common) then the web server only has read and execute permissions. That means that the web server can’t create a new file because it’s not the owner or a member of the owning group so doesn’t have write permission.

Once you give 777 permission you’re allowing the web server process to create the file (other users now have rwx permission). The file is created with the web server process as owner (and group) so when you revert to 775 permissions the next access to the file is using the first 7 (owner) so the web server process can continue to write to the file that it’s created.

You can check if this is what’s happening by doing ‘ls -la’ and looking in the file owner and group columns to see who owns each file. I expect you’ll find the newly created cache file has a different owner and group than other files.

You can probably fix this by using the chown command to change the file/directory ownership to the web server, however you should tread carefully because you could theoretically make the files inaccessible to yourself by doing this… Unless you’re logged in as root because root (usually) has superpowers to ignore permissions.

Hope that explains this a little more.

5

It is. . . my son-out-law is my provider and I have no control :slightly_smiling_face:

He has explained it to me, but . . . :confused:

Like that’s not going to happen. . .

But thanks, Chris :wink:

6

I’m which case 777 is your only option. If your outlaw won’t let ownership be changed then they must be happy to let you use 777 although that brings it’s own risks on a shared server.

7

To clarify, he is more than happy to change ownership when I have identified a problem - I just can’t do it myself. And no, he’s not happy with 777 either. It just worked. . .

I’ll check owner/group for the cached files and discuss it with him.

Thanks again.

8

With my ex-cyber security manager hat on…

It’s probably not just the cached files, I suspect that all of the files that comprise your web site should probably be owned by the web server process too, or at least have a group membership that allows the web server process to access them. The other files don’t get written to which makes it work, but the web server has to rely on the ‘other’ user permissions to get access to the files it needs. However, having to use 775 that means that any other user on the server can also access your files. As some of your files contain passwords and API keys that means they are exposed to anyone who goes looking. That may not be a problem depending on who else shares the server.

9

I temporarily changed permission for the Saratoga cache directory only, which allowed the file to be written. I checked the permissions for the PWS directories and the cache directories there do have different ownership/permission. Now I have identified the problem I will discuss it with my provider so he can tidy up the mess I’ve made :wink:

10

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.