great, it works! thanks

https://broadcast.mexina.fr/

@robi said in Allow custom ports:

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.

I am back after a small test.

@timconsidine Yes it is a large number of small files.

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).

EDIT:

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.

@micmc yeah, most likely it's the app. Maybe just grep through the code for errors.log ?

I see. Thank you for the explanation. I wasn't aware of the Ubuntu-specifica.

great, now you can mark this as a question/solved from the top post menu.

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

@girish said in PHP8.1 outdated (PHP v8.1.19 current):

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 it works with both values!!!! thank you so much for your help and patience, girish! 🙂 i will leave it as 'strict-origin-when-cross-origin'

@oschelde can you give us more context? Why do you want to add www-data to another group? I can't think of a practical situation where this is needed on Cloudron.

@girish Thank you!

@girish Thank you -- that actually seems to have solved the issue for now!

@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!

@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.

LogFormat "%{CF-Connecting-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" proxy CustomLog "|/bin/cat" proxy ErrorLog "|/bin/cat"

See also https://stackoverflow.com/questions/14985518/cloudflare-and-logging-visitor-ip-addresses-via-in-php and https://stackoverflow.com/questions/29558009/logformat-for-cloudflare-in-apache

Seems fine, not sure what the root cause is then. You could give us remote SSH access to take a direct look https://docs.cloudron.io/support/#remote-support and send us a mail to support@cloudron.io with your dashboard domain.

@girish That works great! Many many thanks for you prompt support!

@jayonrails yes, correct.

If you want to host a static site (no php, just html/case/js), choose the surfer app.

Confirm it is working.

5036fbcd-dfc4-4e24-ae99-68a3d577154f-image.png

229fc1e1-e5da-40f2-927f-ae5531464033-image.png

b0db9047-106b-476b-a694-86f7a5b4b995-image.png

Thanks for the fast response and fix 👍

@girish said in Cannot send mail from LAMP app:

@hollosch you have to configure it in the code. https://docs.cloudron.io/apps/lamp/#email has an example. I assume you are using a custom app that you developed?

I'm using https://www.php-guestbook.de/?langu=en