A Linux® and Powerpc™ Platform Installation

Technical Articles

Reducing IT Costs Through Open Source Solutions: A Linux® and PowerPC™ Platform Installation

Author: Sven Luther and Bill Buck Topic: Platforms Date: September 2004 Revision: 1.0

The objective of the Avalanche Desktop Reference Management Platform (DRMP) project is to investigate and validate the promise of a complete open source software (OSS) solution from kernel to plug-in. Through this project, Avalanche member companies sought to document the value of lower IT costs through collaboration in the implementation of a complete PowerPC™ technology-based OSS solution. Factors considered in the reduction of total cost of ownership (TCO) included: hardware, support and operational costs, and intangible costs, such as staff familiarity with the software stack and the hardware. Finally, as most senior managers, CFOs, CIOs, or COOs, are not aware of the complexity and risks of OSS and application stack version control, it is Avalanche's objective to enumerate and clarify these issues.

Success on the desktop was defined by Avalanche and Genesi (which had been selected to support the DRMP project), as follows:

o A well-defined application environment with explicit limits on application functionality, but that still met all the member requirements. o Absolute control of the environment from the system level. o A fully defined hardware platform. o A centralized group that tests, validates and stages every version change (security, reliability, upgrade) of the OS and every application in the stack, including verification of all required inter-application integration.

The Avalanche infrastructure

The complete physical infrastructure used for the Avalanche DMRP project is running on the same operating system, Debian GNU/Linux, and the same hardware, the PegasosPPC (See Figure 1), from thin client to development machine to server in a variety of configurations as follows:

o At the Genesi location, a) a server pool for access by the remote clients, b) a pool of development machines, hosting a package autobuilder, which is used for taking packages (in Debian everything is a package — Mozilla is a package, OpenOffice is a package, and so on.) that exist in source form and rebuilding them for the PegasosPPC with some additional infrastructure, and, c) test systems used for testing the different images, and the improvement of them.

o At the Avalanche member site, there is one or more of the following units, a) diskless thin clients, b) workstation class machines with local disks, and, c) local server machines for the diskless thin clients.

Figure 1: Layout for the PegasosPPC

We term an installation to be the specific version of the software stack that runs on the PegasosPPC hardware. These installations are built on the development machines, and then hosted on the servers for upload to the remote client machines. There are two ways of transferring such an installation: using an installation image, which is a copy of the binary installation seen as a block and transferred in a block, through the network or installation media, such as CDs or DVDs, to new hard disks, or, using an installation snapshot that is a copy of all the information needed to regenerate the actual installation.

The installation snapshot can be used to duplicate or upgrade an installation remotely using the installed package list and the configuration database taken from the installation together with the package repository.

- 2 -

The different steps required to install and manage the systems are as follows:

o Configuring and installing the PegasosPPC hardware as required. o Generating the installation that will be duplicated to the preinstalled hard disk, CDs, DVDs or other installation media. o Completing the initial software installation — both locally and remotely. o Updating the existing installation. o Transferring and upgrading the images and snapshots to the remote systems. o Performing the remote configuration management and per-client differentiation.

The next section details of how this process is handled by the Debian package management system and the Debian infrastructure.

The debconf database and the Debian package system

Debian is well known for its package management system. There are basically two tools that are used to manage packages, the first is dpkg, which installs packages, and apt, which manages the downloading of packages from one or more package archives and resolves packages interdependencies. The list of installed packages and their status (on hold, to install, to remove, and so on) is held in the dpkg/apt-get databases. The list of all configuration information for the individual packages is held in the debconf database. Not all Debian package have debconf frendly installation scripts, but most do. In the case that non-debconf friendly packages are needed to fulfill the Avalanche specification, they are modified accordingly by the Genesi developer team.

Debconf uses various graphical or textual front ends for its configuration. Either a HTML-based front end used together with Web page generated dynamically from a remote installation database, or a Lightweight Directory Access Protocal (ldap) based remote access database, is used.

Debconf also support various priority levels for its queries. At level low, all questions get asked, while at level critical none are asked. This mechanism, together with remote pre-seeding of the debconf database to offer pre-answered questions, allow for seamless upgrades of the images and snapshots on a per-package basis, without remote user interaction.

Often, packages have both system-global defaults, and per-user configuration options. In order to make the images work "out of the box," all the configuration changes are done on the system global defaults, and thus provide the same defaults to every user of the system. Additionally, it is possible to block the ability of the user to do user-specific modifications at the direction of the member CIO.

- 3 -

Initial software installation using the debian-installer

Initial installation of remote system can be done either with installation images, or using the installation snapshot and the debian-installer. The installation image method is faster, as it does not need to unpack and configure the individual packages, but it allows less flexibility in both initial installation and upgrades, and uses more bandwidth during upgrades as there is no possibility for a partial installation. The installation method transfers the compressed image, and then uses partimage or plain dd together with a libparted based partitioning tool to install the image to disk.

