@andreasdueren I've packaged one or two things for myself on Cloudron, and I took a look at Frappe/ERPnext.

First, for the thread: Cloudron does not run Docker images "as-is." Or, if you prefer, simply because a project runs in Docker does not mean that it will immediately be runnable under Cloudron. A Cloudron app needs to be packaged up so that it will "play nicely" with the control architecture that Cloudron provides. Put simply, to get that friendly Cloudron experience, some work is needed when packaging an app.

In the case of ERPnext, it has a compose file that specifies many software services. Traefik is used for routing and load balancing (I assume); Nginx fronts the service; it seems like Frappe (the API backend) is written in Python (another service). There's worker processes of several flavors, a scheduling service, a Redis cache, MariaDB (which, for porting to Cloudron, we'd want to integrate with it's built-in DB add-on), the site creator service... and a large number of storage volumes.

Cloudron does not, to the best of my understanding, support running docker-compose files. As a result, to package this, we'd have to pull all of these services into a single container image. That would take some thinking, especially since Docker "likes" to have one process per container. Or, if there is another way/it is possible, I don't personally know how to package up a multi-container Cloudron application.

The Cloudron team may have something else to say, but I thought I'd drop a note in the thread that helps explain why this app is a more complex proposition than others (perhaps) when it comes to packaging. Yes, it is open, and yes, it installs easily on a VM when you do a docker-compose up. Unfortunately, that is not the same as packaging things up to run under the Cloudron framework.

Flatpack and Appimage formats do not provide the kind of process and filesystem isolation that Docker does. I would not be comfortable running run a service like Cloudron if it allowed running things other than well-defined/managed containers.

Yes, there are ways to break isolation and escalate out of a Docker container, but flatpack apps can, essentially, write anywhere on my system. Updating the ecosystem is also much more difficult; by comparison, it is possible to auto-build Docker containers from source and track recent updates/manage timely security vulns in a way that flatpack/appimage packages do not/rarely do.

@girish Hi Girish. You got it.

