A Few X−Related Commands

ls −li etcinit.d | grep dtlogin 203657 −rwxr−−r−− 4 root sys 2613 Jun 26 1998 dtlogin ls −li etcrc2.d | grep dtlogin 203657 −rwxr−−r−− 4 root sys 2613 Jun 26 1998 S99dtlogin ls −li etcrc0.d | grep dtlogin 203657 −rwxr−−r−− 4 root sys 2613 Jun 26 1998 K10dtlogin On HP−UX platform 9.0x, 10.10, 10.20, 10.30 … the start procedure is the same, except the other file name and locations are used, and symbolic links are implemented: ls −l sbininit.d | grep dtlogin −r−xr−xr−x 1 bin bin 3002 May 30 1998 dtlogin.rc ls −l sbinrc3.d | grep dtlogin lrwxr−xr−x 1 root sys 23 Jun 10 1998 S990dtlogin.rc − sbininit.d dtlogin.rc ls −l sbinrc2.d | grep dtlogin lrwxr−xr−x 1 root sys 23 Jun 10 1998 K100dtlogin.rc − sbininit.d dtlogin.rc • The HP flavor of X, VUE, is started through the etcinittab file: vue:34:respawn:usrvuebinvuerc • On SunOS 4.1.x the etcrc.local script is used; a typical sequence to start the xdm was: if [ −f usrbinX11wdm ]; then usrbinX11xdm; echo −n XDM fi • On IRIX platform etcinittab is used; here is an example with the xdm: xw:23:respawn:usrbinX11xdm −nodaemon • On AIX platform the etcrc.tcpip script is used; for example, an entry to start the xdm looked like: start usrbinX11xdm src_running •

22.5.3 A Few X−Related Commands

X is an extremely rich environment, that offers users a lot. Once users become familiar with X, it is hard to believe they would be eager to return to the character−based world. Advantages and benefits of using X are enormous, and this session should encourage administrators to bring X to life on their systems. Programmers and developers should seriously consider the X environment for their new projects; everybody could only benefit from an X implementation. Besides a nice and friendly environment, X also brought many new, powerful, and versatile utilities commands that could be efficiently used, especially for script programming, to make scripts more powerful and productive. We will list a few X−related commands; readers are encouraged to browse the manual pages for more information, as well as for other X commands. xwd The utility to dump an image of an X window. It allows storage of window images in a specially formatted dump file that could later be read by other X utilities for redisplay, printing, editing, formatting, archiving, image processing, etc. xwud The X image displayer. The utility undumps and displays in a window an image saved in a specially formatted dump file produced by xwd. xpr 565 The xwud is a complementary utility to the xwd. The two utilities could be combined in a very attractive way. For example, we can use xwd to dump save an X image at an X display into a file, and then launch the saved X image by the xwud to another X display. In that way, it is possible to monitor X users by scanning dumping their screens and display the dumped images at the administrators screen. By involving xpr, printouts are also possible. By presenting these X utilities, we will close our session dedicated to X11. After quite a long discussion, and many real−life examples, we should be ready to enter successfully into the X administration arena. 566

Chapter 23: Kernel Reconfiguration

23.1 Introduction to Kernel Reconfiguration

The UNIX kernel is the part of the UNIX operating system that manages the system hardware. Kernel presents control software between OS and the underlying hardware, merging all system devices into a functional OS controllable system. Kernel remains memory resident while the system is up; otherwise a system would behave very poorly. We have already talked about the kernel in Chapter 4 when we discussed system startup. Then we learned that the executable image of the kernel is invoked after a bootstrap program execution and it continues to run at all times. Now, we return to this topic to elaborate the duties of the system administrator regarding the kernel. The kernel is a site−dependent, memory resident executable program; this means the kernel must be appropriately configured for a particular UNIX system implementation. Each installed UNIX system also has a configured kernel; this is usually a generic kernel compliant for most system implementations. However, site−specific conditions and a special system mission could require different, more appropriate kernel configuration. Then we have to change an existing kernel, and we talk about kernel reconfiguration. Generally, reconfiguring the kernel means to create, or to modify, an appropriate kernel configuration file, which defines the kernel correspondingly. In most cases it also means to compile a reconfigured kernel afterward. All changes in a kernel become effective upon rebooting the system, because the newly configured kernel could be invoked only at the next system startup; there is no way to change an actual memory resident kernel image. As a matter of fact, a kernel reconfiguration presents a routine procedure defined by UNIX designers that an administrator should strictly follow. There is not a lot of freedom in implementing this procedure; the existing rules must be fully respected, or our kernel reconfiguration will fail. A failed kernel also means a sick UNIX system, sometimes even a not−bootable one. An administrator must know how to handle such situations; a full understanding of this procedure is very instrumental in doing this successfully. It raises a crucial question, how to bring the system back from a bad kernel to the previously workable one. We must always be prepared for the worst−case scenario. BSD and System V have very different kernel configuration files and reconfiguration procedures. Also, within each of these two UNIX platforms, significant variations exist among different vendors. That is why it is probably more appropriate to talk about vendor−flavored kernel reconfiguration. Nevertheless, we will try to keep continuity with earlier chapters — partially by following this topic historically, and partially by elaborating on the dominant modern UNIX flavors. The nature of a kernel makes it almost impossible to create a universal kernel applicable to any situation. Different hardware configurations require different kernel configurations, and some trade−off must be found. Some systems are shipped with a minimal kernel, so changes may be needed when new hardware or software is added. Usually when new software is installed, the kernel changes, if required, are performed automatically by the installation procedure. This is also the case when OS patches are implemented if the patches are kernel related. In both cases, to become effective, a system reboot is required after implementation.

23.2 Kernel Configuration Database

Both UNIX platforms, BSD and System V, use the kernel configuration files to specify and keep configuration data. Traditionally the configuration data had to be compiled into the kernel binary for 567