Cloudron Forum

As the MeshCentral Development has taken up speed again after a bit of a hiatus: is there any update on it on Cloudron? Would be an extremely powerful addition, especially together with OIDC.

@umnz Thanks for the confirm, can report the same meanwhile - Hetzner Proxmox, regular 24.04LTS Ubuntu as a VM works as smooth as the old installs did.
The only two problems I encountered are more app related.

So can new installations now be done on 24.04 LTS directly if they are already V8?

Hi,
I know developers rightfully hate nothing more than "are we there yet/when are you done" questions, but could you give a rough guess how far 8.0 is away currently?

We will need to move two servers and while we still got a bit of time a rough guess would enable us to decide if it's worth installing the current version or wait for 8.0 and do a clean Ubuntu 24.04 LTS(which would make a few other things easier for us). We are totally happy to wait (it's done when it's done), but I would hate to install two new installations and then 8.0 comes out 3 days later.

Considering that Discord has said goodbye to it's (never true) ad-free policy as well a revolt is currently gaining more traction again.
(https://www.techspot.com/news/102455-discord-looks-boost-gaming-revenue-ditching-long-time.html)
It might be a even more interesting addition now.

Would be quite an interesting business case for smaller corp. users tbh - KASM can do something similar with their sidecar VPN service (or docker desktop with integrated VPN as it's now available with the development version). This enables users to use the Kasm frontend (which is basically Guacamole), connect to docker desktop instance and then use a VPN to the desktop to the Final destination (e.g) in a jumpserver setting.
The downside is the ridiculous pricing of Kasm workspaces for commercial customers - 600-1200$ for a rarely used tool is unfeasible for most smaller customers.

Cloudron could really be useful as a "rougher but still working solution":
While we have no Docker desktop on Linux, these could easily be hosted elsewhere and are provided by various projects.
BUT people should not keep these desktops publicly available via VNC/RDP - That is where Guacamole cones into play.
One option would be to use Guacamole to point to an internal network "behind" a Cloudron instance in a DMZ. But that is currently not possible as Cloudron basically only supports one network,right?
(See my other topic about this from 2022)

The other, imho much easier to achieve, option would be to make Cloudron internal network connection to OpenVPN instances (Portainer is an example of a project than has done similar things) on a container to container base - e.g. letting Guacamole connect to a WG/OpenVPN to then connect to the required external resources.
Even without providing a actual Docker Desktop it would still make it much much easier and safer to provide properly separated infrastructure.
(Besides, in my jumpserver scrnario of course Guacamole alone can act as an direct Jump to the target infrastructure then).

Tbh,I currently don't see a way for people to safely use Guacamole on Cloudron in a public environment safely at all.

Offering something in that regard would be an compelling business case, even nore so as Cloudron of course offers a massive "SSO" solution for all the other business needs as well.

@girish We would actually ve willing to sponsor that feature at least partially-Feel free to contact me.

The last post in regards of this is from 2022, is there any update on this functionality? It would be very interesting if one could use Cloudron to connect to a VPN server - e.g. to use Guacamole as a support tool.

Yeah, would absolutely love that as well. Rustdesk is generally solid, but selfhosted via Cloudron would be really nice.

Considering the bad shape Calibre Web is after all these years (Not Cloudron,I mean thebase) and how great Kavita meanwhile has become I am also fully in support of bringing that to Cloudron.

@Kubernetes said in No option to select folders?:

I mounted a Hetzner Storage Box to my Audiobookshelf App and specified this path (just replace the \ ) :

/media/storagebox-nextcloud-bx11/audiobooks

if you want to just use the common App storage, you should specify /app/data/audiobooks

You are a rockstar! I spent half a day to figure that out before I for some reason saw your post... Thanks, mate!

That will be indeed very interesting. Zabbis is the only real reason I currently still run a parallel yunohost installation.

I was about to write a entry about Tandoor here myself but you were faster.
Thank you for that, absolute something worth supporting.

@girish
As requested:
https://forum.cloudron.io/topic/7839/more-than-1-network-nic-bind-container-to-networks/1

Hi,
as requested by @girish a feature request thread following a discussion here:

Current situation:
(Please correct me if I am wrong here)
At the moment cloudron only "listens" to one NIC per OS instance it is deployed upon. This is usually (and recommended to be) a public IP.
Requests from other NICs are not handled or not properly handled.

Feature request:

• Allow cloudron to listen to more than one NIC at the same time (but not hard-coded all)
• Allow cloudron to listen to more than one network&IP at the same time at least via different NICs (**)
• Allow cloudron admins to govern what networks a app listens to.

(*: As this could kill the setup of some bare-metal users I recon, e.g. when they have other services running on the same machine already)
(**: I am fully aware that this could also facilitated with one NIC in a lot of cases, but this would require far more modifications on the base OS, so maybe we should split these requirements to later FRs)

Reasoning/scenario:
Keeping internal and external networks appart is always a good idea and network segration has is a de facto industry standard for ages now but has become even more important in cases where IoT or guest devices are used within an internal network.

While some users mainly provide only public facing (e.g. LAMP, Wikis, Helpdesk for customers) or only internally facing services (internal Wiki, Media content, etc.) a deployment in a DMZ - in a laymans words: the middle ground between Internal&external networking- makes sense.
(Note: This of course be also facilitated by using two or more separate cloudron instances if you have a seperate set of apps for internal and external and I would recommend this security wise, but it is outside the scope of cloudron if you don't - keeping Apps synched is it's own game)*

Now, in theory you could always let your internal hosts use the "outside" network to access cloudron - but that is often undesired e.g. for security reasons and additonally puts load on your WAN/UTM/FW.

Especially on virtualized cloudron hosts (e.g. on a bridged Proxmox setup) the easiest way for many users might be to just add another virtual NIC to the VM and define the network the VM should also be connected to.

But here comes the problem - while it is absolutely possible to have a docker container listen to different or multiple hosts so far cloudron does not allow this.

To give a few examples where this would be handy:

• You want IoT devices to access media files and be monitored by Prometheus or the proposed [Zabbix](https://forum.cloudron.io/topic/1211/zabbix-network-monitoring-solution?_=1666369185907?
• You want students to access a wiki, moodle and an internal mail system but not the internet; Staff on their Network should meanwhile access the internet, moodle, media files, the wiki, the ticket system.
• You want internal staff to access certain ressources (e.g. invoice ninja and paperless) but don't want them public facing while a project management system should be both internally and externally used?

In all these cases gradual control over the networks would be used to get a proper setup - and in all those cases you need a host that has acess to multiple networks at the same time.

(Disclaimer: As there are a fair bit of not that adept users and people not speaking english as their first language here I tried to keep wording simple, sorry to all the Pros out there)

@subven
Security wise that is a quite limited scenario.
This would mean that internal clients would need external access for services that are both internal and external- a scenario that is often undesired.
DNS is never a security measure.

@girish
Well, especially in setups where Cloudron is on a VM I recon it is somewhat common - just from Reddit alone I know quite a few people who use a similar setup to mine:

Personally my instance is on a Proxmox host in a DMZ,we have separate networks for purely internal services and for non-cloudron external services (and a purely management network as well). For some services we use MacVLAN on docker to provide separate IPs for containers.
While this absolutely could be achieved with VLANs as well, in a Proxmox environment it was easier to use "physically" separate networks and route them properly through an OPN Sense VM.

In theory one surely could use two Cloudron instances, but that would first be quite expensive, but also limit some backend functionality imho.

Kind regards,
Phil

@subven

Where exactly do you see that I am begging a dev here?

I am merely adding that a lot of people are using cloudron free to circumvent the hassle of setting up matrix on their own - in fact that is a advice given quite frequently on some subreddits and the reason why I ended up here - only to become a paying customer later on. (And once they took the bait of the "working matrix" it might be easier to catch them as paying customers with the integrations?)

Sure, one could always use complete self-hosting as you described and I am very happy that it worked out for you - it didn't for a lot of other people and neither for me.
But that is the point why most people use cloudron in the end, isn't it? The ease of things?
This is in the end what most people pay for - the effortlessness cloudron provides.

(Besides: This is not a open source hobby project but something the Devs need to make a living off. So discussing what features are desireable and making sense fiscally is somewhat beneficiary for both sides, isn't it?)

Kind regards,
Phil

Generally speaking a integration of the more popular bridges would be really neat.
Mainly thinking about these:

• Signal
• WhatsApp
• SMS
• E-Mail
• FB Messenger
• Slack
• Discord
• IRC
• Telegram
• WeChat

Especially in the light of Bot and AI integration that could be a really game changer and really bring matrix deployment forward.
And as matrix deployment is a reason for a lot of people to use cloudron (as it is a pain in the bottom otherwise) it might even be financially profitable for you guys to do so - I know a few people who stick with yuno because the lack of bridges on cloudron.

@girish
I am not OP, but wouldn't that be useful to provide some Apps to an internal network and some for an external network only?