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

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.

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

@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 In the case, it has to do with embedded systems.

Tasmota is a FOSS firmware that runs on a variety of ESP8266 and ESP32-based devices. (https://en.wikipedia.org/wiki/ESP8266) Think "cheap, wifi-enabled switches and sensors." The 8266 is a wifi-enabled chip (2.4GHz only) that runs at 80MHz, has around 80K of RAM, and typically between 512K and 4MB of external flash (for static code and data storage).

As a result, fitting a full SSL implementation is not an option. BearSSL is used in this context, and a limited number of algorithms are therefore made available from that library. There's only one RSA-based cipher that is included in Tasmota (IIRC).

Hence, I'm going to see if I can package Mosquitto so that one of the TLS ports can use the system-wide LE certs (which could, for example, be used by server-side home orchestration/automation packages like Home Assistant to talk to the MQTT server), but also allow a second port to use the self-signed certs (that can interact with low-spec embedded devices).

Long story short, the SSL limitations are more about the resource constraints of the systems involved (e.g. small IoT devices) than it is about out-of-date software. (mosquitto is an Eclipse foundation project, and effectively the reference standard for MQTT as a protocol, and BearSSL as a library implements more ciphers; MQTT is not the problem, Bear's limitations, somewhat. The limitations of the ESP8266-based IoT hardware is definitely a problem for doing EC ciphers.)

@girish I started using the DockerHub repo, and will circle back around to try and re-install the local Docker Registry. So, the answer is "sorta no." But I found a path to keep moving.

I'm not sure why, given no changes on my part, that the local registry decided to stop working for app install by Cloudron. (All of these services are on the same host...) There were not disk/RAM issues that I could see, so something was going on, but I couldn't get enough info to debug beyond the fact that things retried-and-failed.

@jadudm Looking at the timeline on this thread, I'm wondering if I have the same problem.

Updating to 7.1.something and reinstalling the image registry to see if that fixes things. Will update this thread when I discover the outcome...

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

@jadudm

And, for myself, for future reference:

Invalid serverAddress: (HTTP code 500) server error - Get "https://reg.cloudron.example/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

I tried manually changing the auth backend to "htpasswd" per documentation on the Docker site, and created a valid htpass file... but that doesn't change anything.

I have no idea why I cannot configure my cloudron instance to use a private registry.

@jadudm Nope.

If the machine I'm working on is dev, and the registry is hosted on my cloudron as registry.cloudron.example

I can now:

1. Browse to my private registry.
2. Authenticate and push to it from the command line from dev.
3. I cannot, via the Cloudron admin panel, set up registry.cloudron.example as my private registry.

I consistently get 500 errors for the registry.cloudron.example/v2/ endpoint. However, if I visit it in a browser on dev, it is easily reachable.

I am up to date on updates, I have restarted my cloudron recently, I have restarted the registry... I've even torn down and rebuilt the registry. I'm unclear why I can't set up my private registry.

Is there an invisible config file somewhere deep in the heart of Cloudron that I could go inspect the old fashioned way, and make sure some old data isn't being held on to that's... bad?

@jadudm Sorry, @girish . This was "user error." I do not know how this local registry ever worked, because I would swear the ports were not open to allow it to work.

However, this is a case where 5000 was not open to me. So, I could hit the /v2/ endpoint via HTTPS, and could locally store my login credentials via docker login, and I could browse the registry... but push and pull would fail.

Sill... I don't know how this worked in the first place, given that I don't think I had firewall rules open for it to succeed.

If this was a ticket, I'd mark it closed.