Project:Installer/Old/Design
An introduction to the Gentoo Linux Installer project discussing its purpose, design structure, and participants.
Overview
Currently, Gentoo has no guided installer. A number of users has expressed interest in such an application to ease the current installation process. Many users new to Gentoo or Linux in general, find the installation process intimidating and even with a strong assurance of support and excellent documentation, they are reluctant to try. Some users have stated this to be the singular reason they have not moved to or tried Gentoo yet. The current process will still be available to those who choose to use it.
The Gentoo Linux Installer project aims to build a normative installation platform for both desktop and server systems. Generally, the goals of the installer are consistency across architectures, usability for all users, and flexibility. The section on features will give a better overview of the specifics, but suffice it to say it will be for all users, of all experience levels, for all environments.
Features
The following is a list of features that will be present in the installer. While not an exhaustive list, it should give you a better idea of what will be possible. Not all of these features are of use to all users, but the idea is to provide consistency for all users so keep the mantra of "if not for me, for someone else" fresh in mind.
= Multiple front ends
The installer will have interchangeable user interfaces of which some will be X GUIs. Since some platforms are more commonly installed with devices that do not support X windows (Sun serial console installs, etc.) a plain text front end will be developed. Users will be free to develop a user interface (of any nature) as they see fit but, due to maintenance, only one text based and one GUI may be officially supported at first.
Reusable back end framework
The actual workhorse of the installer will be a set of APIs that will be called from the desired client. In keeping a clean and complete separation of functionality and user interface, a generic platform will be established for any tools that wish to control the installation of a Gentoo system. This also promotes strong consistency across all platforms and environments.
Automated deployment
The installer will support automated deployment using pre-configured installation profiles. This will allow easy installation in larger environments with similar hardware or in situations where you wish to store a backup of your machine's initial installation parameters for disaster recovery. The installation profile will contain all data required to "replay" an installation (i.e. cflags, use flags, partitioning schemes, post-install packages, etc.).
Dry run profile generation
Users will be able to create installation profiles by going through the installer without actually performing the steps. All data generated by user actions will be serialized to an install profile (represented as an XML document) which can later be used for automated deployment.
Full support for all Gentoo architectures
As a requirement, all architectures supported by Gentoo will be supported by the installer project. These include, but are not limited to, x86, ppc, sparc, alpha, amd64, mips, hppa, and itanium. (The one notable exception is embedded devices. This is due to a highly specialized environment that the installer may not be able to accommodate.)
Specialized profiles
Specialized profiles such as SELinux will be supported along side the traditional (processor based) architectures. These specialized profiles will support the additional features and requirements of their respective installation processes.
Open policies and standards use
Whenever possible, the installer will use open formats and standards as to play nice with other tools that users development. This includes file formats (XML), network protocols, and other such items. Special care will be taken to not exclude the use of alternate tools and utilities.
Integration with future configuration projects
Wherever possible, the installer will integrate with Gentoo specific system configuration tools and utilities to facilitate post-install setup and configuration of machines. Support for non-Gentoo specific tools such as cfengine may also be included.
Design and Structure
The structure of the installer must be generic enough to support the features above while not abstracting ourselves so far away from the system that simple tasks become difficult or maintainability becomes cumbersome.
A few design requirements were stated:
- Multiple UIs must be supported (abstracted view support)
- A complete separation of model, view, and control logic be kept
- All features must be supported regardless of front end or architecture
- Automated deployment always be possible
To this end, the installer platform (as the entire system is referenced) is broken up into three major parts.
Front end (client)
The client is the user's interface to the system. It contains all user interface logic and support. Also, minor state information about temporary configuration of the client, itself, including command line arguments, environment settings, invocation method (interactive / non-interactive), logging locations, binary package server URIs, and more. Some of these settings will "stick" to the install, but most will not.
The user will be able to use their desired front end to generate installation profiles to be used for later deployment, and in this respect can also be thought of as a profile generation utility.
The client may also integrate with system configuration tools at a later date.
Generally, the client is "dumb" and is unaware of implementation logic of the actual installation process, although some architecture specific logic will be present.
Back end (API or framework)
The meat and potatoes of the installer is a set of object oriented APIs that abstract the actual commands run to install the system. The framework is somewhat abstracted in that the behavior is dependent on what architecture template is being used at the time. The number of discreet steps performed largely depends on the requirements and implementation of the architecture template (an XML file that is similar in nature to Portage's /etc/make.profile information).
Since the framework is segregated from the client, it may be used for customized installation products developed by users. The major classes are as follows:
- A controller class that dictates, based on the architecture template (an XML file), what steps to perform and in what order. This is the core of all logic.
- A installation profile class that maintains all installation information such as partitioning schemes, CFLAGS, USE flags, and other such data. This class can serialize itself to XML which can then be placed on an automated deployment server for later use.
Other minor classes may be used for intermediary support, but these two solidify what is to be considered public to developers of clients.
Deployment server
The third component is probably only of interest to those using the automated deployment features of the installer. The deployment server is actually only a combination of services and files.
Installation profiles may be stored on a machine and served up using an rsync server. The client (or, specifically, the back end) will fetch all available profiles when given the URI of the rsync server. This is the one part of the picture.
The deployment server may also run tftp and dhcp services to facilitate netbooting for large scale installations. This usually requires netboot support on the client machine, but custom live cds with such support may be made available by Gentoo.
In short, the deployment server isn't a specific daemon or service, but a combination of freely available and standard services. The idea is to take advantage of services that may be already running on a user's network.
Process
The actual process of which steps to perform in which order and how is primarily determined by the architecture templates. For the most part, the architecture template will replicate the steps shown in the Gentoo Installation Handbook.
The special architecture templates such as the previously mentioned SELinux can use this same mechanism to alter the standard process. The arch templates will override the default behavior from a generic template. This way, each arch does not have to specify thing such as syncing the portage tree, emerging system, or other such steps that all archs have to do.
Contact
The developers working on the Gentoo Linux Installer congregate in two main places. The IRC channel #gentoo-installer (webchat) (on Freenode) is the main discussion forum where many issues are hashed out in real-time. This is usually the preferred place for in depth discussion. For more general discussion we have a mailing list devoted to the installer. You can subscribe by sending an email to gentoo-installer-subscribe@lists.gentoo.org.
Authors and contributors
All information in this document has been hashed out over multiple conversations from a number of places.
In #gentoo-installer (webchat): blackace, dams, esammer, iggy, karltk, klieber, Method, pauldv, port001, Ramereth, Rupart, spyerdous, npmmcullum, and tseng. Others have also passed through and helped, but these people are currently idling during the drafting of this doc.
The desktop-research mailing list was where this project was initially pulled together as an official Gentoo project with the current team. Thanks to those people as well.
The #gentoo-server (webchat) channel has been helpful in hashing out many automated deployment issues and recommendations. Thanks to them.
This document is a cumulative reference and is the work of everyone in the Gentoo community.
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Eric Sammer (author), Blackace (editor) on January 29, 2004
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.