Recently (10-20 minutes ago), amazon couldfront (a cdn) stopped sending dns replies in europe:
% dig -t ns cloudfront.net
; <<>> DiG 9.4.3-P1 <<>> -t ns cloudfront.net
;; global options: printcmd
;; connection timed out; no servers could be reached
I was going to do a guide to set up a varnish to replace cloudfront temporarily (and did actually set up the instance, and software – I might do the guide and ami anyway) when I realized, that I (as well as most other people) can just change the relevant url to point to the S3 bucket. Problem solved. That will, however, not be as fast as either cloudfront itself, or a varnish cached backend.
Should anyone be interested in how varnish is setup to handle failures from cloudfront, I’ll happily do an ami.
Some Curious User brought to my attention, that a ticket has been opened which, when implemented, will add a setting for a cache prefix. It will also allow other cache key manipulations.
Django has implemented
Django 1.3 has implemented
KEY_PREFIX in the development version, which currently means, that it will be out in 1.4 iirc.
KEY_PREFIX which solves the problem once and for all.
Until recently I’ve been using the
file:// django cache, but that has a “problem” when multiple users needs to manipulate the cache (think uid 80 writes a key, that uid 1000 wants to delete).
My problem with the
memcached:// django cache provider has been, that it cannot handle being used on a shared memcached instance, because of the danger of key collissions.
Continue reading Django – sharing a memcached instance
I’ve got nothing more to say than:
mads@workmads ~ % cat .ssh/config