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
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 |
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
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.
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 |
|
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>
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.
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
To start Apache 2 automatically after a server reboot or shutdown, chkconfig must be executed to create the standard runlevel entries:
chkconfig apache2 on
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>
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 |
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
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 |
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.
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. |
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.
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.