6.2 Implementation

The autoyast parameter at the boot prompt of the installation boot medium points to the URL http://<AutoYaST-Server>/xml/ and therefore finds and retrieves the initial default control file, which contains class statements to configure general aspects of the system.

The specified classes contain template variables for their dynamic content. These classes are retrieved from the AutoYaST server and merged by standard AutoYaST functionality into the initial control file, /tmp/profile/autoinst.xml. This merged file still contains the template variables.

AutoYaST then enters the pre-script stage and retrieves the pre-fetch.sh script via HTTP as defined in the scripts section of the default control file.

pre-fetch.sh is the command center of the Novell Consulting Installation Framework that manages all aspects of building the customized control file for the new server.

It first retrieves and sources the CUSTOMER.txt customer configuration file and the main library. From this point on, pre-fetch.sh uses functions from the main ay_lib.sh library.

It then locates and parses the entry for the server being installed in the server.txt server configuration file.

In the next step, the original control file, /tmp/profile/autoinst.xml, is copied to /tmp/ profile/modified.xml. All subsequent modifications of the control file happen on this copy.

If the new server requires a tree name configuration file or a location configuration file, they are retrieved and sourced next.

Additional template files are retrieved based on the information obtained from the configuration files and are merged into the control file. Among other things, these files determine the disk partitioning of the new server and which patterns and packages need to be installed.

The service type specified in Field 14 of the server configuration file is evaluated next and the required XML files are also merged into the control file. These files contain information about the configuration of the various OES services such as eDirectory, NSS, and CIFS, but they are also used to specify some SLES configuration information, such as the memory reservation for the kdump kernel.

The custom library is retrieved and sourced next. As the last execution step, pre-fetch.sh replaces all placeholders that originated from the different template files and XML snippets that are now part of the /tmp/profile/modified.xml control file with the values that have been derived from the various configuration files.

If an error occurs during this process, pre-fetch.sh prints an appropriate error message indicating where the error has occurred. The administrator can inspect the error message and decide whether to abort or to continue the installation.

When pre-fetch.sh terminates without error, AutoYaST recognizes the /tmp/profiles/modified.xml control file and processes it as explained in autoinst.xml, modified.xml, and pre-autoinst.xml.

The remainder of this section explains this process in detail.

Figure 6-1 illustrates the Novell Consulting Installation Framework stored in the directory structure underneath .../autoyast.

Figure 6-1 Directory Structure

.../autoyast/xml is the control file repository directory introduced and explained in Control File Repository.

The .../isos and .../install subdirectories are used to store the installation sources as discussed in Directory Layout for the Installation Repositories.

The .../update subdirectory holds the signed YUM repositories containing updates for the operating system (SLES 11 SP2) and the add-on product (OES 11 SP1) being installed.

These YUM repositories are integrated into the installation process as additional add-on products.

This is a temporary workaround that is required because ZENworks Configuration Management cannot sign the YUM repositories it creates, and unsigned repositories cause warning messages whenever they are accessed in YaST.

The purpose of the other directories underneath .../autoyast is explained in the following table, using the default names for files and directories suggested by Novell Consulting.

.../configs

.../files/addon

.../files/partitioning

.../files/services/oes11

.../files/services/sles11

.../files/software

.../files/tools

.../lib/customer

.../lib/novell

.../scripts

The full default file used by the Novell Consulting Installation Framework is displayed below:

<?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>system.xml</configuration>
    </class>
    <class>
        <class_name>general</class_name>
        <configuration>general.xml</configuration>
    </class>
    <class>
        <class_name>scripts</class_name>
        <configuration>scripts.xml</configuration>
    </class>
    <class>
        <class_name>general</class_name>
        <configuration>net.xml</configuration>
    </class>
   </classes>
 <scripts>
<!--
    This section is mandatory and must not be removed.
    Amongst other things it is used to determine the
    IP address of the AutoYaST server in the post-inst
    phase
-->
    <pre-scripts config:type="list">
  <script>
  <interpreter>shell</interpreter>
  <filename>pre-fetch.sh</filename>
        <location>http://10.0.4.221/bs/scripts/pre-fetch.sh</location>
  <feedback config:type="boolean">false</feedback>
  <debug config:type="boolean">false</debug>
  </script>
    </pre-scripts>
  </scripts>
</profile>

This file contains two different kinds of information. First, class directives define class files that need to be merged to create the initial /tmp/profile/autoinst.xml control file and that configure the following aspects of the system:

The second type of information in the file is in the scripts section, which defines the pre-fetch.sh pre-script file located in the scripts directory on the AutoYaST server. This information causes the AutoYaST engine to retrieve and execute this script.

This section is one of the few places where customer-specific values must be hard-coded. The IP address of the AutoYaST server is unique to every customer environment and cannot be derived from environment parameters. Therefore it must be explicitly specified in the URL to the pre-fetch.sh script in the location directive of the pre-script definition in the default file.

The first action of this script is to retrieve the AY_MAIN.txt system configuration file. This is implemented in the get_main_config_files( ) function that first derives the address of the AutoYaST server to be used from the command line.

The script needs three other pieces of information to be able to retrieve the required files from the installation server:

This information must be available from within the script, so it is hard-coded. If you want to use different names for this file or any of the two directories, ensure that you set the correct values here.

All other file names, directory names, and URLs required to retrieve files from the AutoYaST server are always derived from the system configuration file.

The same function also retrieves and sources the ay_lib.sh main library (a set of shell functions that can be reused to reduce code fragments) and the CUSTOMER.txt customer configuration file (or whatever name is defined for it in AY_MAIN.txt).

Certain configuration information such as the default gateway, a list of name servers, or a suffix search list, and also OES-specific information such as the name of the installation user or the IP address of an existing replica server can be specified in three different places:

