School of Computing

Tim Bishop

Computing Officer

Photo of Tim Bishop, if available

Electronic

Postal address

Telephone

  • Tel: +44 (0)1227 827237
  • Fax: +44 (0)1227 762811

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 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.

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 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.

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 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.

Useful Links

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.

Links

  • Open Source Projects:
    • i-scream
      A collection of various tools which I help develop.
       
    • FreeBSD
      A free unix-based operating system which I'm a developer for.
      freebsd logo
       
    • Maildirarc
      A Maildir archiving and Maildir to mbox tool I wrote.
       
  • Kent FreeBSD Mirror:
    • WWW Mirror
      A local copy of the FreeBSD website.
       
    • FTP Mirror
      Mirror of the FreeBSD FTP site (provided by locally run mirrorservice.org).
       
    • CVSUP/CSUP Repository
      Point your cvsup or csup client at freebsd.kent.ac.uk.
       
  • Compsoc
    The university Computing Society which I used to be involved with but which has now gone quiet.
     
  • Homepage
    My homepage outside of work.
     

Statistics

Valid XHTML 1.1 Valid CSS hCard

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

Enquiries: +44 (0)1227 824180 or contact us.

Last Updated: 19/05/2013 00:00