| Version 29 (modified by , 15 years ago) (diff) |
|---|
Initial Installation
Table of Contents
This is a quick introduction to AII configuration. AII is Quattor component in charge of producing Kickstart configuration file used for initial installation.
Configuration specific to initial installation is made of 2 parts :
- AII_xxx variables used to configure base environment (keyboard, language...). This works both for v1 and v2.
- Filesystems and block devices definitions : this is specific to AII v2.
AII Site Configuration
All AII options may be customized through variables. For the complete list, look at the man pages aii-pxelinux(8) and aii-ks(8) or the source code standard/quattor/aii/ks/config.tpl and standard/quattor/aii/pxelinux/config.tpl.
A typical AII configuration is :
# AII specific parameters variable AII_OSINSTALL_SRV ?= "quattorsrv.lal.in2p3.fr"; # variable AII_ACKSRV ?= "quattorsrv.lal.in2p3.fr"; variable AII_OSINSTALL_ROOT = '/packages/os';
The typical place to customize AII configuration is template site/aii-config.tpl. This template is executed quite late in the configuration, after completion of all the base OS configuration. Thus it is possible to make reference to most of the variables built during the configuration, in particular those reflecting OS flavour (version and arch) used.
Kickstart Site-Specific Installation Actions
AII allows to define in a flexible way site-specific actions that must be done at various points in Kickstart. This is done through several hooks.
Configuration of Filesystems: The Recommended Way
QWG Templates provide a generic template to configure file systems on a typical system with 1 or 2 disks. It is based on template standard/filesystem/config.tpl that may be customized according to your site needs with a limited set of variables. In addition to this generic template to define disk layouts, QWG templates provides 3 examples of how to use it :
- site/filesystems/glite.tpl : define a default system disk layout for a typical grid system running gLite, using LVM for everything except
/boot,/andswap. This template also provides some variables to further refine this default layout without redefining everything. - site/filesystems/ce_nfs_server.tpl : add to the basic layout provided by the previous template 2 filesystems, one for home directories and one for VO software areas. It is intended to be used on a machine configured as a NFS server to serve these file systems to WNs (and possibly the CE if it is not the NFS server). It illustrates how to configure the basic layout template without redefining every thing.
- site/filesystems/extended.tpl : define a default system disk layout for a typical grid system running gLite, using logical partitions instead of LVM for everything except
/boot,/andswap. This illustrated how to customize the default layout. It is an alternative to site/filesystems/glite.tpl. This template also provides some variables to further refine this default layout without redefining everything. - site/filesystems/sw_raid.tpl : define a default system disk layout for a typical grid system running gLite, using software raid (md devices) instead of LVM for everything except
swap. This illustrated how to customize the default layout. It is an alternative to site/filesystems/glite.tpl. This template also provides some variables to further refine this default layout without redefining everything.
These templates are just provided as examples on how to use standard/filesystem/config.tpl. But standard/filesystem/config.tpl can be used to handle many other layouts. You can build your own from scratch or mixing the examples provided (there is no restriction to use only LVM, logical partitions or raid volumes in one layout, this was done just for clarity of examples) or using other types of block devices like hardware raid.
The basic idea is to declare in this base layout templates (like site/filesystems/glite.tpl, site/filesystems/extended.tpl, site/filesystems/sw_raid.tpl) all the possible file system that can be found on a system, most of them with zero size meaning they will not be created unless the variable used to define their size is explicitly set to a non-zero value in another template that include the basic layout (as site/filesystems/ce_nfs_server.tpl does with site/filesystems/glite.tpl). The main effort is to maintain the basic layout but it has the advantage to provide a central point for defining any potential configuration, avoiding a lot of duplication.
To use these templates, you need to define the following 2 variables in your node profile or one of your site-specific templates (typically site/cluster_info.tpl ) :
FILESYSTEM_CONFIG_SITE: define this variable to be filesystem/config.tpl. This is the default in gLite templates.FILESYSTEM_LAYOUT_CONFIG_SITE: define this variable to the name of a template that customize source:templates/trunk/sites/example/site/filesystems/glite.tpl sites/example/site/filesystems/glite.tpl] by defining the appropriate variables. gLite templates define it to be site/filesystems/glite.tpl by default.
Customizing File System List
The responsibility of the layout template (like the provided examples site/filesystems/glite.tpl, site/filesystems/extended.tpl, site/filesystems/sw_raid.tpl) is to build a variable DISK_VOLUME_PARAMS which is an nlist that contains one entry per file system or block device (the key in the nlist is just an arbitrary identifier used for cross-referencing entries). Both of thems are described the same way in the same variable: they all have a set of attributes declared in a nlist. Possible attributes vary dependending on wether it is a file system or block device or depending on the block device type (partition, software raid, hardware raid, LVM). An entry is considered a file system if it has an attribute mountpoint defined.
When the layout template is executed, DISK_VOLUME_PARAMS already exists with some typical default entries. For this reason, the layout template doesn't create the variable from scratch with function nlist() but uses the function filesystem_mod() to update it. This is also for this reason that in the examples (
This should be done as demonstrated in the example, using function filesystem_mod()to update variable DISK_VOLUME_PARAMS.
Defining Default File System Type
Default file system type is ext3. This can be customized by a site defining variable FILESYSTEM_DEFAULT_FS_TYPE variable.
Defining Default Formatting Policy
It is possible to define the site defaults for attributes format and preserve that are used when reinstalling a system with valid partitions. This is done respectively with variables FILESYSTEM_DEFAULTS_FORMAT and FILESYSTEM_DEFAULTS_PRESERVE. They are both true by default.
File Systems and Block Devices : The Gory Details
In AII v2, block devices and file systems are declared separatly. Sections belows give some details about how to configure each of them. Block devices entries are used only if referenced by a file system or another block device entry.
Note: configuring directly file systems and block devices is not recommended as it may be quite complex to ensure consistency of all parts involved. If possible, use the generic template to configure filesystems. Both methods cannot be mixed.
File Systems
Filesystems are declared as an ordered list allowing to customize different aspect of a file system (mount point, mount options, format, ...). Each file system in the list is described as a nlist. One property in the nlist describing a file system is block device : its value is an entry in the structure describing block devices (physical disk, logical volumes, ...). To add or modify a filesystem on a system, it is recommended to use 'fileystem_mod` function. An example is :
"/system/filesystems" = filesystem_mod(
list(nlist ("block_device", "partitions/" + DISK_PART_BOOT,
"mountpoint", "/boot",
"format", true,
"mount", true,
"preserve", false,
"type","ext2"),
nlist ("block_device", "partitions/" + DISK_PART_SWAP,
"format", true,
"mount", true,
"preserve", false,
"type","swap",
"mountpoint","swap"),
nlist ("block_device", "partitions/" + DISK_PART_ROOT,
"format", true,
"preserve", false,
"mount", true,
"type","ext3",
"mountpoint","/"),
nlist ("block_device", "logical_volumes/usrvol",
"format", true,
"preserve", false,
"mount", true,
"type","ext3",
"mountpoint","/usr"),
);
Look at site/filesystems/glite.tpl for more details.
Block Devices
Block devices define logical and physical devices used by file systems. They can be logical devices, HW or SW raid devices, physical disks... A block device can be made of other block devices, for example a logical device is made of one or more physical devices.
Unlike file systems which are described with an ordered list, block devices are defined as a nlist. At installation time, they are processed (partition creation, logical volume creation...) in the order of file systems who use them.
Several functions are available to help in declaration of block devices, in particular :
partition_add(PHYS_DISK,partition_nlist): allow to add entries efficiently in/system/blockdevices/partitionsnlist.lvm_add(VOL_GROUP,logvol_nlist): allow to add entries efficiently in/system/blockdevices/logical_volumesnlist.
An example of block device definition is :
"/system/blockdevices/physical_devs" = npush (
DISK_BOOT_DEV, nlist ("label", "msdos")
);
"/system/blockdevices/partitions" = partitions_add (DISK_BOOT_DEV, nlist (DISK_PART_BOOT, 64*MB,
DISK_PART_SWAP, 4*GB,
DISK_PART_ROOT, 1*GB,
DISK_PART_LOGPARTS, -1
)
);
"/system/blockdevices/volume_groups" = npush (
"vg0", nlist ("device_list", list ("partitions/" + DISK_PART_LOGPARTS))
);
"/system/blockdevices/logical_volumes" = lvs_add ("vg0", nlist("usrvol", 5*GB,
"homevol", 512*MB,
"tmpvol", 1*GB,
"varvol", -1,
)
);
Look at site/filesystems/glite.tpl for more details.
AII v1 to v2 Migration
When migrating from AII v1 to v2, the AII configuration itself should not require many changes, as long as you are using AII-related variables, except for the declaration of Kickstart actions which replace former Kickstart template. The aii-update(8) man page provides complete information on what is needed now.
Important note
The model for file systems and block devices allows to use partition labels others than msdos. It is even possible not to use partition tables at all on non-system disks. However, Anaconda doesn't like this and will stop your installations if it finds disks with non-msdos labels. For this reason, AII will only create filesystems that are fully enclosed in msdos-labeled disks. This means the partition beneath a file system, all members of a given software RAID or whatever combination you can think of. Filesystems on other partition tables must be created after the node is installed, for instance with ncm-filesystems.
If you install and miss any file systems on your Kickstart file, please check the labels on all your disks.
On the other hand, file system definition is not backward compatible and must be edited as described before. The full description of the data structures and helper functions is available at CERN wiki You can also find some useful hints and additions at https://twiki.cern.ch/twiki/bin/view/ELFms/QuattorUpdateFSLayout.
Troubleshooting
Error creating Fetch object for …
Should you get this message when running aii-shellfe, it indicates that /etc/ccm.conf is missing. This may happen if your Quattor server is not managed with Quattor. To fix the problem, create one with the following contents:
debug 0 force 0 cache_root /var/lib/ccm get_timeout 30 lock_retries 3 lock_wait 30 retrieve_retries 3 retrieve_wait 30 world_readable 1
Tainted mode warnings (Insecure dependency...)
These messages indicate that you have clearly insecure hooks running, and that a fix is needed. AII runs in "tainted" mode, meaning that all input must be sanitized. On user hooks you'll usually find warnings when attempting to open a file that is given on the profile or when running a command, for instance:
my $filename = $config->getElement (SOME_PATH)->getValue (); open (FH, ">$filename");
will issue a warning, meaning that $filename must be sanitized. This a sanitized version:
my $filename = $config->getElement (SOME_PATH)->getValue ();
if ($filename =~ m{^(/.+)$}) {
$filename = $1;
} else {
throw_error ("Expected an absolute path on $filename");
return ();
}
open (FH, ">$filename");
Note that the above example assumes you expect an absolute path. If you expected something different (f.i, a path under /osinstall/ks), fix your regular expression accordingly.
The same applies when you run commands:
my $param = $config->getElement (SOME_OTHER_PATH)->getValue ();
# $param is tainted!!!
system ("ls", "$param");
will fail, so you'll have to specify what you are expecting exactly:
my $param = $config->getElement (SOME_OTHER_PATH)->getValue ();
# I expected just a bunch of flags!!
if ($param =~ m{^(-[-=\w]+)$}) {
$param = $1;
} else {
throw_error ("Unexpected flags passed to the command");
return ();
}
system ("ls", $param);
When you get a warning, it will point out the line where the insecure data is used, but please fix it on the place where such insecure data is received. It will reduce a lot your code and efforts.
You'll find more information on the tainted mode on perlsec man page.
