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.
Since we pipe all SSL through frontends, and explicitly reject directly
accessing the main host. However, this call has no payload, so we can
safely allow it without SSL through the frontends. Do that for now, while
we should look at fixing the SSL issue sometime in the future
The idea is a git repository hook will send a POST to this URL, which
will drop a trigger file somewhere. A cronjob (or inotify listener if
we want to be really fancy sometiem in the future) will pick up that
cronjob and run the update script. The goal being to shorten the time
required to process an update.
This can break things (d'uh).
Do this by introducing a new decorator, @ssl_optional. When this is
present, no SSL redirection will happen, regardless of whether the
access comes in over http or https.
This decorator overrides @ssl_required, but for redability's sake,
never use both at the same time.
This will allow us to increase the cache times in the browser for our
CSS, which almost never changes.
Enables a new value to be used in templates, {{gitrev}}, which can be
used to bust pretty much any URL. We could do this for all the images
in the templates as well, but since most of them almost never change,
we'll just enable it manually for each individual image as it becomes
necessray - or just use a ?1, ?2 etc for those.
Enabled by default for CSS and JavaScript links, since those are much
more likely to be changed without having the URL changed.
Cache times aren't increased yet - we'll do that later one we're sure
that all existing caches are expired first.
This will make CSS downloading a single request, instead of making
6-7 requests for each page as it is now. It also moves all the definitions
of URLs for CSS into the templates and not in the raw CSS itself, which
will make it possible to enable client side caching in the future.
Fixes#91
List 5 events on homepage; move navigation / RSS feed links for events above "Upcoming Training"
To maintain the balance of the end columns, this patch also extends the list of
News articles and Planet postings to 7
This is required if the queue is dropped and recreated in pgq as it
gets a new id, which needs to be used when viewing the current status
of the queue in the admin interface.
We don't link statically to it anywhere, but people can link to it from
emails or other places around the world, that sets the search engines
on it's trail.
This allows us to specify both beta and rc versions.
Requires SQL:
ALTER TABLE core_version RENAME COLUMN beta TO testing;
ALTER TABLE core_version ALTER COLUMN testing TYPE integer USING CASE WHEN testing THEN 2 ELSE 0 END;
This replaces the previous ugly hack where beta versions had a negative number
as latestminor, giving a much cleaner model.
Requires SQL:
ALTER TABLE core_version ADD COLUMN beta boolean NOT NULL DEFAULT 'f';
ALTER TABLE core_version ALTER COLUMN beta DROP DEFAULT;
(Yes, we really need to move to something that can do automatic migrations)
This makes no major changes from what was there before from a pure search
perspective:
* /message-id/flat/ was already flagged with a META tag to be excluded from
indexing, since it's the same data as /message-id/.
* /list/ was already flagged with a META tag to be excluded from indexing,
since it carries no actual content, just links, and the links and descriptions
of the lists is already available under /community/ as well.
* /message-id/raw/ required a login so it produced a bunch of 401's anyway,
but this way we don't need to probe for that.
It's more efficient to block these things in robots.txt so we don't have to
spend the processing power to render a page that's not going to get indexed
anyway.
All templates using {% csrf_token %} need to be rendered with a
RequestContext.
This reverts most of commit 58a08f2590
Also permit POST requests to /search/ -- these aren't relevant to the
site itself, but this used to be allowed before.
We want an API for this so they end up in the queue with all the other
requests, and get delivered to all our frontends without needing each node
to know about which frontends exist.
Previously we would only purge based on URLs, but some of the upcoming
new work requires arbitrary expression purging.
NOTE! Require the creation of the new SQL procecure in the database,
either from varnish.sql or varnish_local.sql depending on if it's prod
or dev.
Previously we required superuser, but that seems a bit excessive. We could
limit it based on specific groups, but for now, we'll allow all staff users.
Now that we have more metadata, we can render this on the main page instead of
on the wiki. This commit copies all the text from the current wiki page, and
uses the new fields in the Version model to render the table on the same URL
as the reference was on before.
This won't happen in production since we don't delete quotes, but it
happens on empty dev environments. It still renders a pretty ugly
frontpage, but it doesn't crash...
This allows all models inherited from PgModel to specify which
URLs to purge by either setting a field or defining a function
called purge_urls, at which point they will be purged whenever
the save signal is fired.
Also implements a form under /admin/purge/ that allows for manual
purging. This should probably be extended in the future to show
the status of the pgq slaves, but that will come later.
Includes a SQL function that posts the expires to a pgq queue. For
a local deployment, this can be replaced with a simple void function
to turn off varnish purging.