The configuration files that need to be incorporated into the installation of a particular server are defined in Field 10 and Field 13 of the server.txt server configuration file. pre-fetch.sh sources these files in the following sequence:

customer configuration file > eDirectory tree configuration file > location configuration file

Values defined in global configuration files are overwritten by values for the same variable from more specific configuration files. For example, a list of NTP time servers specified in the customer configuration file as a company-wide default can be overwritten by specifying a different set of NTP servers in a configuration file representing an eDirectory tree. This NTP server list can be further modified by specifying yet another list of NTP servers in a location configuration file representing a particular site.

In some cases, a customer might have a requirement that cannot be accommodated by the ay_lib.sh main library. For these cases, the customer_lib.sh file has been provided. Code contained in this file is evaluated after code from the main library but before the replacement of the template variables takes place.

One of the central functions executed by pre-fetch.sh is the replacement of the placeholders with their real values. The following XML snippet illustrates how placeholders are specified and used:

<dns>
   <dhcp_hostname config:type="boolean">false</dhcp_hostname>
   <dhcp_resolv config:type="boolean">true</dhcp_resolv>
      <hostname>%%HOST_NAME%%</hostname>
   <domain>%%DOMAIN%%</domain>
   <searchlist config:type="list">
    <search>%%SEARCH_LIST%%</search>
   </searchlist><nameservers config:type="list">
    <nameserver>%%NAMESERVER%%</nameserver>
   </nameservers>
</dns>

At some point after parsing the server-specific line in server.txt and processing the specified configuration files, every variable will have its final value assigned. The replacement process now searches for every placeholder (enclosed in %%-signs, such as %%HOST_NAME%%) within /tmp/profile/modified.xml and replaces the whole string with the value of the corresponding $HOST_NAME variable. The replacement itself is using a sed function.

Another important function ensures the merging of complete XML snippets into the final control file. The function is using XSLT techniques by utilizing the /usr/share/autoinstall/xslt/merge.xslt file, which is part of any installation RAM disk provided by SUSE.

In particular, the partitioning, software, and service XML files are merged completely into the final /tmp/profile/modified.xml control file.

The last action performed by pre-fetch.sh is a basic error check. First, it checks to see if the /tmp/profile/modified.xml control file still contains %%-signs (which implies that “%%” must exclusively be used to identify placeholders. Any other usage, even in comments, results in an error).

Then it checks for a /tmp/profile/errors.txt file. This file is created by functions from ay_lib.sh when the retrieval of a remote file fails. If this file exists, a pop-up is generated that displays the content of /tmp/profile/errors.txt and queries whether the installation process should be continued or aborted.

The framework provides two libraries. The main ay_lib.sh library developed by Novell Consulting contains nearly all code used by the pre-fetch.sh script. This library must not be changed or modified in any way. Any potential update to the Novell Consulting Installation Framework almost certainly results in a newer version of this library that overwrites any customer-specific modifications.

To accommodate customer-specific functionality, the empty .../autoyast/lib/ customer/customer_lib.sh library file is available. It can use functions that are already implemented in the main library, but also can implement new functions to provide additional functionality. The content of this file is sourced and executed by pre-fetch.sh just before the replacement of the placeholders takes place. No update to the framework ever touches this particular library.

Configuration files have been mentioned several times in preceding sections. The purpose of these files, stored in the directory defined by the AY_CONFIG_DIR variable in pre-fetch.sh, is to separate information that is applicable to multiple servers from server-specific information.

Name servers, time servers, the distinguished name of the UNIX configuration object, or the list of LDAP servers are examples of settings that can be configured.

Configuration file entries provide three pieces of information:

The following example defines the name of the admin group for Linux User Management:

## Type String
## Description: fully distinguished name of the LUM admingroup
##              in LDAP syntax
LUM_ADMIN_GROUP="cn=admingroup,ou=Cluster1,ou=Servers,ou=DUS,ou=EMEA,o=Novell"

Although it is not always required in a strictly technical sense, we recommend that you always include values in double quotes. There is one notable exception: Because the password for the root user typically contains “$”, it must be enclosed in single quotes. As a best practice, any setting that is not used in a particular configuration file should be commented.

The files stored in the directory structure underneath .../files have been obtained by retrieving the relevant portion from an autoinst.xml file saved after a manual installation and by replacing dynamic information with placeholders.

You should carefully inspect each of these files to ensure that the various settings meet your specific requirements.

Post-installation scripts are necessary to perform installations that cannot be covered by AutoYaST. They must be specified within the <scripts> section of an AutoYaST control file.The framework uses a separate class-file (.../autoyast/xml/classes/scripts/ scripts.xml) that specifies where these scripts are retrieved from and execute. For example:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns" 
xmlns:config="http:/www.suse.com/1.0/configns">
  <scripts>
    <!-- init-scripts (during the first boot of the installed system,
                       all services up and running) -->
    <init-scripts config:type="list">
      <listentry>
        <!-- Miscellaneous changes -->
        <filename>post-inst.sh</filename>
        <interpreter>shell</interpreter>
        <location>%%AY_SERVER%%/%%PREFIX%%/scripts/post-inst.sh</location>
      </listentry>
      <listentry>
        <!-- Install ZCM agent -->
        <filename>zcm-install.sh</filename>
        <interpreter>shell</interpreter>
        <location>%%AY_SERVER%%/%%PREFIX%%/scripts/zcm-install.sh</location>
      </listentry>
    </init-scripts>
  </scripts>
</profile>

The scripts are executed in the init stage as specified by the<init-scripts> tag. The initial release of the Novell Consulting Installation Framework uses two post-installation scripts: