Managing System Identity with changeident

John Spurgeon and Ed Schaefer

When building or reconfiguring a system, an administrator performs many mundane and repetitive jobs to identify the system. These tasks may include setting the time zone, setting the netmask, configuring sendmail, configuring the network interfaces, changing the node name, and so forth. In this article, we present a Korn shell utility called changeident that automates changing the system identity. Changeident includes a generic driver, a collection of program modules where each module performs a specific task (such as changing the node name), and a configuration file that determines which modules need to be executed. Additionally, optional response files can eliminate the need for human interaction.

The changeident Driver

The changeident driver (Listing 1) executes the programs listed in the configuration file. Invoking changeident with no options prompts the user to enter the required configuration information. When run with a nodename option, user interaction is not required because predefined responses to various prompts are stored in a response file.

The changeident driver supports the following options:

-m (modules_file) -- Override the default modules file with modules_file.

-n (nodename) -- Use a response file for nodename instead of prompting the user. Using response files allows an administrator to remotely execute changeident, including rebooting the system if necessary.

-p (program_list) -- Execute a specified list of programs. In this case, the default modules file is not used, but if the option -m (modules_file) is supplied, program_list is appended to the list of programs contained in modules_file.

-r -- Automatically reboot the system if a reboot is necessary to apply the configuration changes.

Example 1

Run changeident in the background, and redirect standard output to /dev/null. Use a response file for the example doomsday server, and automatically reboot the system, if necessary:

changeident -n doomsday -r > /dev/null &

Run changeident using the programs listed in module file Solaris_7:

changeident -m Solaris_7

Run changeident using the program modules Solaris/nodename and Solaris/nics:

changeident -p "Solaris/nodename Solaris/nics"
  

Module files are inherently OS specific, however, additional modules for other Unix variants can easily be added. Later in the article, we examine a module that changes the node name on a Solaris system. See the "Changeident Program Modules" sidebar for a discussion of the other modules we include in the tar file.

Configuration Files

The configuration file is a list of all the modules you'll need to execute. Here is an example of what a configuration file might look like:

Solaris/nodename
Solaris/nics
Solaris/netmasks
Solaris/nsswitch
Solaris/resolv
Solaris/defaultrouter
Solaris/ntp
Solaris/sendmail
Solaris/timezone
Solaris/mymodule

If you support a large enterprise network with many hosts, response files let you predefine the configuration options for each server. Also, response files facilitate administering servers remotely. Without a response file, you could be disconnected from the system in the process of changing certain network settings. With a response file, you can execute the entire program in the background, including rebooting the system if necessary.

Here is an example of what some typical entries in a response file might look like:

nodename=doomsday
nic_action:iprb0=configure
nic_ip_address:iprb0=192.111.11.11
nic_hostname:iprb0=doomday
nic_action:iprb1=disable
hostname_lookup=files dns
change_netmasks=no
change_dns=yes
dns_domain=eds.com
dns1=192.111.9.1
dns2=192.111.9.21
dns3=192.222.10.1
Sourcing the globals File

Among the global variables defined are the following application variables:

CHANGEIDENT_HOME_DIR=/opt/changeident
CHANGEIDENT_BIN_DIR=$CHANGEIDENT_HOME_DIR/bin
CHANGEIDENT_LIB_DIR=$CHANGEIDENT_HOME_DIR/lib
CHANGEIDENT_VAR_DIR=$CHANGEIDENT_HOME_DIR/var
CHANGEIDENT_ETC_DIR=$CHANGEIDENT_HOME_DIR/etc

When executed on a Solaris system, the globals file detects the OS version and sets the module_file variable:

modules_file=Solaris_7

Solaris includes the non-standard utilities ckyorn and ckstr. In a non-Solaris environment where these programs do not exist, the globals file provides replacement shell functions.

An Example Program Module: Solaris/nodename

You may think changing the nodename it is as simple as changing the /etc/nodename and /etc/hosts files. Invariably, it is more complicated than that. Typically, several files contain the system's name and/or IP address, and many other configuration files may also require updating.

The Solaris/nodename module (Listing 3) updates the /etc/nodename file and the transport provider files. This is the program logic:

• Ensure that the effective user is root. (There is no reason for any user other than root to execute a module.)
• Obtain the host name. Either pass the name of a response file (typically the response file name is the name of the host it describes) to the script via the -n command-line option, or query the user for the information.
• Set the host name and transport provider files. The /etc/nodename file contains one entry -- the host name of the local machine. The transport provider files contain one line with the host name repeated twice delimited by a tab:

  doomsday doomsday
  

  According to Sun's Transport Interfaces Programming Guide, transport services allow distributed applications a standard interface to communicate using different protocols. The transport file naming convention is:

  /etc/net/"transport name"/hosts
  

  Solaris 7 supports the ticlts, ticots, and ticotsord transport services, so the files are:

  /etc/net/ticlts/hosts
  /etc/net/ticots/hosts
  /etc/net/ticotsord/hosts
  

  The /etc/netconfig file contains the names of the supported transport services.

• Create and configure a crash dump directory for the new host name. An example for the doomsday server is:

  mkdir -p /var/crash/doomsday
  dumpadm -s /var/crash/doomsday > /dev/null
  

  The dumpadm utility actually performs the configuration. From the Solaris 7 dumpadm MAN page:

  "A crash dump is a disk copy of the physical memory of the computer at the time of a fatal system error. When a fatal operating system error occurs, a message describing the error is printed to the console. The operating system then generates a crash dump by writing the contents of physical memory to a predetermined dump device, which is typically a local disk partition."

  Typically, the savecore utility creates the crash dump file. For more information, check the savecore MAN page.

• Finally, create the REBOOT file. The nodename changes do not take effect without rebooting. If nodename is executed by the changeident driver, the REBOOT file forces a system reboot when the changeident driver terminates.

Conclusion

The changeident application is limited only by your imagination and system needs. The backbone of changeident is a template that facilitates using plug-and-play program modules for solving your particular system identity problems.

References

Transport Interfaces Programming Guide, 1998, Palo Alto, CA: Sun Microsystems, Inc.

For an extensive collection of Sun/Solaris documentation, visit the Sun Product Documentation Web page at: http://docs.sun.com

John Spurgeon is a software developer and systems administrator for Intel's Factory Integrated Information Systems, FIIS, in Aloha, Oregon. Outside of work, he enjoys turfgrass management, triathlons, and spending time with his family.

Ed Schaefer is a frequent contributor to Sys Admin. He is a software developer and DBA for Intel's Factory Integrated Information Systems, FIIS, in Aloha, Oregon. Ed also edits the monthly Shell Corner column on UnixReview.com. He can be reached at: shellcorner@comcast.net.