Tim Bishop

Computing Officer

Electronic

Email: T.D.Bishop@kent.ac.uk
PGP Key:

Postal address

School of Computing,
University of Kent,
School of Computing, University of Kent Canterbury, Kent, CT2 7NF England

Telephone

workTel: +44 (0)1227 827237
faxFax: +44 (0)1227 762811

Blog

Only the most recent entries are included, see the full blog for more.

Eduroam on FreeBSD

We use the Eduroam wireless network at the University of Kent. There’s various guides for getting it working on Linux, but I thought I’d try on FreeBSD. It’s pretty simple.

First create /etc/wpa_supplicant.conf with the following content:

network={ ssid="eduroam" proto=WPA WPA2 key_mgmt=WPA-EAP eap=PEAP group=TKIP identity="tdb@kent.ac.uk" password="YourPassword" }

Then add the following to /etc/rc.conf:

ifconfig_ath0="WPA DHCP"

Replacing ath0 with your wireless adapter if it’s different.

Then start it up as follows (or reboot):

# /etc/rc.d/netif start

You can use ifconfig to confirm the link is up, and ping to test.

For more general information about wireless networking in FreeBSD please see this section of the handbook.

Dovecot is a neat piece of software

For many years now (since before I started working at the University) we’ve been using University of Washington’s IMAP and POP daemons. They worked well, and (through an old bit of unsupported code) also allowed our MH users to access their email.

As time went on people wanted to do more than UW’s software could offer. Things like nested folders, and server-side caching. That’s when we started running Courier IMAP in parallel. This worked, but required users to use a non-standard set of port numbers.

At the time we looked at Dovecot, but it was fairly new, and we were unsure about trusting it with all our users’ email. That was a few years ago, so I decided this week to take another look. This was mainly driven by demand for faster IMAP access to the Maildir folders served by Courier IMAP.

My first impressions were good. I read through much of the stuff on the Dovecot wiki, and I kept thinking and saying to my colleagues “wow, that’s really neat”. Dovecot came across as a well thought out and well structured program, with a vast amount of useful tips and configuration ideas on their website. The level of customisation was good too, right down to allowing you to write a shell script to put in-line and tweak configuration to meet your exact needs.

After a few days of fiddling around I’ve managed to get a setup working that can replace both of our ageing Courier IMAP and UW IMAP installations. It should be a fairly seemless transition for our users, but I’m sure it won’t be that simple in practice. I’ve written a shell script that automatically detects at runtime where a user’s mail might be and sets the configuration accordingly. The script also allows the user to override the mail location and turn on debugging options.

And then there’s the performance issues. One of my colleagues has been having issues with the speed of Courier IMAP, and so far he’s impressed with Dovecot. The main gain here was the ability to store indexes in a separate location. Our mail is stored on an NFS server which becomes a performance bottleneck when using Maildir. Dovecot works around this by storing indexes and caches on a local disk making response times better.

Finally, there’s support. I hit a couple of issues getting things set up so I made use of the Dovecot mailing list. The response times in both cases were brilliant, and in both cases I got an answer to my problem straight away (maybe I asked common or stupid questions? ).

So Dovecot comes highly recommended from me. Give it a try!

(And what about the MH users? Thankfully most have moved on to other things like Maildir & Thunderbird.)

Blog included using rawdog.

Work

I'm a Computing Officer for the School of Computing at the University of Kent. My time is spent on developing new and existing systems, maintaining current systems, and supporting users of these and other systems within our department. Those are listed in order of preference and enjoyment, but in reverse order of actual workload and time spent.

The majority of our core systems are running Solaris, but we have an increasing number of Linux and FreeBSD servers. And a few Windows servers, where necessary.

Here are some of the things that I have deployed and run:

CSProjects

http://projects.cs.kent.ac.uk/

CSProjects is an home grown system, written by myself and Adam Sampson, to sit on top of Subversion and Trac instances. It's designed to be separate to other Kent systems to make it easier for external collaboration, something which there was demand for within our department.

Forums

http://forum.cs.kent.ac.uk

I recently replaced our old forum system with vBulletin. It provides a much richer and more familiar environment to people within our department.

VMware

