Toward a GNU/Linux Distribution for Corporate Environments  Chapter X Toward a GNU/Linux Distribution for Corporate Environments Francesco Di Cerbo, University of Genoa, Italy Marco Scotto, University of Bolzano-Bozen, Italy Alberto Sillitti, University of Bolzano-Bozen, Italy Giancarlo Succi, University of Bolzano-Bozen, Italy Tullio Vernazza, University of Genoa, Italy Abstract The introduction of a GNU/Linux-based desktop system in a large company is often problematic. In literature, several crucial issues represent such a burden, which is often cost effective for SMEs and public administrations. Some of these are technical issues; the others are related to the training costs for the employees. Mainly, the technical obstacles are represented by different hardware configurations that might require several adhoc activities to adapt a standard GNU/Linux distribution to the specific environment, including the applications profile of the company. On Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.  Di Cerbo, Scotto, Sillitti, Succi, & Vernazza the other hand, to lower the learning curve of employers, we decided to work toward adopting some GNU/Linux live distributions features. In this way, we added to our project specific functionalities, which provide new and interesting capabilities to our community of users, such as self-configuration and better usability, without losing compatibility with original distributions, which is too costly in a professional scenario for its greater maintenance cost. DSS1 (debased scripts set) tries to address the issues we mentioned above. It is a next-generation hybrid (both live and regular) distribution that includes an unmodified Debian-based GNU/Linux release and a modular-designed file system with some extended features, which we will describe in this chapter. We will also discuss the interactions with other open source communities and the positive mutual influence on DSS development process. Introduction The massive installation of an operating system on desktop computers in a professional scenario usually relies upon proprietary solutions, as well as the choice of adequate deployment tools. Experiences collected in the EU-funded COSPA project (see COSPA, 2003-2006) aimed to introduce open source software into PAs in Europe and showed that all PAs involved in the project had an IT infrastructure based on Microsoft Windows systems for their desktop computers. This reliance happens because proprietary operating systems and their deployment tools are tailored and strongly rely on their capability to lower the total costs of installation and maintenance, which, first of all, consist of savings in terms of time required to implement. This is achieved thanks to the automation of many steps necessary to perform the deployment operations. Although the same facilities can be found in the GNU/Linux (Stallman, 2004) community, there is no such structured approach to the problem. Moreover, there are other issues to take into account, depending on the specific scenario: If we consider a migration from an existing IT infrastructure, the biggest problems are portability and compatibility of currently adopted software. The fulfillment of these requirements might not be guaranteed, especially when considering legacy software: This is the case of many public administrations in Italy (Assinform, 2006) in which software providers refuse to develop software for non-WIN32 environments. For these reasons, the introduction of GNU/Linux desktop systems in large companies or in public administrations is often problematic both during startup and for subsequent maintenance operations. The different hardware configuration of target computers is one of the major technical problems with installation, since it may require several adhoc activities to adapt a standard GNU/Linux release to the specific environment. Another problem, from the users’ point of view, may be represented by training/learning costs, in order to Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Toward a GNU/Linux Distribution for Corporate Environments  allow the staff to achieve the same productivity level they had on the previously adopted environment. In recent years, the coming of GNU/Linux “live” distributions provided the free/ open source software community with new and interesting capabilities, such as self-configuration and better usability. A “live” distribution is a particular type of GNU/Linux distribution, usually shipped within a read-only removable medium, like CD/DVD, or USB pen-drive. Live distributions cannot save any configuration information in their distribution media and may rely on several adaptation capabilities, which allow them to self-configure themselves in the system they are loaded into. We will illustrate live GNU/Linux distributions features later on in the chapter. Unfortunately, live distributions present a drawback: They are almost always derived from existing GNU/Linux distributions, but they present some relevant differences from them. Such differences make these kinds of operating systems almost useless in an ordinary professional scenario: Live distributions become forks of the original distributions and lose backward-compatibility, which means higher costs for maintenance operations, such as separate management for software upgrades and security patches adoption. DSS (debased scripts set) tries to address the previous issues. It is a powerful GNU/ Linux meta-distribution which incorporates “live” capabilities natively, based on an unmodified Debian-based (Murdock, 2004) GNU/Linux release (Ubuntu, see Ubuntu Group, 2006), including a pure “stock” kernel, that is, a standard distribution-provided Linux kernel (Rustling, 1996-1999) in binary form. DSS includes innovative hardware detection and configuration techniques, based on sound and largely adopted software (such as the hotplug daemon, as described in the Hotplug community, 2006), that is loaded during the very first boot operations. In addition, the use of a special unification file system (UnionFS, see Wright et al., 2004) along with a modular software package approach, allows DSS to deploy, in a single package, a customized company-specific release containing both the operating system and all the desired applications. In summary, DSS is a framework that allows an easy customization of a 100% Debian-based GNU/Linux distribution, which is also at the same time a “live” one. If there is the need to perform some modifications from the standard provided version (and this is common because of an insufficient default application profile), DSS provides Debian-based tools to repackage all the modifications into an extended DSS GNU/Linux distribution. Moreover, thanks to its smart file system design, completely built by modular parts loaded at runtime, it can be easily repackaged again into a live distribution. In this chapter, we illustrate the features of DSS, its history and connections with other free/open source software communities, and we rely on this experience to make some final considerations. Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.  Di Cerbo, Scotto, Sillitti, Succi, & Vernazza GNU/Linux Distributions: “Live” and “Regular” Approach An ordinary GNU/Linux distribution is an aggregation of software, developed and maintained by several free/open source communities, like the GNU project (see again Stallman, 2004), which encloses a Linux kernel. The kernel (Rustling, 1996-1999) is a necessary component because it permits the greatest portion of hardware-software interactions (through its hardware drivers), as well as the management of other running programs. However, there are other companion programs, which are necessary in several stages in running the GNU/Linux operating system. For instance, the already mentioned hotplug performs hardware events monitoring for all devices the kernel is able to manage. Usually, these programs, as well as their configurations and the kernel itself, are stored in a hard drive partition, or, in any event a writable device, and it is very rare to modify these data and information during the startup phase. In a “regular” approach, the boot process is a sequence of operations which may be divided in two main stages: the first, which mainly performs a small setup environment, required to load the kernel into random access memory of the system, and executes it; the second, which launches all the required companion software. Both of them require their set-up configurations, which, for example, are commonly generated during an installation process. A “live” approach relies on the concept that, as the kernel itself just needs an appropriate launching environment, it is possible to generate it dynamically at runtime, without previously existing configurations. In this way, it is possible to boot a system from a read-only device, like a CD-/DVD-ROM, and then, throughout an extensive use of system memory, to create all necessary software structures needed to boot the kernel and the companion processes. This is heavier in terms of load on system memory compared to the “regular” approach, but after the system is booted, there are no significant differences from the point of view of users, except for a possible slowdown due to intense use of the boot medium, which usually has a slower access time. Hardware configurations, as well as any parameters, are considered unknown and specific software solutions are developed to overcome these issues. Since there is almost no need for any configuration specifications, a live GNU/Linux distribution is particularly suited for un- or poorly-skilled users, who may just boot their machine and therefore use a completely working operating system without any additional effort. Usually, a live distribution is generated by a regular distribution, from which inherits software packages and their managing techniques; however, the two types differ notably in their maintenance and upgrade processes. The drawbacks of this approach are essentially represented by the overhead, due to increased memory required, if compared to regularly installed distributions, by the frequent accesses to a medium which is usually not as fast as a hard disk, and by the strong modifications and customizations required to adapt the set-up enviCopyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Toward a GNU/Linux Distribution for Corporate Environments  ronment. Generally speaking, maintenance and upgrade tasks performed on a live GNU/Linux distribution require more (and sometimes much more) effort than the same tasks would be on the same original (regular) distribution. The reason for such an increment in time is usually due to the tight coupling among specific versions of the software that compose a specific release of a live distribution: It may happen that modifying (upgrading or downgrading) a single component causes severe damage in the boot process. As a result, these operations require deep and accurate risk estimation, and are usually avoided by most users. Moreover, such estimation does not guarantee the feasibility of the system change which is often not acceptable for an enterprise environment. State of the Art in Live Distributions: Knoppix2 Knoppix (Knopper, 2000) may be considered the pioneer of GNU/Linux live distributions, either for diffusion, as demonstrated by a large number of works based on it, or historical reasons. However, its approach in providing a Debian GNU/Linux distribution able to boot from removable storage media, makes its use, in a professional setting, practically impossible except for data recovery or hardware testing. Its severe modifications to the standard Debian distribution, cross-combined with unstable and testing Debian applications profiles (the Debian “trees”), make the distribution and upgrade of new applications quite difficult, requiring a great effort to stabilize a new hypothetical desktop installation based on Knoppix. Moreover, “exotic” hardware suffers with Knoppix deep-kernel specificity; such specificity is a constraint due to hardware detection requirements. Uncommon, or not completely supported, hardware often comes with drivers usually not contained in standard kernels, which may even be provided with commercial licenses, and is incompatible with GPL (GNU General Public License, described in Free Software Foundation, 1991 ) statements and thus undeliverable, along with Debian distributions (see Debian, 2004). In these cases, the adoption of Knoppix can be a severe problem. Last, hardware detection and configuration techniques come with special boot applications (such as knoppixautoconfig, described in Suzak et al., 2005), that require a constant maintenance process to be able to recognize new or uncommon hardware. Moreover, their approach, based on kernel-space routines, prevents successive setups (e.g., file systems configuration) from using user-space libraries and applications, which could give the user flexibility in data and device access, especially in the case of plug-and-play USB hardware. These boot applications use adhoc scripts running with maximum privileges, which may lead to security problems, particularly critical in an industrial environment. Beside these technical aspects, Knoppix introduced some interesting usability features at the time, enhancing KDE window manager (KDE e.V., 2006) Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.  Di Cerbo, Scotto, Sillitti, Succi, & Vernazza to allow, for example, an easier management of devices, including removable ones, exploiting its hardware detection skills. DSS Motivation Our experience started when studying the introduction of a GNU/Linux distribution into a Public Administration IT infrastructure of the University of Genoa. This is a very heterogeneous scenario, with a complex user base, composed of some GNU/Linux skilled users and some less experienced ones, and a non-standardized hardware set. It was the third quarter of 2005. This is a paradigmatic use case, which summarizes almost all the important critical features of a medium-sized IT structure. To lower the total IT staff effort, we looked at the hardware auto-configuration skills of live distributions, starting with Knoppix. When we discovered the great maintenance problems we mentioned, which made it unsuitable for its adoption for anything different than a live or recovery system3, we decided not to investigate further into customization tools based on Knoppix. In order to use some well-known software architectures, which would decrease the maintenance effort of our distribution in the middle term, we then moved to study the usual automatic hardware detection and configuration systems in a standard GNU/Linux environment, and we worked to introduce them in a live environment. We succeeded, as described later on, and in this way we solved a part of the problem, with the collateral benefit of the unique management of an installed GNU/Linux system, as a live one, which actually behaves regularly and without any adhoc binary program or patch to common Debian components. Then we started working on improving the overall usability, following the same approach: We looked at standard operating system event monitors and notification dispatchers inside different window managers, extending, based on an existing solution, a notification and action performer daemon able, for example, to detect and react to USB devices plugged in and out the system. Free/open source software obtained from different communities helped us a lot to develop DSS. As they were also under development, which is common for most “successful” open source projects (Crowston, 2003), we requested some changes in the features of the software, which were gladly accepted. In this way, both projects received benefits: We simplified our development process, the others received more bug reporting and fixes due to the improved correlation rate (they “gained a client”). We did also when another community asked us for some changes and adaptations: Our project manager analyzed them and decided they were useful, so we included them into DSS and we “gained a client,” a precious ally in our development process. Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Toward a GNU/Linux Distribution for Corporate Environments  Our use case, at the time of writing, is still in progress, and it is not possible to provide results of this adoption to end users: From a technical point of view, we have designed and implemented the whole distribution infrastructure; we provided the community with several releases, and we are waiting for feedback. We conducted a preliminary usability test by choosing testers with different experience in the use of GNU/Linux distributions, from the unskilled to the expert level. The results of this test, however, lack statistical significance due to the small number (10) of users involved. They were indeed very useful in order to trigger our development process, giving us preliminary feedback before our first public release. There is a larger, statistically relevant migration test planned for first quarter of 2007, which would provide us with more useful results, and will be another milestone towards DSS introduction in the official IT infrastructure of University of Genoa. DSS Main Features DSS main features address two among the greatest issues mentioned in the GNU/ Linux introduction for desktop systems into a complex IT structure. They are the plurality of configuration profiles in target desktop PCs and the distribution/maintenance of the applications. These problems may be expressed as how to cope with the complexity of managing an arbitrary number of target desktop PCs with an arbitrary number of different hardware features, minimizing human effort. Arbitrary Configuration Profiles: Self-Configuration Techniques Considering an arbitrary number of hardware configurations within a corporation, we decided to integrate self-configuration techniques inside DSS. In this way, the total cost of installation would be lowered by decreasing the number of required operations. As mentioned previously in the introduction, we studied the technicalities of live distribution to perform this task, then acquired and adapted them to our needs. While developing our solution, we actually turned a “regular” GNU/Linux distribution, Ubuntu, into a “hybrid” one. In fact, while extending the usually adopted default hardware detection capabilities of Ubuntu, we adopted a special paradigm in the boot phase which could be used with almost no drawbacks either in a live or a regular distribution, actually merging the two approaches. This presents a great advantage compared to ordinary live distributions: There are no differences between DSS and its original distribution, except for a small number of scripts. This let DSS Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited.  Di Cerbo, Scotto, Sillitti, Succi, & Vernazza be administered and maintained as Ubuntu, which provides a lot of tools to perform those operations, and also a large community in charge of releasing updates. DSS adopts a completely new approach to live distributions based on an “early userspace” (as described in Petullo, 2005) mode. It is a set of libraries and programs (that are available even without a running Linux kernel) which provide various functionalities required while a Linux kernel is coming up. In the forthcoming section, a technical description of this aspect will be provided. The “early user space” mode allows DSS to use hotplug, a daemon program normally used for hardware discovery and configuration in standard non-live GNU/Linux distributions, from the first seconds of boot process. This is a great advantage, as the booting kernel relies on already detected hardware, and using its 2.6 series features, may automatically load needed kernel modules in order to use just discovered hardware, as in a regularly installed GNU/Linux system. Due to this feature, DSS does not require developing and maintaining an adhoc kernel, but it may use a stock one, exactly like any other Debian release. To summarize, with the adoption of early user-space, except for a small set of plain scripts (very easy and simple to maintain and modify) which effectively coordinate the boot process, no adhoc component is used to bring in a Debian GNU/Linux release as a “live” distribution; moreover, the set of scripts is also completely able to fulfill hardware-automatic detection/configuration needs for kernel-supported peripherals. Maintenance and Distribution Operations of Applications: DSS Strategies with UnionFS In commercial operating systems, there are facilities to perform the deployment of new applications as well as maintenance for those already installed; for example, Microsoft Active Directory services with group policies4. The valuable benefit they provide is a centralization in the management, combined with an automation of the deployment process. In this way, it is possible to deliver automatically new software in an arbitrary broad network without any required effort on single target nodes. DSS provides several technical solutions fit for its adoption in large-scale IT structures: an easy customization process and a centralization of IT management procedures in a whole network. DSS is designed to be a meta-distribution framework, allowing creation of derivative distributions, both live or in standard package, built up upon a pure Debian release in a very simple way. In this way, it permits a high level of customization and easy maintenance, keeping the new application deployment/removal process fast and centralized. This feature is provided thanks to a special modular file system Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Toward a GNU/Linux Distribution for Corporate Environments  design, made possible by the adoption of UnionFS (see Wright et al., 2004 and Zadok et al., 2000). UnionFS is a particular file system designed to merge different devices. DSS uses UnionFS to group physical devices with virtual (ramfs) ones to set up a final root filesystem. In virtual A device in a GNU/Linux operating system is a reference to a physical or virtual medium, for example, a hard disk partition. Devices are used to perform all operations allowed by the Linux kernel. Almost all hardware supported by the Linux kernel has its specific device, including removable media like CDROM, USB disks and so on. A hard disk partition has its own device that must be used in order to access the file system contained in that partition. This operation is called “mounting.” Usually, a mount operation associates a directory (a “mount point”) to a device, and any further modification within the directory will be actually performed on the file system related to the device. UnionFS allows mount operations involving an arbitrary number of devices into one mount point (see Illustration 2: UnionFS). UnionFS performs a virtual “merge” of file systems considered, as shown in Illustration 1: An example of file system merging with UnionFS. We refer the reader to the following sections for a more detailed description of features. The DSS file system is split into modules (or layers), which are added together via UnionFS.All modules in DSS are compressed archives, which can be mounted at runtime as small file systems. These modules contains programs and libraries, which are merged together into a unique file system, thanks to UnionFS; additive module management permits the creation of a final file system layout which is essentially a “sum” of every used layer. A side effect of DSS modularization is the flexibility in final result of the merging process, which actually allows different installation profiles, based on a combination of a common set of modules. Illustration 1. File system merging with UnionFS /programs/applicationFoo/* /programs/applicationBar/* Layer A Layer B UnionFS /programs/applicationBar/* /programs/applicationFoo/* Resulting file system Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 10 Di Cerbo, Scotto, Sillitti, Succi, & Vernazza Illustration 2. UnionFS Illustration 3. The Upstream Salmon Struct (USS) In Illustration 3: Upstream Salmon Stream (USS) structure for a desktop system, a possible combination of modules for a DSS distribution for a desktop PC is shown. Every module is created to provide a specific group of functionalities. A strict encapsulation of features allows a kind of “polymorphism” in resulting distribution. In this way, it is possible, for example, to generate a “Web server” distribution, starting from the set of layers shown in Illustration 3, including a layer with the Apache Web server and a DBMS, excluding the graphical server layer. In the same way, a customized GNU/Linux desktop distribution may be generated, containing a specific ready-to-use5 corporative environment. An example of a possible usage of DSS in a corporate network may be seen in Illustration 4: DSS in a corporate Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Toward a GNU/Linux Distribution for Corporate Environments 11 Illustration 4. A corporate network with DSS network. For a wider analysis, we remand to following section, dealing with “Upstream Salmon Struct.” Moreover, as compressed modules are merged in an ordered way, a single installation may be multi-purpose, including or excluding any of the boot loader parameters. This feature is very important to contain different installation profiles in a single location, and it is extremely useful in a network installation, or in a DVD release, for example. Module creation process is also very simple, and it may be created in two ways: interactive and non-interactive processes. Starting with the latter, it relies on a standard Debian tool (the “debconf” program, used for Debian distribution software management), just providing as input a list of desired Debian packages to be included in final module; a script would download, configure and re-pack packages into a compressed archive which is actually the desired module. The interactive way, the simplest, needs only to boot DSS, and then, after using the usual GUI and front-ends for new software installation, invoke another script. Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 12 Di Cerbo, Scotto, Sillitti, Succi, & Vernazza Resulting archives may be redistributed inside a standard DSS release without any further modifications to original status. Technical Description of Features Key Technology: “Early User-Space” “Early user-space” mode is essentially a technicality, based on initramfs, a chunk of code that unpacks a compressed file system image (in CPIO format, see GNU Project, 2004), during the kernel boot process. It replaces the old initrd file system format, which contained a set of kernel modules stated to be available at boot time, before mounting the root file system and thus before having all kernel resources available. The main advantage of initramfs is its capability to be used with ramfs, a file system designed to work on physical RAM, scalable in size, instead of the usual initrd. Early user-space allows DSS, in conjunction with later-described UnionFS, to save time in the boot phase: Instead of setting up a boot environment for hardware detection/configuration operations, DSS directly sets up a final working environment, and when the kernel finishes its startup operations, the boot process is over, with a simple environment update. This is because RAM allocated since boot start for required boot operations does not need to be freed/removed, and the previously adopted special environment (which is usually adopted for embedded systems) is not used anymore except for the boot process. Eventually, it is possible to allocate all available RAM on the system to improve overall performance, reducing physical medium access delays by copying the whole DSS content image into a memory partition. Key Technology: UnionFS UnionFS is a stackable file system that operates on multiple underlying file systems (see Illustration 2: UnionFS). It merges the updated contents of multiple directories but keeps their original physical content separated. The DSS implementation of UnionFS merges the DSS RAMdisk with the read-only file systems on the boot CD so it is possible to modify any read-only file as if it was writable. UnionFS is part of FiST, File System Translator project. Its goal is to address the problem of file system development, a critical area of operating-system engineering. The FiST lab notes that even small changes to existing file systems require deep understanding of kernel internals, making the barrier to entry for new developers high. Moreover, Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Toward a GNU/Linux Distribution for Corporate Environments 13 porting file system code from one operating system to another is almost as difficult as the first port. FiST, developed by Erez Zadok and Jason Nieh in the computer science department at Columbia University, combines two methods to solve the above problems in an innovative way: a set of stackable file system templates for each operating system, and a high-level language that can describe stackable file systems in a cross-platform portable fashion. The key idea is that with FiST, a stackable file system would need to be described only once. Then the code-generation tool of FiST would compile one system description into loadable kernel modules for different operating systems (currently Solaris, Linux, and FreeBSD are supported). UnionFS allows DSS to virtually merge (or unify) different directories (recursively) in a way that they appear to be one tree; this is done without physically merging the directories content. Such “namespace” unification has a benefit in allowing the files to remain physically separate, even if they appear as belonging in one unique location. The collection of merged directories is called a union, and each physical directory is called a branch. When creating the union, each branch is assigned a precedence and access permissions (i.e., read-only or read-writable). UnionFS is a namespace-unification file system that addresses all of the known complexities of maintaining Unix semantic without compromising versatility and the features it offers. It supports two file deletion modes that manage even partial failures. It allows efficient insertion and deletion of arbitrary read-only or read-writable directories into the union. UnionFS includes in-kernel handling of files with identical names, a careful design that minimizes data movement across branches, several modes for permission inheritance, and support for snapshots and “sandboxing.” UnionFS has an n-way, fan-out architecture (again, Zadok et al., 2000 and Wright et al., 2004). The benefit of this approach is that UnionFS has direct access to all underlying directories or branches, in any order. DSS Inside UnionFS DSS, just before performing the setup later described as “Upstream Salmon Struct,” mounts different compressed file systems in different mount points and uses a readwritable directory as last layer, in order to prepare the environment to be hosted in just one final mount point (the root directory). Even if the concept of virtual namespace unification appears simple, there are three key problems that arise when using it as root file system of DSS. The first is that two or more unified directories can contain files with the same name. If such directories are unified, duplicate names must not be returned to user-space for obvious reasons. UnionFS solves this point by defining a priority ordering of Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 14 Di Cerbo, Scotto, Sillitti, Succi, & Vernazza the individual directories being unified. When several files have the same name, files from the directory with higher priority take precedence. The second problem relates to file deletion. Files with same name could appear in the directories being merged or files to be deleted residing on a read-only branch. UnionFS handles this situation by inserting a without, a special high-priority entry that marks the file as deleted. When file system code finds a without for a file, it simply behaves as the file does not exist. The third problem is relegated to the previous one and it involves mixing read-only and read-write directories in the union. When users want to modify a file that resides in a read-only branch, UnionFS performs a “copy-up,” that is, the file is copied to the higher priority directory and modified there. UnionFS and the Upstream Salmon Struct (USS) The power of DSS resides in its design, offering high modularity and allowing customization as easy as possible. This has been achieved by designing the USS and using UnionFS as background. The unified root file system is comprised of the content of different modules, each a squashfs compressed file system (see Illustration 3: The Upstream Salmon Struct ): 1. base: console mode module, it contains a basic bootstrapped Debian system; 2. kernel: it contains the /lib/modules/ directory plus kernel related utilities; 3. xserver: graphical mode modules (in case file names clash, the priority in the unified directory is defined by sorting the modules name); 4. deliver: it contains the runlevel scripts needed to reconfigure “debconf” database and the environment reading the user configuration from /proc/cmdline passed to kernel at boot from boot loader (e.g., locales information, force screen resolution); 5. overall: the read-writable branch, it can reside in RAM or even be an external hd; base, kernel and xserver use is self-explanatory, but the packages inside those modules are stored using a “noninteractive” debconf frontend, and so they maintain their own default configurations; that is why DSS can be considered a pure Debian system booting from a CD/DVD/USB. To allow the user his or her own locales settings (i.e., language, keyboard) and video card optimized drivers, some packages need to be reconfigured, and this is done using the runlevel scripts in deliver. Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Toward a GNU/Linux Distribution for Corporate Environments 15 Deliver The scripts in “yuch-bottom,” the directory within the initramfs, write the environment variables in the file /etc/deliver.conf, parsing command line parameters from boot loader, as lang(uage), username, hostname, and so forth. Deliver uses those variables to reconfigure some packages, upgrading at the same time the debconf database. The scripts in deliver are plain text bash scripts, this allows DSS use not only for a i386 live distribution, but even for powerpc or sparc computers, and all the other 11 architectures that Debian supports, making DSS fully architecture-independent. Thanks to its scripts, to be ported from an architecture to another DSS just needs the right initramfs and deliver module, without kernel customization, as it is sufficient as a pure Debian stock kernel. DSS, as opposed to knoppix, uses debconf to configure the system, which provides a consistent interface for configuring packages, allowing the choice from several user interface frontends. It supports even a special “pre-configuration” of software packages before they are actually installed, which allows massive installation or upgrade sessions demanding all necessary configuration information up front, without user interactions (frontend “non-interactive”). It allows for the skipping over of less important questions and information while installing a package but providing a chance to revise them later. It is also interesting to note that debconf itself is completely a Debian-supported tool, and its use is not customized at all: another key point in 100% Debian compatibility. DSS and Usability As said, DSS is mainly aimed at desktop systems and the improvement of global usability. This feature is very important, and we faced many problems when introducing DSS into our use case because of the experience of users with win32 systems. Our approach in that situation was twofold: We improved knowledge of users and we developed some ad hoc solutions. Considering our interaction with testers, we planned to work on their formation, exploiting differences between Win32 systems and our distribution, to simplify their approach to DSS. As mentioned, due to the small number of users involved, our test may not provide general considerations. However, in this process we followed indications and recommendations coming from precedent experiences in larger contexts: in the region of Spain Extremadura (see Vaca, 2005 and ZDNet, 2005) for Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 16 Di Cerbo, Scotto, Sillitti, Succi, & Vernazza example, but also from case studies held in South Africa (see Brink et al., 2006). We also exploited our experience in training and documentation design, gained with several analyses of precedent free open source software adoption experiences (see, e.g., Rossi, 2006; Zuliani, 2004a, 2004b; Russo, 2005). On the technical side, we worked to improve overall usability, exploiting early userspace features to manage the whole desktop system with just user-space software, as it is common to mount devices, for example6 Indications from research activities advise addressing usability matters as crucial for easing the diffusion of free/open source software and how to properly implement strategies to simplify the interactions with users (see Nichols, 2001, 2004; Frishberg et al., 2002). A remark on the principal difficulty in this process: As DSS is a meta-distribution, we could not rely on almost anything connected with window managers’ capabilities. This means that what we could use was limited to the X graphical server and a few other software applications. One of them is the X notification daemon, commonly included in X distribution packages. We added a set of scripts, rules, and policies to hardware management software, such as the largely adopted Hardware Abstraction Layer software (HAL) and message deliver DBUS, to react to events like plugging in and out of USB devices, mounting and un-mounting them automatically in case of storage devices, or proposing a set of actions in the case of a newly inserted CD or DVD. Our notification is graphical in a standard notification window, and comes with a synthesized voice that reads the title of the notification, thanks to standard Debian-provided software (festival, Taylor et al., 1998). Thanks to HAL and DBUS features, it is possible to detect almost every hardware event, and this offers a lot of possibilities for extending default reaction behavior. As for every other DSS component, this is script-based and completely customizable by the user or system administrator. Unluckily, this feature is not yet ready to come into production environments, and we are still bug-fixing and enhancing it. The Community-to-Community Experience During the design and implementation process of DSS, there were many contacts with other software communities, providing help to each other. One of our greatest connections is with the team of developers of the Ubuntu community, and we acknowledge their great work and the easiness of the relationship. In fact, we had a continuous mail exchange, especially when they created their live installation program, ubiquity. They happily agreed to make some modifications to Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Toward a GNU/Linux Distribution for Corporate Environments 17 its behavior, and in this way we were able to include it in our mainstream, so now it also works for DSS. Another great point of interest is represented by interactions with people from File systems and Storage Lab at Stony Brook University, the creators of UnionFS and a lot of theories on file systems. They accepted our advices on UnionFS runtime features, as it was in heavy development phase when we adopted it, and both of us received an added value from this. But we were also providers for other communities: Elive7 developers adopted DSS as the starting distribution for their releases from 0.5 (see Distrowatch, 2006). In this way, as their goal is to care about Enlightenment window manager (Enlightenment community, 2006), they essentially created a layer to be added at top of the USS, without worrying about low-level details. This is one of the the first applications of meta-distribution features, one of our greatest aims in this project. We acknowledge Daniele Favara, our distribution manager and main developer, for all these successful contacts and interactions. What is reported here is just a summary of all contacts Daniele kept, and we report them as the basisfor some considerations. We may look at our experience as an example of positive integration of communities. DSS may be seen as a conjunction point between different groups with, obviously, different objectives, and where it may be very complicated to find an equilibrium point. In this case, we, and especially Daniele, were lucky and skilled in finding a good alchemy between pursuing “client” needs and “provider” objectives. The UnionFS team found an interesting application (a good “client”) in DSS, while Elive developers chose DSS because it is a good “provider,” which allows them to concentrate on their “core business,” the window manager aspects. Everyone gained from this relationship in terms of existing solution reuse, bug reporting, and, in some cases, code contribution. This may be viewed, in some aspects, as a demonstration of statements of Raymond in Cathedral and Bazaar (1999), as the famous “more eyeballs” that allow prompt bug reporting, as well as for role exchange between users and developers of an open source software project. Not in every case it is possible to reach such a happy ending: It happened that several mail exchanges were started, proposing or receiving suggestions or modifications, but it was not possible to reach an equilibrium point. Sometimes there was a domain-specific requestwhich would lead to a loss of generalization to the “provider” community, or sometimes, unmatchable visions between proposers and developers. Anyway, just relying on our experience, it is possible, once a “proper” set of providers and clients is found, to lead a parallel development process, practically constituting a whole, in which every partner receives more benefits than losses. This happens when it is possible to find the proper equilibrium point between features requested and provided, and with continuous attention to other communication channels, such Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 18 Di Cerbo, Scotto, Sillitti, Succi, & Vernazza as partner communities, developer mailing lists, forums, wikies, and so forth to keep each other in touch in a constructive way. A Legal Aspect: Proprietary Software and DSS DSS, as said, is a completely 100% Debian-based distribution, and for this reason it strictly follows Debian Guidelines (see Debian, 2004). So, it is not legally possible to distribute proprietary-licensed software in conjunction with DSS. But we acknowledge that it is common, in public administration and in some companies, to deal with proprietary software. Our choice is, again, to follow Debian guidelines, and so forth allowing and supporting the creation of layers containing non-free software, but permitting their delivery/deployment in separate archives and repositories, following the “non-free” software behavior of Debian distributions. Even if DSS requires a separate delivery mechanism, it completely supports non-free software, without any further impact or differentiation. This is a key point. In this way it is possible to meet users requirements and license restrictions at the same time. Future of DSS DSS is in continuous development, and it is very difficult to give a summary of development directions. One of our greatest points of interest is to make the production of custom layers even easier and more automatic than today. We are looking at specific wiki syntax to give directives to a script able to automate the creation process of a DSS layer; in this way, the editing a wiki page alone would result in an automatic generation of a layer ready to download and use, without any other user activity. We are also focused on usability features: Our notification system still needs testing and tuning, for example. Thus, we plan to involve some usability experts to improve it and to suggest further objectives. We also trust that from a forthcoming large-scale migration test, in which we will try to apply lessons and recommendations coming from the growing academic literature, we may be able to obtain useful directions for PAs and companies willing to embrace an analog path. Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Toward a GNU/Linux Distribution for Corporate Environments 19 Acknowledgment We acknowledge Daniele Favara, who is the main developer and the community leader of DSS. Without his great job DSS would not exist. Conclusion DSS is a 100% Debian live distribution, and may be proficiently used to install a pure Debian system on a desktop PC. Thanks to its features, it is very simple to customize as a starting base version, in a way to meet, for example, large-scale installations with specific requirements, such as in large company networks. Its maintenance is not effort-prone, due to the adoption of standardized technologies. Thanks to the DSS innovative design, the software represents a unicum in the current scenario. Moreover, there are no limitations to port DSS into any of Debian supported architectures, or to use it in embedded systems. We acknowledge that one of our greatest successes may be found in relations with other communities, which allowed us to improve DSS and to help our partners at the same time. References Assinform. (2006). Report on IT, TLC and multimedia 2005. Assinform. Brink, D., Roos, L., Weller, J., & van Belle, J.-P. (2006). Critical success factors for migrating to OSS-on-the-desktop: Common themes across three South African case studies. Boston, MA: Springer. COSPA Project. (2003-2006). Work package 4, deliverable 4.3—Experience report on the implementation of OS applications in the partner PAs. Retrieved August 14, 2006, from http://www.cospa-project.org/download_access.php?file=D4.3ExperienceReportOnTheImplementationOfOS.pdf Crowston, K., Annabi, H., & Howison, J. (2003). Defining open source software project success. In Proc. of Int. Conference on Information Systems. Debian. (2004). The Debian free software guidelines. Retrieved January 2005, from http://www.debian.org/social_contract#guidelines Distrowatch. (2006). Elive 0.5 Beta 3.1 Screenshot Tour. Retrieved August 15, 2006 , from http://osdir.com/Article9182.phtml Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 20 Di Cerbo, Scotto, Sillitti, Succi, & Vernazza Enlightenment community. (2006). Enlightenment project. Retrieved April 12, 2006, from http://enlightenment.sourceforge.net/ Frishberg, N., Dirks, A. N., Benson, C., Nickell, S., & Smith, S. (2002). Getting to know you: Open source development meets usability extended abstracts of the conference on human factors in computer systems (CHI 2002) (pp. 932-933). New York: ACM Press. Free Software Foundation. (1991). GNU GENERAL PUBLIC LICENSE v2. Retrieved April 12, 2006, from http://www.gnu.org/licenses/gpl.html GNU project. (2004). The CPIO project. Retrieved April 12, 2006, from http://www. gnu.org/software/cpio/ Hotplug community., (2001).Hotplug project documentation. Retrieved April 12, 2006, from http://linux-hotplug.sourceforge.net/ KDE e.V.. (2006). KDE Documentation. Retrieved April 12, 2006, from http://www. kde.org/documentation/ Knopper K. (2000, October 10-14). Building a self-contained auto-configuring Linux system on an iso9660 file. In Proc. of the 4th Annual Linux Showcase and Conference, Atlanta, Atlanta, Georgia (pp. 373-376). Murdock I., (1994). Overview of the Debian GNU/Linux system. Linux Journal, (Vol. 1994, 6es). Nichols, D. M., Thomson, K., & Yeates, S. A. (2001). Usability and open source software development. In E. Kemp, C. Phillips, Kinshuck, & J. Haynes (Eds.), Proceedings of the Symposium on Computer Human Interaction (pp. 49-54). Palmerston North, New Zealand: SIGCHI New Zealand. Nichols, D. M., & Twidale, M. B. (2003). The usability of open source software. First Monday, 8(1). Petullo, M. (2005). Encrypt your root filesystem. Linux Journal, 2005(129). Rossi, B., Scotto, M., Sillitti, A., & Succi, G. (2006). An empirical study on the migration to OpenOffice.org in a public administration. International Journal of Information Technology and Web Engineering, 1(3), 64-80. Russo B., Sillitti A., Zuliani P, Succi G., & Gasperi P. (2005, May 15-18). A pilot project in PAs to transit to an open source solution. In Proc. of The National Conference on Digital Government Research (DG.O2005), Atlanta, GA, USA. Rustling, D. (1999). The Linux kernel. Retrieved April 12, 2006, from http://www. tldp.org/LDP/tlk/tlk.html Stallman, R. M. (2002). Free software, free society: Selected essays of Richard M. Stallman. GNU Press. Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. Toward a GNU/Linux Distribution for Corporate Environments 21 Suzak, K., Iijima, K., Yagi, T., Tan, H., & Goto, K. (2005). SFS-KNOPPIX. In Fourth IEEE International Symposium on Network Computing and Applications (pp. 247-250). Taylor, P., Black, A., & Caley, R. (1998). The architecture of the festival speech synthesis system. In Third International Workshop on Speech Synthesis, Sydney, Australia (pp. 147-151). Ubuntu group. (2004). Ubuntu philosophy. Retrieved April 12, 2006, from http:// www.ubuntu.com/ubuntu/philosophy Vaca, A. (2005). Extremadura and the revolution of free software. In M. Wynants & J. Cornelis (Eds.), How open is the future? Economic, social & cultural scenarios inspired by free and open source software (pp. 167-197). Brussels, Belgium: VUB Brussels University Press. Wright, C. P., Dave, J., Gupta P., Krishnan H., & Zadok E. (2004). Versatility and Unix semantics in a fan-out unification file system. Retrieved June 15, 2006, from http://www.fsl.cs.sunysb.edu/docs/unionfs-tr/ Zadok E., & Nieh, J. (2000). FiST: A language for stackable file systems. In Proc. of 2000 Usenix Annual Technical Conference (pp. 55-70). ZDNet. (2005). Extremadura Linux Migration case study. Retrieved June 15, 2006, from http://insight.zdnet.co.uk/software/linuxunix/0,39 Zuliani, P., & Succi, G. (2004a). An experience of transition to open source software in local authorities. In Proceedings of e-challenges on software engineering. Zuliani, P., & Succi, G. (2004b). Migrating public administrations to open source software. In P. Isaías, P. Kommers & M. McPherson (Eds.), Proceedings of e-society 2004 IADIS international conference (pp. 829-832). IADIS Press. Endnotes 1 http://www.dsslive.org 2 http://www.knopper.de 3 4 5 This is acknowledged by Klaus Knopper himself, the creator of Knoppix, in the Knoppix support forum, excluding the possibility to update a Knoppix box with standard Debian procedure (“apt-get dist-update”) See Eckert, J. W., & Schitka, M. J. (2004). MCSE guide to managing a Microsoft Windows Server 2003 Network. Thomson Learning There may be implications, depending on license of software delivered within layers: the Debian Guidelines (Debian, 2004) explicitly prevents redistribu- Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 22 Di Cerbo, Scotto, Sillitti, Succi, & Vernazza tion of software with a license not compliant with free software ones; see next paragraphs 6 7 In traditional GNU/Linux distribution, operations dealing with devices may be performed only by super-users. User-space tools are effective to allow some of those operations to users, in a safe way. Elive distribution, from its website http://www.elivecd.org/, is a Debian-based distribution, powered by Enlightenment window manager (http://enlightenment. sourceforge.net/) and with a strong accent on usability aspects, but focalized primarly on window manager tuning Copyright © 2007, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. View publication stats