New PHP Upload Process

[PaulMy]

From that MXdiags the PHP updates looks to be working fine (the period covered in MXdiags did not include a 15 minute interval update so can't confirm that, but web site seems to be updating fine, realtime.txt and webcam image every 15 seconds).

Enjoy,
Paul

[Nottub]

The diagnostic covered the period when .php was enabled. I had switched back to ftp to get it working again.

I have switched back to .php now and will leave it overnight. Not expecting it to work though.

Thanks

Martyn

[Nottub]

So following the witch back to .php the Gauges aren't updating.

Gauges page suggests the Station is offline with the time corresponding to the time I switched back to .php uploads.


Martyn

[Nottub]

Latest log whilst using .php

[mcrossley]

That last diagnostic shows that the upload.php file on your web site still has the default secret in it?

And your upload path starts with "weather/" that needs removing as the upload.php is already in the "weather" folder.

[Nottub]

Thanks Mark, I’ll look again. The .php screenshot from the earlier post in this thread was from the server version and contained the secret code that I copied from ‘Internet Settings’ within CMX when I was setting up the php upload option.

I thought I could use that code, being generated by CMX.

My sequence was that I copied the secret word from the‘Internet Settings’ page, pasted it in the .php file at the required position in the upload.php file in CMX then uploaded this amended upload.php file to my web server.

I have obviously misunderstood something

I’ll work through your instructions again.

With absolutely no updates to my website since changing back to php late last night, then I have clearly got it wrong.

Thanks

Martyn

[Nottub]

Here's a side by side comparison of the CMX version of the upload.php (right), and the server end version (left). The secret codes are the same! Not sure what the issue is now. I'll check out the location of the server end upload .php.

I do know that it sits in my 'www.calvertoncam.co.uk/weather' folder.

upload_php_comparison.jpg

I'll keep looking but not sure where to go next.

Martyn

[Nottub]

Moved a little further forwards.

Note line 31, I don't know how but the secret code also ended up in the error generation line . I was absolutely sure I'd only added it in line 15

I've copied a new version from my recent download folder in Rpi and added the secret code again.

Part success, 15 minute upload working OK, just need to look at my extra webfiles.

I'll say one thing about this group, now matter how dense you are (me),there's always someone out there to help you out/ point you in the right direction.

Thanks for all your help.

Martyn

[Nottub]

Does the 'upload.php' cope with .jpg files?

Although it is uploading to the server via the extra web files it is unreadable at the far end.

https://www.calvertoncam.co.uk/weather/ ... webcam.jpg

Any thoughts?

Martyn

[mcrossley]

It does upload JPGs, but you have to tell CMX that they are binary files rather than text - check the tick box.

[Nottub]

Mark, thank you.

Thanks for all your hard work and the other contributors.

Most of all thanks for answering my silly questions and helping out with my incompetence.

Greatest respect

Martyn

[jwpetrov]

Hello all:

At the present time I'm running CumulusMX on a Windows 10 laptop.

I was able to update CMX from b3235 to b3241 last evening (US MDT). I upgraded my version using HansR's installCMX program and it worked very well.

Once I verified the upgrade worked properly, I converted my upload to the PHP Upload option. Thanks to Mark's instructions, it went just fine.

I did see one issue in the MXdiags file: 2023-04-26 22:50:12.527 TestPhpUploadCompression: Error - An invalid request URI was provided. The request URI must either be an absolute URI or BaseAddress must be set.

It appears the files are transferring just fine even though I don't have gzip on the laptop or set up on my GoDaddy hosting account. Perhaps there is a way to get this working on a Windows laptop and the GoDaddy Linux hosting account. Otherwise it may have to wait until I have time to move CMX back to a R Pi. I just thought this was worth mentioning for others to know and/or pass along comments.

Jed

[freddie]

It is difficult to debug based on a single MXdiags logging message, as there is no context. It is best to upload the log file to provide context.

Compression and decompression are built in to both MX and probably your web server - there is no need to install gzip in either case. If compression is available on your web server it will be used by MX. In your case it appears to be available and working okay.

Your error to me looks like a configuration error in one of the upload paths. As things are running smoothly I guess you discovered and corrected it.

[jwpetrov]

It is difficult to debug based on a single MXdiags logging message, as there is no context. It is best to upload the log file to provide context.

Compression and decompression are built in to both MX and probably your web server - there is no need to install gzip in either case. If compression is available on your web server it will be used by MX. In your case it appears to be available and working okay.

Your error to me looks like a configuration error in one of the upload paths. As things are running smoothly I guess you discovered and corrected it.

Freddie:

Thanks for your reply. I've attached the full log file (20230426) to this message. I've also included the current log (20230427) that was created after restarting CMX.

Important notes:
1) This MXdiag was created just after I upgraded to b3241 (20230426)
2) Upload was changed to PHP but CMX was NOT restarted
3) I did NOT make any changes or restart CMX after seeing the error mentioned in the previous post
4) There are additional Errors in the (20230426) log that could be a result of not restarting CMX after switching to PHP. These showed up AFTER my previous post.

