Customizing NLD Using YaST

Most of the default system settings (like hardware configuration, partitioning and device setup) can be done using YaST. For more information, see Section A.0, Using YaST to Configure the Novell Linux Desktop.

Initial Environment

When the home directory for a new user is created, it is initialized with files from the /etc/skel directory. As system administrator, you can create files in /etc/skel that provide a default environment for users. For example, you might create a /etc/skel/.profile file that sets the EDITOR environment variable to a text editor that is easy for new users to use.

However, it is usually best to keep /etc/skel as small as possible, because it is difficult to update existing users’ files. For example, if the name of the friendly editor changes, all existing users would have to edit their .profile file. You could try to do it automatically, with a script, but that is almost certainly going to break someone’s file.

Whenever possible, it is best to put global configuration into global files, such as /etc/profile. This way, it is possible to update without breaking users’ personal settings.

Customizing GNOME

The GNOME desktop configuration is done via a centralized repository that can be edited using the gconf editor tool that comes with the GNOME desktop. gconf allows you to customize the following aspects of your desktop:

For more information, see Section E.0, GNOME Configuration for Administrators.

Customizing KDE

The kiosk framework of KDE allows you to customize almost any aspect of your desktop. The KDE desktop comes with the kiosk configuration tool offering a graphical interface to all the different configuration tasks. It allows you to customize the following aspects of your desktop:

For more information, see Section F.0, KDE Configuration for Administrators.

Preparing the Master Machine

The master machine needs to be installed and configured before you can enable firstboot and start the imaging process.

Imaging the Master Machine's Hard Disk

To export the master machine's configuration, you need to image its hard disk and export this image to the targets.

Configuring the Target Machine

After the master machine's configuration has been cloned to the target's hard disk and the target is booted for the first time, firstboot starts and then the user or system administrator needs to complete some final configuration steps.

During firstboot, two additional dialogs are displayed (for writing the data and running SuSEconfig) which require no user interaction. For more information on SuSEconfig, see “Section 11.6, SuSEconfig and /etc/sysconfig” in the SUSE LINUX Enterprise Server 9 Administration and Installation Guide.

Workflows

Using the control file, you can define multiple workflows for different modes and installation stages. The element workflows in the control file evaluates to a list of workflows.

Beside defining which YaST clients should be executed during installation, the workflow configuration also lets you specify the wizard steps and how they should appear during a graphical installation.

A workflow list element is a map with the following elements:

The following is a typical installation workflow:

<workflows config:type=”list”>
        <workflow>
            <!-- ’label’ is what the user will see -->
            <label>Base Installation</label>
            <!-- default settings for all modules -->
            <defaults>
                <!-- arguments for the clients -->
                <arguments>false,false</arguments>
                <!-- allowed architectures “all”, “i386”, “i386,ia64,x86_64”  -->
                <archs>all</archs>
            </defaults>
            <stage>initial</stage>
            <mode>installation,update</mode>
            <modules  config:type=”list”>
                <module>
                    <name>info</name>
                    <arguments>false,true</arguments>
                </module>
                <module>
                    <name>proposal</name>
                    <arguments>true,true,`ini</arguments>
                    <label>Installation Settings</label>
                </module>
                <module>
                    <name>do_resize</name>
                    <update config:type=”boolean”>false</update>
                    <archs>i386,x86_64,ia64</archs>
                    <label>Perform Installation</label>
                </module>
                <module>
                    <name>prepdisk</name>
                    <!-- Multiple modules with the same ’label’ will be
                         collapsed to one single user-visible step.
                         The step is considered finished when the last module
                         with the same ’label’ is finished.  -->
                    <label>Perform Installation</label>
                </module>
                <module>
                    <name>kickoff</name>
                    <label>Perform Installation</label>
                </module>
                <module>
                    <name>rpmcopy</name>
                    <label>Perform Installation</label>
                </module>
                <module>
                    <name>finish</name>
                    <label>Perform Installation</label>
                </module>
            </modules>
        </workflow>

Proposals

Part of the installation workflows are proposal screens, which consist of groups of related configuration settings (for example, Network, Hardware, and the initial Installation proposal).

You can add or modify a proposal, which we do not recommended because of configuration dependencies, by using the control file:

<proposal>
      <type>network</type>
      <stage>continue,normal</stage>
      <proposal_modules config:type=”list”>
           		<proposal_module>lan</proposal_module>
           		<proposal_module>dsl</proposal_module>
           		<proposal_module>isdn</proposal_module>
           		<proposal_module>modem</proposal_module>
           		<proposal_module>proxy</proposal_module>
	 	<proposal_module>remote</proposal_module>
       </proposal_modules>
</proposal>

The proposal in the above example is displayed in the so-called continue mode, which is the second phase of the installation. The proposal consists of different configuration options which are controlled using a special API.

In the workflow, the proposals are called as any workflow step with an additional argument identifying the proposal screen to be started (`net for network, and `hw for hardware proposals). The following example shows how the network proposal is called as a workflow step:

<module>
    <label>Network</label>
    <name>proposal</name>
    <arguments>true,true,`net</arguments>
</module>

Installation and Product Variables

