Configuration Dissertation

If you're counting, this is the fourth article in my Ignite/UX series. And it's an Ignite/UX configuration overview. Previously, I discussed the creation of archiveimages. This month I'll look into the structure and purpose of configuration files. These files control all aspects of Ignite/UX, from what appears in the GUI, to automating an Ignite session, to selecting and configuring the operating system loaded onto a client.

• 01/31/1999

The difficulty in working with configuration files is that there are typically at leastfive files used for every Ignite session. On top of that, some settings only have effectsin certain files, or possibly mean different things when used in different files. Finally,you must carefully plan out your organization of configuration files, since many settingscould be assigned in multiple files. If you fail to do that, things can get veryconfusing, very quickly. If you understand the overall organization of these files andwhen they're used, these issues can be managed.

Here's a look at the categories of configuration files and how they're used.

System Defaults. In the directory opt/ignite/data/Rel_<OSrelease> there areseveral config files. These files are not to be edited, they are shipped with Ignite. Someof them, like the file named config, make good examples. Files that you create mightoverride settings in these files.

System Specified. This category contains files that are shipped with Ignite/UX andthose that are expected, but must be created or edited.

For starters, there is /var/opt/ignite/INDEX. This file will be edited -- it's themaster configuration file. All configuration files that you create must be referencedhere, or they will be ignored. This is also the file in which you name softwareconfigurations and list the configuration files that define them. The actual informationis in the listed files, not in the INDEX file. This is truly where you start configuringan Ignite software load.

Another file expected by Ignite is /var/opt/ignite/config.local. This is used to setdefaults for this particular Ignite server and the clients that are to be installed fromit. Think of it as globally applied local information. It contains information thatcontrols Ignite sessions, as well as local network settings. It's more formally known asthe "local overrides" file and is typically listed last in any namedconfiguration set in the INDEX file. It's not automatically read -- it must be listed tobe used.

WE HAVE IGNITION

Every time a client is ignited, the Ignite server saves a copy of how that client wasconfigured. This can be used during re-installs. The file, named config, will be createdunder the /var/opt/ignite/clients directory, in a sub-directory named after the MACaddress of the client.

You can also create config files in this directory before a first Ignite session anduse it to assign the permanent IP address, hostname, and/or other client-specificinformation, such as which configuration to load. That would come in handy when usingIgnite to deploy a new release in a network. Be forewarned though, this file isoverwritten after every Ignite session for that host.

A file pivotal to performing hands -off installations is /opt/ignite/boot/INSTALLFS.This is the memory based file system that is downloaded to a client when a session isstarted. At first it would not appear to be a configuration file. Especially when younotice the pathname -- it lives in the /opt directory. If you think about it though,you'll realize that there are some settings that control hardware, or the Ignite sessionitself, so the client must know about these before the actual installation begins.

A good example -- you must set the keyboard type in this file so that the session doesnot stop and prompt for it. Those chunks of data are loaded into the first 8KB of theINSTALLFS file so that they are available to the client when it reboots to thememory-based kernel and filesystem. You will use the command instl_adm to "poke"certain configuration information into the INSTALLFS file.

KNOW YOUR DEPOT

Finally, if you're using software depots, instead of, or in addition to archive loads,software in the depot must be made known to Ignite. This is done with files that aretypically placed in the /var/opt/ignite/data/Rel_<OSrelease> directory. The commandmake_config can automatically create these files from a depot.

Archives also need to be described. Those config files could be stored here, or in anydirectory you choose. Archive config files are commonly created by editing a copy of oneof the supplied templates. Most people like to keep all hand-edited files lumped togetherfor an easier backup.

User Specified. This third category of configuration files is where you perform themajority of your edits, control how an Ignite session runs and how clients are installedand configured. It is recommended that you store these files in/var/opt/ignite/data/Rel_<OSrelease>. The convention is to place "_cfg" atthe end of the file name.

If all your hardware is similar and all hosts will be loaded with a similar softwareconfiguration, you might create only one file. You could end up with many files -- it's upto you. Since there is a type of "if-then" statement in the syntax ofconfiguration files, you have an amount of dynamic decision making capability. That allowsyou to do quite a bit in one file.

If you're not concerned with setting up for hands-off installations, there is no needto create any User Specified files. The GUI based Ignite tools allow you to controlsessions.

In fact, if you go through an Ignite installation manually, there is an option to savethe configuration. That file can be used as the basis for creating your own automaticconfiguration files.

Next month we'll dive into the syntax used in configuration files and run through a fewexamples.

Are you still fired up over Ignite? Let Fred know at frederm@famece.com.

Fred Mallett

frederm@famece.com