Let There Be Light - Forming Policy
An entirely different kind of Policy Editor
In any organisation, it is important that progress happen by consensus. There's very little point implementing a solution if the people who are going to use it are not comfortable with it. When it comes to choosing an Operating System, this should be a Policy Decision.
A common question is "What is Policy?" or "How do you Form Policy?". The answer to the former is simple, Policy is whatever you do, with reasons. It may well be that you already have a policy without implementing it. If you always use djbdns because somewhere at the back of your head you think there's a good reason, that's policy. It just has not been written yet.
People in a room
The best way we found to form policy was to get all of the affected parties in a room and to discuss it. This ensures an independent, hopefully unbiased policy which suits everyone.
This process does not stand on it's own though. It is neccessary to bring everyone up to speed on all of the options. Since one of the solutions we were studying seriously was Debian GNU/Linux, we made sure that everyone had at least some exposure to it in order to assess any benifits it might have for themselves.
Once you do form a policy, it is also important not to consider it too rigid. Policies are guidelines or recommendations. We have a firm belief that they should not be hand-cuffs. They should be designed to make your life as a system administrator as easy and efficient as possible.
Standardise Software
So we got some people in a room, with the aim of forming a consistent Policy on a preferred Operating System, to reduce operational overhead. We chose Debian. Most of the techniques we'll be discussing can be implemented on any operating system, and if you have a significant investment in anotehr Operating System in terms of Staff, Training, Hardware by all means stick with it. Extrapolating relevant approaches from our Debian Case-Study should be more than feasible.
When evaluating software and operating systems our number one requirement was Security. If the project did not have an active, responsive and responsible security team, it was left to one side. Debian is particularly impressive in this regard, and it's excellent co-ordination over issues such as the OpenSSH bug made a mark.
As a leading-edge Research Network, we decided to go with IPv6 availability on all existing and new services, so that became a basic requirement. Other considerations were the consistency and ease of configuration of the software and our ability to support it in production. We also looked for solid remote administration capabilities, including out of band access, which we'll discuss later.
Standardise Hardware
Allthough it wasnt one of our initial policy aims, it turned out very quickly that having bought identical hardware was proving very beneficial from a system administration Point of View. Having utilised some Dell PowerEdge hardware on a small scale we were impressed by some of it's capabilities.
As server-grade hardware, it came with the SCSI and CPU performance we had come to need, but also features like serial console support at a BIOS level have become invaluable. These were features we had enjoyed for years on our high-end SUN and DEC/Compaq Alpha Servers.
As such, a Policy rapidly formed itself based on our aquisition habits. We eliminated as many single points of failure within the hardware as possible by utilising Mirrored System Disks, Dual PSU and Dual Gigabit Ethernet, all of which could be provided with Dell Poweregde Hardware at a price-level we were comfortable with.
We also chose to go with Rack-mountable servers as standard, which greatly improves storage efficiency and lets be honest about it, we like the cool blinky LED's they come with.
The benifits of standardising your hardware are great indeed. From a simple financial point of view, there is a larger discount with greater volume but also from a system administration point of view. It reduces the number of support points, we now deal with one support provider for the vast majority of our server hardware. It makes it possible to develop specific install procedures and media, as we'll see later.
With the economies of scale, it is also possible to implement standby servers more easily. At HEAnet, we invested in a Dell Poweredge as a cold standby server. Because of our hardware policy, it is possible to take the disks from a server which may have a failure of some sorts and to place them into the standby server where we know they'll work. This greatly minimises downtime in the event of a serious hardware failure.
© 2003 Colm MacCárthaigh & Colin Whittaker
