This was discussed in a previous post. Various changes
have happened since then, improving the customisation process and updating
for newer versions of Nginx and associated add-on modules.
I’ve updated the custom version of Nginx that supports operating with a
Shibboleth SP to version 1.6.0, now that this version has become the lastest
The build scripts located at
https://github.com/jcu-eresearch/nginx-custom-build have been updated, along
with the patches required to make the Shibboleth integration happen due to the
changes in the Auth Request Module now being built into Nginx since version
If you’re running a Python-based web application and using SQLAlchemy as your
database integration layer (as an ORM or otherwise), you may also be using
uWSGI to act as the application container.
If you try and fire up multiple processes to handle greater load coming in
with the uWSGI option --processes (or -p, --workers; or uWSGI’s
various configuration mechanisms), then you’ll probably find that after a
short time, your web application will lock up and refuse to serve requests.
For me, this was between 1 and 10 requests with using the cx_Oracle
database adapter against an Oracle ...
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
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 ...