-
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 isarmhf
, 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. -
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...
-
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 toinitBaseImage.sh
andinstaller.sh
inside the cloudron package that is downloaded from the internet bycloudron-setup
- The changes in
cloudron-setup
were just not upgrading the kernel (not installinglinux-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 toarm64
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, butarmhf
, 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 ofamd64
in their names, and stuff likearmv7l
for armhf architecture, it seems. We'd have to map these package names to their architectures in a more explicit way, I think.
- The rpi I was using in the hosting company was not
- 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!
- I was able to install cloudron pretty easily with just a few changes to the
-
@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.
-
@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.
-
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 recordmy.pi.mydomain.com
pointing to my192.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 sayssudo: 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 themy.pi
domain either times out with a "no server could be reached" message, or, when I do it RIGHT AFTER a successfuldig
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!
-
@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 bemy.pi.mydomain.com
-
If there's nothing private in it; could you post your /etc/hosts file?
-
Yup, so I'm testing it again from scratch.
@jamesgallagher, here's the entire contents of my
/etc/hosts
right after runningcloudron-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 beforesetupdns.html
on the browser. I've ran a bunch of commands, here are the results:host my.pi.<mydomain.com>
- not foundhost my.pi.<mydomain.com> 127.0.0.1
- not foundhost 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.
-
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 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.
-
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.
-
@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?