1. Prefix all our local modules with "pgweb" as required by the new
project layout.
2. Change the django core imports to match 1.8
3. redirect_to has been changed to RedirectView
In passing also tabify the urls file which used a horrible mix of tabs
and spaces. The python standard is spaces, but since the rest of the
pgweb projects uses tabs, make the urls.py files do that as well.
Move manage.py up one step, set up a new wsgi.py file, and adjust
relative paths that refer to other directories for the new project
layout that we need to use in django 1.8.
The queue used for varnish purges has so few entries that it's really
not worth paying the management overhead for skytools/pgq. Instead we
can use a very simple local deamon using LISTEN/NOTIFY to fire them off.
Now include a proper nagios plugin in this package, so we can get rid
of the not-very-nice munin plugin currently used in the deployment.
This appears to have become dependent on a django setting that we no
longer set -- and it's best to have a predictable format regardless.
Most things on the frontpage used the standard format, but not news,
leading to an annoyingly inconsistent view.
We were already using signals for everything except delete, and even
in our old version of django the delete signal exists (it didn't exist
when this code was first written).
Django doesn't really like models to be OOP like this, so keeping PgModel
would cause issues with upcoming changes in django 1.8. Using simple functions
is easier, and the actual functionality is replicated straight off.
This removes the dependency on django from docload, facilitating
incremental upgrades of the infrastructure.
This now requires a new docload.ini file in the tools/docs directory,
with a section "db" and a setting "dsn".
These errors typically happens when someone tries to log in before they
have completed the process by clicking the link in the received email,
so give them an error message showing this.
The check was for is_behind_cache without the (), meaning it always
returned true, which in turn meant we trusted all x-forwarded-for
headers. It was pretty hard to get them into the system, and
we didn't actually use it for anything other than locking survey
submissions, so it's not a big problem.
However, the basic logic was also wrong, as it assumes that all
SSL connections terminate directly at the backend server, which is
not necessarily true anymore.
The new version of the function will trust an X-Forwarded-For as
long as it's set on one of our frontend servers, regardless of if
it's an encrypted connection or not.
