update / improve docs

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

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
 

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

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