We have a small VMware farm used primarily for student virtual machines. These are used by students on a modules where each student needs a complete system they can use exclusively. Due to lack of physical space we can't allocate a physical machine to a student for a whole term, so this provides a flexible alternative. Each student retains the same virtual machines for the whole period of their module, and can access it from anywhere on campus or even from home using the VPN.

The farm consists of three Sun Fire X4170 servers and a Sun StorageTek 2540 array. These are linked to the same fibre channel infrastructure as the cluster below.

Veritas Cluster Server (VCS)

We run VCS to make our core services highly available. The system consists of four Sun Fire V240s and two Sun StorageTek 2540 arrays all tied together with dedicated network and fibre channel switches. There is pretty much complete redundancy built in to this system so that in the case of hardware failure all services will continue to run unaffected.

We have the following services running within our cluster:

CSProjects and Forum systems (see above).
Caching DNS server with mirror of Kent domains. This provides resilience if the upstream Computing Service systems fail or are unreachable.
Student databases. Both MySQL and PostgreSQL databases are available for student work.
Internal databases. These back our internal systems such as our helpdesk software, website, and spam checking facilities.
Backup mail hub. Should our other mail hubs all be unavailable this service will ensure email is still delivered.
IRC. Used internally by students and staff across the University to communicate with each other.
Centralised filestore. All our user based servers share filestore shared from this cluster. This gives the same home directories and shared areas on all machines, which gives users more flexibility.
Some internal resources for the Kent IT Clinic.

Future plans include moving our main webserver into the cluster.

Some people might also be interested in our efforts to make VXFS quotas work over NFS on Solaris. It's fortunately a trivial fix.

Mail Hubs

We run a pair of mail hubs that receive all email for School of Computing systems. These hubs offload the work of spam checking from our end-user systems where it had an impact on other work. We currently process around 6,000 emails per day through these machines.

Apart from Exim these machines run SpamAssassin to perform the spam checking. This took some work to integrate, and some development of local tools to allow users to configure individual settings. Our user docs are available here.

Helpdesk Software (RT)

We also use RT to manage our support system. I deployed this and developed various scripts to help integrate RT with our requirements. We have improved our productivity as a result of deploying RT and we would highly recommend it to others.

Software Packaging

We run a variety of Solaris systems ranging from end-user workstations to servers with specific tasks. This requires a lot of software to be installed and distributed to our machines. We have central server which distributes its software overnight to all our machines, with specific rules and exceptions where required. This makes the effort of maintaining extra machines minimal.

For building the software we make use of the GARStow framework. This make it easy to install new software and even easier to keep things up-to-date. We're still in the progress of migrating fully to this system, but most of our core software is done. A list of packaged software can be found here.

Monitoring

We use a collection of tools for network and systems monitoring. Each has it's own role although there is some overlap. They are:

Nagios - monitors services on machines.
i-scream - monitors machine resources.
Snort - monitors network activity.

Kent IT Clinic

We provide interal resources to the Kent IT Clinic. This includes a Windows domain, an Exchange email systems with ISA frontend for offsite access, and internal networking across two sites. We also maintain Internet connections at both sites.

By managing the core infrastructure we allow the students to spend their time working on other more useful projects without fear of damaging the infrastructure required by their colleagues.

Useful Links

Computer science systems webpages
All about the Systems Group - docs, faqs, etc

Research Interests

I don't do much research that isn't directly related to whatever systems work I happen to be doing. So there isn't much here, and the stuff that is here I wrote a long time ago.

Access Control Lists for TCP/UDP in Java

This mini-project was an attempt to integrate some ACL functionality into the existing Java networking API. Specifically I wanted these features in the ServerSocket (for TCP) and the DatagramSocket (for UDP). The code here, integrated into the generic i-scream util package, provides a common ACL class to define an access control list, and then two replacements for the above named classes - ACLServerSocket and ACLDatagramSocket. Both of these two classes extend their non-ACL counterparts meaning they can be dropped straight in as replacements into existing code.

Documentation for the ACL classes is available here:

Source code is available here.

The compiled classes are available as part of the i-scream util package jar file, which is available from here.

You might also be interested in the Queue class which was designed to work in a multithreaded environment.

Statistics

KentIRC stats
Statistics from the local irc network.

Navigation menu

School of Computing

Studying

Activities

Local users

About us

Search