Cloudron Forum

I know this thread has drifted somewhere else, but I wanted to come here and say thank you to the devs as well. Thanks for Cloudron and for all your work. Sometimes I think about it and can't really believe there's just the two of you, @nebulon and @girish. You guys plan long-term, commit code everyday, are active on the forums, chats, git issues, are able to take the community's ideas and work with us. This is really much more than I expected from a two-person team, you guys rock!

Also, shout-out to all the app packagers out there, you guys are amazing! And to all the community, really, we've managed to grow a bit and still be supportive of each other, helpful, thankful, we've been able to disagree on things respectfully without becoming toxic.

Here's to many more years of this.

Cheers!

@girish That's great news. You can count on me for translation to Brazilian Portuguese.

Hi, all.

I remember reading somewhere that cloudron wouldn't run on a raspberry pi, bc it required x86. But that was sometime ago, and since then I've seen someone here on the forums claiming it would be possible.

What's the current situation on this, is this possible? I'm currently paying for a server with a lot of storage, and tought maybe if I could run it from my home it could be cheaper. I understand I'd have issues with IP changing and all that, that's why I'm only thinking about it right now, but I'd like to know where we currently stand on that issue?

I understand VERY LITTLE about this, and not sure this question even makes sense in this thread, but I'll shoot my shot anyway:

Would it make sense maybe to make Cloudron a "proper" OpenID provider, backed by its LDAP directory, so we could maybe sign into third-party apps that support OpenID with our cloudron identities?

I think like @nebulon said most apps nowadays are settling for google/facebook/github authentication, but maybe, just maybe, as people get more concerned about privacy, we can push to go (back) towards a decentralized identity kind of thing?

<old-man rant>
Sad how for a while, a decade or two back, we had this thriving hivemind of how the internet would empower us and build decentralized everything, and then all of a sudden we let a few big companies just commodify our identities and sell us as products with no regard for our privacy.
</rant>

Sorry about the last paragraph, but what do you guys think about being an openid provider and stuff?

Hey, yall.

So my Raspberry Pi finally arrived, and I could start testing cloudron on it without the hassles I was having with the hosting company. So here are some thoughts and the current bump on the road I'm trying to overcome:

• I was able to install cloudron pretty easily with just a few changes to the cloudron-setup script itself, and to initBaseImage.sh and installer.sh inside the cloudron package that is downloaded from the internet by cloudron-setup
• The changes in cloudron-setup were just not upgrading the kernel (not installing linux-generic, like I talked to @girish about earlier in this thread), and not downloading the cloudron package from the website, instead using my modified version so I coud change things and test.
• The changes inside the package were pretty much just changing amd64/x64 strings to arm64 in all the downloaded packages
• Another important change is the boot part, where cloudron changes grub files, and I had to switch things to the /boot/firmware files
• I was able to keep unbound untouched, I guess it was a problem with the hosting company

So that was what I had to do, and here are the things I'm currently thinking about this:

• It would be good to have the current architecture in a variable, say arch, but there's a few questions to answer, like:
  • The rpi I was using in the hosting company was not arm64 architecture, but armhf, I think. If there's different architectures for different models, we'd have to test it on others. I currently own an arm64 rpi 4 model B.
  • Some downloaded packages use x64 instead of amd64 in their names, and stuff like armv7l for armhf architecture, it seems. We'd have to map these package names to their architectures in a more explicit way, I think.
• We'd have to extract the boot configuration (grub vs /boot/firmware confs) somewhere

I'm now facing ANOTHER problem, which is: it seems my ISP doesn't allow me to forward low ports like 80 and 443, so I can't really host cloudron from inside my home at the moment. I'm starting another thread asking for ideas with that, but I can't test cloudron apart from the installation process (which went smoothly all the way to the domain setup, but then I can't access it because of port forwarding restrictions).

So there it is, this is were I'm at currently regarding installing cloudron on an rpi, I'd greatly appreciate any input, thoughts, ideas, whatever you guys have.

Cheers!

Hey, all.

Happy to say this is now going on on my raspberry pi:

I have NO idea wheter stuff is really working hahaha.
I'll probably choose a simple app and build it for arm64, then try to install it from command line and run tests, maybe?

Not sure how to run tests against addons, or even apps. Is there some documentation around about this? @girish, could you point me somewhere? Thanks!

@atrilahiji I used yunohost for a while, and cloudron's ssl certificate stuff and containerization was what got me hooked.

I actually liked yunohost's SSO a bit more (from a user standpoint, can't say about it being well-designed or this kind of thing), because IIRC you could actually sign-in to an app and be already signed into all others that you hosted, which was a nice experience overall.

I still think cloudron is a MUCH better product, which is why I stuck with it and started paying for it. Managing of ssl certificates without intervention and containerization were what got me into it, but great documentation, ease of packaging, support, and a thriving community is what keeps me here. Cloudron rocks.

Edit: Just remembered something else: automatic DNS management, and BACKUPS! Holy moly, automatic off-site backups!

Kimsufi server over here, no avx support

@timconsidine Sorry, but that's not it. Putting the "woke socialism" label everywhere is really not what we should do.
I've seen more entitled pro "freedom" people whine about a company not doing what they want, saying they'll call for a boycott or what have you, "vote with your wallet"-style, than anyone else.

