Posts made by jadudm

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

@jadudm This might be an aggressive firewall issue.

I'll update when I know for sure. However, I suspect I'm not letting :5000 through, which would allow web clients to browse the registry, but not allow me to autheticate/push from the command line.

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

@girish, Even with a clean re-install of the docker registry, I can't convince my Cloudron instance to authenticate against it. I get 500 errors from it consistently (but can hit the v2 URL from a browser just fine?).

I'm happy to do whatever I can to help with debugging. Perhaps this is one of those "it works everywhere else, but not on my machine" kind of things.

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

When I attempt to update my Docker registry credentials in the Settings, I get the following error:

(HTTP code 500) server error - Get https://docker.host.us/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) 

From the command line on my dev machine, I can

curl -X GET -u jadudm:ASDFASDF https://docker.host.us/v2/_catalog

and get a list of the images on the host. Hence why I am confused as to what may have changed under the hood that my private registry no longer works from Cloudron as an image installation source (when it did not that long ago).

EDIT: In docker.js,

https://git.cloudron.io/cloudron/box/-/blob/master/src/docker.js#L60

The comment says what it says:

    const [error] = await safe(gConnection.checkAuth(config)); // this returns a 500 even for auth errors

I have the correct username/password in my Registry conf. It never changed... but it stopped working at some point in Cloudron. It works just fine elsewhere. So, I don't know if this is a network issue, or an auth issue, or what... because it looks like checkAuth doesn't give me a lot of info to debug with?

@robi I do.

I think the error is somewhere in Cloudron.

Feb 06 10:21:35 box:docker downloadImage: pulling image. attempt 10
Feb 06 10:21:35 box:docker pullImage: will pull docker.host.us/jadudm/grocy:1.0.0. auth: yes

I'll claim that the better behavior would be for Cloudron to fail when it cannot pull an image. Instead, it is trying to set up the extensions and run the container when the container doesn't exist.

Given that it loops through 10 (failed) attempts to pull the image, there's something going wrong with the image pull. There's nothing in the existing logs that gives me enough information to figure out why I'm getting a 404 on the image. (I can pull the image from another machine, and both the dev machine and the Cloudron host are effectively on the same network.)

I'll see if there's a way I can... I don't know. I feel like I'm missing something obvious, but I'd like a bit more info from the Cloudron logs in order to debug this.

EDIT: It looks like

https://git.cloudron.io/cloudron/box/-/blob/master/src/apptask.js#L354

is where downloadImage is called, but I'm unclear where errors that are generated from that process are handled. It looks like a failed image download does just fall through to a continued attempt to run the container.

Hi all,

I thought I'd explore putting a Grocy container together. Groovy.

I can push/pull (and even DELETE via curl) from this registry, which is hosted on my cloudron machine (docker.host.us). From my dev machine, it would appear that the docker registry is ticking over just fine.

When I build the Grocy image and push it to the registry, I can find it there via the web UI and via curl. However, when I try and do a cloudron install, I get the following error in the installation logs for the app:

Feb 05 17:06:00 box:docker downloadImage docker.host.us/jadudm/grocy:3.1.3
Feb 05 17:06:00 box:docker downloadImage: pulling image. attempt 1
Feb 05 17:06:00 box:docker pullImage: will pull docker.host.us/jadudm/grocy:3.1.3. auth: yes
Feb 05 17:06:21 box:docker downloadImage: pulling image. attempt 2
Feb 05 17:06:21 box:docker pullImage: will pull docker.host.us/jadudm/grocy:3.1.3. auth: yes
Feb 05 17:06:41 box:docker downloadImage: pulling image. attempt 3

and it ultimately fails after 10 retries. There's then... an attempt to standup extensions (based on the manifest, I imagine), and then this:

