This redesigns how update works. installer.sh now rebuild the package,
stops the old code and starts the new code. Importantly, it does not
download the new package, this is left to the caller. cloudron-setup
downloads the code and calls installer.sh of the downloaded code.
Same goes for updater.sh. This means that installer.sh itself is now
easily updatable.
Part of #152
Docker uses an embedded DNS server (127.0.0.11) for user defined networks (UDN).
With the latest releases of docker, specifying 127.0.0.1 as --dns makes the
containers resolve 127.0.0.1 _inside_ the container's networking namespace
(not sure how it worked before this).
The next idea was to only specify --dns-search=. but this does not work.
This makes docker setup the containers to use 127.0.0.1 (or 127.0.0.11 for UDN).
In my mind, the UDN case should work but doesn't (not sure why).
So, the solution is to simply go with no --dns or --dns-search. Sadly,
setting dns-search just at container level does not work either :/ Strangely,
docker run --network=cloudron --dns-search=. appimage # does not work
docker run --network=cloudron appimage # works if you manually remove search from /etc/resolv.conf
So clearly, something inside docker triggers when one of the dns* options is set.
This means that #130 has to be fixed at app level (For Go, this means to use the cgo resolver).
The new DO images have a different label causing DO images to not boot
root@ubuntu-2gb-sfo1-01:~# e2label /dev/vda1
cloudimg-rootfs
net.ifnames=0 is used get unpredictable names as per
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/.
Not sure why we want that.
Not sure about notsc and clocksource.
This change also preserves any existing cmdline
With our current self-hosting installation process, this
is not longer required. It should be the users responsibility
to gain access to his server. For Cloudron managed hosting,
this does not apply as we always create servers with ssh keys.
Also do not tinker with the sshd configs. The user may choose
to use access via password.
Fixes#104
DO uses Google nameservers by default. This causes RBL queries to fail.
Can be tested with the following command:
$ host 2.0.0.127.zen.spamhaus.org
Host 2.0.0.127.zen.spamhaus.org not found: 3(NXDOMAIN)
With unbound we get:
$ host 2.0.0.127.zen.spamhaus.org
2.0.0.127.zen.spamhaus.org has address 127.0.0.2
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
2.0.0.127.zen.spamhaus.org has address 127.0.0.4
Also, we do not use dnsmasq because it is not a recursive resolver. It will
always forward and this defaults to the value in /etc/network/interfaces
(which is Google DNS on DO!).
