Cloudron on a Raspberry pi?

[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/