Single file version available here.
Last updated on 2008-06-17.
To discuss, comment here.
| Prev | ||
| Home |
http://www.columbia.edu/acis/sy/unixdev/projects/acis-linux/automatic_installation.html
This document is draft. Last revised Wednesday, February 25th, 2004.
The AcIS Linux Project will benefit from some form of automatic installation, (aka 'jumpstart') functionality. This document will create a reference of such functionality, describe various approaches, and draft a plan to achieve it.
When deploying a large number of machines, ALP can save time and ensure uniformity by automating the process of operating system installation. There are many different software packages that do this in slightly different ways, but they mostly boil down to a few basic methods, listed here along with their benefits, drawbacks, and an software package that implements them:
Disk image: Create one working system (template). Then make an 'image' of the disk. When you want to deploy a new machine, plant the image onto it's hard drive and go.
Filesystem sync: Create a working system (template). When you want to deploy an additional machine, create filesystems on it and then 'sync' the two.
Automated Installation: Automating the OS installer itself. Install OS on a machine using the normal single system method, and record the choices made through the installation process. Supply this information to the installer in an automatic fashion when it boots (url, append arguments, etc.) and the installer installs the OS in the usual way, except making the choices for you.
It is important to note that many different auto install systems have 'hacks' which workaround their natural deficiencies. System Imager for example distributes scripts to modify configuration files for slightly different hardware, though this requires additional configuration. It is not clear where the benefit lies in this approach compared to using a seperate tool designed specifically for this job, such as cfengine.
Regarding type 2 systems, they are not actually installer systems and require an installed system running to run their update software.
Regarding type 1 and 2 systems, there are serious drawbacks as far as hardware compatibility. If one wanted to use the same procedure to install slightly different types of systems (larger or smaller hard drives, raid arrays, etc.) it becomes necessary to multiply the number of configurations stored by the installer. This is in addition to the number of configurations that will need to be stored by the configuration management tool, if the same tool is not used, which is probably will not be, as when compared to tools designed specifically designed for the purpose of configuration management, installer-configuration combination tools fall short. Thus multiple hardware specific configuration sets will need to be maintained.
Type 3 systems do not typically include configuration management tools, allowing us to make seperate choices for that. Their big payoff however is simplicity, elegance, and flexibility. The same kickstart or debian-preseed file would work with multiple architectures (powerpc, i386), as well as multiple hardware configurations (raid, multiple drives, larger or smaller drives, different network hardware, etc.) to the extent that that hardware is supported by the installer itself. Being that most server hardware supported by an OS is supported by the installer, this means that adding different types of machines will not necessarily result (at this stage anyway) in additional work.
Type three systems, acting seperately or in chorus with a configuration management system, provides the most functionality and flexibility with the least work. Thus, ALP will persue type 3, automated installation systems.