@girish In the meantime there were already several official, stable releases of statping-ng. The last one was 6 days ago (v0.90.80)
cfr this link.
So I suppose there is no reason anymore to stay with the original statping (for which the latest version was released in december 2020) ?
@girish hmmm, I see, but imagine the following scenario:
Our clients come to us for developing a new Wordpress website and obviously they also want an integrated email system so they can send and receive mails for that website and probably they also want to see some analytics.
So we set up a separate cloudron for such client and install Wordpress for the website, SOGo (or one of the other webmail apps) for the email and Ackee for the analytics.
This means the cloudron is dedicated to the client and therefore the trusting factor is there since the client is the only party that makes use of the cloudron and its apps.
However, our clients aren't interested in administering the cloudron themselves so we will manage it for them. But they do want to be able to add extra email addresses when needed.
So the client will get the mail manager role while we are the admin of the system. In this scenario it doesn't make sense - and isn't even desirable - that the client can see our admin user.
So while I definitely understand your explanation, I hope you can see my point as well 
@girish I see, but I wouldn't expect any solutions from the old, abandoned ticket 
Maybe you can open a new ticket at statping-ng?
After Nextcloud was automatically upgraded from v23.0.2 to v23.0.3 we started getting issues with up- and downloading of files and even opening of files in the browser.
We're using server-side encryption and a Hetzner storage box over sshfs for the data dir.
Further investigation learned that there was an issue with the encryption/decryption on the server.
The exact error we got was:
Encryption not ready: multikeydecrypt with share key failed:error:0407109F:rsa routines:RSA_padding_check_PKCS1_type_2:pkcs decoding error
Apparently some of the keys were changed in our data dir (the mounted external storage). Luckily we found older, correct keys in the original data dir of the cloudron app (i.e. inside yellowtent).
After replacing the keys on the mounted storage with the older keys from the original data dir everything started working again.
Since there are a lot of encryption related tickets in the Nextcloud repository I mentioned my issue and resolution as a response on one of the still open, relevant issues: https://github.com/nextcloud/server/issues/8349.
But I'm also reporting it here in case it's related to the cloudron packaging and/or someone else here is experiencing similar issues.
Is it possible to use a single domain, let's say example.com, with 2 (or more) cloudrons?
The use case would be to host multiple applications for the same company each on their own server, e.g. websites on one server and forum and mail on another server.
Note: I'm new to Cloudron and I really like it so far, but I'm having some specific use cases and it's not clear to me whether Cloudron is a good fit for them.
According to this thread DoT support was added in v1.2.0 of the AdGuard package (with Cloudron 6.2).
The Cloudron package documentation however still mentions that DoT is "not yet supported"
Therefore I decided to just try it out and after some fiddling with OpenWRT and stubby in particular I was able to get DoT working.
So I guess Cloudron's AdGuard documentation can use some extra love regarding DNS configuration
@girish That definitely sounds like an interesting solution, except that in my use case it's not (entirely) related to automation / programmatic access. So I guess it will also need some UI changes.
Ok, so I was correct when I said I seemed to remember there are some limitations with CF proxy and subdomains in the free plan.
When trying to open a ticket with CF regarding this issue I was pointed to the following link on their community:
https://community.cloudflare.com/t/subdomain-too-deep/81872
The certificates available with the free account (universal certificates) cover only one level of subdomains so my.domain.tld is covered, but my.sub.domain.tld isn't.
@girish actually both.
Visually, because it doesn't make sense to show admin users to mail managers when they can't do anything with them.
But also security wise because in my opinion users with a lower access role (in this case mail managers) shouldn't know any (sensitive) details about users with a higher role (in this case admins), e.g. username, email address, ...
We all know passwords shouldn't be reused for different accounts/logins but I'm sure usernames are and therefore I think it's better to not show such data to others when that data isn't relevant for them.
@girish actually we have similar use cases.
First of all sender/ip reputation. Some apps send emails in bulk and/or to unverified email addresses while others only send transactional emails to known/verified addresses. Therefore we want to use different email servers/systems for them.
In addition, some apps use email templates built within the mail service and therefore need to send out emails via that particular service, while other apps don't need to / shouldn't send via that service.
The same for newsletters: they have to be sent via a specific service.
Great to hear you implemented this functionality already!
@robi Yes, I tried it but it's too locked down. There were several plugins that didn't work, e.g. some security plugins.
Ok, I thought the whole point of the developer package was to have a "regular" version of Wordpress where you have more permissions and control over the code (such as plugins, themes, ...) similar to packages of other apps (NextCloud, Matomo, whatever) and that the managed version of Wordpress was to have a locked down version for security reasons.
But actually it seems none of the 2 Wordpress packages work in a similar way as the packages for other apps, since the managed version is a locked down version and the developer version is a "do it yourself" version.
Is that correct?
If so, then why is there no regular version of the Wordpress package where the core (i.e. Wordpress itself) is updated, similar to other Cloudron apps, while the plugins and other stuff are up to the user (again, similar to other Cloudron apps)?
Take for example Nextcloud:
When there's a newer version of Nextcloud a new Cloudron package is prepared and after updating to that new package Nextcloud is at the newer version. Nextcloud plugins/addons are not updated and should be managed by the user.
Why isn't this behaviour applicable to (one of) the Wordpress package(s)?
Hi all, this isn't pretty much about how to keep Wordpress up-to-date or secure but about how Cloudron updates it (or not).
As I said, Cloudron DOES update the package to the latest version so it is expected that the version number is increased. If that is not the case then what's the point of updating it.
I'm sorry, but I still don't get it.
Of course I can enable auto-updates in Wordpress, of course I can use MainWP, ManageWP and others to keep Wordpress and its plugins and themes up-to-date, but that's not the point of this topic.
I see, but then I still think there's something fundamentally wrong with the versioning of the developer edition.
I understand it's unmanaged and I also understand the difference between managed and unmanaged, but unmanaged doesn't necessarily mean unmaintained.
So if there is an update for the developer edition then it's still expected the app is automatically updated, because that's what Cloudron tends to do: keep apps updated to their latest (packaged) version.
And in fact Cloudron DOES update all packages automatically (unless you manually turn this feature off).
Moreover, according to the Cloudron store the package "org.wordpress.unmanaged.cloudronapp@2.14.4" contains Wordpress 5.9.2 whereas "org.wordpres.unmanaged.cloudronapp@2.14.5" contains Wordpress 5.9.3.
(this is a screenshot from the Cloudron store for the Wordpress Developer package org.wordpres.unmanaged.cloudronapp@2.14.5)
So if my Cloudron updated my Wordpress Developer package from org.wordpress.unmanaged.cloudronapp@2.14.4 to org.wordpress.unmanaged.cloudronapp@2.14.5, which it did, then Wordpress is in fact updated from v5.9.2 to v5.9.3 according to this information.
And the updates section in the Cloudron dashboard confirms this (cfr screenshot in my initial post).
So as a result of all this I still expect the version in the Wordpress admin area to be v5.9.3 and not v5.9
That the plugins aren't automatically updated is to be expected since it's the unmanaged version of the package, but not so for the core of the software.
There seems to be an issue with the version string in the Wordpress Developer package:
I have several Wordpress Developer sites and while they are all up-to-date according to the Cloudron dashboard (v5.9.3), Wordpress sees them as v5.9 and says there is a newer version available.
Version info in Cloudron dashboard:
Version info in Wordpress:
For the Managed Wordpress sites everything seems to be fine.
@girish thanks for updating the docs.
On my Android phone (Android 10) I can't get it working for the moment, I get "unable to connect".
But it's definitely an issue on my end since I have it working on my router.
Anyway, it's not a big deal since my phone is behind my router most of the time.
According to this thread DoT support was added in v1.2.0 of the AdGuard package (with Cloudron 6.2).
The Cloudron package documentation however still mentions that DoT is "not yet supported"
Therefore I decided to just try it out and after some fiddling with OpenWRT and stubby in particular I was able to get DoT working.
So I guess Cloudron's AdGuard documentation can use some extra love regarding DNS configuration
@msbt no worries, I'm glad I for once can share my own solution to this great community
Most of the time it's the other way araound 
Anyway, you have a point that Nextcloud's server-side encryption probably isn't worth it and therefore I'm also experimenting with Seafile, which has the possibility of client-side encrypted libraries. And in my (short) experience so far it is much much faster.
But unfortunately Seafile isn't currently available on Cloudron.
@msbt Hey, yes I was lucky that I kept the original data.
But if you have backups - which I hope you do - you can probably recover the correct keys from those backups
Thing is that you should only restore the keys and nothing else from the backups, otherwise you might get more trouble than you currently have 