Cloudron Forum

@jdaviescoates and @girish: Excellent. Thank you. I can work with this. Very much appreciated.

Hi all,

I can't find this question asked elsewhere. I'm hoping there's a simple answer.

1. I log in to something via OIDC as Alice.
2. I log out.
3. I go to another app.
4. I click "Log in via OIDC." I want to log in as Bob.
5. I auto-login as Alice.

What is cached, where, that does this? How can I clear that cache so I can log in as Bob?

Many thanks,
M

I've started work on this, and will update this thread when I have it in a repo. That might be later today, it might be in another day or two. I managed to get:

1. A modified Dockerfile
2. A modified startup script
3. The image pushing to a (local) private repo
4. An install into my local Cloudron

And, at that point, I have more environment variables to set.

So, it seems possible/I'll make the work public shortly.

Agreed. I'm not offering thoughts from a spirit of "GIVE UP!," by any means. It is more from the perspective of "I think this one is trickier than it seems at first glance."

But, I am still learning. So, the staff may say "this is actually easy!" Or, they might say "Yep, it's kinda tricky." And, as a result, we all learn more.

@Neiluj

I would welcome input from a member of the team on this.

Docker is intended to run a single process in a single container. When you want to run multiple services, you run multiple containers.

This is where you (typically) would use some kind of tool to orchestrate or compose those containers. For example, a docker-compose.yml will define a set of services, and how they connect and interact with each-other.

Cloudron is designed to host singleton containers. Unlike industrial-scale platforms as a service, it provides limited tooling for how to define connections to other services. The manifest allows you to connect to the services that exist; for example, I can say "connect to the Cloudron-provided Postgres server." However, I have no way to say "I have chosen to run an S3 server/Minio at location X, and please use it." As a result, it puts a significant burden on the user. Further, there is no way within the package to say "this should not boot if that service is not present." You have to write custom code in order to provide that logic.

Further, the Docs app itself wants to run multiple services. The frontend is separate from multiple backends in their design. The app itself has orchestration concerns and considerations.

So while I appreciate people saying "but it is all there!," we're not discussing what is required to make this a production-grade package.

1. You have to pull the codebase.
2. Study how it wants to be run, and decide how it can be run in Cloudron.
3. Write a custom build/containerization script for the app, compressing multiple services (that want to be in multiple containers) into a single container.
4. Write custom code to make sure external services that are not part of the Cloudron PaaS are present, and fail gracefully/in a way that a non-expert user can debug, so that they can add those services and connect them to the app.
5. Make this all automated and testable.
6. Maintain all of this while upstream rapidly evolves.

I'm forgetting things, I'm sure. I estimate 80-120h of work in this, and it is essentially devops work. It should bill at $85+/hour. Further, I'm notorious for underestimating how long it takes to develop features by a factor of 2x-4x. So, I think this is work worth at least $8K-$12K---to say nothing of having to maintain the package, against a large, fast-moving target. (And, while it is open source, governments tend to be very careful about accepting changes from third parties, because there are significant security and compliance burdens they must bear.)

Maybe I'm just accustomed to deployments in Ansible and Terraform, and am overstating the difficulty of this deploy. However, my experience is that when a system is designed to run one way, and you want it to run some other way, there's significant work involved.

So, in return, please forgive my ignorance. I may be misunderstanding things about packaging for Cloudron, and you may be right: this may be easier than I think.

I've started poking at a package for Planka to refresh myself on packaging, because it is a singleton Node app that only has Postgres as an external dependency. It is an example, in my mind, of an app that fits the Cloudron model perfectly. However, anything that wants orchestration beyond the core services Cloudron provides---especially when some of those services are custom components internal to the application itself---is, in my mind, significantly more effort.

Ah. I tend to look at the compose, because if there is a large list of additional services, cramming them into a single container can become a problem from my point-of-view.

I agree 100% with your assessment. (I think that was what I was implying with my #2.)

If the Cloudron team thought this was good to add to the stable of apps, I'd give it a go. And, I'd want to do the work to integrate it into whatever build/test frameworks that are in place. However, my workplace is going through some complex and public difficulties, so my energy at the end of the day tends to be limited. So, that's a "yes, but" on diving in on packaging right now.

Looking at the Docker Compose, this one is actually a very clean/light app.

1. The license is the GNU Affero, so there should be no licensing issues.
2. The Dockerfile is small, and basically a node app.
3. The docker-compose.yml is actually simple! It spins up the image for Planka, it has a whole bunch of environment variables (commented out as documentation, mostly), and it expects Postgres as a database.
4. It has a backup script!
5. It has an active repo and community!

I'm... in a rather tough spot in terms of time, but this feels like a good packaging target. @girish , @nebulon , is this app one that you would want to see in the app store? (To me, that's an important first question.) If so, do you have additional requirements (e.g. tests, automation) that you would want to see in place?

