Kernel Configuration Example

In this example, the system administrator, Susan, is setting up a new HP-UX system to run a database server called Prophet. It has just finished booting after the initial install.

The first thing Susan does is save a copy of the initial kernel configuration, in case she needs it later. She puts comments on all of her changes (with -C). She also puts a title on the saved configuration (with -t) to remind herself of what it contains.

The document for Prophet tells Susan to set the maxdsiz tunable to at least 0.5 TB, to set the semmni tunable to 3000, and to add 50 to whatever value she’s using for shmmni. She also decides to add 1000 to the current value of nproc. Susan starts by looking at the current values of these tunables, and the descriptions of the ones she’s unfamiliar with.

Having done that, she sets the values as directed. She sets them all on the same command line so that they will all take effect at the same time. Since one of the changes cannot be made immediately, all of the changes are held for next boot.

Susan also decides to remove an unused LAN driver. First, she verifies which drivers are currently in use.

Then she verifies that the modules are installed.

Finally, she removes the iether driver.

Since iether is static, a new kernel is built, and marked for use at next boot.

Susan checks a summary of all of her changes that will take effect when she reboots.

Satisfied, she reboots.

After the reboot, Susan verifies the configuration status.

Then, she saves the new kernel configuration under the name good, so that she can go back to it, if needed. She gives it a title to help recognize it later.

After some time, one of her users asks her to increase the size of the buffer cache, hoping to speed up the application. She complies — after all, it doesn’t need a reboot, so she can do it without disturbing anyone. Since it’s the first change after a boot, the system asks whether to make automatic backups.

It’s a good thing she said yes. The larger buffer cache actually slowed things down — but all she has to do is restore the automatic backup.

While Susan is on vacation, her colleague, Fred, decides to use the machine for billing software during the night. This software needs to execute code on the stack (a security risk), so he enables that behavior (which is prohibited by default). No reboot is needed to do so.

The billing software also uses the kernel Random Number Generator module. Fred checks and sees that it’s not in use, but since it’s loadable he doesn’t need to reboot to use it.

He goes ahead and loads the module.

Fred saves these new configuration settings under the name night, with a descriptive title.

Since good isn’t a very helpful name for Susan’s configuration anymore, Fred renames it to day. He checks the list of configurations to make sure everything looks OK.

Finally, he tries loading first the day configuration, and then the night configuration, to make sure he can move back and forth at will.

When Susan returns from her vacation, the first thing she does is check the automatically maintained log file to see what Fred has done.

She can see that Fred has put a new application on her server, and worse, an insecure one. At least he tested and documented his changes.

Susan doesn’t want to leave her system the way Fred changed it, so she moves the nightly billing job to another system. First, she exports his night configuration to a text file.

Moving the file over to another machine, she imports the configuration there, using the -V option to ensure that exactly the same kernel software is in use. Then she loads the configuration. Something about the configuration can’t be changed immediately — probably a tunable setting — so she has to reboot the machine. As intended, the machine uses Fred’s night configuration when it comes back up.