Cloudron on a Raspberry pi?

malvim

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?

girish

@malvim Given that Cloudron is mostly nodejs, shell scripts, ubuntu and docker, it's very much possible to support ARM. I guess one big "task" to do this is to rebuild all the apps, addon containers to create ARM docker images. In theory, this is just a matter of switching the base container to be ARM ubuntu instead of x86 ubuntu and we are set.

We haven't invested any time in this so far since because while there is much interest from enthusiasts, it's very hard for us to justify the time investment costs.

girish

Hmm, now that I think about it... Maybe it's not as simple as switching the base image to ARM ubuntu. Can one build docker ARM images on x86 or does one require a ARM server? Maybe someone who has experience in this can explain.

yusf

@girish said in Cloudron on a Raspberry pi?:

Can one build docker ARM images on x86

Sure seems like it.

By the way, ubuntu image is already multi-arch.

ARM support would be immensely useful in combination with the upcoming fleet-like multi-Cloudron dashboard feature.

malvim

Thanks for the replies, guys. I'll take a stab at it, tomorrow or on Friday, and see what it looks like. I don't have a Raspberry Pi 4, but I'm willing to even "rent" one for a month to see where I can get to with this.

Thanks a lot!

mehdi

@malvim It would not work right now, as cloudron container images are not built as multi-arch, but everything else may just work out of the box

girish

Yeah, as @mehdi said, I suspect installation, setup and everything will work fine. Just you can install any apps. But I will be curious to know if those things work fine, if you get around to it. Maybe we should just setup the CI/CD system to build app images which we have been planning for a while.

rmdes

This post is deleted!

iamthefij

I've build and maintain a bunch of multi-arch images myself for some of my smaller projects.

You can definitely build on an x86 system by using emulation. I used to install qemu and then use build args to ensure that the right base image was being pulled (eg library/ubuntu for x86 vs armv7/ubuntu for armv7) because otherwise, by default, an x86 machine would pull the x86 image. After building and pushing I generate a manifest and push that so that each platform pulls the right image. This is probably the simplest example I have of that since it's a single Python file.

All that said... there is now an experimental feature of Docker available via the docker buildx command.

Here's a recent (April) blog post from Docker about the new method. It's far simpler, so if you can get that working, it'd be ideal. I haven't taken the time to switch over myself just yet.

malvim

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

will

@yusf THIS!

"Gathers fleet of Rpi's for cloudron to eat"

will

@malvim How about I ship you mine?

malvim

