Cloudron Forum

@d19dotca Looks great, thanks for sharing!

I totally agree. It is my third year using Cloudron and I still love the stability and reliability.
I would also like to thank in addition to the Cloudron Community which is always open and supportive!

THANKS!

Hi there,

I read about this RCE vulnerability of the Ingress NGINX Controller:
https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

They mention Kubernetes, and I am not sure, if we are using this Controller on Cloudron?

Anything we have to do here?

Best,
Michael

@nebulon I will build up real experience and report here

I understand your concerns, but in this case it is a Hetzner Volume which is mounted as a local SSD Disk. I guess in this case you agree that it is ok?

@humptydumpty I tried all of them, but I did like Navidrome most, followed by Koel. Ampache was okish and I didn't like Emby.

Regarding the Navidrome crashes. If you have many music files, I suggest to raise the memory limit. The default one is to low.

@crazybrad yes, I did tests. Unfortunately I was never able to restore a Cloudron App Backup because of using encyription. Somehow I was not able to decrypt the backups - even if I noted the encryption key in a password database. In the meantime I disabled the encryption, but didn't test a restore so far.

Restoring Snapshots/Backups from VPS is totally easy. Tests to second VPS always worked flawlessly and I used VPS snapshots two times for migrating between hosting zones (Nürnberg -> Helsinki -> Falkenstein) without problems.

I retried this morning and it did work on my Cloudron instance. It just takes a couple of minutes until all the images are pulled. I am still not sure if the command systemctl start docker is really required, because it never give back control - since CPU, Disk and Network usage was idle for some minutes I decided to perform the reboot of the VPS and everything went fine then.

One question regarding disaster recovery. When I do need to restore my Cloudron from VPS Snapshot, the new location of /var/lib/docker is not in the Snapshot anymore because I am using a Hetzner Volume for it. When the Volume is not destroyed I guess there wont be any problem when writing back the snapshot. But what happens when the Volume has been destroyed? I assume that Cloudron will just need to pull all the docker image stuff again? Is there anything that I should know before the worst case may happen?

@luckow One Cloudron Instance running at Hetzner VPS (8GB RAM, 80GB Disk, 4 Cores), 10 Domains, 15 Apps running. Doing Cloudron Backups twice a day and VPS Backup once a day. Before Updating Cloudron to new versions, and sometimes before NextCloud Updates, I perform a VPS Snapshot in addition.

I didn't see any errors. A second ssh connection and systemctl status docker was looking okay, but Dashboard was timing out. I guess you are right and loading and recreating the images might consuming the time. I was not expecting a long wait because the guide mentions to update the version to trigger re-download and creation of the images. Probably I will try again tomorrow with some more patience.

Hi there,

I tried to organize storage on my VPS better by moving Docker Images to a Hetzner Volume (SSD, Mountpoint) according to this guide https://docs.cloudron.io/storage/#docker-images

Unfortunately it took neverending when executing systemctl start docker

Finally I lost my nerves and reverted all previous changes and at least after rebooting the VPS my Cloudron was working again as before.

I just would like to know if that part of the documentation should still be valid and applicable?

Cheers,
Mike

I can confirm that on my Cloudron I see the same messages when restarting the mail service.

@joseph 1) This approach is seperate to the common Cloudron usage
2) Updates are not automatically, but manually
3) Not everybody is able to build and install custom packages
4) It requires public space on docker.hub or a private instance of docker repo
5) the package is not optimized by the Cloudron maintainers

When i look at the time this thread is open I wonder if it could be an interims solution until the add-on is ready

@girish what do you need to make this gem a official package?

Maybe to add that a cronjob in NextCloud App is recommended to update the index, e.g.

*/15 * * * * occ fulltextsearch:index --quiet

@andreasdueren Great, thanks, it seems to work on my cloudron now.

I think I configured NextCloud the right way, but I still get no results when doing search. In the Logs of the elasticsearch container doesn't happen much. Does it need some time to start building the index?

@andreasdueren said in Elasticsearch:

https://git.due.ren/andreas/elasticsearch-cloudron

Great! Thanks for taking the initiative.

The .env file or a template is missing in the source, therefore the package.sh file fails to copy and build.

elasticsearch.yaml needs to be added to the copy command in package.sh, too

and the command "cloudron package" needs to be "cloudron build" ?

And you should use Cloudron Base Image 5.0.0 instead of 4.0.0

It is up and running now on my Cloudron and I still need to connect it with my Nextcloud.

I noticed that the Cloudron Proxy is exposing Elasticsearch (protected by username and password from credentials.txt)

It was a bit tricky to understand where to use the curl to create the indices. Best was to execute it inside of the container (IPADDRESS 127.0.0.1)

@andreasdueren How did you change it in the DB? Did you use a cli in the container?