drop python 2.6 (not supported by django any more)
switch from django-registration (dead and broken) to django-registration-redux, fix issue #116
remove south dependency (and south migrations)
create new initial migration with django's builtin migrations
update docs
Some reverse proxy configurations pass REMOTE_ADDR
as a IPv4-mapped IPv6 address when listening on a
IPv6 socket. This patch converts such a mapped
address into a IPv4 address at all usages of
REMOTE_ADDR. It handles both, the ::ffff:192.0.2.128
format as well as the deprecated ::192.0.2.128 format.
this is esp. useful for v6 hosts, where your provider might give you a changing prefix (we assume /64), but your interface ids stay the same.
but same mechanism also principally works for v4 (we assume /29), except that you usually do not get a v4 network where the network address is changing.
and when it comes to dynamic addresses, many people only get 1 ipv4 address anyway. the related host could then be used for aliaseses with ifid == 0 for all aliases.
as we first check for a nochg update, we couldn't always get the expected dnserr here as the dns update is tried after the nochg check.
so, if the address did not change, the test failed. fixed by making sure it is not a nochg update.
as we precisely expect 1 result (0 or more than 1 are error cases), use .get() instead of .filter().
avoid usage of len().
maybe this is a little more efficient than before.
Very similar to /nic/update and /nic/update_authorized, /nic/delete and /nic/delete_authorized delete
the A or AAAA record, depending in the kind of IP address given.
As this is a delete, the specific ip address value is ignored.
for the dnstools tests, tests were already changed to use a random test host in the test zone,
so parallel tests runs should not use the same hostnames.
test_api tests still use same host names, though
there is an issue with south and sqlite - it doesn't handle migrations that add BooleanField columns with defaults.
just use the faults script to set the flags to their correct default after migrating with south.
we do not really need it as far as the service is concerned (we would give some other valid failure result code),
but it might help to user to more quickly find the mistake in his client configuration.
