$ debconf-get-selections --installer > file $ debconf-get-selections >> file
Introduction & Explanation
Desktop / New-User Friendly Installers
Run-from-CD Distributions / Installers
Unofficial (or Beta) Installers
Official Installer
Specialised Installers
Chroot Installation
UML Installation
PXE Installation
Installation from Windows
USB Memory Stick Installation
Non-Interactive Installers
Roll Your Own
documented on: 2005.01.16
For installing on multiple computers it's possible to do fully automatic installations. Debian packages intended for this include fai (which uses an install server), replicator, systemimager, autoinstall, and the Debian Installer itself.
The Debian Installer supports automating installs via preconfiguration files. A preconfiguration file can be loaded from the network or from removable media, and used to fill in answers to question asked during the installation process.
The preconfiguration file is in the format used by the debconf-set-selections command. A well documented and working example that you can edit is in Section C.1, "Preconfiguration File Example".
Alternatively, one way to get a complete file listing all the values that can be preseeded is to do a manual install, and then use debconf-get-selections, from the debconf-utils package, to dump both the debconf database and the cdebconf database in /var/log/debian-installer/cdebconf to a single file:
$ debconf-get-selections --installer > file $ debconf-get-selections >> file
However, a file generated in this manner will have some items that should not be preseeded, and the file in Section C.1, "Preconfiguration File Example" is a better starting place for most users.
Once you have a preconfiguration file, you can edit it if necessary, and place it on a web server, or copy it onto the installer's boot media. Wherever you place the file, you need to pass a parameter to the installer at boot time to tell it to use the file.
To make the installer use a preconfiguration file downloaded from the network, add preseed/url=http://url/to/preseed.cfg to the kernel boot parameters. Of course the preconfiguration will not take effect until the installer manages to set up the network to download the file, so this is most useful if the installer can set up the network via DHCP without asking any questions. You may want to set the installation priority to critical to avoid any questions while the network is being configured. See Section 5.2.1, "Debian Installer Parameters".
To place a preconfiguration file on a CD, you would need to remaster the ISO image to include your preconfiguration file. See the manual page for mkisofs for details. Alternatively, put the preseed file on a floppy, and use preseed/file=/floppy/preseed.cfg
If you'll be booting from a USB memory stick, then you can simply copy your preconfiguration file onto the memory stick's filesystem, and edit the syslinux.cfg file to add preseed/file=/hd-media/preseed.cfg to the kernel boot parameters.
Wed Jun 30 07:40:44 PHT 2004
> There's one thing I'd like to see in dselect though: let it mutate > from just a package manager to a full-scale installer system suitable > for system cloning
Although I don't know if any of them are quite what you expect, there are a number of pretty good automatic installation systems available for Debian (sort of like kickstart). I personally use FAI[1] which has a class-based system that allows you to very flexibly design a fully automatic installation system for Debian machines.
Some alternative tools exist, although I have yet to find time to try them out and compare them with FAI. There's autoinstall[2], and Replicator[3]. There may be others, but I haven't quite found them yet.
So far I'm pretty happy with the flexibility of FAI, although Replicator looks interesting enough to make me want to look into it in detail when I have the time.
Federico Sevilla
Template Tree 2 is a software system for efficiently managing the configuration of large and heterogeneous Unix installations.
Setting up a Unix machine in an enterprise environment requires not only the installation of the OS distribution, but also a great deal of customization to integrate the machine into the local environment.
This integration process requires the replacement of some parts of the operating system with customized configuration files or even the integration of whole new features. Files like /etc/services, /etc/inetd.conf, /etc/mail/sendmail.cf come to mind but also third party software like AFS (Andrew File System), SSH (Secure Shell) or Postfix.
These changes have to be performed during the initial installation of the machine but may also be necessary after changes to the local environment and if updates or security fixes have to be integrated.
At the simplest level this customization is done by hand on an individual, per machine basis. This has unacceptable disadvantages in an enterprise setup:
Progress is slow due to the interactive nature of the work
Cost is high because highly skilled personnel is required to perform repetitive and tedious tasks.
Documentation of the customization is often poor because it is at best in the form of an installation log. Clickable interfaces are the worst when it comes to documenting what has been done.
The approach scales linearly or worse if the growing likely hood of inconsistencies is taken into account.
In other words automation of the post install process is imperative for large installations.
An simple approach taken by many is to write a special customization script which is run on a machine after its installation. While this script can do everything necessary and is also fast it does not solve the scalability issue on another level:
Not every machine is the same this means many special cases have to be handled by the script.
Customization itself can be a complex venture. With an all dancing all singing customization script the script itself becomes huge and unmanageable.
Template Tree 2 resolves these issues. It uses a centrally configurable, modularized approach to the problem.
The different aspects of a computers post install customization are grouped into features. One feature could be SSH support another one the local printer setup. Each feature consists of a set of files and a META file describing how the feature is to be applied to a machine.
A single central configuration file pulls all the features together and defines which feature should be used on which host. The syntax of this configuration file has been designed to allow highly flexible configuration without sacrificing legibility.
The teTre2 program is basically a preprocessor. It converts the configuration information contained in the tetre configuration files and in the feature tree into a number of target formats.
At the moment there are two target formats available. First there is cfengine which generates a cfengine configuration file. You can then run this file with cfengine to update the local machine. Second there is a pod mode which produces comprehensive documentation of all features available in the local feature repository.
documented on: 2007.08.03
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.
Pros: Simple. Can also be used for updates in a limited fashion.
Cons: Need identical hardware, right down to the disk size. Does not automatically effect host specific changes (i.e. hostname, network configuration, etc.)
Example: Systemimager
Filesystem sync: Create a working system (template). When you want to deploy an additional machine, create filesystems on it and then 'sync' the two.
Pros: Almost as simple as disk image. Can also be used for updates in a limited/expensive fashion.
Cons: Need a semi-running system to start with. Need identical hardware. Does not automatically effect host specific changes (i.e. hostname, network configuration, etc.)
Example: Radmind
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.
Pros: To the extent that the installer supports various hardware and architectures, identical hardware not required. Software updates do not necessitate rebuilding the 'image' or 'golden client'. Not necessary to keep a 'golden client' sitting around for updates to occur.
Cons: Distribution specific. Requires a different tool for updates.
Example: debian-installer, FAI, Red Hat kickstart
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.