Cloudron Forum

@girish Thank you so much!
This was the simple update method I needed to save a lot of headache. We'll need to edit some things to get ready for 8.1, but know it's as simple as editing a file and rebooting the app is such a relief.

Thanks again!

@girish We're on

App Title and Version
LAMP (PHP 7.3) PHP 7.3
Package Version
lamp.cloudronapp.php73@2.0.0-1

It used to be each php version was another package altogether, and you had to migrate to a new package.
We needed support before because the mysql import kept timing out (Johannes told me "For information, there was a REST api timeout hit in the mysql addon, which was hard-coded to 10min.") Ideally that's completely resolved, but I'm bracing myself for the worst again!

I am very glad that going forward changing the PHP version will not require moving to a new LAMP package (that seems like a pretty important design flaw that is now resolved).

@girish Thanks, Grish. This is what I previously had to do to move from 7.2 to 7.3 and it was such a large hassle (requiring a support ticket and manual help from you guys to make the package accept the large backup!) that I avoided ever doing it again. That's why I'm so grateful there's a new package that will handle changing PHP versions a lot easier!

That said, I'm still dreading the downtime and the liklihood that the new package also won't be too pleased about importing such a large backup.

I wonder if there's any reason I couldn't just manually update the PHP version for the app via the console?

Hello,

First, I am very glad to see that Cloudron now has a single LAMP package which allows changing the PHP version internal to that package. It was very frustrating when I had to change PHP versions previously and move my giant LAMP package to a new one involving days of downtime for my site.
Now, I'm looking at having to do that again. Is there any way to upgrade from a LAMP 7.3 package to the current LAMP package without shutting off my site, doing a backup, downloading the backup, and the uploading it to a new LAMP package?
The last time I had to manually migrate from one LAMP package to another there were many server errors because the site's database is so large and in the end Johannes had to make the migration for me (after 3 days of emailing back and forth).
If I can avoid that hassle at all, I would love to!

Hey @girish - is this still on the roadmap for some time in the future? If so, do you have an idea of when it's likely to be set up?

@jdaviescoates Yes - which also occurs if you add new domains/subdomains to an app while the app goes down to reassociate everything with itself. This meant that my live site was displaying this message briefly yesterday (the more domains/subdomains you have connected to the same app for legacy reasons the longer it takes that process to complete...)

Is there a simple way to change/rebrand the "You found a Cloudron out in the wild!" page that displays from time to time when different things happen?
If not, perhaps this could be moved to the suggestions forum - as it feels like a good addition to the "Basic Branding" feature set.

@marcusquinn Thanks for this. I deactivated even the add-ons that felt trustworthy and moved to a default theme (since that wordpress is really more of an archive than an active site). I also ran the scan you suggested and found that one add-on that I deactivated, and a theme, were both had scripts in them with known issues.

I wonder if a suggestion for the cloudron managed wordpress package is rate limiting external calls?

@iamthefij Thanks - it seems to be have been one of the wordpress instances (this memory spike corresponds to the same times the CPU spiked for the attack).
However, it's a Managed wordpress instance and so autoupdates are disabled (as cloudron does these updates) - I have no plugins installed on it.

@mehdi Have two wordpress apps, a webmail app, and two LAMP apps running Xenforo.

@nebulon Thanks for the quick reply!
They provided logs (which I'll leave at the end of this reply), but they don't seem to give enough information if it's a host system compromise or an app.
/root/.ssh does not have any authorized keys listed (which I take as a good sign).

we detected a DOS attack from your network.

Below the logs.
172.105.104.122 - - [23/Nov/2020:15:43:33 +0100] "GET /wp-login.php HTTP/1.0" 200 1296 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:15:43:35 +0100] "POST /wp-login.php HTTP/1.0" 200 1659 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:15:43:36 +0100] "GET /wp-login.php HTTP/1.0" 200 1296 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:15:43:37 +0100] "POST /wp-login.php HTTP/1.0" 200 1669 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:15:43:38 +0100] "POST /xmlrpc.php HTTP/1.0" 403 212 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:33 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:34 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:35 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:36 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:37 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:37 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:38 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:39 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:39 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:40 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:41 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:41 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:42 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:43 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:44 +0100] "POST /xmlrpc.php HTTP/1.0" 403 212 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

Please take action as soon as possible. The destination IP of the attack from your network is: web.mercurio.vhosting-it.com

Hello,

I use Cloudron in part because managing a VPS is outside of my usual comfort zone. I was gravely concerned when I received an email today from Linode suggesting my VPS had been used to attempt some sort of brute force/DoS attack targeted at another site. I rely on Cloudron to ensure the general security of the VPS, and my root password is quite secure (generated from a password manager and only saved there). I've changed the root password, but am not sure of what next steps I should take, or how I can prevent this in the future.

@girish said in Elasticsearch:

Indeed, current plan is to implement Elastic search as an addon and not as an app.

Hey Grish - this sounds good, and exciting! I noticed that Elasticsearch has been on the roadmap for some time and am wondering if this is something we're likely to see in the Cloudron 6.x series, or if it's much further down the road yet?

Perhaps my understanding is erroneous, but I was under the impression that apps in containers aren't able to interact with each other on the server and so these things would have to be in the same container to engage with each other appropriately.
However, as I review the documentation using Elasticsearch with the forum software I'd be attaching to it, I realize that as long as the container is able to access the port necessary it should be fine - in which case, I guess I'll just wait patiently for an Elasticsearch app to be available!

Hello,

I've seen that there's some conversation about adding Elasticsearch to Cloudron - which is great, but it reads like the plan is to have it in its own container, which for my usecase would not be great.

Is it possible for me to install it through the console in my LAMP app? I tried to use apt-get to do so (following these directions ), but to no avail.

@makemrproper yes, I think this method isn't going to work for me. Especially if it still refers to the old app's database. (Though, if that's the case, I'm not sure why it continually fails due to a MySQL disconnection error) I'll just transfer the files and the database myself. Seems like way less headache!

I tried to migrate to 7.3 using the steps provided above - and all seemed to be working swimmingly until it errored out with "ECONNRESET" importing the mysql DB.
It's a very large mysql DB (5.8 GB). Any idea why the connection might reset (the backup is on a linode volume connected to the local filesystem)? Or a way to go about upgrading this app without hitting the same error again?

EDIT: To make matters worse, I also can't uninstall the app where I tried to do the upgrade for likely the same reason. Error was: " Error : Addons Error - Error tearing down mysql: socket hang up "

EDIT 2: I resolved, at least the uninstall problem, by allocating more RAM to mysql. Seeing if that solves the over all problem now!

To be clear: When you say "The approach would be to restore from an app backup into a new instance of the lamp app with php 7.3"
Do you mean that I do the normal stuff of downloading the DB, copying over all the files, then editing DB/redis credentials across the app - or do you mean download the backup file for the LAMP app the Cloudron supplies, create a new LAMP app, and use the "import from external file" function?

When I set up my app, I chose the LAMP app that just said "LAMP" and not one that specified the version - and am now realizing that I should have chosen 7.3 specifically.
So, I'm wondering if there's an easy way to update the PHP in that app without needing to create a new app (with new database information, new redis information, etc.).