The Docs installation requirements:

https://github.com/suitenumerique/docs/blob/main/docs/installation.md

This requires Kubernetes. Or, their "native" deployment method assumes Kubernetes.

From that page:

an OIDC provider (if you don't have one, we will provide an example)
a PostgreSQL server (if you don't have one, we will provide an example)
a Memcached server (if you don't have one, we will provide an example)
a S3 bucket (if you don't have one, we will provide an example)

In theory, it might be possible to take their repository, and deploy this in a single container as a Django app that uses

• Minio for S3
• The Cloudron-native Postrges instance
• The Cloudron-native OIDC
• ... mumble mumble memcached...

To make this viable, the right thing would be to extend Cloudron to provide a "native" Minio and Memcached instance for apps to use. (That is, have them present from time of install along side the various databases.) I could imagine making a product case for Minio, I think we'd struggle to convince girish and nebulon that the additional complexity of including memached everywhere was worth it.

Either way, this would be a major packaging effort. Without digging deeper, I'm going to assume that the Django app is not abstracted away from the services as well as we'd like, and that K8s requirement will make it very difficult to package/deploy to Cloudron. "Very difficult" means "many, many weeks of work, including changes to the core infrastructure of Cloudron."

(It looks like they have a compose (link) which I suspect is for local development of the app. It uses Redis instead of Memcached, still needs Minio, but also wants an Nginx instance and Celery instance... and Keycloack... and the app is in multiple containers/pieces...)

Long-and-short, there is no apparent easy path to bring this to Cloudron as a single-container/single Dockerfile application.

Someone more familiar with packaging Cloudron apps would be able to answer better than me. However, I find that whenever a docker-compose.yml is involved, it is probably hard to move the app to Cloudron.

https://github.com/AppFlowy-IO/AppFlowy-Cloud/blob/main/docker-compose.yml

In this case:

• It wants nginx. That might be avoidable, or it might be serving static assets/code for the app.
• It wants minio. This could probably be accommodated by requiring users to run minio on their Cloudron before installing this.
• It wants postgres, which might be able to be leveraged from the internal stack.
• It wants redis. Again, possibly from the default stack... I can't remember.
• gotrue is an auth component from supabase. This will need its own container, and may (or may not) play nice with the SMTP/OAuth running on Cloudron.
• appflowy_cloud is the hosted app. It wants its own container, and configuration information for all of the services included.
• admin_frontend has its own Dockerfile. I haven't looked. Looks like more things.
• ai. I have no idea. It looks like it wants some kind of OpenAI. This is getting heavy in terms of resources.
• appflowy_history is... another Dockerfile. Looks like a rust application that has been Dockerized.

The problem, I think, is that Cloudron assumes/is structured such that applications run as single containers. The compose is suggesting that this application has a number of independent components. Perhaps those could be bundled up/run separately... but, it might be a real trick to make work.

This isn't to say it isn't possible, but that's what I see that needs to run, and it isn't clear to me that this is an easy app architecture to move over to Cloudron. YMMV, etc.

Many thanks, all. I missed that bit of the documentation.

I'll definitely backup; I'm running on bare hardware, and didn't even do myself the courtesy of running Cloudron in a VM. I may... use this as an opportunity to change that.

Either way, this is all I needed. Thank you!

I've followed the 8.0.3 to 8.0.4 update path. The underlying platform is still on Ubuntu 22.

Will an eventual update to Ubuntu 24 LTS be managed by Cloudron automatically, or do I need to manage the OS level update myself? (I assume not, but I thought I'd ask.)

Many thanks,
Matt

Hi all,

This thread is intended to document my reading of other support tickets, and what I've done in an attempt to bring my cloudron back.

BLUF: I succeeded, but I don't like how I did it. Ultimately, I had to edit resolv.conf. This ticket can likely be closed.

Initial problem

My experience so far is similar to this thread: https://forum.cloudron.io/topic/12294/autoupdate-cloudron-aborts/9

I pushed the button for the update to 8.0.3. Unfortunately, I did this shortly before leaving the house for two days. I thought "everything will be fine."

Return from trip

I came back to find apps and services down. (Unbound was down, for example.) I did a reboot to see what would happen. ("Turn it off and turn it back on again.") The services came back, but the apps did not.

Looking at one of the apps, I see this error:

An error occurred during the configure operation: Network Error: Network error downloading icon : getaddrinfo EAI_AGAIN api.cloudron.io

Explore the forum

I tried some possibly obvious fixes from the forum.

Update unbound settings

Following this page:

https://docs.cloudron.io/networking/#dns

I added a file to /etc/unbound/unbound.conf.d called override.conf, and it contains the following:

server:
    val-permissive-mode: yes
forward-zone:
    name: "."
    forward-addr: 10.0.0.1

My cloudron lives behind an OpnSense instance which serves as my router, and it is at 10.0.0.1. If you are following this, your DNS server is probably not 10.0.0.1. So, if you're also trying to fix something similar... you cannot just "plug and play" the values I use, but you might be able to follow the process.

After that change and an unbound restart, I could do:

host www.cloudron.io 127.0.0.150

and it reported back

Using domain server:
Name: 127.0.0.150
Address: 127.0.0.150#53
Aliases: 

www.cloudron.io has address 165.227.67.76
www.cloudron.io has IPv6 address 2604:a880:800:10::b66:f001

This is good. I then tried to configure a failing app, and it still would not talk to api.cloudron.io. So, the problem did not go away.

Update netplan

I still had a DNS problem. Based on this thread:

https://forum.cloudron.io/topic/12266/auto-update-to-8-0-3-systemd-resolved-empty-response/6

I considered the possibility that the issue might be deeper down. I went into my netplan, and modified my configuration. It was set for straight DHCP. My netplan now reads as:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      dhcp4: true
      dhcp6: false
      dhcp4-overrides:
        use-dns: false
      nameservers:
        addresses:
          - 10.0.0.1
          - 1.1.1.1
          - 8.8.8.8

This should, I think, set my router as the first DNS option, with Cloudflare and Google as fallbacks.

I did a netplan apply and then I rebooted the machine (shutdown -r now), and everything came back. I also enabled DNS query forwarding in OpnSense at this point, just in case. I don't know that it mattered.

host www.cloudron.io 127.0.0.150

works.

curl https://releases.cloudron.io/versions.json

does not work. So, curl is not picking up the DNS; it seems to be looking to the default :53, which I suspect is not unbound, but instead... something else. dig has the same problem.

 dig google.com
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused

; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> google.com
;; global options: +cmd
;; no servers could be reached

Edit /etc/resolv.conf

I don't like the solution I ended up with.

Based on this thread:

https://forum.cloudron.io/topic/12286/dns-failure/8

I decided that my empty resolv.conf was a problem. (I don't know why it was empty, and I don't like editing a file that claims it will be overwritten.)

I entered

nameserver 10.0.0.1

(again... for me is a good value.)

Reboot

After that change, I was able to manually configure/restart two apps. From there, I decided the fastest way to bring everything back (and confirm things might be good in general) would be to do a reboot from the admin panel.

This is not fix all of the apps. I had to retry the configure task on each, and Restart App for each.

Conclusion

At this point, I now have all my apps back. Cloudron claims v8.0.3 (Ubuntu 22.04.1 LTS), which is the most recent version.

Platform Version: v8.0.3 (Ubuntu 22.04.1 LTS)
Vendor: Dell Inc.
Product: OptiPlex 7040
CPU: 4 Core "Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz"
Memory: 33.51 GB RAM & 8.59 GB Swap
Uptime: 9 minutes

I think this ticket can be closed, but given that a number of updates to 8.0.3 seem to have had DNS issues, I am going to submit this here. It may also be that I fixed the problem incorrectly.

Assuming this is just for you, and not that you want to build out a hosting infrastructure for many people...

Not quite what you're looking for, but you could

1. Render the 11ty site locally.
2. Push it to a LAMP stack or similar on Cloudron.

https://forum.cloudron.io/topic/4042/beginner-s-guide-hugo-gitlab-ci-surfer

suggests a path where you're hosting both Gitlab and runners, which feels heavy. I think Nebulon wrote about this:

https://forum.cloudron.io/topic/1118/hugo-cms/3?_=1717342765687

with Hugo. He used Surfer

https://docs.cloudron.io/apps/surfer/

which would, potentially, do everything you need. You could do your build, and then push the resulting build outputs (_site or similar; I forget what 11ty spits out) to your server using the Surfer CLI.

I've done this for many sites over the years; typically, it's been a recursive scp to sync the build output to the remote host. I've wondered about a setup like you describe, but ultimately, I'm just as happy:

1. Having a git(tea/lab) instance that hosts my code
2. Doing the test and build locally.
3. Taking the resulting build product and pushing it to the web host.

The number of moving pieces to connect up Gitlab/Netlify (now Decap) is more than I would want to do on any given evening, but your mileage may vary. I've been wondering about moving a domain to cloudron, and all it has is one static website. This might be the path I go (that is, use Surfer on Cloudron to be my webhost).

I have a Dell 7040 SFF, with 32GB of RAM.

It has:

1. A 1TB NVMe drive
2. A 1TB SSD
3. An external USB HD (2TB?)

I let Cloudron have the entire NVMe. My Nextcloud instance is on the NVMe. However, I currently do not expect to have more substantially more than 200-300GB of data in Nextcloud.

I run backups to the internal SSD.

I have a cron job that rsyncs (or similar) the backups to the USB drive. The USB drive is mounted using its drive ID, so that it always appears at the same mount point.

There is also a process that pushes (monthly?) my backup to Backblaze.

I probably have too many layers in the backup process, but I had the USB drive around, so I plugged it in.

For network, I run a Protectli box with OpnSense as my firewall. That is not a trivial path; you will have learning to do, if you go that route. I am paranoid, but at the end of the day, @humptydumpty is right: you should be able to configure your cloudron to be as secure as anything you would be running on a VPS.

The only difference, really, is that if the machine at home is compromised, then someone will be inside your network. But, they'll probably be mining bitcoin anyway, and don't care about the rest of your network.

Hopefully that helps.

(If you're trying to store huge amounts of data, I would question whether Nextcloud is your best approach, and give consideration to having a dedicated NAS or similar (which... could run Nextcloud), but you will want to consider using a different disk configuration to support multi-terabyte configurations (I think).)

@girish Thank you. I am running a relay. I will check if I'm blocking 25 outbound (I probably am not). My ISP does not seem to block 25 inbound, because once I opened 25 inbound (I now route 80, 443, and 25 to my.cloudron), mail started to arrive.

I'm confident OpnSense will let me open it in one direction for NAT traversal, and block it in the other.

@necrevistonnezr Thank you. Absolutely good advice.

My firewall pulls dynamically, twice a week? (I'd have to check---might be weekly) from what I've been able to identify as a "good" set of lists. I think have 6-7 different on the firewall. I could go further, but these seem like the "big ones" from my research. Could be good for me to revisit them.

Fascinating.

So, I already had SendGrid already for outbound. I have sent one email in the last month. (Or, my.cloudron has.) This part was already done.

I wiped out my Cloudflare email forwarding experiments, picked a domain to test with, and set up email.

Nothing worked for a while (meaning "why are these messages I'm sending from over there not ending up over here?"), but then I read the documentation. Turns out I had to open port :25 to receive email. Documentation is so silly sometimes.

Email routed through. "Step 3: profit," as the cool kids say.

This is slightly terrifying to me, for what it is worth. My concerns are... at least a decade old here, but is there any reason I need to be concerned about my Cloudron becoming an open relay? Given that I'm using SendGrid, could I close my outbound 25 as a precaution? (Would it matter?) Or, is that what my DKIM and other DNS records are for? (Eh... kinda, to answer my own question. Documentation rears its head again!)

I went ahead and expanded my DNSBL zonelist:

zen.spamhaus.org
spamcop.org
uribl.com
nixspam.org

because I could.

Thank you all again for the responses.

This is all good.

@luckow , @Kubernetes , thanks for the context. The... difference between a data center is mostly immaterial, I think. I mean, unless you consider that there is no power infrastructure in my basement, the ethernet cables are tacked to the ceiling, and there's no redundancy... OK. So, it's a little different. That's a separate issue, though, from the question of "Cloudron as my mail solution." So, thank you for the +1s.

@fbartels , @Dave-Swift , and @BrutalBirdie , I think you've all raised good questions.

• How will I send mail out? Do I relay? If so, what service?
• Will my ISP allow port 25 all the way down? I don't know. I know they're letting :80 and :443 in, because I'm hosting Cloudron at the end of my fiber connection. But, that doesn't mean they're not blocking :25.

Many thanks all. Good considerations.

Hi all,

I once, long ago, ran an exim mailserver with a colleague. At some point, we got zero-day'd, and I decided that running a mailserver was less fun than I thought. I've never looked back.

I maintain a domain on an external provider almost entirely for the email forwarding. That is, I have a domain and addresses that I only forward on to other email hosts (e.g. Gmail).

I could move that domain to my Cloudron. At that point, I would be putting all of my personal infrastructure on a box in my basement, and be relying on it for my most important piece of comms infrastructure. And, I know I'd need to actually test my backup and restore process at that point, because I really couldn't afford to have an outage take out my family's email for (say) days.

Do people use Cloudron for production mail? (I mean, I assume they must.) Are there any concerns? Gotchas? Are there other paths people have walked? I've tried experimenting with Cloudflare's email forwarding solution, but was unable to get it to work reliably (a number of months ago).

Many thanks,
Matt