The debian-installer method uses an installation snapshot to pre-seed the debconf database and the package list, to allow for fully automated, no-interaction installations. The configuration script of the individual package runs with pre-fed responses to allow for a more controlled customization than an image duplication process would allow. This is the key to successful upgrades or the installation of additional packages remotely on existing images or snapshots.

An installation can be either done from the network or using a CD or DVD installation media. A network install is done using a initrd (initial ramdisk) kernel that is booted over the network (netbooted), which can then either perform the Debian-installer installation, or overwrite the disk with a compressed image. Additionally, CDs or DVDs containing images or, package repositories and configurations, can be used to preserve bandwidth.

Additionally, another Debian mechanism can be used to perform the installation of groups of software by using tasks, and the tasksel (task select) package. For example, a pre-selected group of tasks are the desktop task and various server tasks (mail, DNS, Web, printer). The tasks to control exactly what software is included for each member and for each task to be addressed are provided from the server level.

- 4 -

Figure 2. The Avalanche DRMP network configuration

- 5 -

Upgrading remote machines

There are three types of machines to consider: stand-alone workstation class machines, remote diskless machines, and remote diskless machine servers. The first situation to consider is a remote workstation upgraded from a Genesi server at the Genesi facilities. There are two kinds of upgrades to consider, packages upgrades and kernel upgrades.

Package upgrades occur in the same way as snapshot installations. The remote box gets the package list and the debconf answers from the remote database and then updates its apt-get database, installs the packages with a priority of critical, using the pre-seeded debconf database to neatly upgrade the packages without user interaction. An alternative to this, where only the debconf answers get changed, but the package does not get upgraded, the database can be changed by calling dpkg-reconfigure to reconfigure the already installed packages.

The difference between the kernel upgrade and the normal package upgrade is the need of a reboot for a change to take effect. Every other upgrade can be done remotely without need for a reboot. When a machine is switched off/on every evening/morning, a small OpenFirmware (OF) program upgrades from OF and then installs the kernel. It not only upgrades the kernel, but also the modules included in it. That said, Debian uses an initrd kernel anyway, so by adding a small modification to this upgrade kernel, which loads the initrd and the provided modules, it upgrades the kernel-image package before pivot_root is used and then moved to the real root. This allows an installation with the kernel upgrade at the start of the daily use at switch on, without requiring a second reboot.

For remote diskless machines the difference is that the actual system resides on the Genesi server, and is either served over Network File System (NFS) or uploaded to a ramdisk at machine boot time, either directly or via an image server local to the diskless machine (see Figure 2). The images on such a server are upgraded either per image, or using the snapshot method in a chrooted installation, depending on bandwidth considerations.

Configuring and upgrading the images and snapshots

Creation and management of the installations is done either in a chroot on a development machine or on a test machine. The normal Debian upgrade tools run here in a chrooted environment which makes it rather easy to manage. The difficult part is to synchronize the package list and debconf database with the external database. A revision system is be used to store these.

After each change and before production, each of these images is tested on a Genesi local machine under real time conditions. Then Genesi tests the changes or makes the actual modifications. The team also monitors the Debian bug database, and either applies Debian proposed fixes or codes the fixes themselves. Again, if official Debian packages do not contain applicable defaults, the team modifies them and provides them for the production.

- 6 -

Controlling the user desktop

All packages installed are properly synchronized to the member desktop environment appearance and main menu, and are configured according to the needs for all users of the system (language considerations would be made here if needed).

Initially, the decision was made to mount much of the system in a read-only state, and not allow user configurable changes. Another solution being tested is a read-only home directory that stores all the user data either on a separate NFS, SMB, or similar mount, or in a writeable sub directory.

About Avalanche

The Avalanche Corporate Technology Cooperative is a collaborative initiative organized to develop, produce, manage, and service information technology systems on behalf of its corporate members. The Cooperative is founded on the simple concept that much of the work done by corporate information technology departments has already been done before by another company. Avalanche seeks to reduce cost and increase control over mission-critical software with the adoption of an open source solutions that can be validated and disseminated for use by its members.

Author information

Sven Luther is Linux Manager and Bill Buck is General Manager for Genesi.

Genesi has developed a PowerPC technology based computer platform and a proprietary firmware for the platform that conforms to industry "open" standards and allows the platform to function with standard PC peripherals (for example, keyboard, mouse, game controllers, USB- driven devices, and so on). Because the platform is "open," any PowerPC operating system can run on the platform, including a variety of Linux® distributions and MorphOS, a proprietary non-UNIX® platform-based operating system that has also been developed by Genesi.

Freescale(tm) and the Freescale logo are trademarks of Freescale Semiconductor, Inc. The PowerPC name is a trademark of IBM Corp. and used under license. All other product or service names are the property of their respective owners.

- 7 -