Separate from the ability to manually reconfigure apache after the default install?
The container exposes a port, 80 in this case. This 80 is hardcoded as httpPort in the manifest.
Thinking more, maybe what you mean is: disable apache altogether, I will run something else on port 80. If this is the case, you are right that manifest does not need to be changed.
I don't think we will support this though. It's not a normal flow to install LAMP and then disable apache as first step and run something else. This works for your specific situation only because you don't want a database or expose another port. What if I want postgres? Java? At this point, you will install everything into a data directory and run it from there. This is really not in the spirit of Cloudron.
After checking with different formats. Only started to work as it should with ".tar" format. It works like lightning with a new folder or in the current folder where the application is located.
With this format, the extraction takes in a second and is ready.
And I use a server from Hetzner - CX41 (Intel, 160GB Disk and 16GB RAM).
I would still add that I had resources allocated during the test: 4GB ram and 75% CPU. I still checked with the standard one, i.e. 256MB ram and 50% CPU - with ".tar" format it extracts just as fast.
If you don't care to use the proxy features in LAMP via Apache2, you can launch the App-Proxy app from the App Store and configure it on a new subdomain to proxy to any of the LAMP installed apps on local ports via the internal Cloudron IP, ie. http://172.18.xx.xxx:port (make sure to use HTTP and not HTTPS).
You can get the internal IP from the web terminal by typing hostname -i
I assume you are asking this for security reasons.
Hey @girish. Thanks for your reply. Actually it depends!
For MySQL: It's a matter of running not into backup import/export stuff or facing data losses because of some DBMS bug. So there I just prefer to having a up2date DBMS because in the past I faced one or two major issues with productive software where patching the systems could have prevented it.
For apache2: Yes, I think no application really relies on the version nor it's super likely to hit a bug in it. Of course I faced apache2/nginx module bugs in the past but that's quite rare. Nevertheless it would help to have an up2date version at that point as well to prevent cases like that and sometimes security issues are fixed there as well.
For PHP: Indeed this is the most relevant part for your deployed websites. In the past I just had to care about major PHP releases; minor versions never broke anything for me and had never been a requirement for any software I saw. Of course, security matters here as well.
Thanks for clarifying which software of LAMP is managed by the platform/OS and which is managed by Cloudron itself. That gave a better insight for me.
@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.
@JLX89 Is the use to access the real client IP in php code ? If so, Cloudflare sets the CF-Connecting-IP header. You can just access that in PHP as $_SERVER["HTTP_CF_CONNECTING_IP"] . If the issue is apache logs, I think just replace X-Forwarded-For with CF-Connecting-IP will do the trick.