After errors showed up in the CMX diaglog box on the laptop, I restarted CMX and the current log (20230427) appears to be free of any errors as of this morning.

I'll be keeping an close eye on the log and will provide any updates if further errors are logged.

Thanks again...

Jed
SoJo Wx

[billy]

I changed from ftp to http/php on May 1 with build 3241. It worked very well ... I have two uploads at realtime interval (realtime gauges and a bespoke extra web file) and the elapsed time from start to finish for the realtime cyce went from about 1.4 seconds to 0.4 second.

When I upgraded to b3244 a few days ago these two files failed to upload with a 403 error. An example from the log file:

2023-05-26 18:40:26.192 PHP[120]: Uploading to realtimegauges.txt
2023-05-26 18:40:26.449 PHP[120]: Upload to realtimegauges.txt: Response code = 403: Forbidden
2023-05-26 18:40:26.449 PHP[120]: Upload to realtimegauges.txt: Response text follows:
<!DOCTYPE html>
<html style="height:100%">
<head>
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no" />
<title> 403 Forbidden
</title></head>
<body style="color: #444; margin:0;font: normal 14px/20px Arial, Helvetica, sans-serif; height:100%; background-color: #fff;">
<div style="height:auto; min-height:100%; "> <div style="text-align: center; width:800px; margin-left: -400px; position:absolute; top: 30%; left:50%;">
<h1 style="margin:0; font-size:150px; line-height:150px; font-weight:bold;">403</h1>
<h2 style="margin-top:20px;font-size: 30px;">Forbidden
</h2>
<p>Access to this resource on the server is denied!</p>
</div></div><div style="color:#f0f0f0; font-size:12px;margin:auto;padding:0px 30px 0px 30px;position:relative;clear:both;height:100px;margin-top:-101px;background-color:#474747;border-top: 1px solid rgba(0,0,0,0.15);box-shadow: 0 1px 0 rgba(255, 255, 255, 0.3) inset;">
<br>Proudly powered by <a style="color:#fff;" href=http://www.litespeedtech.com/error-page>LiteSpeed Web Server</a><p>Please be advised that LiteSpeed Technologies Inc. is not a web hosting company and, as such, has no control over content found on this site.</p></div></body></html>

This has been solved by turning the web server's modsecurity off ... not something that I really want to do permanently.

The response to the 403 issue from the web server manager was this:

The issue is that file being uploaded is triggering the web server security as the server doesn't know what sort of file it is or what to do with it so is rejecting it.
Message: Access denied with code 403 (phase 2). Test '&REQUEST_HEADERS:Content-Type' against '@eq 0' is true. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "369"] [id "920340"] [rev "3"] [msg "Request Containing Content, but Missing Content-Type header"] [severity "NOTICE"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [MatchedString "718"]
Basically the file is missing
Content-Type: text/plain
in the header of the file to say it is a valid txt file

Maybe there is another cmx setting that I have missed that would resolve this?