Yeah, it seems mysql-server-5.7 is not available (though there's a later version that is), and I wasn't able to get past installing linux-generic as well, since it seems kernel patching is not exactly the same under arm...

Also, I saw the script downloads a specific version of nginx, which is amd64 as well. I'll keep trying, but I've been having network problems which I think have to do with the provider I chose. I'll get back when I have more news.

malvim

@will Man, I'd REALLY love to, but my guess is we don't live in the same country heheh... I'm from Brazil!

If you can get it on a network with an ubuntu 20.04 version, maybe I can access it via ssh and fiddle for a bit?

will

@malvim Yeah man, PM me what you want on it, and I'll reimage it soonest and beam over creds.

girish

@malvim Yeah, you can adjust that apt line as needed. Essentially, you have to make the https://git.cloudron.io/cloudron/box/-/blob/master/baseimage/initializeBaseUbuntuImage.sh script succeed. You can make the script standalone, it does not require any args.

nginx ARM packages - http://nginx.org/packages/ubuntu/pool/nginx/n/nginx/

Node ARM packages - https://nodejs.org/dist/v10.18.1/

Docker ARM packages - https://download.docker.com/linux/ubuntu/dists/bionic/pool/stable/

Also, I saw you are testing in Focal. One issue I hit (even on x86) was that collectd has issues with the python3 plugin. I haven't gotten around to fix that.

malvim

@girish Yeah, I'll try bionic again, it just crashed on something related to initramfs-tools, and focal still does when i try to install linux-generic, which I assume has something to do with kernel images and the like? This stuff is a bit above my current knowledge, so I'm not exactly sure what I'm doing heheh.

girish

@malvim Cloudron doesn't really use any of the packages like linux-kernel, initramfs etc directly. I think it's just added there for completeness. Feel free to remove them.

malvim

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

malvim

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.

malvim

Alright, so I learned how to load kernel modules, and the problem now is that the / partition in this particular provider is over nfs, and overlay is not supported.

So, as this is not a problem with cloudron on a rasberry pi, and is particular to this provider, I'm thinking of trying to change the docker driver tomorrow, just to see how far I can get to...

malvim

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!

girish

That's fantastic news I replied here about the port forwarding - https://forum.cloudron.io/topic/3324/testing-from-home-without-nat-port-forwarding-capability

yusf

Stellar effort getting this far, @malvim! It’s sounds quite promising.

robi

@malvim arm64 is only available on the rPi 4 as far as I recall.
armhf is for the previous models as they are 32bit ARM chips.

It would be cool if both were supported and autodetected, but you should be aware of the arch differences between the different models.

malvim

@robi Yeah, I don't know much about the different architectures, and at present I don't have access to any earlier armhf model, so I'll keep pushing with what I have for now. Maybe if we can suport the arm64 rPi 4 to start, some modifications (like explicitly handling architecture information, different boot locations and whatnot) will help us deliver cloudron to other models more easily.

malvim

Just keeping everything relating to the rpi setup in this thread:

So I finished setting up, went to https://<ip> like cloudron-setup says, and started domain setup. As per the other thread, I set up my IP to the interface I'm using (wlan0). I'm using Amazon AWS as a domain provider, and set up the keys and such.

So cloudron was able to create the DNS records (using a subdomain, like pi.mydomain.com, which should - and does - create an A record my.pi.mydomain.com pointing to my 192.168 internal IP).

Afterwards, though, cloudron is never able to check for the records, as I cannot seem to resolve the my.pi domain from inside the pi.

Other stuff that happens:

sudo always says sudo: unable to resolve host ubuntu, even though it does change user to root no problem; ubuntu is the default hostname on a bare ubuntu 18.04 install on the pi;
I can dig other domains that are already hosted on my zone, and get corret responses. dig- ing for the my.pi domain either times out with a "no server could be reached" message, or, when I do it RIGHT AFTER a successful dig to other domain, returns an "empty" response (with a line indicating 0 answers, like this: ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1)

I'm a bit over my skill level on this, so if anyone could chime in, id'd be greatly appreciated. Either with an idea on what might be going on, or maybe something I could do/check/run to get mor info on what might be going on.

Thanks!

nebulon

@malvim said in Cloudron on a Raspberry pi?:

sudo: unable to resolve host ubuntu

This is expected and has nothing to do with arm. To get over that you have to setup the hostname correctly. In your case the hostname is still set to the default ubuntu whereas following your example it has to be my.pi.mydomain.com

malvim

@nebulon huh, that makes sense, but I thought this was supposed to be done by cloudron during setup? I don’t remember having to manually set the hostname in any other cloudron setup before, but I might just have forgotten...

girish

It looks like the blocking issue is the DNS does not work? Does host my.pi.mydomain.com and host my.pi.mydomain.com 127.0.0.1 work on the pi?

jamesgallagher

If there's nothing private in it; could you post your /etc/hosts file?

malvim

Yup, so I'm testing it again from scratch.

@jamesgallagher, here's the entire contents of my /etc/hosts right after running cloudron-setup, but before setting up the domain in the browser:

127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

@girish, the record is already there with the previous IP, and right now I'm just after cloudron-setup, but before setupdns.html on the browser. I've ran a bunch of commands, here are the results:

host my.pi.<mydomain.com> - not found
host my.pi.<mydomain.com> 127.0.0.1 - not found
host www.google.com 127.0.0.1 - ok (huh, unbound seems to be somewhat working)
host code.<mydomain.com> 127.0.0.1 (gitea instance on production cloudron) - OK!
host my.<mydomain.com> 127.0.0.1 (production cloudron admin) - NOT FOUND! (wat?)

And I ran host my.pi.<mydomain.com> on my local machine, outside the pi, and it works and returns the old record (192.168.0.109 from my previous attempt).

I'm now setting up DNS in the browser, just to check what happens, I'll re-run the commands and post here.

malvim

This post is deleted!

malvim

Okay, so some weird stuff seems to be going on with the DNS lookup thing, I think. Here's what happened after running cloudron domain setup (setupdns.html on the browser):

I ran it pointing to a subdomain of my domain (pi.<mydomain.com>), and pinted it to a network interface (wlan0, in this pi's case), as @girish suggested. So I'm tailing /home/yellowtent/platformdata/logs/box.log, and here's what I see:

2020-10-07T23:43:30.489Z box:dns/waitfordns waitForDns (try 20): my.pi.<mydomain.com> to be 192.168.0.6 in zone <mydomain.com>
2020-10-07T23:43:30.497Z box:dns/waitfordns resolveIp: Checking if my.pi.<mydomain.com> has A record at 205.251.196.70
2020-10-07T23:43:30.498Z box:dns/waitfordns resolveIp: Checking if my.pi.<mydomain.com> has A record at 205.251.199.85
2020-10-07T23:43:30.500Z box:dns/waitfordns resolveIp: Checking if my.pi.<mydomain.com> has A record at 205.251.192.234
2020-10-07T23:43:30.501Z box:dns/waitfordns resolveIp: Checking if my.pi.<mydomain.com> has A record at 205.251.195.139
2020-10-07T23:43:35.499Z box:dns/waitfordns resolveIp: Checking if my.pi.<mydomain.com> has CNAME record at 205.251.196.70
2020-10-07T23:43:35.501Z box:dns/waitfordns resolveIp: Checking if my.pi.<mydomain.com> has CNAME record at 205.251.199.85
2020-10-07T23:43:35.503Z box:dns/waitfordns resolveIp: Checking if my.pi.<mydomain.com> has CNAME record at 205.251.192.234
2020-10-07T23:43:35.504Z box:dns/waitfordns resolveIp: Checking if my.pi.<mydomain.com> has CNAME record at 205.251.195.139
2020-10-07T23:43:35.516Z box:dns/waitfordns isChangeSynced: NS ns-1094.awsdns-08.org (205.251.196.70) errored when resolve my.pi.<mydomain.com> (A): Error: queryCname ENODATA my.pi.<mydomain.com>
2020-10-07T23:43:35.516Z box:dns/waitfordns waitForDns: my.pi.<mydomain.com> not done ns: ["ns-1094.awsdns-08.org","ns-1877.awsdns-42.co.uk","ns-234.awsdns-29.com","ns-907.awsdns-49.net"]
2020-10-07T23:43:35.525Z box:dns/waitfordns isChangeSynced: NS ns-1877.awsdns-42.co.uk (205.251.199.85) errored when resolve my.pi.<mydomain.com> (A): Error: queryCname ENODATA my.pi.<mydomain.com>
2020-10-07T23:43:35.629Z box:dns/waitfordns isChangeSynced: NS ns-234.awsdns-29.com (205.251.192.234) errored when resolve my.pi.<mydomain.com> (A): Error: queryCname ENODATA my.pi.<mydomain.com>
2020-10-07T23:43:35.635Z box:dns/waitfordns isChangeSynced: NS ns-907.awsdns-49.net (205.251.195.139) errored when resolve my.pi.<mydomain.com> (A): Error: queryCname ENODATA my.pi.<mydomain.com>

So I go to my LOCAL machine to check the records:

$ host my.pi.<mydomain.com>
my.pi.<mydomain.com> has address 192.168.0.6

$ host my.pi.<mydomain.com> ns-1094.awsdns-08.org
Using domain server:
Name: ns-1094.awsdns-08.org
Address: 2600:9000:5304:4600::1#53
Aliases: 

my.pi.<mydomain.com> has address 192.168.0.6

$ host ns-1094.awsdns-08.org
ns-1094.awsdns-08.org has address 205.251.196.70
ns-1094.awsdns-08.org has IPv6 address 2600:9000:5304:4600::1

$ host my.pi.<mydomain.com> 205.251.196.70
;; connection timed out; no servers could be reached

So it seems when I look up the records using Amazon's DNS server IP's instead of their names, I can't look them up! EVEN ON MY LOCAL MACHINE! I have no idea what might be going on. Then, going back to the pi:

$ host my.pi.<mydomain.com> ns-1094.awsdns-08.org
Using domain server:
Name: ns-1094.awsdns-08.org
Address: 2600:9000:5304:4600::1#53
Aliases: 

my.pi.<mydomain.com> has address 192.168.0.6

$ host my.pi.<mydomain.com>  205.251.196.70
;; connection timed out; no servers could be reached
$ host my.pi.<mydomain.com> 127.0.0.1
;; connection timed out; no servers could be reached
$ host my.pi.<mydomain.com> localhost
;; connection timed out; no servers could be reached

So... Yeah, this is where I'm at right now. Totally at a loss hahah! NO IDEA what might possibly be going on now...

girish

@malvim Check the unbound logs maybe? I think in journalctl -u unbound

malvim

@girish meh, I can't see anything wrong

Oct 08 03:53:12 ubuntu systemd[1]: Started Unbound DNS Resolver.
Oct 08 03:53:12 ubuntu unbound[29715]: [29715:0] notice: init module 0: subnet
Oct 08 03:53:12 ubuntu unbound[29715]: [29715:0] notice: init module 1: validator
Oct 08 03:53:12 ubuntu unbound[29715]: [29715:0] notice: init module 2: iterator
Oct 08 03:53:12 ubuntu unbound[29715]: [29715:0] info: start of service (unbound 1.6.7).
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info: service stopped (unbound 1.6.7).
Oct 08 03:54:49 ubuntu systemd[1]: Stopping Unbound DNS Resolver...
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info: server stats for thread 0: 35 queries, 1 answers from cache, 34 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info: server stats for thread 0: requestlist max 18 avg 10.6765 exceeded 0 jostled 0
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info: average recursion processing time 12.169607 sec
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info: histogram of recursion processing times
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info: [25%]=0.371371 median[50%]=1.375 [75%]=25.3333
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info: lower(secs) upper(secs) recursions
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info:    0.131072    0.262144 3
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info:    0.262144    0.524288 3
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info:    0.524288    1.000000 1
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info:    1.000000    2.000000 4
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info:   16.000000   32.000000 3
Oct 08 03:54:49 ubuntu systemd[1]: Stopped Unbound DNS Resolver.
Oct 08 03:54:49 ubuntu unbound[29715]: [29715:0] info:   32.000000   64.000000 3
-- Reboot --
Oct 08 03:54:55 ubuntu systemd[1]: Started Unbound DNS Resolver.
Oct 08 03:54:56 ubuntu unbound[2090]: [2090:0] notice: init module 0: subnet
Oct 08 03:54:56 ubuntu unbound[2090]: [2090:0] notice: init module 1: validator
Oct 08 03:54:56 ubuntu unbound[2090]: [2090:0] notice: init module 2: iterator
Oct 08 03:54:56 ubuntu unbound[2090]: [2090:0] info: start of service (unbound 1.6.7).

I disabled ipv6 on boot just to be sure, but I see nothing. completely at a loss here.

malvim

I'd love to test it on another network, but can't really go anywhere else right now...

malvim

So I found this code in start.sh:

echo "==> Setting up unbound"
# DO uses Google nameservers by default. This causes RBL queries to fail (host 2.0.0.127.zen.spamhaus.org)
# We do not use dnsmasq because it is not a recursive resolver and defaults to the value in the interfaces file (which is Google DNS!)
# We listen on 0.0.0.0 because there is no way control ordering of docker (which creates the 172.18.0.0/16) and unbound
# If IP6 is not enabled, dns queries seem to fail on some hosts. -s returns false if file missing or 0 size
ip6=$([[ -s /proc/net/if_inet6 ]] && echo "yes" || echo "no")
cp -f "${script_dir}/start/unbound.conf" /etc/unbound/unbound.conf.d/cloudron-network.conf

It says unbound sometimes doesn't resolve names if ipv6 is not enabled? I had it enabled, and then disabled it thinking it might pose problems... The code seems to just set ip6 variable and nothing else, not sure whether this might be related to the problems I'm having or not.

girish

@malvim I don't think IPv6 is the issue. IIRC, unbound won't even start without that flag. In your case, unbound is running.

So, I would debug this step by step: First, is DNS working at all? You can do host my.pi.domain.com 8.8.8.8. This uses Google DNS and skips unbound altogether. Does this work? If not, we have to fix this first. Are you able to run the above command on other machines on the same network as the PI?

malvim

@girish said in Cloudron on a Raspberry pi?:

I'm in the middle of running installation without unbound, and everything worked. I'll re-run it now with unbound again, but host my.pi.domain.com does NOT work from any machine inside my home network, and does work from my main cloudron server, so I think there's more to debug here, unfortunately.

host my.pi.domain.com DOES work from my local machine, but not using Google's server, which is kind of weird.

I guess I'll have to solve this issue (maybe with my ISP?) before proceeding with cloudron on the pi. Sucks.

malvim

Okay, so this was related to my ISP. After a few calls with tech support and buying a new router, DNS issues are gone and I was able to install cloudron from start to finish!

Now I ssh into the pi and, as expected, the first containers (mysql, turn, sftp, graphite) are continuosly restarting, since they're installed from the production amd64 images which won't work.

So now I'm thinking I'll just clone, say, the mysql addon (from https://git.cloudron.io/cloudron/mysql-addon.git), try to build it for the pi, publish the image on my repo and try to use it, see if mysql works, and go from there. I'll try to do that tonight and get back to you guys.

What do you guys say? @girish ? Is that the right path to start on?

Baby steps.

girish

@malvim w00t, awesome progress. If you can create a branch of your box changes, that will help others as well. Yes, starting with one of the addon containers is a good start. They all have automatic tests, it's easy to run them as well.

malvim

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

malvim

Hey,

So I'm building docker-base-image and the other initial docker containers, but I can't seem to find them on cloudron's git repo.

I found this code in infra_version.js:

    'images': {
        'turn': { repo: 'cloudron/turn', tag: 'cloudron/turn:1.1.0@sha256:e1dd22aa6eef5beb7339834b200a8bb787ffc2264ce11139857a054108fefb4f' },
        'mysql': { repo: 'cloudron/mysql', tag: 'cloudron/mysql:2.3.1@sha256:c1145d43c8a912fe6f5a5629a4052454a4aa6f23391c1efbffeec9d12d72a256' },
        'postgresql': { repo: 'cloudron/postgresql', tag: 'cloudron/postgresql:3.1.0@sha256:261c38d332a20cd4160930d7395fd342496159e94c522d92fde8163c680adc98' },
        'mongodb': { repo: 'cloudron/mongodb', tag: 'cloudron/mongodb:3.0.0@sha256:59e50b1f55e433ffdf6d678f8c658812b4119f631db8325572a52ee40d3bc562' },
        'redis': { repo: 'cloudron/redis', tag: 'cloudron/redis:2.3.0@sha256:0e31ec817e235b1814c04af97b1e7cf0053384aca2569570ce92bef0d95e94d2' },
        'mail': { repo: 'cloudron/mail', tag: 'cloudron/mail:2.10.0@sha256:3aff92bfc85d6ca3cc6fc381c8a89625d2af95cc55ed2db692ef4e483e600372' },
        'graphite': { repo: 'cloudron/graphite', tag: 'cloudron/graphite:2.3.0@sha256:b7bc1ca4f4d0603a01369a689129aa273a938ce195fe43d00d42f4f2d5212f50' },
        'sftp': { repo: 'cloudron/sftp', tag: 'cloudron/sftp:2.0.2@sha256:cbd604eaa970c99ba5c4c2e7984929668e05de824172f880e8c576b2fb7c976d' }
    }

And I could find the database addons (mysql-addon. postgresql-addon and mongodb-addon), but I'm not sure they're what you use to build these images, and also I wasn't able to find anything to do with turn, redis, sftp, graphite...

I was able to build mysql-addon on top of my arm64 base image, but can't seem to find the others in order to keep going. Are these Dockerfiles somewhere else we have access to?

mehdi

@malvim said in Cloudron on a Raspberry pi?:

Thanks for the replies, guys. I'll take a stab at it, tomorrow or on Friday, and see what it looks like.

I honestly had about 0 confidence that we could go from there to :

@malvim said in Cloudron on a Raspberry pi?:

I was able to install cloudron from start to finish!

in like a month...

Hat's off

nebulon

The mysql-addon repo is at https://git.cloudron.io/cloudron/mysql-addon and according to that repo naming convention also the others.

The sftp addon is at https://git.cloudron.io/cloudron/docker-sftp (not sure why that repo name ended up like it is)

On a side topic, does anyone know of some good naming convention for docker images when it comes to supporting multi-arch?

For example:
cloudron/mysql-amd64:2.3.1 (amd64)
cloudron/mysql-arm64:2.3.1 (arm64)

fbartels

@nebulon said in Cloudron on a Raspberry pi?:

On a side topic, does anyone know of some good naming convention for docker images when it comes to supporting multi-arch?

I think the preferred way is to not have the architecture in the name or tag, but rather populate the manifest properly: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

girish

@malvim we build images manually using docker build and push them out. When building you have to tag it locally as cloudron/mysqladdontest (just docker build -t cloudron/mysqladdontest.). Do the tests work?

malvim

@nebulon thanks! I was able to find most of them, but still missing graphite, turn and mail. Are those regular docker containers as well, and if so, are their dockerfiles published on git.cloudron? A search for those terms did not yield any meaningfule results for me.

On your side topic: I went looking for the arm64 version of the base ubuntu image, and it's published as multi-platform, so I guess there's no need to publish under another name, like @fbartels already answered. What I did have to do, though, was to strip the sha256 hash from the FROM statement. When I tried building on the rpi keeping the hash, docker selected the amd64 version of the image. Not sure how we'd go about making sure the image passes the integrity check (which I assume is why the has is there in the first place) while also being able to build for different architectures.

@mehdi Man, I appreciate it! It was almost about a month just to get my hands on one, then weird networking stuff, trying to sneak in a few hours of banging on this problem in between work... Haha! A lot of fun though! So thanks for the kudos, they're highly appreciated, especially coming from you!

@girish yeah, I'm publishing to a private docker container (which I packaged together with verdaccio in a custom app just to have docker and npm private registers haha), so that part is good, I'm tagging them pointing to it and it's all good.

Haven't run the tests yet, though.

malvim

Okay, so another question: Do we depend on mongodb being 4.0, or can we upgrade it to 4.2?

It seems mongodb 4.0 on arm64 only has support for ubuntu 16.04 (as per https://docs.mongodb.com/manual/administration/production-notes/)

girish

https://git.cloudron.io/cloudron/turn-addon is the turn addon and https://git.cloudron.io/cloudron/docker-graphite/ is graphite (the names are a bit here and there). The mail server is not open, I have sent you an invite though.

malvim

@girish Thanks, I'll check them out!

girish

@malvim said in Cloudron on a Raspberry pi?:

Okay, so another question: Do we depend on mongodb being 4.0, or can we upgrade it to 4.2?

yeah, we can bump it. But it requires the usual round of testing against all apps.

malvim

@girish Cool. I'll bump it to 4.2 (4.4 needs ubuntu 20.04) and keep pushing hehehe. I'll ping people here when I have something we can run tests on.

girish

@malvim Are you using buildx? We bumped 5.6.2 to have docker 19 so we can have buildx

malvim

@girish Not yet, I tried installing it for cross-platform building, but had some errors and didn't want to waste time, so I'm now just building the images from the pi itself. Later today I might have to start using it again for installing cloudron, so that might become enought of a hassle that I try again.

Anyone here with experience building for other architectures using buildx?

malvim

Hey, all.

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

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!

girish

@malvim Wow, that's some incredible progress! If the status indicator is green, it's pretty sure that the addon containers are responding to health checks!

For the test for the addons, there is a test/ inside the repo of each addon. You can just do npm install and npm test.

girish

To be clearer, like this (say with postgres addon). The tests will always test the latest cloudron/{addonname}test image.

$ docker build -t cloudron/postgresqladdontest .
$ cd test
$ npm install # only have to do this once
$ npm test

> postgresql-addon@1.0.0 test /home/girish/yellowtent/postgresql-addon
> mocha --bail ./test/test.js



  Postgresql Addon
Error response from daemon: network with name cloudron already exists
    auth
      ✓ fails without access_token
      ✓ fails with invalid access_token
      ✓ succeeds
    add database
      ✓ succeeds (410ms)
      ✓ succeeds when added again
    remove database
      ✓ succeeds (140ms)
    use the database
      ✓ can create extension (49ms)
      ✓ can create table foo
      ✓ can insert into table foo
      ✓ can read from table foo
      ✓ restart (5241ms)
      ✓ can read from table foo
    backup and restore
      ✓ succeeds to create backup (392ms)
      ✓ succeeds to create new database (422ms)
      ✓ succeeds to clear new database (449ms)
      ✓ succeeds to restore backup (875ms)
      ✓ succeeds to check restore data (47ms)
    restore of invalid dump fails
      ✓ succeeds to create backup (175ms)
      ✓ succeeds to clear new database (434ms)
      ✓ fails to restore backup (174ms)
    restore of existing dump
      ✓ succeeds (1895ms)


  21 passing (35s)

girish

@malvim Our e2e tests use this app - https://git.cloudron.io/cloudron/test-app . You can just build it like any other app and deploy it on Cloudron.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron on a Raspberry pi?