Cloudron Forum

@girish said in WordPress app container stuck on updating from package version 3.7.2 to 3.7.3:

This happens with apps which contains files that change their size when the backup is going on. ... Maybe you have some plugin that writes to somewhere periodically?

Thank you @girish Great advice and just the clue we needed. We figured out what that was, stopped it and then we could take a WP backup manually; and then we were also able to update to the latest packaged WP version 3.8.0

Thank you once again; your prompt help is much appreciated

You can mark this ticket as resolved; cheers!

Thank you @joseph for your reply

I did that; clicked on X to stop the current upgrade process (stuck on backing up); went to repair and clicked Retry task to get the app container back to a healthy, non-error state.

But... what it gets stuck on is the backup process; I tried twice to create a new backup and the process gets stuck at the same exact point 4304M into the backup, which I guess you must have expected would happen and why you suggested taking a server snapshot and then "skipping the backup" when I try upgrading the WP container to the next release. I guess you must also be hoping that post a successful update to the next packaged WP releases, the backup process will start working again, right? Is this common behaviour / have you seen this before with other apps and their upgrades?

Thank you @nebulon for your reply

I cloned another PeerTube app from a v2.16.0 backup, it upgraded ok to v2.17.0 but this instance gets stuck on Starting

Some lines from the Logs which seem relevant

Jul 18 23:11:41 2024-07-18 22:11:41,764 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message...

Jul 18 23:11:41 ==> Changing ownership

Jul 18 23:11:41 Could not connect to Redis at redis-d6625bc3-17a7-40ec-9b21-50eb3bf74b7e:6379: Connection refused

Jul 18 23:11:43 2024-07-18 22:11:43,973 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)<30>1 2024-07-18T22:11:43Z server redis-d6625bc3-17a7-40ec-9b21-50eb3bf74b7e 189870 redis-d6625bc3-17a7-40ec-9b21-50eb3bf74b7e - 2024-07-18 22:11:43,973 INFO success: redis-service entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

