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:
Puppet is brilliant. It automates the management and building of our machines. It ensures consistency. It ensures repeatability. It's effectively self-documenting (if you understand Puppet). It makes my life easier. I can't imagine sysadmining without it now :-)
The UK Mirror Service
In April 2012 I took over running the UK Mirror Service. The system had been neglected for a while and was running on a large collection of old hardware using a lot of legacy software. There were a lot of positive points about that system, but with little handover information I took the decision to restructure it from the ground up.
In the subsequent 8 months I built and developed a new parallel system using our Puppet infrastructure and new modern hardware. The new system is more reliable and significantly easier to manage. In January 2013 the new hardware became fully operational and all the mirrors we wanted to keep and been moved across. The migration was complete.
The improved system requires far less sysadmin time and consequently makes justifying it's continued operation far easier.
Linux (and FreeBSD)
We have a long history of Solaris use within the department and the University. But since the Oracle acquisition of Sun Microsystems it has become far too costly to continue using their hardware, and their software looks far less appealing when taken as a standalone product. We're therefore well underway in a migration to Linux and FreeBSD.
There's an awful lot of history on our system, and this is a much larger task than you might think. So it's taking a long time, looking at each system in turn and working out a replacement plan. It's a challenge, but an interesting one :-)
Why Linux? It's pretty much the defacto standard in the open source world. I'm a big FreeBSD fan, but I work in an environment where people and applications expect Linux, so it's easier to go with the flow. We've chosen Ubuntu because of it's excellent packaging system (from Debian), and the choice of LTS and non-LTS releases, depending on the systems we're building. Plus it's free, and we have the choice of paid support if we ever need it. The alternative was RedHat Enterprise, but you have to pay per-machine, and make use of external package repositories if you want useful software.
And why FreeBSD? For non-end-user machines, where the underlying OS doesn't get seen, and when you want the latest software for a particular application, sometimes FreeBSD is the best choice. I try not to get too religious about the whole thing and just pick the best tool for the job.
CSProjects is a home grown system, written by myself and Adam Sampson, to sit on top of Subversion and Trac instances. It's designed to be separate from other Kent systems to make it easier for external collaboration, something which there was demand for within our department.
I recently replaced our old forum system with vBulletin. It provides a much richer and more familiar environment to people within our department.
We have a 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.
We are now starting to make use of the farm for other infrastructure tasks with the aim of replacing most physical servers in the long run.
The farm consists of a number of 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 IT Services 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.
Some people might also be interested in our efforts to make VXFS quotas work over NFS on Solaris. It's fortunately a trivial fix.
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.
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.
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 and resources on machines.
- Munin - produces historical graphs of resource usage on machines.
- i-scream - monitors machine resources.
- Snort - monitors network activity.
Kent IT Clinic
We provide internal 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.
Computer science systems webpages
All about the Systems Group - docs, faqs, etc
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.
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.
- Open Source Projects:
- Kent FreeBSD Mirror:
The university Computing Society which I used to be involved with but which has now gone quiet.
My homepage outside of work.
Statistics from the local irc network.