5.4 Repositories

5.4.1 Installation Repositories

An installation repository contains the same file structure as delivered with the corresponding installation media. The simplest way would be to copy the content of all DVDs for SLES 11 SP2 and OES 11 SP1 into a directory structure and to provide remote access to these directories over HTTP. However, to protect against unintended alterations of installation sources, image files are copied to a directory and their content presented via read-only loop mounts.

Because current SLES products only support eight loop devices by default, this value needs to be increased in /etc/modprobe.d/ as follows:

options loop max_loop=64

Directory Layout for the Installation Repositories

The directory structure for the installation repository is defined as follows:

All installation data is stored below /data
ISO images are placed in the /data/isos directory
For loop mounts, the following directory structure needs to be created:
- The start directory is /data/install
- A mount point consisting of the architecture, product name, version, service pack, and media number needs to be created in the start directory. For example, a SLES 11 SP2 image of architecture x86_64 would be mounted below the /data/install/x86_64/sles11/sp2/cd1 structure.
- Directories for initial releases are named ga
- If an image contains both architectures (such as SLEPOS), the architecture directory is named biarch

The suggested directory layout is summarized in the following table:

Table 5-2 Directory Layout for the Installation Repositories

Directory	Description
/data	Start directory
/data/isos	Contains ISO images
/data/install	Contains mount points for ISO images
/data/install/x86_64	Architecture directory
/data/install/i586	Architecture directory
/data/install/biarch	Architecture directory
/data/install/x86_64/sles11	Product + version directory
/data/install/x86_64/oes11	Product + version directory
/data/install/x86_64/sles11/sp2	SLES 11 service pack directory
/data/install/x86_64/oes11/sp1	OES 11 service pack directory
/data/install/x86_64/sles11/sp2/cd1	SLES 11 SP2 media directory
/data/install/x86_64/oes11/sp1/cd1	OES 11 SP1 media directory

/etc/fstab Entries for the Installation Repositories

Loop mounts that are required to persist a server boot must be entered in /etc/fstab:

The full name to the image must be specified in column 1.
Column 2 holds the corresponding mount point.
In column 3, the file system type must be specified. It is iso9660 for image files.
Column 4 defines the mount properties for the mount point, which should be auto,ro,loop
The last column determines whether the appropriate file system should be checked on boot or not. 0 0 (no file system check on boot) is the recommended entry here.

An example how to specify loop mounts in /etc/fstab is given below:

Figure 5-1 Sample fstab Entries for an Installation Server

5.4.2 Control File and Classes Repository

The repository for the control files contains the main control file (default) which contains class declarations and the individual class files located in the directory structure outlined below.

Directory Layout for the Control File Repository

Directory Layout for the Control File Repository

In parallel to the installation repositories, some standards are defined for control files:

The top-level directory for AutoYaST is /data/autoyast
Control files are stored in /data/autoyast/xml and its subdirectories
The main control file is /data/autoyast/xml/default
All classes must be located underneath /data/autoyast/xml/classes because this directory name is hard-coded in the AutoYaST plug-ins
Below the classes directory, the Novell Consulting Installation Framework currently requires the following subdirectories: ask, general, scripts

The following table summarizes the directory layout for control files:

Table 5-3 Directory Layout for the Control File Repository

Directory	Description
/data/autoyast	Base directory
/data/autoyast/xml	Contains the classes directory and the main control file
/data/autoyast/xml/classes	Contains the class subdirectories
/data/autoyast/xml/classes/ask	Contains all classes tagged with class_name ask
/data/autoyast/xml/classes/general	Contains all classes tagged with class_name general
/data/autoyast/xml/classes/scripts	Contains all classes tagged with class_name scripts
/data/autoyast/xml/classes/general/net.xml /data/autoyast/xml/classes/general/...	Single class files tagged with class_name general

