12.3.3.1. Creating Profiles
Simple-CDD defines “profiles” that match the FAI “classes” concept, and a machine can have several profiles (determined at installation time). A profile is defined by a set of profiles/profile.* files:
the .description file contains a one-line description for the profile;
the .packages file lists packages that will automatically be installed if the profile is selected;
the .downloads file lists packages that will be stored onto the installation media, but not necessarily installed;
the .preseed file contains preseeding information for Debconf questions (for the installer and/or for packages);
the .postinst file contains a script that will be run at the end of the installation process;
lastly, the .conf file allows changing some Simple-CDD parameters based on the profiles to be included in an image.
The default profile has a particular role, since it is always selected; it contains the bare minimum required for Simple-CDD to work. The only thing that is usually customized in this profile is the simple-cdd/profiles preseed parameter: this allows avoiding the question, introduced by Simple-CDD, about what profiles to install.
Note also that the commands will need to be invoked from the parent directory of the profiles directory.
12.3.3.2. Configuring and Using build-simple-cdd
QUICK LOOK Detailed configuration file
An example of a Simple-CDD configuration file, with all possible parameters, is included in the package (/usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed.gz). This can be used as a starting point when creating a custom configuration file.
Simple-CDD requires many parameters to operate fully. They will most often be gathered in a configuration file, which build-simple-cdd can be pointed at with the --conf option, but they can also be specified via dedicated parameters given to build-simple-cdd. Here is an overview of how this command behaves, and how its parameters are used:
the profiles parameter lists the profiles that will be included on the generated CD-ROM image;
based on the list of required packages, Simple-CDD downloads the appropriate files from the server mentioned in server, and gathers them into a partial mirror (which will later be given to debian-cd);
the custom packages mentioned in local_packages are also integrated into this local mirror;
debian-cd is then executed (within a default location that can be configured with the debian_cd_dir variable), with the list of packages to integrate;
once debian-cd has prepared its directory, Simple-CDD applies some changes to this directory:
files containing the profiles are added in a simple-cdd subdirectory (that will end up on the CD-ROM);
other files listed in the all_extras parameter are also added;
the boot parameters are adjusted so as to enable the preseeding. Questions concerning language and country can be avoided if the required information is stored in the language and country variables.
debian-cd then generates the final ISO image.
12.3.3.3. Generating an ISO Image
Once we have written a configuration file and defined our profiles, the remaining step is to invoke build-simple-cdd --conf simple-cdd.conf. After a few minutes, we get the required image in images/debian-6.0-i386-CD-1.iso.
12.4. Monitoring
Monitoring is a generic term, and the various involved activities have several goals: on the one hand, following usage of the resources provided by a machine allows anticipating saturation and the subsequent required upgrades; on the other hand, alerting the administrator as soon as a service is unavailable or not working properly means the problem can be fixed earlier.
Munin covers the first area, by displaying graphical charts for historical values of a number of parameters (used RAM, occupied disk space, processor load, network traffic, Apache/MySQL load, and so on). Nagios covers the second area, by regularly checking that the services are working and available, and sending alerts through the appropriate channels (e-mails, text messages, and so on). Both have a modular design, which makes it easy to create new plug-ins to monitor specific parameters or services.
ALTERNATIVE Zabbix, an integrated monitoring tool
Although Munin and Nagios are in very common use, they are not the only players in the monitoring field, and each of them only handles half of the task (graphing on one side, alerting on the other). Zabbix, on the other hand, integrates both parts of monitoring; it also has a web interface for configuring the most common aspects. It has grown by leaps and bounds during the last few years, and can now be considered a viable contender.
→ http://www.zabbix.org/
ALTERNATIVE Icinga, a Nagios fork
Spurred by divergences in opinions concerning the development model for Nagios (which is controlled by a company), a number of developers forked Nagios and use Icinga as their new name. Icinga is still compatible — so far — with Nagios configurations and plugins, but it also adds extra features.
→ http://www.icinga.org/
12.4.1. Setting Up Munin
The purpose of Munin is to monitor many machines; therefore, it quite naturally uses a client/server architecture. The central host — the grapher — collects data from all the monitored hosts, and generates historical graphs.
12.4.1.1. Configuring Hosts To Monitor
The first step is to install the munin-node package. The daemon installed by this package listens on port 4949 and sends back the data collected by all the active plugins. Each plugin is a simple program returning a description of the collected data as well as the latest measured value. Plugins are stored in /usr/share/munin/plugins/, but only those with a symbolic link in /etc/munin/plugins/ are really used.
When the package is installed, a set of active plugins is determined based on the available software and the current configuration of the host. However, this autoconfiguration depends on a feature that each plugin must provide, and it is usually a good idea to review and tweak the results by hand. It would be interesting to have comprehensive documentation for each plugin, but unfortunately there's no such official documentation. However, all plugins are scripts and most are rather simple and well-commented. Browsing /etc/munin/plugins/ is therefore a good way of getting an idea of what each plugin is about and determining which should be removed. Similarly, enabling an interesting plugin found in /usr/share/munin/plugins/ is a simple matter of setting up a symbolic link with ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Note that when a plugin name ends with an underscore “_”, the plugin requires a parameter. This parameter must be stored in the name of the symbolic link; for instance, the “if_” plugin must be enabled with a if_eth0 symbolic link, and it will monitor network traffic on the eth0 interface.
Once all plugins are correctly set up, the daemon configuration must be updated to describe access control for the collected data. This involves allow directives in the /etc/munin/munin-node.conf file. The default configuration is allow ^127\.0\.0\.1$, and only allows access to the local host. An administrator will usually add a similar line containing the IP address of the grapher host, then restart the daemon with invoke-rc.d munin-node restart.
GOING FURTHER Creating local plugins
Despite the lack of official documentation for standard plugins, Munin does include detailed documentation on how plugins should behave, and how to develop new plugins.