Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added some sample configuration code to the SP Configuration section

The SP includes a plugin for storing persistent information, including user sessions, in a database using an ODBC driver. It's very challenging to get even a simple ODBC "client" application to work across databases, even on Windows. For Linux/Unix, it's approaching the impossibleThe odbc-store.so extension includes support for: MSSQL, MySQL, PostgreSQL, and Oracle.

Before trying to use this pluginextension, strongly consider whether it's really necessary. Most applications worth clustering are not going to be able to rely on the SP's built-in session functionality. It's there primarily for simple web sites and smaller applications.

Even if you do need clustered sessions, a better option may be to run a single shibd instance and share it using a private network between the machines. It's a single point of failure, but so is a database in most cases.

However, if you insist on trying this, here Included below are the basic steps for getting a database session storage system setup. (If you have experience with a specific database, please provide any information down below.) The thing to remember is that the plugin is written to work with a fully ACID database that is providing 100% serializable transactions. This means taking locks on reads to prevent another transaction from updating the record until the plugin is done with it. To my knowledge, only a few databases do that (and Oracle isn't one of them). The result will be a lot of trial and error to adjust other settings to compensate, so expect problems.

Database Setup

The first thing you have to do is get a database ready. The plugin odbc-store.so extension requires a database to store the shared sessions. The odbc-store.so extension does not automatically create any tables for itself, so you have to prepare it. The rough SQL DDL for the database is the following:

...

You may need to adjust data types when moving between database systems, but this has to be done carefully to maintain compatibility. The SQL itself is not yet pulled out of the plugin code, so you can't change it without changing the code.

...

The default configuration file comes with some comments to help set this up. You'll need to uncomment the <OutOfProcess>/<Extensions> element containing the odbc-store.so extension. Then you'll need to comment out the four elements grouped together that manage in-memory storage and uncomment the four below them that are labeled with the ODBC comment.

Code Block
languagexml
titleshibboleth2.xml
  <OutOfProcess logger="shibd.logger">
  <Extensions>
    <Library path="odbc-store.so" fatal="true"/>
  </Extensions>
  </OutOfProcess>

Database Notes

Finally, apart from adjusting any of the timeout controls, you'll have to put the right connection string into the <ConnectionString> element.

Database Notes

Microsoft SQL Server

This is the primary test platform, and has been tested under only light load on both Windows and CentOS 5 (x86_64). On Linux, the freetds FreeTDS client and ODBC driver from the OS were used.

The simplest way to set this up is to use the SQL Server or freetds FreeTDS client and define a server alias so you can give the server a logical name. A typical connection string would then be:

...