I, too, don't like the attitude of "cloudron NEEDS to go open source bc my admins are whining about it". I'd love for cloudron to be open-source, but I understand why it's currently not, and I'm okay with it. So much so that I have been a paying customer since early 2017 on version zero dot something, and have no plans to cancel my membership anytime soon.

I'd much rather have serious, respectful, adult discussion about open source software and business models (which most people in this thread are doing) than slapping labels on others willy-nilly.

@scooke Hi, sorry for the delay.

Yeah, @girish was able to solve the problem, which was not a technical one, as usually is the case with these things, heh.

The email she uses is an alias, and not <username>@<mydomain>, and she hadn't used it in a while. We're both pretty sure she used to be able to log in with either username only (no '@domain'), or with her aliased email <alias>@<mydomain>, but it seems we're both wrong on this.

So I tried to log into her email with <username>@<mydomain> and, lo and behold, it worked.

She doesn't use this email at all, so I'm talking to her and seeing if we change her username, since there's only a few apps and email will be the most important one from now on.

Thanks everyone for the help!

Sounds awesome! You guys rock.

I've had an interest in multi-host support forever, but haven't been following the discussions as of late. Curious about how billing and support will work.

Is this a single dashboard for multiple cloudrons, so that we'll pay for each one separately? Or is it a single cloudron with multi-host capabilities, so that we just throw a bunch of machines on a single cloudron install and it just does its thing?

Thanks!

@girish I've already started and had some minor issues when using ubuntu 18.04, but running now on ubuntu 20.04 (step by step, following the install script so I can debug), and it seems to be going fine.

As for apps, I'll follow @yusf's link and @iamthefij's advice to package one of my own custom apps, which is VERY simple, and see how it goes!

They won't work on /app/code, as it is mounted as readonly inside the docker container. A subdirectory of /app/data would work (though /app/data goes to you backups, not sure if sessions are something you want to backup, but that's not your point).

I've been through trying to create /app/data subdirectories on the Dockerfile, but this doesn't work because /app/data is mounted when Cloudron brings the container up. So /app/data when your app is running points to another filesystem (namely, it mounts a directorie that lives inside home/yellowtent/appsdata/<app-id> on your server). It's a runtime vs "compile time" thing (in this case, runtime vs image build time).

So your best bet is to ensure this directory is created on your start.sh script. Run something like mkdir -p /app/data/sessions (and also chown it to the correct user since start.sh runs as root), and it should work.

@girish great! I was already commenting out these lines to see where it went.

So it seems I'm losing name resolution after installing unbound. Installation of resolvconf is not a problem, but as soon as I install unbound, lots of names stop resolving and I can't install anything anymore.

Not sure how unbound works, might have to go into it a bit more, but my guess is maybe the problem is inside my provider. I'll check with @will later to see if we can try it in his device, and see if the problem persists.

I use gluetun at home with an OpenVPN-based VPN service, and it works like a charm.
Not sure how we would implement it in cloudron, though.

At my home server I use a docker-compose file with all the services, and on the ones I want to use the VPN, I use network_mode: service:gluetun.

Gluetun also needs NET_ADMIN capability enabled.

Just to keep you guys updated on what's going on: I commented out unbound just to go through (and probably have to come back to it later, but still).

I also switched to installing nginx from the repos instead of downloading a specific package with curl manually, as their version is arm64 and it seems the rpi I'm on is armhf, which I know nothing about but some nginx-arm64 dependencies were not being met.

I switched node to the armv7l package and it went ok.

I switched docker packages to armhf, they intalled okay, but it seems I don't have the overlay kernel module loaded and have NO IDEA how to load it heheh. A few google searches still got me kinda stuck, I'll try again tomorrow.

I'd be very interested in a multi-node cloudron setup. I have some stuff I'd be able to host at home, and other stuff I'd like to run on a VPS or physical server somewhere.
Also, there's software that needs tons of storage (like nextcloud), and others that need a bunch of memory but very little storage, so I'm currently renting a server with lots of storage and memory, which could easily be switched to a cheaper dual-node setup, I think.
So yeah, eagerly awaiting that 6.0 release.

Ah, just noticed I might need a new cloudron baseimage, right? Hahah! This is gonna be fun

Hey, @Lonk! You mind testing this on your laptop? I'm not getting these errors only on the Pi, I'm getting them on my amd64 laptop and amd64 server as well!

Repo is here: https://git.cloudron.io/cloudron/postgresql-addon, it's just a matter of:

• cloning it;
• building the image locally (docker build -t cloudron/postgresqladdontest .)
• installing dependencies (npm install)
• running the test (npm test)

Could you run this somewhere and see if you have the same problem?

Thanks!

@marcusquinn I run a nextcloud instance, mysql and all, on a Raspberry Pi at home using docker-compose. It is CPU hungry, yes, but I had no need to use a different docker tag or anything.

Ran with the same docker-compose.yml file I used on my (amd64) laptop for testing and configuration. Not sure we need to repackage for apps that DO provide multi-arch docker images.

There is a need to rewrite a bunch of the install script and initial configurations, with the addons and all. I'm not saying it is easy or trivial, please don't get me wrong. Just saying we might not need to repackage many apps.