It is possible to define some installation variables and force them in the proposal. The user can still change them, however.

The following variables can be set:

The following example shows all options listed above:

	<globals>
        <enable_autologin config:type=”boolean”>true<enable_autologin>
        <language>de_DE</language>
        <timezone>Canada/Eastern</timezone>
	</globals>

Software

Use this section in the control file to change the software proposal during installation.

An example software section could look like the following:

<software>	 		
<delete_old_packages config:type=”boolean”>false</delete_old_packages>
    <selection_type config:type=”auto”>auto</selection_type>
</software>  

By default, the software proposal is generated depending on the available space in the system. If enough space is available, a fairly large number of packages and add-on package groups are automatically selected. This behavior is controlled by the selection_type element in the control file.

The default value for selection_type is auto. To force a selection (which a user cannot change), use the fixed value.

If you want a fixed software selection, the fixed selection name must be specified in the control file. This selection must be a base selection. To specify the name of the base selection to be forced, use the base_selection element.

The list of base selections can be found on the first CD of the product in the suse/setup/descr directory or by using the following command over the NLD-9 repository of your network installation source:

for i in `grep -l baseconf CD1/suse/setup/descr/* `; do 
      basename $i .sel; 
done

The above command generates the following output:

Gnome
Kde

which matches the base selections in NLD.

Additionally, you can configure package updates using the following options:

delete_old_packages

Does not delete old RPMs when updating.

only_update_selected

Updates only packages already installed or upgraded (also installs new packages with new functionality).

You can also use the software_proposal element to switch from desktop-based proposals to the normal behavior of software proposals in YaST. Setting the value to desktop makes YaST show a dialog with desktops to select from (KDE or GNOME). If this element is not defined, default behavior is assumed.

Adding Custom Software

You can also add additional software by creating custom software selections according to the procedure described in Software and pulling them in via the software proposal described in Software.

Partitioning

If present, the partition proposal is based on the data provided in the control file.

Algorithm for Space Allocation

Space allocation on a disk happens in the following order:

If more than one of the available disks are eligible to hold a certain partition set, the disk is selected as follows:

If there are multiple partition groups:

Configuration Options

The following elements are global to all disks and partitions:

Examples of Flexible Partitioning

In the example below, if the machine has three disks, each of the partition groups is put on a separate disk. So one disk holds /var; another disk holds /home; and another disk holds /, /usr, and /opt.

          <partitions config:type=”list”>
            <partition>
                <disk config:type=”integer”>3</disk>
                <mount>/var</mount>
                <percent config:type=”integer”>100</percent>               
            </partition>
            <partition>
                <disk config:type=”integer”>2</disk>                                
                <mount>/</mount>
                <size>1G</size>
            </partition>
            <partition>
                <disk config:type=”integer”>2</disk>                                
                <mount>/usr</mount>
                <size>2G</size>
            </partition>
            <partition>
                <disk config:type=”integer”>2</disk>                                
                <mount>/opt</mount>
                <size>2G</size>
            </partition>
           <partition>
                <disk config:type=”integer”>1</disk>
                <mount>/home</mount>
                <percent config:type=”integer”>100</percent>               
            </partition>       
       </partitions>

If the machine has only two disks, then /home is on a separate disk (because it has lower priority than the other partition groups) and /, /usr, /opt, and /var share the other disk. If there is only one disk in the system, all partitions are on that disk.

A more complete example with other options is shown below:

      <partitioning>        
        <partitions config:type=”list”>
            <partition>
                <disk config:type=”integer”>2</disk>
                <mount>swap</mount>
                <size>auto</size>
            </partition>
            <partition>
                <disk config:type=”integer”>1</disk>
                <fstopt>defaults</fstopt>
                <fsys>reiser</fsys>
                <increasable config:type=”boolean”>true</increasable>
                <mount>/</mount>
                <size>2gb</size>
            </partition>
            <partition>
                <disk config:type=”integer”>2</disk>
                <fstopt>defaults,data=writeback,noatime</fstopt>
                <fsys>reiser</fsys>
                <increasable config:type=”boolean”>true</increasable>
                <mount>/var</mount>
                <pct config:type=”integer”>100</pct>
                <size>2gb</size>
            </partition>
        </partitions>
        <prefer_remove config:type=”boolean”>true</prefer_remove>
        <remove_special_partitions config:type=”boolean”>false
      </remove_special_partitions>
    </partitioning>

Hooks

It is possible to add hooks before and after any workflow step for further customization of the installed system and to perform nonstandard tasks during installation.

Two additional elements define custom script hooks:

prescript

Executes before the module is called.

postscript

Executes after the module is called.

Both script types accept two elements: the interpreter used (Shell or Perl) and the source of the scripts (which is embedded in the XML file using CDATA sections to avoid confusion with the XML syntax). The following example shows how scripts can be embedded in the control file:

                <module>
                    <name>info</name>
                    <arguments>false,true</arguments>
                    <prescript>
                        <interpreter>shell</interpreter>
                        <source>
<![CDATA[#!/bin/sh
touch /tmp/tux
echo anas > /tmp/anas
]]>
                        </source>
                    </prescript>
                </module>