Feb 05 17:09:37 box:apptask run: app error for state pending_install: BoxError: (HTTP code 404) no such container - No such image: docker.host.us/jadudm/grocy:3.1.3
at createSubcontainer (/home/yellowtent/box/src/docker.js:397:28)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
at async Object.createContainer (/home/yellowtent/box/src/docker.js:403:12)
at async createContainer (/home/yellowtent/box/src/apptask.js:88:23)
at async install (/home/yellowtent/box/src/apptask.js:385:5) {
reason: 'Docker Error',
details: {},
nestedError: Error: (HTTP code 404) no such container - No such image: docker.host.us/jadudm/grocy:3.1.3
at /home/yellowtent/box/node_modules/docker-modem/lib/modem.js:315:17
at getCause (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:345:7)
at Modem.buildPayload (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:314:5)
at IncomingMessage.<anonymous> (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:286:14)
at IncomingMessage.emit (events.js:412:35)
at endReadableNT (internal/streams/readable.js:1317:12)
at processTicksAndRejections (internal/process/task_queues.js:82:21) {
reason: 'no such container',
statusCode: 404,
json: { message: 'No such image: docker.host.us/jadudm/grocy:3.1.3' }
}
Feb 05 17:09:37 box:taskworker Task took 219.043 seconds

... cut more nested errors of the same flavor ...

What is odd to me is that I have had my private (locally hosted) container registry running for some time without any issues. I've installed other images from this registry. I don't think I'm out of disk or memory, but... I find that the stacked RAM diagram to be not helpful for checking the status of the cloudron host; I've killed a bunch of things just for fun/just in case RAM is an issue. It looks like I have many gigabytes of working space everywhere I need disk.

Is this an auth problem with my local registry (and why would it happen now)? The image comes down fine on my dev machine; could this be a DNS resolution problem on the Cloudron host? (Which... it's on the same network as the dev machine, so that feels odd.) I don't think it's a Cloudflare proxy issue, because (again) I've used this setup for other applications. That said, something probably changed, and that's the mystery of the moment.

Anyone have thoughts about how to go about debugging this? (I don't know if this is an "app development" question, but it is using the cloudron tools to attempt to locally develop an app, hence why I asked here.)

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

The question: Is it possible for me to have a Cloudron Docker container that grabs a USB serial device?

I have set up Home Assistant in a Cloudron container, and mosquitto (an MQTT broker) in another. They talk to each-other. They're friends.

I would like to have a container running zigbee2mqtt. This is a node app that talks to a USB zigbee adapter (I'm using this one).

Is it possible for me to have a Cloudron Docker container that grabs that USB device?

If I was spinning this up outside of Cloudron, I'd use the devices tag in my docker-compose.yml. (This is the zigbee2mqtt compose, for reference.)

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

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

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

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 For reference, these are the constraints if we're trying to support Tasmota-based IoT devices using BearSSL:

Your SSL/TLS server must support TLS 1.2 and the RSA_WITH_AES_128_GCM_SHA256 cipher - which is the case with the default Mosquitto configuration
 
The server certificate must have an RSA private key (max 2048 bits) and the certificate must be signed with RSA and SHA256 hash. This is the case with default LetsEncrypt certificates.

The docs are obviously dated, because I don't know that those LE defaults still apply.

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

For anyone following along at home... I have, in "draft" form:

1. A Home Assistant app, and
2. An MQTT instance that:
   • uses self-signed certs, and
   • listens on 8883 (the default secure port) with TLS

The self-signed certs are because I'm working against the constraints of BearSSL, which means I need 2048-bit RSA CA/keys and SHA256.

However, the test is that I now have a Sonoff Basic switch that is chattering away at my Home Assistant instance over TLS-secured MQTT.

There's a bunch of cleanup I'd like to do in order to make these apps usable for others. The MQTT container alone might be generally usable... perhaps I can put the LetsEncrypt certs on the default port, and put the self-signed certs on a different port (e.g. 8883 for LE, and 9993 for the self-signed certs...)

And, now that I've thought about it some more.

1. Being able to run a TLS-protected MQTT server is good. It allows full-featured clients to talk to the sever. That said,
2. Embedded devices will need the CA compiled in. (Or, I might be able to get away with a fingerprint. That said...)
3. It would require an RSA cert, no larger than 2048 bits.

This could be more annoying than it is worth. Certainly, having an RSA cert that would play with BearSSL would be nice, but it might not be in the cards.

I'll have to think about whether there are other options/approaches available.

@girish, Based on

https://git.cloudron.io/cloudron/box/-/blob/master/src/acme2.js#L279

which is part of the function Acme2.prototype.createKeyAndCsr, suggesting... it is where the key and CSR are created...

let key = safe.child_process.execSync('openssl ecparam -genkey -name secp384r1');

which suggests a key based on an EC.

But, this is a few minutes of code spelunking. I'm going to hold for a bit, and see if you have any thoughts. I'll do some more reading, but I have a suspicion solving this is going to require more access to box than an app packager currently has.

I wonder if I can include a self-signed cert in the app package that matches the domain as a stop-gap?

Anyway. Thoughts welcome, and thank you.

@girish I have learned more things.

I know/understand certs and PKI at a high level, not at a here's now it works level. I'm in the process of learning more of here's how it works to solve this.

I was able to stand up a container with mosquitto running just fine, and as long as the clients that talked to it were running on full-featured hosts, everything "just worked" (e.g. running mosquitto_sub on another Linux host). This works for a cloudron-packaged version of Home Assistant, which bundles an MQTT client, and performs auto-discovery. It has happily discovered my MQTT container, which is good, and sends messages to it.

However, my mosquitto container did not work with my (one) piece of IoT test hardware. Specifically, it did not work for my little "smart switch," based on an ESP8266 (a Sonoff Basic). This is an 80MHz device with KB of RAM and 1MB of flash. As a result, the Tasmota team uses BearSSL as the SSL implementation, and it only deals with one encryption algorithm and TLSv1.2. It is known to work with mosquitto (being an Eclipse foundation "standard" of sorts in the MQTT broker world). As proof that it works, I can build an insecure container (meaning I configure mosquitto to use comms unencrypted by TLS), and the Tasmota device will talk to the container just fine. That confirmed for me that it wasn't a network issue... it is definitely a cert/encryption question.

But, it looks like there's a cert question w.r.t. the LetsEncrypt certs that cloudron pulls down. Or, that's where I'm going to investigate next.

From a developer on the Tasmota end of things:

I used the laptop version of BearSSL and I got the same error:

build/brssl client mqtt.example.com:443 -cs ECDHE_RSA_WITH_AES_128_GCM_SHA256
WARNING: no configured trust anchor
connecting to: 1.2.3.4 connected.
Algorithms:
    RNG:           rdrand
    AES/CTR:       pwr8
    GHASH (GCM):   pclmul
    EC:            all_m31
    RSA (vrfy):    i62
 ERROR: SSL error 296 (received alert 40)

Using OpenSSL shows that Server public key is 384 bit
We don't support EC keys for servers, they need to be RSA 2048 or 4096. In general we don't support ECDSA. You need to generate a new certificate with RSA private/public key

Now, this is where I need to do more learning. Does cloudron pull an elliptic-curve-based cert (as opposed to an RSA-based cert), and that's going to be something I need to work around? (For example, I could bundle self-signed certs into the mosquitto container, or generate them when the container is launched, or...). Or, is there something I don't (yet) know about cloudron that will let me solve/work around this?

If y'all have insight, I welcome it. In the meantime, I'm going to go digging into the box source, and find out what happens when cloudron requests LE certs on my behalf.

When I'm done, I'll document all of this somewhere, so that people following after me don't have to walk the same path.

Cheers,
M

@girish Many thanks; that was useful to know about/something I did not know existed (the LE cert page), but sadly didn't solve my problem. (I was hoping for magic.)

I'm going to call it a day; it is clear that mosquitto should support the cipher that tasmota is offering, but I keep getting

error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher

on the broker side. I hoped that this might be a "missing piece."

When I have this figured out, I'll feel better about suggesting there possibility of a viable MQTT container.

(My goal here is to pair it with Home Assistant, and know that Tasmota, an open source firmware for home automation devices, will work with the MQTT broker.)

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

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