diff --git a/docs/admin.rst b/docs/admin.rst index 72f3ee1..d676e7e 100644 --- a/docs/admin.rst +++ b/docs/admin.rst @@ -70,6 +70,14 @@ To create and initialize the database, use:: python manage.py migrate +Create the superuser account +---------------------------- + +To create the user who is administrator of the service, use:: + + python manage.py createsuperuser + + Start the development server ---------------------------- @@ -81,9 +89,8 @@ Start the development server Nameserver ---------- -Now as the server is running, you can log in using the database administrator -account you created in the manage migrate step and use "admin" from the menu -to start Django's admin. +Now as the server is running, you can log in using the superuser account you +just created and use "admin" from the menu to access Django's admin interface. You'll need to configure at least 1 nameserver / 1 zone to accept dynamic updates, see the "Domains" section in the "user" part of the manual. @@ -131,12 +138,12 @@ django apps (wsgi apps) with the webserver you use. Django has nice generic documentation about this, see there: -https://docs.djangoproject.com/en/1.6/howto/deployment/ +https://docs.djangoproject.com/en/1.7/howto/deployment/ Even if you do not follow or fully read the deployment guide, make sure that you at least read the checklist: -https://docs.djangoproject.com/en/1.6/howto/deployment/checklist/ +https://docs.djangoproject.com/en/1.7/howto/deployment/checklist/ HTTP Basic Auth @@ -288,32 +295,33 @@ You need to run some commands regularly, we show how to do that on Linux (or other POSIX OSes) using user cronjobs (use crontab -e to edit it). Make sure it runs as the same user as the nsupdate.info wsgi application:: + PYTHONPATH=/srv/nsupdate.info DJANGO_SETTINGS_MODULE=local_settings # reinitialize the test user: - 50 2 * * * django-admin.py testuser + 50 2 * * * $HOME/env/bin/python $HOME/env/bin/django-admin.py testuser # reset the fault counters: - 55 2 * * * django-admin.py faults --flag-abuse=20 --reset-client --notify-user + 55 2 * * 6 $HOME/env/bin/python $HOME/env/bin/django-admin.py faults --flag-abuse=150 --reset-client --notify-user # clear expired sessions from the database, use your correct settings module: - 0 3 * * 1 django-admin.py clearsessions + 0 3 * * * $HOME/env/bin/python $HOME/env/bin/django-admin.py clearsessions # clear outdated registrations: - 0 3 * * 2 django-admin.py cleanupregistration + 30 3 * * * $HOME/env/bin/python $HOME/env/bin/django-admin.py cleanupregistration Dealing with abuse ------------------ In the regular jobs example in the previous section, ---flag-abuse=20 means that it'll set the abuse flag if the client fault counter -is over 20 (and, for these cases, it'll also reset the fault counter back to 0). +--flag-abuse=150 means that it'll set the abuse flag if the client fault counter +is over 150 (and, for these cases, it'll also reset the fault counter back to 0). --reset-client additionally sets all client fault counters back to 0, so all -counts are just "per day". +counts are just "per week". --notify-user will send an email notification to the creator of the host if we set the abuse flag for it. The email will contain instructions for the user about how to fix the problem. -So, if you run this daily, it means that more than 20 client faults per day are +So, if you run this weekly, it means that more than 150 client faults per week are considered abuse (e.g. if someone runs a stupid cronjob to update the IP instead of a well-behaved update client). @@ -321,7 +329,7 @@ Hosts with the abuse flag set won't accept updates, but the user will be able to see the abuse flag (as ABUSE on the web interface and also their update client should show it somehow), fix the problem on the client side and reset the abuse flag via the web interface. If the problem was not really fixed, then it will -set the abuse flag again the next day. +set the abuse flag again the next week. This procedure should make sure that users of the service run sane and correctly working update clients while being able to fix issues on their own without diff --git a/docs/project.rst b/docs/project.rst index 03f225e..036c44d 100644 --- a/docs/project.rst +++ b/docs/project.rst @@ -27,7 +27,11 @@ Translations are done on Transifex - please collaborate there to avoid double wo https://www.transifex.com/projects/p/nsupdateinfo/ -Translation update workflow (start from a clean workdir): +Please make sure to configure your notification settings so that you are +notified when the translation project is updated (so you can react quickly and +keep your translation fresh). + +Translations update workflow (start from a clean workdir): :: @@ -35,6 +39,8 @@ Translation update workflow (start from a clean workdir): tx pull # update the translations with changes from the source code: django-admin.py makemessages -a + # compile the translations to .mo files + django-admin.py compilemessages # push updated translation files back to transifex: tx push -s -t diff --git a/docs/security.rst b/docs/security.rst index 4071475..f54db13 100644 --- a/docs/security.rst +++ b/docs/security.rst @@ -16,7 +16,8 @@ set to True, it will suggest you better use the https site and link there. Additionally, the service administrator can implement a redirect from the http to the https site within the webserver configuration for the WWW_HOST. The redirect should **not** be implemented for WWW_IPV4_HOST and WWW_IPV6_HOST -as it is unknown whether all update clients can deal with a redirect. +as it is unknown whether all update clients can deal with a redirect (and +support TLS). For the router / update client configuration examples we show when creating a update secret, we use update URLs with https: (and we also tell why it might diff --git a/docs/user.rst b/docs/user.rst index 719d63e..754e9e7 100644 --- a/docs/user.rst +++ b/docs/user.rst @@ -13,7 +13,7 @@ update client. Usually this kind of software is built-in in your internet router (search for "dynamic DNS", "DDNS", "dyndns" on its user interface). -Alternatively, you can also run a software on a PC / server (like ddclient for Linux). +Alternatively, you can also run a software on a PC / server (like ddclient or inadyn for Linux). Or even just use your browser to update your IP via the web interface of the service. @@ -352,9 +352,16 @@ Here are some clients that likely qualify: - good working, reliable - the official version is IPv4 only, IPv6 support needs a patched version - Linux & other POSIX systems +* inadyn (>= 1.99.11) + + - we offer configuration help for it, just copy & paste + - good working, reliable + - IPv4 only + - Linux & other POSIX systems * python-dyndnsc - - IPv4 and v6 support + - still alpha/beta, but works + - IPv4 and good IPv6 support - Mac OS X, Linux and FreeBSD * whatever your router / gateway / firewall has for dyndns / ddns