Jul 18 23:11:47 ==> Installing OIDC plugin
...
Jul 18 23:11:48 [<domain-name-removed>.com:443] 2024-07-18 22:11:48.518 info: Installing plugin peertube-plugin-auth-openid-connect.
Jul 18 23:11:50 => Healtheck error: Error: connect ECONNREFUSED 172.18.18.171:80
Jul 18 23:11:50 [<domain-name-removed>.com:443] 2024-07-18 22:11:50.438 error: Cannot install plugin peertube-plugin-auth-openid-connect, removing it... { <30>1 2024-07-18T22:11:50Z server d6625bc3-17a7-40ec-9b21-50eb3bf74b7e 189870 d6625bc3-17a7-40ec-9b21-50eb3bf74b7e - "err": { <30>1 2024-07-18T22:11:50Z server d6625bc3-17a7-40ec-9b21-50eb3bf74b7e 189870 d6625bc3-17a7-40ec-9b21-50eb3bf74b7e - "err": {
Jul 18 23:11:50 "stack": "Error: Command failed: yarn add peertube-plugin-auth-openid-connect@0.1.1\nwarning package.json: No license field\nwarning No license field\nerror /app/data/storage/plugins/node_modules/ffi-napi: Command failed.

Eventually it gets to this part:
Jul 18 23:13:17 => Healtheck error: Error: Timeout of 7000ms exceeded
Jul 18 23:13:27 => Healtheck error: Error: Timeout of 7000ms exceeded
Jul 18 23:13:37 => Healtheck error: Error: Timeout of 7000ms exceeded
Jul 18 23:13:43 => Healtheck error: Error: connect EHOSTUNREACH 172.18.18.171:80
Jul 18 23:13:53 => Healtheck error: Error: connect EHOSTUNREACH 172.18.18.171:80
Jul 18 23:14:03 => Healtheck error: Error: connect EHOSTUNREACH 172.18.18.171:80

Not sure where to take this next; no point restoring the original PeerTube app back to the v2.16.0 backup and upgrade again to v2.17.0 which is did successfully (and so did the new cloned instance); clearly something in v2.17.0 doesn't agree with however PeerTube is configured or what plugins we have running.

Hi guys,

I have another query if you could help please.

A PeerTube app "container" we use on Cloudron to host some training videos upgraded successfully from v2.16.0 to v2.17.0 and some hours later its status is Not responding as opposed to the healthy Running status.

We did a Restart App and also a stop and start in case this is different than a restart and still same outcome, Not responding.

There are some errors in the logs, quite a few hours after the successful upgrade; quite detailed information, so I've just pulled out the following which seems relevant (and was quoted on other posts on this forum):

Any ideas how we fix this please? I haven't yet tried enabling the recovery mode, I thought I'd ask for help first as the app failure is not something we generated through use of the video platform or indeed any configuration of it.

Thank you in advance.

Ovidiu

The above may be linked to Cloudron update to v8.0.1 as detailed here:
https://forum.cloudron.io/post/91544

But still, there must be a way to break the vicious update cycle on the WordPress app "container" because when I go into Settings, under Updates and I click the Updates Available button it tells me there are apps blocking the Cloudron update and I should wait for these operations to finish first:

@girish said in What's coming in 8.0:

w00t, I have fixed the long-standing issue of backups getting stuck (usually, it would says @0Mbps) . Fix is in 8.0.1 (not released).

@girish Bingo! We might be affected by that very issue: backups getting stuck @0Mbps (in the middle of a managed WP version upgrade, all be it a minor upgrade)
Just logged this ticket
https://forum.cloudron.io/topic/12123/wordpress-app-container-stuck-on-updating-from-package-version-3-7-2-to-3-7-3

If the fix is to upgrade to Cloudron v8.0.1, I'll need to look at that because just like @eddowding we are currently running v7.7.2 (due to our, let's say, lack of human resources and time)

Thank you, guys! Great forum and community here, and not for the first time!

Hi guys,

Could you assist with the following please?

We run a number of WordPress "app" websites on Cloudron, all but one have updated successfully to package version 3.7.5. One website, our main one, hasn't and I've just noticed it's been trying and failing to update from 3.7.2 to 3.7.3 daily for a few weeks.

The app is currently stuck on:

We can't stop the app (print screen does not capture the "not allowed" mouse cursor when hovering over the Off button):

Nor can we use any of the buttons on the Repair tab, likely due to the app being in the middle of trying to update the packaged WP version:

Nor can we take a fresh backup of the website, which is up and working despite the following message:

On the Cloudron My App home page we see the app is Updating:

It started the update process probably over 12 hours ago, it will fail at some point and then start again; it looks as follows:

How do we safely break the vicious cycle please?

Incidentally, I see we also have a notification for Cloudron v8.0.1 being available; a Reboot required notification is also present to finish the Ubuntu security updates; I was under the impression that these reboots happen automatically, but maybe they don't and we have to initiate them manually as our uptime show as "a year" and our platform version is v7.7.2.

Your help, advice and guidance are much appreciated.

Thank you in advance.

THI Staff

For future readers, the error was that the domain was not hosted on GoDaddy

Correct; we were hosted on GoDaddy, but created a subdomain for another website, which we moved to another hosting company, we moved the domain there in the process and then forgot to update the Cloudron domain setup to change the provider from GoDaddy to Cloudflare.

Great support by the way, I must say; I work in IT support myself, but web hosting is not my main expertise

@girish All sorted; schoolboy error on my part. Thank you again

I've just sent an email with the supporting information to support@cloudron.io
Thank you in advance

Perfect, thank you @girish I saw that drop down, all items are green, but did not click on any of them; will do and then email you guys.

@girish Thank you very much for your prompt reply
Where are these certificate logs please? If you can advise please, I shall collect them and send an email to the address you provided
Thank you again

Hi Cloudron guys and forum

One of our website certificates is failing to renew; we have 2 websites hosted on Cloudron, both with the same setup, both on GoDaddy, one is fine, the other isn't (expired certificate error).

We renewed all certificates manually in Cloudron 3 times today, the Renew section shows all green, yet under the Event log we can see the certificate for one of the website is failing to renew / apply.

This is something for Cloudron to fix, right? And how do we log a formal support call with Cloudron as I really don't want to share sensitive details here?

Thank you all.

THI Staff

@luckow Thinking about it, maybe it was Postal that I came across before and didn't save that webpage; it certainly wasn't on postalserver.io, the webpage had a different design and look and feel, but the content and complexity of the technical setup seems pretty similar; thank you again.

@girish @ekevu123 @crazybrad Thank you for that; Postmark was next on our list to try; in fact I did save a link to some of their documentation which was so detailed that it looked well worth referencing at a later stage.

@crazybrad What about the DMARC Monitoring optional add-on (starting at $10/month per domain, is that worth getting as well?

@luckow We'll have a look, thank you; may need some good research on github, but learning a lot about mail delivery certainly sounds helpful; we did briefly consider building our own email server; I did find a very good link / article on setting up such an email server on a non-Windows server, starting from some Cloudron forum searches, but sadly I did not save that link; it did start with explaining many basics and advanced concepts about mail delivery before going into the email server setup; I didn't think we'd ever need to consider that.

It seems we found a way forward, using a different mail relay provider; fundamentally the process is the same, but if there is a difference in the technical implementation then it is the fact this new provider requires CNAME records to be created instead of TXT records for SPF and DKIM as was the case for MailJet; and the emails land in the inbox now. Moral of the story perhaps being that if you fail once, get up and try again.

Hi Cloudron Forum!

We have 3 websites hosted on Cloudron, I'll detail some email scenarios where we'd appreciate some advice / guidance from those of you who have been there already.

domain1
Manual DNS setup in Cloudron, but in Email | Status tab all is green (MX / DKIM / SPF / DMARC / PTR / outbound SMTP direct / IP address not on a blocklist)
Email relay on Outbound tab is via Built-in SMTP server
When emailing an Office 365 / Exchange Online mailbox our emails get delivered to Junk Mail; analysing the email header there is only 1 issue: DKIM Authenticated (this according to mxtoolbox); namely, from the mxtoolbox report:

dkim:domain1:cloudron-<domain1_domainkey>
DKIM public record (in green)
v=DKIM1; t=s; p=MIG...<long alphanumeric string>
DKIM signature (in red)
v=1; a=rsa-sha256; c=relaxed/simple; d=domain1; s=cloudron-<domain1_domainkey>; h=from:subject:date:message-id:to:mime-version; bh=<some body hash string>=; b=<some other long alphanumeric string>=
PS: The failed test is "DKIM Signature Body Hash Verified" and the result is "Body Hash Did Not Verify".

Why would the DKIM Authenticated element be flagged as an error? Our DKIM record is correct, so the DKIM email signature should be derived from it without any issues; the email in question is DMARC Compliant, but still it ends up in Junk on O365.

As an aside, I must note the email was sent with rich text formatting; if the email is sent to Hotmail in plain text, the email headers check out perfectly, green all round, yet the outcome is the same, still gets labelled as spam. Now, why would plain text or rich text have any bearing on the DKIM Authenticated element passing or failing as far as mxtoolbox analyse headers is concerned, to me this makes no sense at all. But it does seem to suggest the outcome is driven by something else, not just the technical setup per se.

If from Roundcube webmail we email any icloud.com address we get this bounceback message:

Final-Recipient: rfc822;<name>@icloud.com
Action: failed
Status: 5.7.0
Remote-MTA: mx02.mail.icloud.com
Diagnostic-Code: smtp;554 5.7.0 Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=<our IP address>

So whilst Cloudron says our IP address is not on a blocklist, icloud.com must have us blocked, right? Is O365 blocking us as well?

Let me link the 2 scenarios together with a surprising outcome; we have a free Mailchimp account for domain1 (we email our paying members), where domain1 is verified and authenticated as an email domain. From there we can send to icloud.com just fine (likely because Mailchimp is the sender on our behalf, so emails don't go out from our IP address) and we can deliver emails to O365 Inboxes too (the surprising element being that if you analyse the O365 email headers it's a Christmas tree of red lights: DMARC fail, SPF fail, DKIM fail, yet it gets to Inbox?!). What's the moral of this story? Mailchimp good, our Roundcube webmail bad? I'm specifically interested in deliverability to O365 and other enterprise grade email systems. Our emails get to Junk in Hotmail too, regardless of plain text or rich text, which is what makes me think that sender reputation or being blocked are just as, if not more important than our technical setup being correct, which it is.

Finally, on domain3, same setup as domain1 with the exception of a GoDaddy automatic Domain / DNS setup in Cloudron, we get pretty much the same issues, outgoing emails go to Junk. The plain text "trick" when emailing O365 does not yield a perfectly clean mxtoolbox email headers analysis, but then it seems this is not enough any way for a successful Inbox delivery. We have tried to relay through a free Mailjet account on domain3, but this was a waste of time as ultimately we discovered that the underlying Mailjet mail server was blacklisted on 2-3 sites hence the waste of time.

So, how can we send legitimate emails out successfully from Cloudron and have them reach recipients' Inboxes? We are not spammers, nor are we selling anything, so I'm keen to cover all the bases and tick all the boxes. The emails we want to send are directed at specific people to raise awareness of various topics (one email and that's it, pretty much); they engage with us, fine, they don't, fine again, bu I mention this because we can't use Mailchimp as the T's and C's of that platform (as well as others presumably) are that you can only email subscribers (and our intended audience are not subscribers, but one off / hand picked people) or else you fall fault of spam rules and legislation, hence why we are staying clear of that.

Are there other free mail relay services which can be relied upon? Or does one need to get a paid service for that level of service and end result, i.e. Inbox deliverability? At the moment, given the hit and miss results and baffling analysis of email headers, I must say I'm not really sure.

Thank you for reading and thank you in advance for any ideas / advice you have; hopefully this post proves helpful to others as well.

THI Staff

@girish Yes, all sorted, thank you for asking.

Thanks to @robi's suggestion all we needed to do was the following:

• in terminal window for our WordPress app, at /app/code/wp-content/uploads we created a symlink (ln -s /media/ovitest ovitest) and then updated its permissions, just in case (chown -R www-data:www-data ovitest)
• then we could access the mp4 at https://<our_web_domain>/wp-content/uploads/ovitest/Red-cloud.mp4

Thank you very much all; we did enjoy finding the fix in the end. And of course we will make good use of it as we can now keep 10-20 GB of data, or even more, outside the WordPress data container, so out of the backup, but still reference this content on our website, which is great.

@robi That makes a lot of sense, though we've not seen any of this mentioned in the Cloudron documentation.

I will talk to our WordPress developer though he is new to the Cloudron packaged WP container deployment so if anybody can detail further what exactly is required for the following 2 steps, we would be very grateful indeed. Of course we'll have a go ourselves as well. Thank you @robi

"However now you have to map the mount dir to something the webserver can read and have access to.
For WP that means something like an additional dir in the wp-content/uploads/ tree that links to the /media/ovitest mount path."

Hi guys

Please could you help with the following; thank you very much in advance.

We've done out homework using both Cloudron and forum resources, see links below (thank you to all who documented their prior experience and troubleshooting):

• https://docs.cloudron.io/volumes/#filesystem-mountpoint
• https://docs.cloudron.io/apps/#mounts

We created a volume, we presented it to the WordPress app container / website, but we are not able to access an mp4 hosted on the volume from within WordPress to display the mp4 on a website page or post.

Here is what we've done:

• In Cloudron Volumes, we created a volume called ovitest of type Filesystem and pointing to /srv/ovitest (we created this folder on the host first using FileZilla); permissions were assigned to root, as one would expect
• In one of our WordPress Cloudron containers / websites, on Storage tab under the Mounts section, we added the volume ovitest with Read and Write permissions
• As per advice from https://forum.cloudron.io/topic/5747/volumes-are-not-working/8 we figured out that our cloudron user and group equivalent on our setup is www-data, so we ran "chown -R www-data:www-data /media/ovitest" to change permissions on the new volume, we confirmed from FileZilla that this change applied succesfully and plus, checking other hosted apps / systems we have, we noted the same Owner of www-data elsewhere so we are confident that the mount is set up correctly from a host / Cloudron perspective
  NB: We were slightly surprised by the chown command using /media/ovitest given that we set up the Filesystem volume with /srv/ovitest, but the chowm command worked. Also when we run "ls -lah /media" in the Terminal for the website, we do get ovitest returned in the results.

Now, trying to access the mp4 file from the WordPress site, we can't figure out what the correct URL or UNC path is; we tried /media/ovitest/Red-cloud.mp4 which is correct from a Cloudron perspective, but it does not load in a video WordPress object (because the mp4 can't be found or accessed); we also tried https://<our_web_domain>/media/ovitest/Red-cloud.mp4 but this does not work either (mp4 can't be found or accessed). We confirmed the mp4 has correctly inherited the www-data user and group permissions, so we are out of ideas, hence asking you guys for advice.

Not sure if we also need a symlink created as detailed here https://forum.cloudron.io/topic/7619/filesystem-mount-inside-container/5 but our website is not showing under /home for root as benborges detailed in his post; so this may not apply to us.

Finally, as mentioned here https://forum.cloudron.io/topic/7619/filesystem-mount-inside-container/11 we also ran "chmod 777 Red-cloud.mp4" but this made no different as far as accessing this file from WordPress.

Your help and assistance is much appreciated, thank you again.

THI Staff