Table of Contents
Many of you might have installed an operating system before, probably Windows, possibly Mac OS X or Linux, or possibly even dabbled with other operating systems. The desktop versions of Windows and Mac OS X, which are aimed at the mass market, is designed to be very easy for the user, with minimal choice. Linux systems have been moving in that direction for a long time now, and are now almost as easy, but because Linux caters for a more technical audience, there is still plenty of options to choose from during installation, all the way from “easy and quite painless” up to “frustrating and error-prone”, depending on the distribution you wish to install. Ubuntu and Redhat are both at the “easy and quite painless” end of the spectrum.
Installation of these “easy and painless” systems is comparatively fairly boring, but none-the-less important, and so we have included reading material in today's lab aimed at getting you to think about operating system installation differently (eg. how might you install and maintain a computer laboratory?), as well as trying to get you thinking about how one installation might vary from another (eg. workstation versus database server versus web server).
In brief, today we shall be installing our server, which will be used for the rest of the paper. Here is an overview of what you will need to accomplish today:
You will need to create suitable documentation for what you are doing today, such that another person, with the same training as yourself, can follow your instructions and arrive at the same result. This is the prime assessment for this lab.
Create a virtual machine in VirtualBox. To help this proceed quickly, we shall install it onto the local workstation’s disk, and when it is complete, we shall move it into your “My Virtual Machines” share on Gallardo. Because installation is a very disk intensive operation, and our virtual disk would otherwise be stored on the network, this can save a great amount of time and network resource.
We shall install “Ubuntu 10.04 LTS Server Edition” into our machine. This will be a command-line only environment, for reasons discussed later. We will aim at a suitable “first” system, where we don’t have much of an idea of exactly how we should approach some tasks, e.g. how to partition disk storage.
We shall ensure all system updates come from an appropriate source and are applied to our server.
We shall install the VirtualBox Guest Additions, and make use of the “Shared Folders” feature.
We shall remove some of our ignorance that we had when installing our system for the first time, and figure out just how large different parts of the filesystem are.
Finally, we shall move our new server from its “development” environment on your local workstation into its “production” environment, which for us will be in your “My Virtual Machines” share on Gallardo.
As time allows, you will have a look at some of the extra reading material which covers important background material concerning storage, security issues during installation and different options for installing systems.
To cater for students at different levels of experience, and to help you manage your time and workload more effectively, some material is marked as optional.
In the next lab, which deals with post-installation, we will apply further configurations to introduce it into its new network setting and start performing just some of the many things we would generally do after having just installed a server.
It is recommended you read this section before coming to do the lab.
The largest assessable, though not the largest deliverable, in this laboratory will be your documentation. You need to create sufficient documentation such that one of your class-mates could follow your instructions and arrive at the same result.
First, a few ideas about documentation:
You don’t need to include default options, except perhaps where they are significant. In real-life, some defaults change between operating system releases, and so detailing important default options can be important.
Documentation becomes faulty if it is not maintained, and thus a liability. Therefore, documentation needs to be kept up-to-date with a list of revisions. A list of dated revisions is important for quickly determining what change might have caused a problem. In larger environments, “Configuration Management” and “Change Management” procedures are formal procedures for ensuring that you can easily back out of a change if it causes problems, minimising downtime. Missing documentation is even more of a liability, particularly in complex systems: it makes it hard to determine what services another service might be dependent on, and thus the effect of a service failing.
What does this system do? What has it done in the past? When reading someone elses documentation, it is very useful to appreciate the task that the system was installed for. A lot of servers have had a long life and may have accumulated a lot of cruft over years of service. Knowing what a server does, why a service is needed, how important it is, and the key configuration of it is important information for a team-member to put their hands on.
Of course, putting your hands on such documentation indicates that such documentation should be easy to find. However, in many environments you find very disorganised standards regarding where documentation should be stored, how it should be edited, etc. One person might use a Wiki, one might use a paper exercise book, one might use Google Docs and another might use a Microsoft Word document. This is not helpful if you are a backup systems engineer.
Given the amount of work that is done on servers remotely, a paper exercise book can be too easy to forget to update. Similarly, don’t store your documentation for a server on the same server, lest you can’t get to it when you need it. Collaborative editing can occassionally be useful, particularly as it results in fewer revisions of the document floating around at one time. Being able to access the document is obviously very important, and so if your documentation is kept “in the cloud” (such as on Google Docs), then it would also be useful to occassionally keep the most recent version printed, with its attendent synchronisation problems.
So, what should documentation contain? To illustrate, here is a (slightly edited) table of contents of some documentation we have maintained for one of our servers. Note that each server would be different, so take this simply as a guide. You will not yet understand all that presented here; that’s okay, we’ve put a † next to those items that you aim to complete for this lab.
Management of the server ‘NAME’ Administrator † Who is the administrator, and their contact details. Release Information † What OS and version is this machine currently running? Recent Changes † On every change, this gets updated manually 5 November 2010 4 November 2010 … History The systems history and artefacts Hardware † CPU, Memory, Location, Physical Acess General Management Filesystems † How are the disks partitioned? Network Interfaces † How is the system connected? inside IP address…, Connected to… outside If this host has two interfaces Administration Rights † How to get them Authentication How is user-authentication managed? Password Requirements These are additional to the system default behaviour Password Expiration These are additional to the system default behaviour Software Upgrades † Where does the software come from. How are updates made? Time Synchronisation Is the time synchronised with a time server? Cron What periodic jobs are run on this host? backup Every host should have something similar report-users-old These are particular to this host… … Firewall Where is it defined, brief description TCPWrappers Useful for limiting access to network services Log maintenance and monitoring Backup (client) This is IMPORTANT Bare-Metal Restoration Preparation DOCUMENT how to restore onto an empty disk Restoration Procedure [Last tested: 12 October 2010] And TEST that it works, periodically Role Management What services does this server house? Web Server How important is it? Who should have access? What is its “normal” behaviour? What are its major configuration changes? Any particular policies that need to be catered to? Local E-mail Server Another fairly standard service… …but perhaps you have some added monitoring which you should document. SSH Server Another very standard service… …but perhaps with some added service-specific notes. GIT Repositories for Research Students (via SSH) A lot of servers do fairly unique things, so be sure to document such things well, particularly with regard to any management tools that might be developed.
You may create your documentation anywhere you wish, so long as it is not stored on the server itself. You do not have to follow the outline above, but you do need to at least include the material marked with a †.