I have a small IoT service hosted in the home network that adding auth/protection to would be painful. (It doesn't have a notion of auth, I don't think. So, Cloudron-as-LDAP-authority doesn't even save me.) The App Proxy feature made it easy to bounce through to it from outside, but I don't want it unauthenticated.

So, yes. You nailed exactly what I was wondering.

I would like to politely ask for a bit more info around cert updates, please.

I received an email yesterday from LetsEncrypt saying I had one day left on my cert renewal for the my domain in my Cloudron instance. It is not spam or a scam; I believe this email was legitimately from certbot.

I pushed the "renew certs" button in the control panel, but... did it work? How would I know? I read the logs, and played with openssl; of course, the latter is an external measure, and may be confused by my Cloudflare proxy. I think the update worked... but, visual log parsing is the hard way to figure out if a complex process succeeded. Was that null result buried in a JSON log an indicator of success? It was late, I was tired, and perhaps tomorrow my certs will fail.

1. It would be nice if the dashboard/control panel told me, after pressing the button to update certs, if the system thought it succeeded.
2. It would be nice if that same panel area are simply told me "Certs last renewed on <date>, expire on <date>, and the next cert update will run on <date>."

Cheers,
Matt

@nebulon Many thanks, @nebulon and @girish . The concern wasn't so much that I could not figure out what the status of my certs were external to Cloudron, but more that it would be nice if the area of the dashboard regarding certs would, as a matter of course, just say "You have 47 days remaining, and Cloudron should automatically update your certs in 17 days."

And, if I do mash the button to manually run a cert update, it would be nice to get a response in the dash that says "Success! New certs will expire in 90 days!" (Or, whatever it would say.)

I was mostly surprised that I got a certbot email saying I only had one day left, making me wonder what was up. (I did do a domain registration move at some point, and possibly other things that could have somehow upset the automatic update process. So, this isn't a bug report.) Not having a simple UI response to the act of hitting "update certs" (and instead being dumped into the log) is all I'm poking at.

I don't know how long my personal instance has been running (a month or two now), but it has been a joy. Thank you.

@jdaviescoates Yep. That was it.

I will look at the source for App Proxy, and look at adding it/making a pull request. (Unless someone beats me to it.)

Hi all,

I have signed up for a managed plan to test some features of Cloudron. I really love the promise of a platform that is fundamentally based on managed containers.

The Question/Premise: Assume I want to support students enrolled in a class or academic program. I want each student to be able to have a blog, and perhaps one or more Wekan boards, and so on. From my experimentation, it looks like a single Cloudron instance cannot meet this need?

I created an administrator account and a student account. When I chose WP as one of my apps, both the administrator and the student are writing to the same blog. As a result, each "user" does not have their own blog space on a single (in this case, managed) Cloudron instance. However, each user does have their own Wekan board. Perhaps I'll have my students maintain microblogs in Wekan...

It seems to me that, given the current structure of Cloudron, that to provide every student with their own spaces, I would need:

1. To have a VM for each student, and
2. Provision Cloudron to that VM

We would create common admin accounts on each student VM, and they could then choose which apps to run on each virtual machine. Or, each student could be an admin of their own Cloudron instance. Details, details...

I guess the point of the question is: if I want to get into the space that every one of my students has a "domain of one's own," eg.

astudent.dept.institution.edu

then is it likely that I must run a separate Cloudron instance for every student, or is there a way to simply run one server, with a bunch of RAM, and have each student running their own apps in their own containers?

(All of this might be my own confusion in some way, but I really do think I'm logged into two different browser instances, as two different Cloudron users, and still seeing the same WP instance in both cases. Hence my question.)

Many thanks,
Matt

Hi all,

I'm working on a mosquitto (MQTT) package. I'm... wrestling with testing a variety of clients, and am uncertain where I have a failure with an SSL handshake from one of my devices. Hence, I'm fishing.

When I configure mosquitto, I need to give it the following for TLS to work (in theory?):

certfile /etc/letsencrypt/live/mqtt.example.com/cert.pem
cafile /etc/letsencrypt/live/mqtt.example.com/chain.pem
keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem

Using the TLS addon, I seem to be able to provide... two of these three (certfile and keyfile)? If I'm using the cloudron base image, is there a path I can pass to mosquitto in its config to get a valid cafile?

Why I'm fishing up this stream: I'm wondering if the absence of the cafile is something that could break a TLS handshake? (Some clients I test work fine; some don't. I'm wondering if there's a cipher mismatch or TLS v1.2 vs v1.3 problem here...)

Many thanks,
Matt

The App Proxy is a handy little app. Thank you.

Feature request: It would be really useful if the App Proxy could, like some other apps, insert authentication in front of my proxied app. That is, I would love to say "require a valid Cloudron user before you proxy through."

I haven't looked at the App Proxy repo yet, but if this would be an easy option to turn on, it would be something I would use immediately. That way, I could have some authentication/protection at the Cloudron "gateway," and just bounce valid users through.

@mehdi Good question, and correct; if I could pass the USB device through to a Cloudron-hosted container, I could just pass the USB Zigbee radio directly to HA.

For the record: I have answered my question. The rest is detail/how I solved it.

I had previously already packaged HA and MQTT as Cloudron containers. I pushed those images to my local Docker image repository (hosted on my Cloudron! Haha!), and then... pull them locally. (Silly, but it works.) I did this because I had one Tasmota-based WiFi switch that I was trying to control, and it was (I thought) easiest to have it talk via WiFi to the MQTT server, and in turn, HA could subscribe/catch the device that way.

This worked.

Cloudron is running on a Proxmox-hosted VM. I realized I could spin up a second VM...

One VM is running Cloudron; the second VM is running nothing but zigbee2mqtt. I passed the USB device to that VM, and am running (of all things) the Docker image for z2m, with the USB device poked through to the container. (It's virtualization all the way down...) I then talk from z2m to the mqtt server running on Cloudron, and HA was happy to find all of the Zigbee devices that way.

@girish Hi Girish. You got it.

I have a small IoT service hosted in the home network that adding auth/protection to would be painful. (It doesn't have a notion of auth, I don't think. So, Cloudron-as-LDAP-authority doesn't even save me.) The App Proxy feature made it easy to bounce through to it from outside, but I don't want it unauthenticated.

So, yes. You nailed exactly what I was wondering.

@jdaviescoates Yep. That was it.

I will look at the source for App Proxy, and look at adding it/making a pull request. (Unless someone beats me to it.)

The App Proxy is a handy little app. Thank you.

Feature request: It would be really useful if the App Proxy could, like some other apps, insert authentication in front of my proxied app. That is, I would love to say "require a valid Cloudron user before you proxy through."

I haven't looked at the App Proxy repo yet, but if this would be an easy option to turn on, it would be something I would use immediately. That way, I could have some authentication/protection at the Cloudron "gateway," and just bounce valid users through.

@jadudm My initial experiment suggests that I cannot use the Golang Docker SDK to do something like:

	ctx := context.Background()
	cli, err := client.NewClientWithOpts(client.FromEnv, client.WithAPIVersionNegotiation())
	if err != nil {
		panic(err)
	}

	containers, err := cli.ContainerList(ctx, types.ContainerListOptions{})
	if err != nil {
		panic(err)
	}

	for _, container := range containers {
		fmt.Println("CID", container.ID)
	}

The expected error of

Apr 10 23:26:29 panic: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

comes up. This is with the docker addon.

It's late; I've done all the investigation I can for a weekend. If there's a solution where I can do this robustly on my Cloudron host, that would be ideal.

@robi Thank you. This makes sense.

Unfortunately, it is fragile. I am not guaranteed that my Directus instance will keep the same 172.* address. I'm trying to read from my MQTT broker (running on my Cloudron host) and insert data into my Directus server (running on my Cloudron host). Those services have good (subdomain) names in the world, and I don't want to author an application that is fragile based on dynamic, internal Docker network IP addresses in the 172 range. Is there a better way?

@robi, @girish , @nebulon, is there a more robust way for me to write an application that will run on my host and talk to another application on the host? For example, can I use the docker addon to list containers on the internal network, and from that, get their IP addresses and exposed ports?

I feel like this is information that the Cloudron runtime knows, but I as an application author do not (but might want to know).

My alternative... I can just run this on another VM on my Proxmox host. But, then I'm a sysadmin again. I really like the idea of being able to have a container that I can update and, when I do, Cloudron will pull the image and update the running application for me. (And, yes... I could use watchtower on the VM for this...)

@jadudm So.

When I use cloudron/base:3.1.0 for my container, I can get a shell (meaning, I can pound the terminal button in Cloudron and get a root prompt in the container). If, from within the container, I curl something like https://www.google.com/, I see a good grab. I can also use openssl to get the cert chain for Google. This tells me it is not a "general" SSL problem from within the container.

When I try and hit a domain like my.cloudron.example running on my Cloudron host, both curl and openssl hang.

Is this:

1. A Docker networking thing?
2. A Cloudron-does-things-to-iptables thing?
3. A my-home-opnsense-firewall-is-doing-something thing?

This is almost certainly either a 1) Cloudron/Docker network thing, or 2) an interplay with my home network setup. That said, the container is on the host it is trying to reach.

root@5b7bf2bf-f81d-4fdc-8952-13a99497d6ef:/# curl -vvv -4 https://my.cloudron.example/ 
*   Trying CORRECTIP:443...
* TCP_NODELAY set

It is doing what it should from within the container. Something in the surrounding network universe is not?

Help or recommendations would be welcome.

@jadudm Oh... perhaps this is a certs issue...

I wrote a small go app to do the following:

1. Subscribe to some MQTT channels.
2. Post data that it sees to a Directus instance.

When I run the application from my dev machine, everything is fine.

When I containerize the application and run it on Cloudron, I get one dial tcp error, and then on subsequent runs (the container is automatically restarted, it seems) I get

context deadline exceeded (Client.Timeout exceeded while awaiting headers)

on my GET against the Directus server. (I did try and set a 5, 30, and 60s timeout on my calling HTTP context, none of which make a difference.)

The containerized go application is being installed to my Cloudron server, and the Directus instance is also running on my Cloudron server.

It really is a simple app. I would expect I could containerize and run it on Cloudron, given all it does is 1) listen to one server and 2) read/write to another (via HTTPS GET/POST).

Thoughts welcome.

A new not-what-I-was-looking-for-but-it-works-solution:

1. I'm mirroring the Dockerfile/project from my local Gitea to Gitlab.
2. I've set up Gitlab as my registry for the project.

(The project in this case is a Grocy package for Cloudron.)

This arguably gives me a private-enough repo for what I'm exploring, but I was hoping to be able to entirely leverage my Cloudron for this.

I'm just plain confused why, at some point in the past, my locally-hosted registry worked, and now, it does not. This is why I believe there is "crufty" config laying around, somewhere, and things therefore don't work.

(But... this makes almost no sense, because I have uninstalled and reinstalled the registry, so it is not clear how any state could persist.)

Anyway. This remains a mystery, and I would need some explicit guidance as to where I should dig around in the backend of Cloudron to figure out why things are not behaving. (It could also be that there's still some port that I don't have open, or... )

@robi Many thanks. I see where you're coming from. What confuses me... is that everything is on the same machine.

Which is why I'm (O_o), and think something really simple is going on.

1. I can hit the registry from the web (meaning port 443 gets through the firewall from the outside world), and authenticate as a Cloudron-based user.
2. I can hit the registry from the command line, and am authenticated as the same Cloudron user. This means port 5000 is getting through.
3. I cannot convince the Cloudron admin interface to let me authenticate as that user. The Cloudron admin interface (which is on the same machine as the registry) will not authenticate; it gets the 500 error.

I'm thoroughly confused, and am uncertain where to find the debug information that I need to solve this particular problem. Hence why I'm wondering if there's some kind of config that might have... "hung around" from previous attempts?