Matt Johnson

Systems Programmer
Computing Support Group
Department of Computing
Imperial College London

Making your sysadmins' lives easier...

Telephone: (020) 7594 8440 (x48440)
Email: mwj@doc.ic.ac.uk
Web: http://www.doc.ic.ac.uk/~mwj/

Note: This page does not reflect the official policies of the Computing Support Group in any way, shape or form.

I (speaking as a sysadmin) appreciate that a systems failure which means you can't work is frustrating, particularly if you have an imminent deadline for a paper, project report or somesuch -- and we all know that computers, switches and power switches always seem to choose the most inconvenient time possible to give up the ghost and start causing trouble!

In no particular order (yet!), here are a few things that would really help me to solve any systems problems that you approach me about.

• Your first stop when reporting a fault should always be either:
  • sending an email to help@doc
  • calling x46664
  • visiting the Helpdesk in person (Room 220 Huxley)
• This does not mean calling specific people in Systems, or calling into the Systems office unbidden -- there is a sign on our door, please read it!
• The Helpdesk is the first line of support, and they can deal with the vast majority of user problems, particularly during term-time when a member of the Systems Group is also in the Helpdesk to assist. However, if the staff in 220 cannot help you, they may either log the problem and pass it to us internally, or, if it is more urgent, ask you to go to 225 (the Systems office). If the problem has been passed to us by the Helpdesk staff, now we become fair game for questions. :-)
• Conversely, if Room 220 is closed, please do feel free to call into 225, particularly outside of term-time. The college vacation periods, particularly the Summer, are the only opportunity the Systems Group has to perform large-scale development, and as a result the full-time Systems staff tend to be coding in 225 during these periods.
• If you are asked to call into 225, please bear in mind that it is a working office first, and a second-line help service second. As a result, people who appear busy in 225 most probably are -- please don't disturb them! Knocking quietly on the door before entering serves two functions: it's polite, and it also allows us to finish the line of code (or sequence of mouse clicks, or whatever) we are working on before we help you with your problem.

• Telling us that an application "doesn't work" or "is broken" or "brings up an error" makes the problem report almost as useless to us as the application is to you! In order for us to be able to help, we need to know exactly how the application doesn't work. Does it produce an error message? If so, tell us what it is -- and copy it accurately!
• If something really big has broken (e.g. home directories under Linux gone away, access to the Internet at large), we probably already know about it! Again, we (the members of the Systems Group) do our best to keep the Helpdesk updated in the case of any problems, and so asking the Helpdesk about current problems (and/or checking the CSG webpage) is the first thing to do if you have a problem.
• If something has broken in your surrounding area (e.g. your whole office suddenly loses access to the network), it is very useful (and probably equally instructive to you) if you check along the corridor to see if anyone else is having the same problem. It may of course be that the problem is Department-wide, but if you can come to the Helpdesk with information such as "Everyone I've asked on level 3 can't get to their home directories nor access the Internet", that will allow us to pinpoint the problem more quickly (and fix it)!

• Project (and lab exercise) problems: Please, before contacting CSG, think carefully about the problem you are reporting. If it is an "implementation problem" (i.e. "How do I do X?") you should almost certainly be asking your Project Supervisor, PPT or Lab Co-Ordinator for advice. (This is far more prevalent in project situations than in lab exercises.)
  If it is a "this should work, but it doesn't", then CSG are likely to be more interested. If you can come up with compelling evidence that the problem is systems or configuration related, CSG will be very interested and will help you as much as possible -- a recent case of where we are happy to help was with a project student who was attempting to use Rendezvous (multicast) and was seeing inconsistent behaviour across lab subnets. In other cases, CSG will examine the problem and determine whether it is indeed a systems issue; if it is not, we will probably point you in the direction of your error and suggest you contact your Project Supervisor (or other appropriate academic) for advice.
• Deadlines and systems failures: If a systems failure impacts negatively on you being able to fulfill an academic deadline, your first port of call is your Year Rep, and the academic responsible for the deadline. If it's an integrated lab (Years 1 and 2 or MSc), your Lab Organizer is the person to contact, otherwise, the lecturer for the course concerned. They will then contact CSG if they deem it necessary to verify any problem, and will make their own decisions on any possible extension. However, it is your responsibility to ensure that deadline-critical work is backed up and handed in on time.
• Home directory quotas: The disk quota you are allocated at the beginning of your course is ample for the full length of your course with us. If you find yourself over quota, you should check your home directory for the usual miscreants which use lots of disk space -- core dumps (core.*) and web browser caches (.mozilla/*/*/cache/, .netscape/*/cache) usually eat quotas for breakfast when misconfigured.

• Windows Profiles: Above all, Windows users, do not confuse your Profile Quota with your Disk Quota. Your Profile Quota is permanently fixed (we cannot change it on an individual basis), and reflects the contents of any files in your Windows Profile, which includes any files on your desktop. Furthermore, Windows profiles are not backed up -- do not store files you care about on your Desktop!
• Backups are good: CSG has both tape backups and the Online Backup System, which are backups we take at varying periods of time. However, when you have data you really care about (for example, project reports...), there's no harm in taking regular backups onto your own removable media, or across the Internet to a non-DoC host.