Archive for July, 2009

A new look CS website

Wednesday, July 29th, 2009 in Work

A little over 3 years ago I posted about the reskin the Computer Science website at the University of Kent had just received. Well, we’re there again, although we’re now called the School of Computing.

I’ve been working on this project for the last few months. It started out with some meetings with the Information Services web team. They talked us through their current systems and then did a good job of selling their new system (which later became known as Pantheon). We decided to go with the new one, but hit a slight snag – it wasn’t quite written yet.

After a bit of waiting we finally got our hands on the code and I began the integration work. Although we’re deploying their system, we’re running our own copy of it on our servers. This is a good mix; it keeps us in sync with the central web development, but allows us to maintain the flexibility we’ve had for years. So this first integration step was a little slow, and it took some lengthy IRC conversations and a session around my desk to finally get it sorted.

Over the next month or so I spent more time tying this in to our system. I found various bugs and issues with the code and fed my fixes back to the development team where necessary. I also tried to bring across the look from our blog, and sorted out the configuration and menu structures. Then, with a working system in place, and new theme from the web team called Bacchus, I was ready to do the final integration step – tying it in to our existing build system.

At this point time was becoming more of an issue. We could have just chucked all our old ways of doing this out of the window. This might have been less effort for me, but it would have been more for everyone else. The decision was made to stick with our old infrastructure and tie the new system in to our templates. This didn’t turn out to be too hard, and only took a couple of weeks to complete.

What we’re left with is an interesting system. Our build scripts take user generated content and wrap them up with our templates to generate a HTML file. Then, at runtime, this HTML file (which contains special markup) is fed through the Pantheon system which uses the Bacchus template to render the final page. So we’ve got a baked and fried system all in one :D .

The final step was a week long effort to rebuild pages and tweak the various build scripts and jobs to generate reasonable looking and valid XHTML pages. This was more tedious than technical I suppose, but a satisfying finaly step to the project. Then the work passed over to our web editors to start reorganising and rebuilding the content.

And there we have it – the new Computer Science website. Just don’t dig too deep or you’ll find the pages we haven’t finished with yet :-) .

  • Share/Bookmark

Implementing SRS with Exim and SQLite

Wednesday, July 29th, 2009 in Computing, Work

Due to issues with SPF-style restrictions I decided I’d take a look at implementing SRS (the Sender Rewriting Scheme, a good description of which is over here) with Exim. I thought it’d be fairly straightforward and well documented, but it wasn’t. I’m left wondering if anybody actually does it like this?

To start with I built Exim on FreeBSD with the SPF and SRS libraries (I used libsrs_alt). This was straightforward enough – although where are the options in the FreeBSD port? – and would be standard across most operating systems.

Since this was a trial run I thought I’d take the lightweight approach and use SQLite rather than set up a full database like MySQL. This again was a straightforward install.

Lets look quickly and the SQLite tables. The instructions on the libsrs_alt site don’t talk about creating these, so I just figured it out for myself. This is what I ended up with:

# sqlite3 /var/tmp/srs.db .dump
BEGIN TRANSACTION;
CREATE TABLE SRS(Key TEXT, Address TEXT, Time INTEGER);
COMMIT;
#

That’s pretty simple. The database should probably live somewhere a bit more permanent though :-) .

Right, back to the instructions. Basically we need to add a bit of config and a new router to the exim configuration. Starting with the default configuration I added the following option in the global section:

hide srs_secrets = asecurestringofareasonablelength

And then the following routers:

srs_reverse:
  driver = redirect
  domains = +local_domains
  srs = reverseandforward
  srs_dbinsert = ${lookup sqlite{/var/tmp/srs.db \
    INSERT INTO SRS ('Key', 'Address', 'Time') \
    VALUES ('${srs_db_key}', '${srs_db_address}', \
    strftime('%s','now'))}}
  srs_dbselect = ${lookup sqlite{/var/tmp/srs.db \
    SELECT Address FROM SRS \
    WHERE Key = '${srs_db_key}' \
    AND Time > strftime('%s','now','-30 days') \
    LIMIT 1}}
  data = ${srs_recipient}
srs_forward:
  driver = redirect
  domains = +local_domains
  srs = forward
  srs_dbinsert = ${lookup sqlite{/var/tmp/srs.db \
    INSERT INTO 'SRS' ('Key', 'Address', 'Time') \
    VALUES ('${srs_db_key}', '${srs_db_address}', \
    strftime('%s','now'))}}
  data = $local_part@example.org

As you can see in this case, I’m simply forwarding all email to another domain. That’s not the most useful setup, but again I’m just testing.

Note that I had to put these in the opposite order to the instructions. The first router is looking for addresses that are already SRS encoded (so bounces for forwarded messages, etc). If it doesn’t find one, it just passes on to the next one. So this way round work best for me.

That’s it really. At a simple level this works. I’ve not looking at proper integration in to the forwarding setup or any kind of database maintenance yet. But given the lack of useful documentation online I thought I’d post my findings.

If you’re reading this and thinking “why on earth is he doing it like that?” please drop me a comment below and enlighten me :-) .

  • Share/Bookmark