The following example is for the main control file that sources particular class files:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://
www.suse.com/1.0/configns">
  <classes config:type="list">
    <class>
        <class_name>general</class_name>
        <configuration>bootloader.xml</configuration>
    </class>
    <class>
        <class_name>general</class_name>
        <configuration>ca_mgm.xml</configuration>
    </class>
    <class>
        <class_name>general</class_name>
        <configuration>general.xml</configuration>
    </class>
    <class>
        <class_name>general</class_name>
        <configuration>net.xml</configuration>
    </class>
    <class>
        <class_name>scripts</class_name>
        <configuration>scripts.xml</configuration>
    </class>
    <class>
        <class_name>general</class_name>
        <configuration>system.xml</configuration>
    </class>
  </classes>
</profile>

5.4.3 Apache Web Server Configuration

Global Configuration

At this stage, the contents of installation repositories and the AutoYaST control file repository are only available in the file system of the AutoYaST server.

This section explains how to publish these repositories via the Apache 2 server for remote access.

Interface Binding

Apache 2 listens for requests on all interfaces by default as defined by the following directive in /etc/apache2/listen.conf:

Listen 80

If a particular interface must be used, its IP address must be added to this directive. For example:

Listen 10.10.10.221:80

Apache 2 Service Activation

To start Apache 2 automatically after a server reboot or shutdown, chkconfig must be executed to create the standard runlevel entries:

chkconfig apache2 on

Directory Configuration

In the next step, the directories whose content is to be published for remote access must be configured. Apache 2 has a default directive that ensures that all files located in the /etc/apache2/conf.d directory that have the conf suffix are treated as additional configuration directives and will be read in when Apache 2 is started.

With this in mind, you need to create a file, such as inst_server.conf, in /etc/apache2/conf.d to provide all configuration directives for installation repositories and control file directories.

The configuration part responsible for the directory configuration is displayed below:

<Directorymatch "/data/autoyast|install|isos">
    Options +Indexes
    IndexOptions +NameWidth=*

    Order allow,deny
    Allow from all
</Directorymatch>

Directorymatch directives allow you to specify a regular expression for directory configurations. By doing this, access to multiple directories can be configured with one configuration statement achieving the following:

The /data/autoyast, /data/install, and /data/isos directories are made accessible via HTTP.

In a strict sense, the isos directory is not required to be remotely accessible. However, administrators sometimes need to download the images themselves, so this directory is also allowed to be accessed via HTTP.
Access is allowed from everywhere
The content of these directories is displayed if no index document exists

The Directorymatch directive does not support symbolic links. For more information, see the ASF Bugzilla Web site.

If you need support for symbolic links in any of your repository directories, you need to configure it with an ordinary Directory directive. For example:

<Directory "/data/install>
    Options +Indexes +FollowSymLinks
    IndexOptions +NameWidth=*

    Order allow,deny
    Allow from all
</Directory>

Alias Configuration

With this configuration, the /data/install/x86_64/sles11/sp2/cd1 URL needs to be specified to access the installation source for SLES 11 SP2. For example:

http://<IP-Address|DNS Name>/data/install/x86_64/sles11/sp2/cd1

URLs to installation repositories or control files must be specified in different places. If the URL is complicated, there is a technique to overcome this possible error source.

Apache 2 provides an alias mechanism to shorten a path specification and to make access to deeply nested file structures easier. The alias directive has the following syntax:

Alias URL-path file-path|directory-path

Novell Consulting has defined the following standard for creating aliases in /etc/apache2/conf.d/inst_server.conf:

Aliases must contain one path component only (a single '/')
Aliases for installation repositories are made up of the following components:
- product
- version
- service pack (GA, SP1, and so forth)
  
  The shortcut ga is used in place of a service pack if the corresponding installation repository is the initial release of a product
- Architecture (i586|x86_64|biarch) separated by an underline character from the preceding part ('_')
The alias for the Novell Consulting Installation Framework base directory is /autoyast
The alias to specify the main directory of the control file repository is /xml

Applying these rules results in the following alias configuration for the installation repository for SLES 11 Service Pack 2, 64-bit:

