backup: dont remove old increments because then we lose the backup history right before the last full backup, instead let them disappear along with full backups when a whole chain becomes very old

Doesn't seem like 2 minutes is a problem, but 4 minutes seems better. A little less bandwidth, possibly less battery usage (though we don't have evidence that's actually true), and the interval should be shorter than any peer timeouts that might occur due to inactivity

fixes #129

if the machine didn't have resolvconf before (my box didn't after an upgrade from Ubuntu 13.xx), make sure it has it now and archive any old resolv.conf since it should now only list 127.0.0.1 for bind9

migrate the migration state from MIGRATIONID in /etc/mailinabox.conf to STORAGE_ROOT/mailinabox.version so that the data format of STORAGE_ROOT is stored in the directory itself

after creating the local encrypted backup, execute the after-backup script if the user has provided one to copy the files to a remote location

whats_next: offer DNSSEC DS parameters rather than the full record and in validation allow for other digests than the one we suggest using

fixes #120 (hopefully), in which Gandi generates a SHA1 digest but we were only checking against a SHA256 digest

Also see http://discourse.mailinabox.email/t/how-to-set-ds-record-for-gandi-net/24/1 in which a user asks about the DS parameters that Gandi asks for.

dont ask the user for the machine's IP address if we can be sure our guess is right (trust icanhazip to give us the right answer)

put a 15-second timeout in asking icanhazip.com for our IP address, although this limit does not seem to actually work (i.e. if I set the limit to 5 seconds, curl still hangs 10+ when I turn off my network connection)

have nsd bind to the network interaface that is connected to the Internet, rather than all non-loopback network interfaces

hopefully fixes #121; thanks for the help @sfPlayer1

the SSL private key would be overwritten if ssl_certificate.pem file was deleted; maybe the cause of #98

* check that the PUBLIC_IP is not listed in zen.spamhaus.org
* check that the PRIMARY_HOSTNAME is not listed in dbl.spamhaus.org
* check that a connection to Google's MTA is working (i.e. we're not on a residential network that blocks outbound port 25)

see #118

the cron job to re-sign DNSSEC zones was still not working because the script needed a hash-bang line; what I did in 65c3a44e didn't actually fix the problem

fixes #116

Rather than pass `-r /dev/random` to ldns-keygen (it was `-r /dev/urandom`),
don't pass `-r` at all since /dev/random is the default.

Merges branch 'master' of github.com:pysiak/mailinabox

/dev/random should be used for crypto-grade RNG.

To make sure use of /dev/random doesn't stall due to lack of entropy, install haveged which fills the entropy pool with sources such as network traffic, key strokes, etc.

On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
	modified:   setup/dns.sh
	modified:   setup/system.sh
	modified:   setup/webmail.sh

dont serve web for domains with custom DNS records that point A/AAAA elsewhere, and in whats_next only check that an A record exists on a domain if we are serving web on the domain

the cron job to re-sign DNSSEC zones wasnt working after adding the API key to the management daemon because the script relied on a bash-ism but cron runs it with (probably) sh

Merges branch 'patch-1' of https://github.com/sfPlayer1/mailinabox

Add new extra bool parameter.

The dns_update script didn't generate IPv6 (AAAA) glue records for the name servers.

This caused http://dnscheck.pingdom.com to complain about a mismatch between the glue records reported by the parent name server and mailinabox nsd.

Here's the failing dnscheck output for reference:
> Checking glue for ns1.my.domain.tld (1.2.3.4).
> Child glue for bgwe.eu found: ns1.my.domain.tld (1.2.3.4)
> Checking glue for ns1.my.domain.tld (1234::1).
> Missing glue at child: ns1.my.domain.tld
> Checking glue for ns2.my.domain.tld (1.2.3.4).
> Child glue for bgwe.eu found: ns2.my.domain.tld (1.2.3.4)
> Checking glue for ns2.my.domain.tld (1234::1).
> Missing glue at child: ns2.my.domain.tld

I'm not very familiar with Python and DNS, please verify ;)

don't create a www. subdomain on any domains that are themselves subdomains within a zone, i.e. don't create www.PUBLIC_HOSTNAME if PUBLIC_HOSTNAME is a subdomain of another domain, which is what we normally recommend

run management/dns_update.py from the console to dump the DNS records, with explanations, in case the user wants to host DNS off of the box