Welcome to the Cumulus Support forum.

Latest Cumulus MX release 3.28.5 (build 3282) - 23 February 2024

Legacy Cumulus 1 release v1.9.4 (build 1099) - 28 November 2014 (a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)

Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki

New PHP Upload Process

From build 3044 the development baton passed to Mark Crossley. Mark has been responsible for all the Builds since. He has made the code available on GitHub. It is Mark's hope that others will join in this development, but at the very least he welcomes your ideas for future developments (see Cumulus MX Development suggestions).

Moderator: mcrossley

User avatar
PaulMy
Posts: 3732
Joined: Sun 28 Sep 2008 11:54 pm
Weather Station: Davis VP2+ Cumulus1 / CummulusMX
Operating System: Windows8 / Windows10
Location: Komoka, ON Canada
Contact:

Re: New PHP Upload Process

Post by 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
Davis Vantage Pro2+
C1 www.komokaweather.com/komokaweather-ca
MX www .komokaweather.com/cumulusmxwll/index.htm
MX www.komokaweather.com/cumulusmx/index.php
MX www.komokaweather.com/cumulusmx/index.html

Image
Nottub
Posts: 164
Joined: Fri 04 Dec 2020 4:35 pm
Weather Station: Davis VP2 (Cabled)
Operating System: RPi 4
Contact:

Re: New PHP Upload Process

Post by 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
Image
Nottub
Posts: 164
Joined: Fri 04 Dec 2020 4:35 pm
Weather Station: Davis VP2 (Cabled)
Operating System: RPi 4
Contact:

Re: New PHP Upload Process

Post by 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
Image
Nottub
Posts: 164
Joined: Fri 04 Dec 2020 4:35 pm
Weather Station: Davis VP2 (Cabled)
Operating System: RPi 4
Contact:

Re: New PHP Upload Process

Post by Nottub »

Latest log whilst using .php
You do not have the required permissions to view the files attached to this post.
Image
User avatar
mcrossley
Posts: 12505
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: New PHP Upload Process

Post by 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
Posts: 164
Joined: Fri 04 Dec 2020 4:35 pm
Weather Station: Davis VP2 (Cabled)
Operating System: RPi 4
Contact:

Re: New PHP Upload Process

Post by 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
Image
Nottub
Posts: 164
Joined: Fri 04 Dec 2020 4:35 pm
Weather Station: Davis VP2 (Cabled)
Operating System: RPi 4
Contact:

Re: New PHP Upload Process

Post by 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
You do not have the required permissions to view the files attached to this post.
Image
Nottub
Posts: 164
Joined: Fri 04 Dec 2020 4:35 pm
Weather Station: Davis VP2 (Cabled)
Operating System: RPi 4
Contact:

Re: New PHP Upload Process

Post by 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 :roll: . I was absolutely sure I'd only added it in line 15 :bash: :groan:

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. :clap:

Thanks for all your help.

Martyn
Image
Nottub
Posts: 164
Joined: Fri 04 Dec 2020 4:35 pm
Weather Station: Davis VP2 (Cabled)
Operating System: RPi 4
Contact:

Re: New PHP Upload Process

Post by 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
You do not have the required permissions to view the files attached to this post.
Image
User avatar
mcrossley
Posts: 12505
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: New PHP Upload Process

Post by mcrossley »

It does upload JPGs, but you have to tell CMX that they are binary files rather than text - check the tick box.
Nottub
Posts: 164
Joined: Fri 04 Dec 2020 4:35 pm
Weather Station: Davis VP2 (Cabled)
Operating System: RPi 4
Contact:

Re: New PHP Upload Process

Post by 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
Image
jwpetrov
Posts: 15
Joined: Sat 19 Oct 2013 1:24 pm
Weather Station: Davis Vantage Pro2
Operating System: Windows 10 22H2 64 bit
Location: South Jordan, Utah
Contact:

Re: New PHP Upload Process

Post by 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
Posts: 2394
Joined: Wed 08 Jun 2011 11:19 am
Weather Station: Davis Vantage Pro 2 + Ecowitt
Operating System: GNU/Linux Ubuntu 22.04 LXC
Location: Alcaston, Shropshire, UK
Contact:

Re: New PHP Upload Process

Post by 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.
Freddie
Image
jwpetrov
Posts: 15
Joined: Sat 19 Oct 2013 1:24 pm
Weather Station: Davis Vantage Pro2
Operating System: Windows 10 22H2 64 bit
Location: South Jordan, Utah
Contact:

Re: New PHP Upload Process

Post by jwpetrov »

freddie wrote: Fri 28 Apr 2023 7:30 am 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
You do not have the required permissions to view the files attached to this post.
User avatar
billy
Posts: 255
Joined: Mon 30 Nov 2015 10:54 am
Weather Station: WLL / Davis VP2+
Operating System: RPi bullseye
Location: Gooseberry Hill, Western Australia

Re: New PHP Upload Process

Post by 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?
Post Reply