We had all this logic because we allowed the user to create a CaaS
cloudron with a custom domain from the appstore. This flow has changed
now.
One can only set the DNS config after verification. Only thing that
is required is a domain check.
Because of the docker upgrade, dnsbl queries are failing again
since we are not using the unbound server from the containers.
For some reason, docker cannot query 127.0.0.1 (https://github.com/docker/docker/issues/14627).
Make unbound listed on the cloudron network and let docker proxy
DNS calls to unbound (docker always use the embedded DNS server
when using UDN).
See also #130
One idea was to use docker binary packages. However, docker binaries
are statically linked and are incompatible with devicemapper.
See https://github.com/docker/docker/issues/14035 for more info.
Holding will let the user turn on automatic updates for non-security
packages as well.
Fixes#183
When docker is not passed the --storage-driver option, it tries to
auto detect the storage driver. Roughly:
1. If existing storage paths like /var/lib/docker/aufs exist, it will
choose that driver.
2. It has a priority list of drivers to scan in order (driver.go)
As it stands the ordering is aufs, btrfs and then devicemapper.
3. Docker will attempt to "init" each driver. aufs, for example,
tests for insmod'ing aufs and also looks into /proc/filesystems.
The fact that we installed aufs-tools and linux drivers (for aufs
driver) was a programming error since we want docker to use devicemapper.
However, what is curious is why docker still ended up choosing devicemapper
despite having all aufs requirements (as we do not pass --storage-driver explicitly).
The answer is that "apt-get install aufs-tool linux-image-* docker-engine"
can install packages in any order! This means there is a race on how docker
chooses the storage engine. In most cases, since linux-image-* is a big package,
docker gets to install first and ends up using devicemapper since aufs module is not found yet.
For some people, linux-image-* possibly installs first and thus docker
chooses aufs!
Mystery solved.
Part of #183
For reasons unknown, the images build by the buildbot (which currently
uses btrfs), does not work with devicemapper.
Existing cloudrons with aufs will not be affected because docker will
just ignore it.
devmapper: Base device already exists and has filesystem xfs on it. User specified filesystem will be ignored.
Existing AUFS users can move to devicemapper either by restoring to
a new cloudron (recommended) OR
* systemctl stop box
* systemctl stop docker
* rm -rf /var/lib/docker
* Edit /home/yellowtent/data/INFRA_VERSION. Change the "version" field to "1"
* systemctl start docker
* systemctl start box # this will download images all over
Fixes#182
