If you’re finding that you’re using Fanstatic to
serve static resources within your Python-based server process, you may be left
scracthing your head if you suddenly find that resources aren’t being served
correctly. For me, this was manifesting as an incorrect Content-Type
header, always being set to text/html for any type of static file being
served. As a side effect, because I’m using Diazo to
theme my backend Pyramid application, this was automatically seeing this
mimetype being returned to the browser and trying to “theme” the raw files.
The global picture looked like a whole …
Just created a new Shibboleth Service Provider (SP) instance and found an
Identity Providers (IdPs) is not releasing attributes to you? Don’t
worry, you’re not alone. In fact, the issue is far more common than you think,
despite a lack of documentation on the web.
Confirming the problem
Firstly, make sure that your Shibboleth SP configuration is, as best you can
tell, correct. Also, make sure that your shibd daemon has been
restarted after any configuration changes you’ve made (and your
FastCGI shibauthorizer and shibresponder applications too, if you’re
If you’re using uWSGI with XML support (this is its default), then it will
be requiring you to have libxml2 installed — or something similar that
provides xml-config. What you’ll find is some erratic behaviour (or
complete failure) when attempting to serve an application that is also
relying on libxml2, but a different version.
In my case, my original uWSGI was built with CentOS 5’s stock libxml2
library, but my Python application was using lxml, built with a custom
version of libxml2 (via Buildout with the z3c.recipe.staticlxml recipe, in case you
were curious). Because of these …
The canonical place for this documentation is now the
nginx-http-shibboleth custom Nginx module
GitHub repository. All updates will be reflected there, and as a result,
this page has become severely outdated. Please contribute to that repository!
With changes in Nginx after version 1.5.4, the auth request module is now
built in. This means the following instruction have changed, yet again.
For the latest information and build process, always see
tl;dr: You can have Nginx with Shibboleth. Rebuild Shibboleth with
FastCGI support, and recompile Nginx with a custom …
Good news! The Shibboleth SP software features FastCGI authorizer and
responder applications for use with your favourite non-Apache and non-IIS
web server. Unfortunately, the default distributions don’t come with it
built by default. I’m looking into why this is the case, but for now
here’s how to rebuild the RPMs yourself.
Note: if you’re just looking to download something that works and don’t
want to rebuild things yourself, we have RHEL 6, x86_64 packages available
in a Yum repo at https://www.hpc.jcu.edu.au/rpm/. You’ll also need to trust
Have you recently installed the Shibboleth SP software and found that
the error pages the software is generating are missing the Shibboleth logo?
If so, it’s because those error pages are attempting to display a logo
(typically /shibboleth-sp/logo.jpg by default) but the logo of the Griffin
that you may have been used to seeing is no longer distributed with the software.
All information here on a server level is related to RHEL 6. You will
need to change some instructions for Debian based systems. CentOS
should be fine and needs only a minor URL change in the repo configuration.
After a switching away from Apache some time ago, our primary web server
had been running Cherokee for quite a while
- since September 2011, in fact, looking back at the configuration history.
More recently, however, I’ve switched us again. This time to Nginx - with impressive improvements in performance and
configurability (10x for some static files) — and reliability.
Originally, the selection of Cherokee as web server software looked
promising - the Cherokee project had been around for a while, was gathering
support, had a reasonable level of uptake, and consistent …
Serving up uWSGI application using Nginx is super-simple and is configured
effectively like a standard reverse proxy_pass. However, the documentation
isn’t entirely clear exactly how one can correctly serve an application
against a sub-directory — and have the application know its correct path
such that it can create correct URLs.
Coming from a background of using the Cherokee webserver, uWSGI operated
slightly differently within its configuration. This behaviour, as best I
know, must have modified the given uWSGI parameters to correctly handle the
sub-directory path. I haven’t looked into it, but it probably just does
the same thing that …
Yes, I’m a little ashamed that I did used to run Wordpress as my blog and my
website. Being a Python developer that I am, it’s not exactly good form, nor
is it good for one’s sanity to have to keep updating something every few days
with security updates. Maybe I’m giving PHP applications and Wordpress a hard
time given their prevalence out in the wild, but the fact remains that it just
wasn’t working for me. It might also have a little to do with the fact that my
existing web host has decided …