What happens when you boot? What happens when you shut down the machine
The first process that Linux kicks off once the kernel has entered memory and the root (/) partition is mounted is init. The init process is always process 1. Killing this process will do the same thing as running halt or shutting down The advantage to the Red Hat startup method is that it's the same as other commercial operating systems (OS) such as Solaris 2.
The LILO program allows you to select a boot partition for your system. If you have multiple operating systems (Linux, Windows 98, NT, etc.) all on different partitions and want to choose one to boot, LILO will let you do this.
In addition, LILO allows you to send boot parameters to the kernel before it starts up, much as the Sun architecture allows you to send boot parameters to Solaris. For example, you can specify the root drive and what devices you have installed, and pass instructions to the init command.
When you start your machine up after installing Linux, you will probably have the LILO: prompt awaiting your command. At this point, you can choose to boot whatever operating systems were configured previously (Linux or DOS, for example). If you're starting something like DOS or Windows 95, there isn't much you need to worry about, and you can just type in DOS, Win95, or however you configured LILO when it was installed. If you forget, you can press the TAB key to see a list of what operating systems LILO knows about and will boot.
If you're starting Linux, there's a bunch of configuration parameters you can add to the end of the name you use to start Linux. For example, let's say that we configured the startup name to be linux.
root=partitionThis signals Linux to use a different root partition than what is configured in the kernel. When you build Linux on one system, it assigns a default of what the current root partition is. For example, if you build a Linux kernel on an SCSI-based machine with the root partition on the first drive, first partition, Linux will assign the boot device to be
/dev/sda1. If you were to put this kernel on a floppy drive and use it to boot an IDE-based system, it would not boot correctly since there is no SCSI system to boot off of. Addingroot=/dev/hda1, for example, would tell the kernel to boot off of the first IDE drive, first partition. So, the same kernel can be used for multiple systems.[1]roThis signals Linux to mount the root filesystem in read-only mode. No changes can be made to the filesystem when in read-only mode. The advantage is that the startup scripts can perform a filesystem check (
fsck) to verify the integrity of the filesystem. Iffscksucceeds, the root partition is mounted read-write and normal bootup continues. If there is a problem withfsck, the partition remains in read-only mode and the administrator will have to either do a manualfsckor reload from tape if the problem is severe. Read-only mode is used by default, so it would be rare for you to need this flag.rwThis signals Linux to mount the root filesystem in read-write mode, as opposed to read-only mode (see above). This is dangerous, since a filesystem check of the root filesystem cannot be performed.
mem=Some BIOSes won't recognize above 64MB of RAM in your system. Since Linux needs the BIOS to tell it how much memory is installed, systems with more than 64MB of RAM will be incorrectly reported. The
mem=option tells Linux to ignore the BIOS and to determine how much memory there is. You can either use a hexadecimal address (mem=0x1000000, which is 16MB) or a number followed bykor M (16384k or 16M).NOTE: If you lie here and tell Linux you have 128MB when you really have only 64MB, it will crash at some point. Also, due to paging and some BIOS settings, you may not have the full amount of memory accessible to your system. Check your BIOS or motherboard documentation for how much memory is used.
Additionally, the Linux 2.2 kernel is better at recognizing more than 64MB on most motherboards. We leave this just in case you need to use it.
debugKernel hackers may want to use this when booting experimental kernels. Kernel messages are sent to the screen instead of being sent to disk or to the
syslogfacility. Most users may not need this.init=Specifies what program to boot as the
initprogram. Normally, the kernel looks for/sbin/init, then/etc/init, then gives up and runs/bin/sh. This way, if theinitprogram is corrupted, you can still get into the system.panic=Whenever your kernel panics, it normally waits for the administrator to come by and physically press the power or reset switch. Setting this option will allow the kernel to try to reboot
xseconds after a panic. For example, a setting ofpanic=60will have the kernel try to reboot 60 seconds after a panic.vga=LILO has the ability to change VGA video modes from the standard 80x24 to other modes, such as 80x50 or 132x44. A setting of
vga=askwill provide a list of video modes and allow you to choose when it boots. Users of the 2.2 kernel can use this to select a graphical display if they're using the new Frame Buffer drivers (also known as FBcon). More documentation on Fbcon can be found in the Linux Kernel drivers under/usr/src/linux/Documentation.
If you need to configure SCSI, CD-ROM, Ethernet, and other controllers, there are a number of options to tell the kernel that you have a controller on a non-standard IRQ or I/O address, or if Linux for some reason is not probing the right IRQ or I/O address for your device. The most common is Linux not recognizing some IDE CD-ROM drives. This can be fixed by explicitly adding hdb=cdrom to the LILO boot config. This tells Linux that the second IDE device is really a CD-ROM drive. The rest of the options can be found in the LILO documentation or the BootPrompt HOWTO.
Once you have Linux started the way you want, there is a way to have LILO add your favorite options each time you boot. The /etc/lilo.conf file contains information that LILO uses each time it starts. This is where the operating systems you want to boot are configured. Here's a sample lilo.conf file:
# Tell LILO to install itself as the primary boot loader on /dev/hda
boot = /dev/hda
# The boot image to install; you probably shouldn't change this
install = /boot/boot.b
# The stanza for booting Linux
image = /vmlinuz # The kernel is in /vmlinuz
label = linux # Give it the name "linux"
root = /dev/hda2 # Use /dev/hda2 (first drive, second partition)
# as the root filesystem
vga = ask # Prompt for VGA mode
append = "hdc=cdrom" # Tell Linux that the third IDE drive is
# really a CD-ROM
mem=160M # This BIOS does not correctly report how
# much memory the machine has.
#The stanza for booting MS-DOS
other = /dev/hdb1 # This is the MS-DOS partition
label = msdos # Give it the name "msdos"
table = /dev/hdb # The partition table for the second drive
In the above setting, the first section (the boot and install lines) configures LILO itself. The boot line tells LILO where to install. Since it's the first drive, LILO gets configured as the primary bootloader. If you have another bootloader such as the OS/2 bootloader or System Commander, you can configure LILO to use the Linux root partition to be a secondary bootloader. In this case, set the boot line to be the root partition of Linux. In the above case, that would be /dev/hda2. You could also take out references to other operating systems, since the primary bootloader would handle booting to other operating systems.
The section for Linux handles many of the configuration options mentioned in the previous section. The label, root partition, VGA setting, and CD-ROM are all configured. Once you choose a VGA mode that suits your needs (you'll enter a number for a video mode), you can replace the ask parameter with this number. One important line here is the image section. This line tells LILO which file to boot. Some Linux installations configure the kernel to be in the root partition (/) and some put the kernel in the /boot directory. You should be sure which setting you want to use when configuring LILO. A feature of the image line is you can boot multiple versions of the kernel all using the same Linux installation. For example, if you're developing new kernels and want to have a safe kernel around that you know boots correctly, you can create a "safe" entry in LILO. Its configuration would look something like this:
# Create a safe entry for Linux. I know this kernel works. image = /boot/vmlinuz.safe # Boot this file. Make sure it exists! label = safe # The label for this is "safe" root = /dev/hda2 # Specify the root partition just in case vga = ask # Not really needed, but helpful append = "hdc=cdrom" # Make sure Linux knows about the CD-ROM
In the event that a kernel you build doesn't work correctly and you are unable to boot it, you can just enter safe in the LILO prompt and boot the older kernel. Note that this will not help if there is some problem not related to the kernel, like a hardware failure or serious partition corruption.
Once the /etc/lilo.conf file is configured to your liking, you can run the /sbin/lilo command as root to install the configuration file. The next time you boot the machine, you should see the LILO boot prompt. If at some future time you need to remove LILO from your system, you can do this from DOS (and presumably Windows 98 as well) with the fdisk /mbr command. This tells fdisk to reinstall the MBR to the first partition of the first drive.
The rdev command allows you to change parameters without using LILO. For example, you can use the dd command to put a Linux kernel on a diskette, then move it to another machine to boot. To change the root partition, just use the following command:
rdev kernel root
where kernel is the kernel file and root is the new root partition to use. If the kernel is on a floppy diskette (you used dd to put it there or make floppy when compiling the kernel), the command would look like this:
rdev /dev/fd0 /dev/hda1
This would configure the kernel file on /dev/fd0 (the floppy diskette) to change its root partition to use /dev/hda1 instead of the default. For a list of other features that rdev has, use the rdev -h command.
While the kernel is starting up, you'll see a series of messages flying across the console. Most of these messages you can catch, due to the delay while the next driver initializes. If you miss something, the dmesg command will list all the kernel messages since and during boot time.
Here's an example of what the boot messages look like on an AMD K6-233 machine with an Adaptec 2930 SCSI card, 3c503 Ethernet card, and an IDE hard drive. This is the standard kernel for Red Hat 6.0:
Linux version 2.2.5-15 ([email protected]) (gcc version egcs- 2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Apr 19 22:21:09 EDT 1999 Detected 233867589 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 466.94 BogoMIPS Memory: 62816k/65536k available (996k kernel code, 412k reserved, 928k data, 60k init) VFS: Diskquotas version dquot_6.4.0 initialized CPU: AMD AMD-K6tm w/ multimedia extensions stepping 02 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking `hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xf0430 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP Initializing RT netlink socket Starting kswapd v 1.5 Detected PS/2 Mouse Port. Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A pty: 256 Unix98 ptys configured apm: BIOS version 1.2 Flags 0x03 (Driver version 1.9) Real Time Clock Driver v1.09 RAM disk driver initialized: 16 RAM disks of 4096K size PIIX3: IDE controller on PCI bus 00 dev 39 PIIX3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xe800-0xe807, BIOS settings: hda:DMA, hdb:pio hda: Maxtor 90576D4, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: Maxtor 90576D4, 5495MB w/256kB Cache, CHS=700/255/63 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12 raid5: measuring checksumming speed raid5: using high-speed MMX checksum routine pII_mmx : 386.715 MB/sec p5_mmx : 362.331 MB/sec 8regs : 344.043 MB/sec 32regs : 246.126 MB/sec using fastest function: pII_mmx (386.715 MB/sec) scsi : 0 hosts. scsi : detected total. md.c: sizeof(mdp_super_t) = 4096 Partition check: hda: hda1 hda2 < hda5 hda6 > RAMDISK: Compressed image found at block 0 autodetecting RAID arrays autorun ... ... autorun DONE. VFS: Mounted root (ext2 filesystem). (scsi0) <Adaptec AIC-7860 Ultra SCSI host adapter> found at PCI 11/0 (scsi0) Narrow Channel, SCSI ID=7, 3/255 SCBs (scsi0) Warning - detected auto-termination (scsi0) Please verify driver detected settings are correct. (scsi0) If not, then please properly set the device termination (scsi0) in the Adaptec SCSI BIOS by hitting CTRL-A when prompted (scsi0) during machine bootup. (scsi0) Cables present (Int-50 YES, Ext-50 NO) (scsi0) Downloading sequencer code... 413 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.15/3.2.4 <Adaptec AIC-7860 Ultra SCSI host adapter> scsi : 1 host. (scsi0:0:0:0) Synchronous at 5.0 Mbyte/sec, offset 15. Vendor: SEAGATE Model: ST31055N Rev: 0532 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 (scsi0:0:1:0) Synchronous at 5.0 Mbyte/sec, offset 8. Vendor: TOSHIBA Model: CD-ROM XM-5701TA Rev: 0167 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 1, lun 0 (scsi0:0:2:0) Synchronous at 5.0 Mbyte/sec, offset 15. Vendor: SEAGATE Model: ST51080N Rev: 0913 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi0, channel 0, id 2, lun 0 (scsi0:0:6:0) Synchronous at 5.0 Mbyte/sec, offset 15. Vendor: QUANTUM Model: FIREBALL_TM1280S Rev: 300X Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdc at scsi0, channel 0, id 6, lun 0 Uniform CDROM driver Revision: 2.54 SCSI device sda: hdwr sector= 512 bytes. Sectors= 2069860 [1010 MB] [1.0 GB] sda: sda1 SCSI device sdb: hdwr sector= 512 bytes. Sectors= 2109840 [1030 MB] [1.0 GB] sdb: sdb1 sdb2 SCSI device sdc: hdwr sector= 512 bytes. Sectors= 2503872 [1222 MB] [1.2 GB] sdc: sdc1 autodetecting RAID arrays autorun ... ... autorun DONE. VFS: Mounted root (ext2 filesystem) readonly. change_root: old root has d_count=1 Trying to unmount old root ... okay Freeing unused kernel memory: 60k freed Adding Swap: 120452k swap-space (priority -1) 3c503.c: Presently autoprobing (not recommended) for a single card. 3c503.c:v1.10 9/23/93 Donald Becker ([email protected]) eth0: 3c503 at i/o base 0x300, node 02 60 8c dd 2b b0, using internal xcvr. eth0: 3c503-PIO, 16kB RAM, using programmed I/O (REJUMPER for SHARED MEMORY). Installing knfsd (copyright (C) 1996 [email protected]). nfsd_init: initialized fhcache, entries=256
There are other messages that will probably display as programs start up. For example, output of things like fsck will not be in a dmesg output. But, messages that will be added to dmesg include changes of CD-ROMs or floppies (VFS disk change detected on device xx:xx) or if modules get loaded (for PPP or the parallel port, for example).
These messages are also stored in the /var/log/messages file, which is the default location wheresyslog stores its messages.
After the boot messages you saw above, you'll see more screens of text as other programs start up. These programs are not started as part of the kernel bootup, but are started by the init program. The init program is always Process ID (PID) 1, and is started automatically by the kernel. This program then starts up the rest of the daemons and other programs.
The/etc/inittab file is read by init, which tells it what init level to start out on and what processes to start. This would include programs like getty (which is what gives you the login prompt on the console). Other scripts are run based on what runlevel you've entered.
An entry in the /etc/inittab file has four fields:
l0:0:wait:/etc/rc.d/rc 0
Colons delimit the above fields. The first field is one unique to the file and is just an arbitrary two-letter (or -digit) sequence. The second field tells init what runlevel to reference this field on. In this case, it's runlevel 0. The third field is an option to init on what to do while the script is running. Since you don't want to cause problems by having multiple runlevel change scripts running at once, init will wait until the script has finished before running any other scripts. Other options include respawn, which will restart the process if it dies or stops (for getty), and once, meaning that the process should be run only once and never again. The fourth field lists the script or process to run. You can see how these scripts work below.
The runlevel of a machine determines what functionality the system should be providing. Just as Windows 98 provides a safe mode, UNIX has a single-user safe mode, plus other configurations available:
| Runlevel | Functionality |
|---|---|
| 0 | Halt |
| 1 | Single-user mode |
| 2 | Multiuser, no NFS |
| 3 | Multiuser, with NFS |
| 4 | Unused |
| 5 | X11 console (xdm, gdm, or kdm)[a] |
| 6 | Reboot |
[a] In Solaris 2.x, runlevel 5 will power down the system. It won't do that in Linux. | |
Two of these runlevels are really for stopping or rebooting the machine. Runlevel 1 allows only root to log in, and only the root partition is mounted. This is primarily for emergency situations where one of the other partitions is corrupted. The default runlevel for Red Hat is 3, which is a typical multiuser system and starts the network filesystem daemons as well. If you're not using NFS, you can use runlevel 2 if you like. Runlevel 5 automatically starts X with a login prompt. Normally, this is the xdm process. Red Hat 6.0 uses the gdm (GNOME Display Manager), but you can change the entry in /etc/inittab to use xdm, gdm, or the KDE Display Manager, kdm.
The first script that gets run by init, no matter what runlevel you're using, is the/etc/rc.d/rc.sysinit script. This script activates swap partitions, checks the filesystem consistency on any partitions it's about to mount, and performs a few other functions we won't worry about yet. In short, the rc.sysinit script runs all the programs that would be required no matter what runlevel you'd be using.
Once the rc.sysinit script completes successfully, init goes on and calls the /etc/rc.d/rc script with an option being the number of the runlevel to enter (0–6). Here's where things get interesting.
Under the /etc/rc.d directory are six directories to look at called rc.[0-6].d. Each directory has a number of scripts that start with a "K" or an "S", a two-digit number, and a program name. The "S" is for start scripts, and they are run when init enters that runlevel. This is for starting up programs that are specific to that runlevel. The "K" is for kill scripts, and they do the reverse of the S scripts, killing any programs that are not in a runlevel. The numbers give order to the apparent chaos, as scripts with a lower number are executed first, allowing the networking software to initialize the Ethernet card before the NFS daemons try to start. In all this, the name is just a descriptive one to the user. Kill scripts are run before start scripts.
As each script starts, Red Hat 6.0 throws in a way of reporting on the success or failure of startup scripts. By default, a message will look like this:
Starting rwho services: [ OK ]
The messages you see will display OK in green. In the event of failure, you'll get FAILED in red, making it easy to spot failures. In some cases, you'll also get an error message to indicate the reason for failure. In previous versions of Red Hat, all you'd get is something like:
Starting rwho services: rwhod
You can change between the two startup modes, and you can edit the /etc/ sysconfig/console file to change the entry BOOTUP=color to BOOTUP=verbose. Changing the BOOTUP to anything else will include the OK and FAILED messages, but without ANSI coloring. This file also contains information on the size of the screen, and ANSI commands to change colors.
All these scripts are links to the/etc/rc.d/init.d directory, which contains the master of all the scripts. This allows one master script to not only control starting and killing processes, but it also allows you to find all the scripts in one location.
You can change your init level on-the-fly using thetelinit command.[2] The telinit command takes only one argument—the runlevel you want to go to. This has to be run as root since you don't want just anyone dropping your system into single-user mode or making it reboot. telinit will handle running all the scripts to kill or start new processes.
There are only a few places in the boot sequence that will cause the kernel to not finish loading (or not load at all). These include the following:
Can't mount the root partition—The kernel may be trying to load a partition other than the one that is really the root. Your kernel may not have the right drivers for the hard drive loaded. This can happen with SCSI drives, where each controller has its own driver. You'll have to boot an older or emergency kernel and fix this.
Can't automatically check the filesystem for errors using
fsck—In this case, the system will give you a warning and drop you into single-user mode. At this point, only the root partition is mounted, and you should usefsckto try to fix whatever damage was done. If you can't fix the partition, you can try to remove it from the list of partitions that get mounted at boot time. If it's a necessary partition, like/or/usr, you may need to restore from backup.The kernel was told to start up in Runlevel 1—Check
/etc/inittabto see what the default runlevel is. It should be 2 or 3. You can go to Runlevel 2 or 3 using thetelinitorinitcommands.Other errors loading drivers—This usually signifies a hardware error, such as a card not being found. In general, if a non-essential card isn't working (Ethernet, sound card, serial port card, etc.), the kernel will still boot. If the card is severely damaged,[3] it can cause the entire motherboard to start to fail. Remove all non-essential cards and try rebooting again.
Bad startup scripts—If a script in
/etc/rc.dis not written correctly, it can cause the system to go into a loop and appear locked up before it gets to the point where you can log in. Note the point where the machine appears to lock up and boot into single-user mode (if possible) or boot an emergency floppy. Once you get access to the system, find the script that is causing trouble and look for any problems. You may want to keep backup startup scripts handy just in case.
To summarize, here are the things you should have ready after installing Linux:
Emergency boot floppy—As part of the installation procedure (see Chapter 2, "Installation" ), you have the option of making an emergency boot floppy.
Root floppy with
fsck,mkext2fs,fdisk, copies of startup scripts, andtaror another program to restore backups—Red Hat includes a rescue diskette on the CD-ROM that you can build in case the hard drives on your system go bad. See below for instructions on how to use the rescue diskette.Known good kernel on the root partition—Use the one used to install the system, if you have it available. It may not have all the drivers, but you will be able to boot.
Screwdrivers and grounding strap—Have these handy, just in case you suspect a hardware problem.
For a proper Red Hat installation, you should have four diskettes handy[4]. Two are for the install (only one disk may be needed), one for the emergency kernel that gets created after installation, and one for the rescue floppy. Using the rescue floppy and the first installation diskette (labeled boot), you can have a Linux system up and running using only the two floppy diskettes. The purpose of this is that it helps you determine where a problem is and fix it without using the hard drive, in case that's your problem. For example, if your root partition fails, you won't be able to use the emergency diskette to boot. But, if you have the boot floppy and rescue disk, you can start the system up and use fsck (which is on the rescue disk) to fix the problem.
Making the rescue diskette is as easy as making boot diskettes. Just enter:
dd if=rescue.img of=/dev/fd0
assuming that rescue.img is in the current working directory. Then, use the boot diskette to start the system. Type in rescue at the LILO prompt. You'll get prompted to insert the rescue diskette and the system will start.
Shutting Linux down is somewhat easier than starting it, since all you need to do is kill off all the available processes and tell the kernel to either stop or reboot the system.
There are a few ways to shut the system down, depending on how and when you want it to happen. The safest way is the following:
The three sync commands tell the system to sync up the internal hard drive cache and the hard drive itself. Anything that has to get written to the hard drive gets done at this time. Why three sync commands? There are varying reasons, but the simplest one is that by the time the last sync is done, the buffers have had time to clear.
There are a few other methods of telling the machine to halt, including kill -9 1 and telinit 0. In typical UNIX fashion, more than one command will work. Red Hat also provides for shutdown using the linuxconf interface. You can read more about linuxconf in the next chapter.
If you choose to reboot the system, you can replace halt with reboot or telinit 6.
All of the above commands are for shutting down the system immediately. If you choose to have a planned shutdown and want to give users time to finish their work and log out in an orderly fashion, you'll want to use the shutdown command.
When shutdown is run, the following options are available:
Once shutdown is started, only root can log in until the machine is rebooted or the shutdown is canceled.
Shutdown is a nice front-end to the init process, since once shutdown has determined that it's time to shut down, it sends a signal to init to change to Runlevel 6 or 0.
If you have a UPS that works with Linux, then you may have the power monitor daemon (powerd) installed. If the power goes off and the UPS activates, it will trigger a safe shutdown in two minutes. However, if the power comes back on during those two minutes, the shutdown will cancel.
You can get a copy of powerd from contrib.redhat.com. It works with a wide variety of UPSes that have serial outputs. You can also enable network support so if you have multiple machines connected to one UPS, they can all shut down in an orderly manner.
Yes, the famed "three-finger salute"—CTRL+ALT+DELETE—will shut down Linux as well, in a pinch. The init process is watching for this and will shut the machine down if it receives this signal. The default setting is to run the reboot command immediately.
If you're in a common lab area and don't want just anyone to be able to reboot a machine on a whim, you can take a line out of /etc/inittab and you're all set. Unfortunately, this doesn't prevent malicious people from hitting the power switch or pressing the reset button. The next section shows how to disable rebooting via CTRL+ALT+DELETE.
During a reboot, a Linux box has very low security. If you're trying to keep a PC safe, the standard architecture makes it very hard to do. The PC can boot an OS (DOS) that can fit on a floppy, plus contain enough programs on it to completely ruin a hard drive. A virus can infect the MBR of a hard drive, which is what Linux needs to boot, or a user can bring their own Linux boot floppy to get root access, mount the hard drive, and start editing the /etc/passwd file.
Additionally, the chance of users hitting the power switch or reset button is always a factor. Running any kind of program remotely on a publicly accessible system is not a good idea, as the system can go down at any time. Here are a few suggestions for keeping a publicly available Linux machine for X86 safe.
Protect the Basic Input/Output System (BIOS)—This is the first thing you need to do, as many of the other protections depend on this. Password-protect access to the BIOS. Most modern ones will allow this. Also, be sure that no one can open the case. Locks are available for many cases. In the event that you forget the password, you can disconnect the on-board battery or make a jumper connection on the motherboard and the BIOS will be set to its default values.
Prevent booting from the floppy drive—Many BIOSes allow you to specify that only the hard drive can be booted first, forcing the computer to go into Linux or another OS on bootup without checking the floppy drive. This will not only prevent booting into DOS, but may also prevent a boot sector virus or two from infecting the hard drive.
Use Linux only—Booting into DOS or Windows can cause trouble, especially if someone intends to harm a computer. Booting into Linux will minimize this risk, since they cannot run any DOS programs.[5]
Don't use LILO unless you have to—LILO can boot off another device if told to (and if you have a Linux boot disk). Putting the Linux kernel on the MBR of the first hard drive can help prevent other OSes from being loaded inadvertently.
If necessary, disconnect the reset and power switches—This may force you to have people nearby who can power-cycle in the event of a crash.
Don't give out the root password—This goes without saying, but just in case. . . it's been said.
Be on guard—These steps will not make your computer bulletproof, but they should help prevent major damage to Linux systems.
Disable
CTRL+ALT+DELETEin/etc/inittab—The line you'll want to look for is probably similar to this:
Once you have your machine secure against reboots, you can set the machine up in a lab for public use.
In this chapter, we covered the following:
LILO is used to start up the kernel. There are a few different ways to install it on your hard drive.
The kernel, on bootup, displays a number of messages regarding the drivers and devices it finds.
Back up your system often, and keep emergency diskettes handy in case of any problems.
The
initprocess is Process 1 (PID=1). Killing it will reboot your Linux machine.Even though the X86 architecture is not very security-conscious, there are steps you can take to secure a Linux setup.
Killing the
initprocess is the same as telling Linux to shut down.
[1] Assuming, of course, that all the drivers that each system needs are installed.
[2] telinit is really just a link to init, so you could use init <number> instead.
[3] Static electricity is one of the quickest ways to ruin a card. Be sure you're grounded before working on the inside of a machine.
[4] If your CD-ROM and BIOS support booting from CD-ROM, you can skip this and just boot from the CD-ROM. You can boot rescue from the CD-ROM as well.
[5] If this is the case, you should also take DOSEMU off the Linux system.