Alias /sles11sp2_x86_64 /data/install/x86_64/sles11/sp2/cd1

The following table summarizes alias definitions for the AutoYaST base directory, installation repositories, the control file repository, and the directory that contains ISO images.

Table 5-4 Main Alias Configuration Directives

Alias	Path
/autoyast	/data/autoyast
/isos	/data/install/isos
/oes11sp1_x86_64	/data/install/x86_64/oes11/sp1/cd1
/sles11sp2_x86_64	/data/install/x86_64/sles11/sp2/cd1
/xml	/data/autoyast/xml

Validating the Apache Configuration for the Repository

After you have completed your Apache configuration, ensure that you validate it by issuing the following command before restarting your Apache server:

apache2ctl -t

Then restart the Apache daemon gracefully:

rcapache2 graceful

5.4.4 Creating the Customized Boot Image

The main intention of a customized boot image is to easily provide all required boot parameters to invoke unattended installations from remote repositories for different installation variants that fit into a specific customer environment.

The following table lists the most important parameters that can be specified at the boot prompt to manage AutoYaST:

Table 5-5 Boot Parameters

Parameter	Value and Meaning
kernel (mandatory)	Path to the kernel image of the target system on the boot medium, such as kernel /kernel/sles11sp2/x86_64/linux
domain (optional)	Domain search path for DNS
nameserver (optional)	Comma-separated list of DNS servers; required if you want to use DNS names instead of IP addresses
netsetup (mandatory)	Invokes initialization of network components in the pre-installation system to gain network access to repositories and special metadata files. A value of 1 ensures that dialog windows open to specify the IP address, net mask, gateway, and name server.
netmask gateway nameserver	Corresponding values can be predefined at the boot prompt. Dialog windows contain these values as the default. All three parameters are optional.
netwait	Delay after activating the network interface in seconds
autoyast (mandatory for AutoYaST framework)	URL to AutoYaST control file or directory. For example: http://<IP-Address>/xml/
install (mandatory)	URL to the installation repository. For example: http://<IP-Address>/sles11sp2_x86_64

Parameter

Value and Meaning

kernel

(mandatory)

Path to the kernel image of the target system on the boot medium, such as kernel /kernel/sles11sp2/x86_64/linux

domain

(optional)

Domain search path for DNS

nameserver

(optional)

Comma-separated list of DNS servers; required if you want to use DNS names instead of IP addresses

netsetup

(mandatory)

Invokes initialization of network components in the pre-installation system to gain network access to repositories and special metadata files.

A value of 1 ensures that dialog windows open to specify the IP address, net mask, gateway, and name server.

netmask
gateway
nameserver

Corresponding values can be predefined at the boot prompt. Dialog windows contain these values as the default.

All three parameters are optional.

netwait

Delay after activating the network interface in seconds

autoyast

(mandatory for AutoYaST framework)

URL to AutoYaST control file or directory. For example:

http://<IP-Address>/xml/

install

(mandatory)

URL to the installation repository. For example:

http://<IP-Address>/sles11sp2_x86_64

Requirements

For each target platform, the corresponding kernel and initrd are required on the boot medium. Typically, they must be copied from the /boot/<architecture>/loader directory on the original boot media shipped by Novell/SUSE. The kernel file is named linux.

Other pieces needed are the data structures to configure the graphical boot menu and to predefine the boot parameters described above.

Finally the boot loader (GRUB) binaries that are necessary to build a bootable image must be present on the boot medium.

Novell Consulting recommends the configuration and creation of boot media at a workstation that already contains all needed software parts or at the AutoYaST server itself.

Directory Structure of the Boot Image

A boot medium can be built below a working directory that represents the root of the image.

Novell Consulting suggests the following main directory structure for the boot medium:

/boot – Contains the initial GRUB configuration file, GRUB stage files, and the message file that is responsible for the graphical aspects of the boot media (typically also copied from a SUSE installation medium)
/grub– Contains nested configuration files for GRUB menus
/kernel – Contains kernel and initrd images for all platforms that need to be installed from this medium

