appbackup_%s_%s-v%s.tar.gz -> app_%s_%s_v%s.tar.gz
drop 'backup'. rationale: it is known these files are backups
timestamp has '-'. rationale: colon in filename confuses tools like scp (they think it is a hostname)
backup_%s-v%s.tar.gz -> box_%s_v%s.tar.gz
drop 'backup' and name it 'box'. this makes it clear it related to the box backup
timestamp has '-'. rationale: colon in filename confuses tools like scp (they think it is a hostname)
Part of #159
Since we don't have cases like failing to charge credit card so far, the
only reason it can fail here is that the appstore token or userId is
incorrect/expired
Fixes#52
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).
Girish Ramakrishnan