Upgrading the kernel
We’ve seen in an earlier section how the Red Hat kernel is split into sections and how the GRUB needs to know about some of them. In this section we are going to look at upgrading these components as there are some extra wrinkles over and above a usual package upgrade.
/boot/
/lib/modules/version/ /boot/grub/grub.conf
Slide 183: Files relevant to Red Hat’s kernel
Kernel packages
First let’s look at the packages that form the installed kernel. The first thing we discover is that we have an unnecessary package:kernel-source. We’re not about to build kernels in this course nor do we need PCMCIA cards and we might as well simplify the upgrade procedure as much as possible.
# rpm --query --all | grep kernel- kernel-pcmcia-cs-3.1.31-13
kernel-source-2.4.20-8 kernel-2.4.20-8
# rpm --erase kernel-source kernel-pcmcia-cs
# arch -k i686
# mount -o ro nfs-uxsup.csx.cam.ac.uk:/linux/redhat /redhat # cd /redhat/updates/9/en/os/i686
# ls kernel-*
kernel-2.4.20-24.9.i686.rpm
kernel-bigmem-2.4.20-24.9.i686.rpm kernel-smp-2.4.20-24.9.i686.rpm
Slide 185: Upgrading Red Hat’s kernel—1
# cd /redhat/updates/9/en/os/i386 # ls kernel-* kernel-2.4.20-24.9.i386.rpm kernel-BOOT-2.4.20-24.9.i386.rpm kernel-doc-2.4.20-24.9.i386.rpm kernel-source-2.4.20-24.9.i386.rpm
Slide 186: Upgrading Red Hat’s kernel—2
Locating the relevant packages
You will also recall from the RPM section that the kernel packages are some of the few where there are different versions for i386, i486 and so on. We can determine the architecture of our system with the command “arch -k”. Red Hat have started to split their updates according to kernel architecture. The result is a confusing mess of directories, but the most recent versions of the packages that depend on kernel architecture have moved to a directory of their own, calledi686in our case. The header files, however, are generic across all Intel platforms so are in thei386directory.
We must identify just the kernel packages that match our installed set and select the relevant kernel architecture where there is a choice. The “-smp-” set are the “Symmetric Multi-Processing” kernels. These are only suitable for systems with multiple CPUs. The “-bigmem-” kernels are compiled with support for more than 4GB of RAM and need not concern us.
If we examine the packages we see that the actual kernel package has the kernel version wired into every file path. This is to support the installation of multiple versions of the kernel. We will exploit this feature to install an extra kernel alongside the original. We also note that there can be dependencies between the kernel and other packages though they will not affect us here.
And finally!
# cd /redhat/updates/9/en/os/i686
# rpm --install kernel-2.4.20-24.9.i686.rpm
Slide 187: Upgrading Red Hat’s kernel—3
Installing the new RPMs
Note that we do not do an upgrade. We are installing a new kernel alongside the existing kernel. An upgrade would have left us without the old kernel.
/boot: Files added to. Symbolic links changed.
/lib/modules: New subdirectory.
/boot/grub/grub.conf: Manual change needed.
Slide 188: Booting off the new kernel
Changes made
The installation has made several additions to the software installed. The “new” kernel sits alongside the original in
/bootand/lib/modules, but the three symbolic links in/boothave been changed to point to the most recently installed kernel:
vmlinuz module-info System.map
Note that if we reboot at this stage we still get the old kernel because the GRUB has the old kernel’s parameters wired into it as the default. (See/boot/grub/grub.conf.) It has the linedefault=1which refers to the second entry in the file (the first being number 0, of course) which boots the old kernel. We neeed to change this.
default=1 timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz title Red Hat Linux (2.4.20-24.9)
root (hd0,0)
kernel /vmlinuz-2.4.20-24.9 ro root=LABEL=/ hdc=ide-scsi initrd /initrd-2.4.20-24.9.img
title Red Hat Linux (2.4.20-8) root (hd0,0)
kernel /vmlinuz-2.4.20-8 ro root=LABEL=/ hdc=ide-scsi initrd /initrd-2.4.20-8.img
Slide 189: Checking/boot/grub/grub.conf
... default=0 ...
Slide 190: Editing/boot/grub/grub.conf
Fixing the GRUB
To get the GRUB to boot the new kernel we need to change its configuration file. Changing thedefaultline is all that is needed. Out of paranoia we do not remove the ability to boot off the old kernel. The new instruction block is the same as the old one was but with the version number updated.
Boot off the original Red Hat 9 kernel.
Now make the original 9 kernel the default again.
7
Service configuration
Continuous?On demand? Periodic?
Slide 192: Types of service
Types of service
The various services provided on a Unix system can be categorised in a number of ways: They can be network services or purely internal services. They can be continually running, run on demand or run at regular intervals. Finally, they can be subtle services whose absence you don’t notice for weeks or unsubtle services whose absence has an immediate impact.
From the administrative point of view of this course, the way the processes run and the corresponding ways they are launched is the most important categorisation.
7.1
Continually running services
sshd—Secure logins
gpm—Mouse handler
syslogd—Logging service
xinetd—Launcher of on-demand network services
crond—Launcher of periodic services
portmap—Lookup service for RPC services
Slide 193: Examples of continually running services
Simple service daemons
The simplest daemons to consider are the simple daemons that sit around waiting to do something. These are typically launched from a startup script in the directory /etc/init.d. (This is actually a symbolic link to
/etc/rc.d/init.d, but the former is more standard and Red Hat are moving towards using the standard di- rectory. As the first stage in this migration they have put in this symbolic link.) There are two aspects of the configuration of these services: whether they should be run at all and how they should run if they are. The latter depends greatly on the nature of the service itself. The former has a uniform solution provided by thechkconfig
#!/bin/bash #
# chkconfig: 2345 85 15
# description: GPM adds mouse support to text-based Linux ... \ # the Midnight Commander. Is also allows ... \ # cut-and-paste operations, and includes ... \ # menus on the console.
# processname: gpm
# pidfile: /var/run/gpm.pid # config: /etc/sysconfig/mouse
Slide 194: The comments at the top of/etc/init.d/gpm
Thechkconfigprogram
Each service start up file has (or at least should have) some lines of structured comment at the top. See slide 194 for the example of the startup script for thegpmmouse handling daemon.
The directly pertinent line is
# chkconfig: 2345 85 15
which says that the defaults for the service are that it should be run in runlevels 2, 3, 4 and 5 and that its startup scripts for those runlevels should be prefixed by “S85”. For the remaining runlevels its shutdown script should be prefixed by “K15”.
The other lines provide hints for future, more comprehensive system service manipulation programs.
Thechkconfigprogram provides the main tool for changing the set of runlevels a service runs in, and for listing what services run when. The output comes in two distinct halves. The first half describes the constantly running services which we are describing here. The second half describes the “on demand” services and whether they are available. These will be covered later.
# chkconfig --list
kudzu 0:off 1:off 2:off 3:on 4:on 5:on 6:off syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off ...
httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off xinetd based services:
chargen-udp: off rsync: off
...
# chkconfig --list gpm
gpm 0:off 1:off 2:on 3:on 4:on 5:on 6:off # ls -l /etc/rc?.d/*gpm lrwxrwxrwx ... /etc/rc0.d/K15gpm -> ../init.d/gpm lrwxrwxrwx ... /etc/rc1.d/K15gpm -> ../init.d/gpm lrwxrwxrwx ... /etc/rc2.d/S85gpm -> ../init.d/gpm lrwxrwxrwx ... /etc/rc3.d/S85gpm -> ../init.d/gpm lrwxrwxrwx ... /etc/rc4.d/S85gpm -> ../init.d/gpm lrwxrwxrwx ... /etc/rc5.d/S85gpm -> ../init.d/gpm lrwxrwxrwx ... /etc/rc6.d/K15gpm -> ../init.d/gpm
Slide 196: Listing just one service
Listing all services
Thechkconfigprogram has a--listoption which will list all the services managed through the startup scripts. Next to each it will list whether or not the service is run in runlevels 0 to 6. See slide 195 for an example.
Alternatively it can be given the name of a service to list and will produce a single line of output for that service. (It cannot be passed multiple service names, unfortunately.)
# chkconfig --list gpm
gpm 0:off 1:off 2:on 3:on 4:on 5:on 6:off # chkconfig --level 24 gpm off # chkconfig --list gpm
gpm 0:off 1:off 2:off 3:on 4:off 5:on 6:off # ls -l /etc/rc[24].d/*gpm
lrwxrwxrwx ... /etc/rc2.d/K15gpm -> ../init.d/gpm lrwxrwxrwx ... /etc/rc4.d/K15gpm -> ../init.d/gpm
Slide 197: Changing when thegpmservice is launched
Changing when a service runs
We can also usechkconfigto change the set of startup/shutdown symbolic links in a controlled manner. If we wanted to stopgpmbeing launched in runlevels 2 and 4 we can callchkconfigwith the--leveloption as shown in slide 197.
Note that this changes the scripts run at the next shutdown and startup. If you are already running the runlevel you are changing you need to manually startup or shutdown the service to bring the running system into line with the new set of startup scripts.
# ps -ef | grep gpm | grep -v grep
root 1105 1 0 Nov04 ? 00:00:00 gpm -t imps/2 -m /dev/mouse # runlevel
3 5
# chkconfig --level 3 gpm off # ps -ef | grep gpm | grep -v grep
root 1105 1 0 Nov04 ? 00:00:00 gpm -t imps/2 -m /dev/mouse # /etc/init.d/gpm stop
Shutting down gpm mouse services: gpm # ps -ef | grep gpm | grep -v grep #
Slide 198: Turning off a service in the current runlevel
service httpd start = /etc/init.d/httpd start service httpd restart = /etc/init.d/httpd restart service httpd status = /etc/init.d/httpd status service httpd stop = /etc/init.d/httpd stop
Slide 199: Theserviceprogram: Syntactic sugar for start-up scripts
Services that launch services
Two of these permanently running services deserve special attention. The “crond” is designed to start services periodically. These are used to perform routine system maintenance, etc. The “xinetd” listens to the network on behalf of a range of services. When a query comes in for a particular service thenxinetd starts up that service for this particular query, connects the network connection to this newly started service and then waits for the next incoming connection.