The problem
On a couple of Debian Etch systems we have a
plone-site that is published using a
backport of the
nginx web server.
The Zope instance is running on the standard port and serves the Plone
contents under the
/plone path.
Initially we were publishing the site to the external world using an https
site served by
nginx using the following entry on the configuration:
location /plone/
proxy_pass http://plone:9673;
include /etc/nginx/proxy.conf;
The
proxy.conf contents are quite standard:
# proxy.conf
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 0;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
With this settings we see the
/plone contents using the same path that is
used by the
Zope instance, but after testing we have decided to change the
/plone path and server the contents under the
/web path.
The Wrong Solution
The fist option I though about was quite simple, rename the Zope's
plone object to web.
Seems reasonable and simple for someone without Zope experience (I don't
administer the internals of the Zope/Plone site), but now I know that it
is a very big mistake, because renaming objects in Zope in not cheap, as it
implies that the server has to modify all the contents of the renamed object
and the operation can take a very long time.
With my ignorance I tried to rename the plone object using the
Zope
administrative interface and after a minute or so I cancelled the page
loading that was running on my browser, thinking that I had cancelled the
rename operation.
To make a long story short I'll tell you that the operation was still running
and after several hours the folder was renamed (in fact I noticed when the
good solution broke, as I had already solved the problem using the next
method), but something went wrong and part of the site functionality was
broken... the final solution to the debacle has been to recover a backup of
the Zope instance older than the rename operation and continue from that copy.
The Right Solution (TM)
It seems that
Zope has a couple of systems to do
Virtual
Hosting
and the best option is the use of the product called Virtual Host Monster,
a weird and confusing system (IMHO, of course), that does the job once the
right configuration settings are in place.
The best solution to our problem was to modify the requests done by the
reverse proxy without touching anything on the
Plone site (the original one
already had a Virtual Host Monster object installed and that was the only
thing that we needed to add).
The
nginx configuration for the new
/web path is the following:
location /web/
proxy_pass http://plone:9673/plone/VirtualHostRoot/_vh_web/;
include /etc/nginx/proxy.conf;
With this change, when the user asks for anything under the /web/ path the
Zope server gets the contents traversing the
/plone object and adding to
it the elements that appear after the
VirtualHostRoot component, ignoring
components that start with the
_vh_ prefix (the protocol and host name of
the requests are not modified, as we did not touched that).
Once the object is found, the server rewrites the URLs included on the HTML
files using the path components that appear after the
VirtualHostRoot one,
including the suffix of the components that start with the prefix
_vh_.
For example, when the
Zope server receives a request for an URL like:
http://plone:9673/plone/VirtualHostRoot/_vh_web/home
it publishes the content found on:
http://plone:9673/plone/home
but the HTML files returned assume that their base URL is:
http://plone:9673/web/home
Last week we held our promised miniDebConf in Santa Fe City, Santa Fe province,
Argentina just across the river from Paran , where I have spent almost six
beautiful months I will never forget.
Around 500 Kilometers North from Buenos Aires, Santa Fe and Paran are separated
by the beautiful and majestic Paran river, which flows from Brazil, marks the
Eastern border of Paraguay, and continues within Argentina as the heart of the
litoral region of the country, until it merges with the Uruguay river (you
guessed right the river marking the Eastern border of Argentina, first with
Brazil and then with Uruguay), and they become the R o de la Plata.
This was a short miniDebConf: we were lent the APUL union s building for the
weekend (thank you very much!); during Saturday, we had a cycle of talks, and on
sunday we had more of a hacklab logic, having some unstructured time to work
each on their own projects, and to talk and have a good time together.
We were five Debian people attending:
We had the following set of talks (for which there is a promise to get
electronic record, as APUL was kind enough to record them! of course, I will
push them to our usual conference video archiving service as soon as I get them)
Looking back, I cannot think of a single moment when Joey wouldn't have shown the utmost patience and courtesy towards anyone involved in Debian, even towards mere users filing sometimes senseless bug reports against his packages. From this perspective, I cannot help but venture that whatever chain of events lead to Joey's decisions essentially means one thing: Debian must have seriously gotten off-course for someone who has been involved for so long to call it quits. As for the current situation at hands, while I admittedly haven't followed too closely who or what caused Joey's decision, I nonetheless cannot help but feel that whoever pushed Joey's buttons so hard as to make him decide to leave Debian ought to be the one(s) kicked out of Debian instead.
The Linux community 
Yesterday night, we were at Stade de France to witness the debacle of
the French national rugby team against Australia (16-59). 7 tries to 1.
For someone who loves rugby and knows the high level of players we
have in France (Top 14 is a collection of great games every week), it hurts.
Maybe, next time, there will be a little more Toulouse players on the
field and a little less people who have nothing to do there (should I
name a few? Andreu, Huget, Porical...). The only
good point of that game was (as usual) the scrum first row (at least
during one hour...then even there we got crushed by the Australians).
French winter was even here to help, but apparently the yellow/green
folks didn't really care. Australia has a really impressive team,
particularly their back line. We'll be having hard times in RWC in New
Zealand next year.
Big round of aplause at the end of the game for that team.
For our team: a pique.....fort!
Seriously, every time Sarah has surgery, it all goes pear shaped.
The bottom (
Last week-end, I was in Prague for 
(This post is mostly as a reminder to myself on how I've set up my
backup system. It should probably go on a wiki instead so I can keep
it up to date.) After the recent OpenSSL debacle in Debian and
Ubuntu, I found that all my backups were encrypted with something
amounting to a well-known secret key. Ouch. I was not entirely happy
with how my old backup system worked either (it was based on
There are obviously some things we need to remind if we don t want something like the OpenSSL debacle to happen again. It doesn t mean we need to throw stones nor to rush into changing our processes without thinking. However, there are already some things that should be obvious but unfortunately are not.
Because a lolcat is worth a thousand jokes,