The following table displays a complete directory structure of a boot medium as an example for a certain configuration:

Table 5-6 Directory Structure of the AutoYaST Boot Medium

Directory	Content
/boot/grub	stage1, stage2, iso9660_stage1_5, message (always copy from a current system). menu.lst contains the first level of the nested menus; see Figure 4-1.
/grub/main	message (customized settings and background, optional). instserver.lstcontains the second level of the nested menus; see Figure 4-2.
/grub/sles10-sp4	sles10-sp4.lst GRUB configuration file that contains predefined parameters to invoke an AutoYaST installation for SLES 10 SP4-based products.
/grub/sles11-sp2	sles11-sp2.lst GRUB configuration file that contains predefined parameters to invoke an AutoYaST installation for SLES11 SP2-based products.
/kernel/sles10-sp4/x86_64	initrd and kernel of the original installation medium, 64-bit, SLES 10 SP4.
/kernel/sles11-sp2/x86_64	initrd and kernel of the original installation medium, 64-bit, SLES 11 SP2.

LST Files

GRUB by default searches its configuration directives in the path /boot/grub/menu.lst on the boot medium. An example of the menu.lst file is shown below:

# autoinst level 0
color white/blue black/light-gray
default 0
timeout 15
root (cd)
gfxmenu (cd)/grub/main/message

### localboot
title localboot
  rootnoverify (hd0)
  chainloader +1

### network sles10-sp4 64bit
title network installation sles10-sp4 64bit
  configfile /grub/sles10-sp4/sles10-sp4.lst

### network sles11-sp2 64bit
title network installation sles11-sp2 64bit
  configfile /grub/sles11-sp2/sles11-sp2.lst

Lines beginning with a # sign are comments.

The above configuration forces GRUB to use the first boot entry when no user interaction takes place for 15 seconds (timeout 15, default 0).

The gxfmenu directive controls which file provides the graphical background image and user customized setting, such as the language or keyboard mapping stored in /boot/grub by default.

You should store a customized version of the file in the /grub/main directory to protect against accidentally overwriting it when updating the GRUB files to a newer version.

By using the configfile parameter, GRUB can be directed to a second configuration file, which can contain another configfile parameter, and so forth. This technique is used to implement nested menus.

If the second menu entry, network installation sles11-sp2 64bit, is chosen, GRUB evaluates configuration directives specified in the /grub/sles11-sp2/sles11-sp2.lst file on the ISO image.

The content of sles11-sp2.lst is shown below. This example shows required boot parameters predefined within a GRUB configuration file of a customized boot image.

# autoinst level 2
color white/blue black/light-gray
default 0
timeout 1
root (cd)
gfxmenu /grub/main/message

### sles11 SP2 x86_64
title sles11-sp2 x86_64
  kernel /kernel/sles11-sp2/x86_64/linux gateway=10.10.10.1 netsetup=1 ...
     ... autoyast=http://10.10.10.221/xml/...
     ... install=http://10.10.10.221/sles11sp2_x86_64/
  initrd=/kernel/sles11-SP2/x86_64/initrd

### back
title back
  configfile /boot/grub/menu.lst

IMPORTANT:If you use this example as a model, ensure that you type the kernel directive on a single line.

You can see that the configfile parameter is also used to implement the Back functionality.

Image Creation

Finally, when kernel and initrd, boot binaries, and GRUB configuration files are prepared, the boot image must be created. This is achieved by executing mkisofs with the following parameters:

mkisofs -f -rV "AUTOYAST-BOOT-IMAGE" -b boot/grub/iso9660_stage1_5 -no-emul-boot 
-boot-load-size 4 -boot-info-table -D -o autoyast-boot.iso <path_to_working_directory>

The size of the resulting autoyast-boot.iso image file that will be stored in the path provided as the last parameter of the command depends on the number of platforms whose installation should be supported by the boot image. The corresponding kernels and initrds are consuming the most space, but it is still far smaller than the size of the original boot media.