| CONTENTS | |
Your Unix machine can likely talk to a wide collection of hardware: disk controllers and disks (Section 44.4, Section 44.5), CD-ROMs (Section 44.6), ethernet cards (Section 44.8), modems (Section 44.10), sound cards (Section 44.13), and so on. Each device needs its own little piece of software within the kernel, called a device driver. Some device drivers are simple, and some are very complex; some cover multiple devices, and some are specific to one particular piece of hardware.
Many modern Unix platforms use loadable kernel modules for most device drivers, so that drivers can be loaded at run time rather than compiled into the kernel.
Many devices also have user-space tools to configure them, like ifconfig (Section 44.8) for network devices (Section 44.6, Section 44.7), mount (Section 44.9) for disks and so forth.
In this chapter we'll give you the whirlwind overview of devices on Unix. Since there are so many devices and so many platforms, we'll gloss over a lot of details, but hopefully this will give you enough to get started with and a few hints as to where to find more information.
— DJPH
As your Unix machine boots up, it will display a message for each device driver as it initializes. This is a good way to tell what devices your kernel was able to find. The exact output varies, but here is the output for hard drive controllers, hard drives, and network cards from a FreeBSD machine and a Debian Linux machine:
# FreeBSD
atapci0: <Intel ICH ATA66 controller> port 0xffa0-0xffaf at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ad0: 19569MB <ST320430A> [39761/16/63] at ata0- master UDMA66
afd0: 239MB <IOMEGA ZIP 250 ATAPI> [239/64/32] at ata0-slave using PIO3
acd0: CDROM <ATAPI CDROM> at ata1-master using PIO4
rl0: <D-Link DFE-530TX+ 10/100BaseTX> port 0xbc 00-0xbcff
mem 0xefdfff00-0xefdfffff irq 11 at device 4.0 on pci1
# Linux
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: WDC WD307AA-32BAA0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: WDC WD307AA-32BAA0, 29333MB w/2048kB Cache, CHS=3739/255/63, UDMA
Partition check:
hda: hda1 hda2 hda3
rtl8139.c:v1.07 5/6/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html
eth0: RealTek RTL8139 Fast Ethernet at 0xd400, IRQ 11, 00:50:ba:d3:9e:14.
More specifically, in the line:
atapci0: <Intel ICH ATA66 controller> port 0xffa0-0xffaf at device 31.1 on pci0
atapci is the name of the device; 0 is the number of the device (devices are generally numbered sequentially with the first one probed getting the number 0); <Intel ICH ATA66 controller> is the name of the specific driver that successfully attached to this device; port 0xffa0-0xffaf at device 31.1 is physical address information about where this particular device is located; and finally, on pci0 tells us this device is attached to the first PCI bus (since pci is the device name of a PCI bus and 0 is the number assigned to the first PCI bus probed).
Note that in both FreeBSD and Linux, each line gives information about which driver is being used, hardware addresses, and options. Other platforms give similar information during boot. Often if you have a device that's not being recognized, you will see a line in the boot output telling you that a device was found but no driver for it could be found. If you would like more information, you may be able to boot your machine with boot -v from the bootstrap prompt — the BSDs and Solaris support -v. This enables verbose booting, which prints out a lot more information during device probing and may help you understand why a device driver couldn't be found. Linux doesn't have any straightforward way to get verbose information like this, but you can use lspci to show every device on the PCI bus, whether there's an active driver for that device or not.
— DJPH
Generally a Unix kernel is made up of some core, which handles fundamental functionality like virtual memory, and a lot of modules for various devices. A kernel configuration file is used to build a kernel and, on some platforms, a set of loadable kernel modules.
A kernel configuration file has a list of kernel options and then a list of devices and device options. The kernel build process uses this file to determine exactly what to build; this way you can have a kernel that supports exactly the hardware you have in your machine but isn't using any extra resources to support hardware you don't have.
Some example device lines from various kernel configuration files:
# # FreeBSD samples # maxusers 128 options INCLUDE_CONFIG_FILE options INET #InterNETworking device isa device pci device ata0 at isa? port IO_WD1 irq 14 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering # # Linux samples # # Loadable module support CONFIG_MODULES=y CONFIG_MODVERSIONS=y # CONFIG_KMOD is not set # General setup CONFIG_NET=y CONFIG_PCI=y # Block devices CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDEFLOPPY=m # CONFIG_BLK_DEV_IDESCSI is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y
The kernel build process involves setting up an appropriate configuration file for your platform and then using a tool (generally config(8); check the manpage) to create a kernel build setup from the configuration file. Then you simply run make within the kernel build setup and you have a new kernel. Once the new kernel is installed, you reboot the machine, and poof, you're running on a sleek new customized kernel.
To understand how to configure the kernel on your platform, consult the documentation for that platform. Note that many platforms have tools or even GUIs for helping you configure your kernel. For the free Unixes, search the Web. There are extensive HOWTOs available describing how to configure your kernel in excruciating detail.
Linux has a very detailed HOWTO for kernel configuration at http://www.tldp.org/HOWTO/Kernel-HOWTO.html. The short version is that the configuration file mentioned above is stored in the .config file at the top of the kernel source tree (usually /usr/src/linux). Generally you don't have to edit it directly; instead you'd use make menuconfig or make xconfig, again at the top of the kernel source tree, to use the fancy kernel configuration tools.
— DJPH
A physical disk can be divided into smaller blocks, called partitions. Unix disk devices operate on partitions, where each device is a single partition. The simplest configuration is one big partition for the entire disk.
The advantage to having filesystems on separate partitions is that different parts of your operating system are somewhat protected from each other. If your users have filled up /home, programs writing log files in /var aren't affected if /home and /var are separate partitions. If your disk gets corrupted, only the corrupted partition is damaged. The disadvantage is that, in most cases, if you mistakenly allocated too little disk space for a partition, you can't steal space from your /var to give you more room on /home once your system is set up.
On non-PC hardware, partitioning is generally simple enough; use format or disklabel to write a partition table onto the disk. Traditionally, partitions are named with a letter following the device name, for example, /dev/ad0a, /dev/ad0c and so forth. By convention, partition a is for a root filesystem (/), b is for swap space, c represents the whole disk, and so forth. Of course, every current platform changes this in some way. Check the manpages for the various tools mentioned for more details on what to do for your specific platform.
Solaris's disk device naming scheme is /dev/dsk/c?t?d?s?, where each ? is a number. The c is for controller, the t for target (a physical address on the controller), the d for disk, and the s for slice, another concept like partition. In this case, rather than partition c representing the whole disk, slice 2 does. This set of four numbers uniquely identifies a specific partition (slice) on a specific disk. Solaris uses format to manipulate partition tables.
On PC hardware, it's a bit more complicated, because the PC BIOS has a concept of partitions built into its understanding of disks. Unixes like Linux and FreeBSD that run on this hardware need to coexist with this partition table, especially if you want a machine that can dual-boot Unix and Windows. The BIOS understands no more than four primary partitions on each disk, due to the way it addresses partitions. To get around this limitation, one primary partition can be set to be an extended partition, which can then serve as a container for a different partition addressing scheme. Partitions within an extended partition are called logical partitions and have a few restrictions, but they aren't limited to four. The BIOS requires a primary partition to boot; it can't boot from a logical partition.
Linux names the IDE hard drives /dev/hda through /dev/hdd and the SCSI drives /dev/sda through /dev/sdg. Higher letters are possible with extra controllers. The device name itself represents the whole disk, as partition c and slice 2 did above. Linux uses the BIOS nomenclature and uses primary partitions, extended partitions and logical partitions. Primary partitions get partition numbers one through four, and thus partition two on the second IDE disk would be /dev/hdb2. Logical partitions get numbers higher than four. Linux uses fdisk to manipulate partition tables.
FreeBSD calls the BIOS primary partitions slices and doesn't use extended or logical partitions. Its own partitions within a slice are then just called partitions. This has the advantage of allowing a fairly traditional a through h partitioning, which just lives in a particular slice. So the swap partition within the second BIOS slice of the first IDE drive would be /dev/ad0s2b. FreeBSD uses fdisk to deal with slices and disklabel to manipulate partition tables.
As you can see, each platform has its own idiosyncrasies, but each unambiguously defines a scheme for uniquely referring to a particular partition on a particular disk. This lets us decide where we want our filesystems and refer to them in mount commands and in /etc/fstab (Section 44.5).
— DJPH
A filesystem is the scheme used to organize files on the disk. In the Windows world, FAT, FAT32, and NTFS are all filesystems. Various Unixes have their own filesystems with a forest of names: ufs, ext2fs, vxfs, ffs, nfs, mfs, ISO9660 (which most CD-ROMs use) and special filesystems like tmpfs, procfs, and devfs.
Filesystems like ufs (Unix File System), ffs (Fast File System), vxfs (Veritas Extended File System), and ext2fs (Extended File System, Version 2) are simply ways of organizing inodes and bytes with various strengths and weaknesses. nfs (Network File System) is a filesystem for making remote files appear to be available locally. mfs (Memory File System) is a filesystem for ramdisks, that is, file storage in memory instead of on disk. tmpfs (Temporary File System) is a file system often used for /tmp which shares filespace and swap space dynamically. procfs (Process File System) simulates a filesystem, but with process information in it instead of files. (procfs on Linux is different from procfs on the BSDs; FreeBSD has a linprocfs to simulate part of Linux's procfs.) devfs is similar, but for devices instead of processes.
Standard mounts are configured using /etc/fstab (or, on some platforms, /etc/vfstab). fstab is just a list of filesystems that should be mounted, along with where they should get mounted, what type of filesystem each device contains, and any options. My FreeBSD fstab looks like this:
# Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b none swap sw 0 0 /dev/ad2s1b none swap sw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad2s1e /home ufs rw 2 2 /dev/ad0s1f /usr ufs rw 2 2 /dev/ad0s1e /var ufs rw 2 2 /dev/acd0c /cdrom cd9660 ro,noauto 0 0 proc /proc procfs rw 0 0
I have two swap partitions, /dev/ad0s1b and /dev/ad2s1b. My /, /home, /usr, and /var are all separate ufs filesystems, and I have a CD-ROM that can be mounted on /cdrom (but must be manually mounted (Section 44.6)) and a standard procfs. The last two columns determine priority for backups and for being consistency checked by fsck. The ufs filesystems are all fscked, with / first; the rest of my filesystems are types that don't need to be fscked.
On other platforms, the options may be different, and the device names will certainly be different, but the basic gist of fstab will be the same.
Some filesystem types support "soft updates," which changes slightly the way the filesystem writes files out to the disk and can dramatically increase your effective disk speed. Consider looking at the documentation for your platform and turning on soft updates (generally this is done via tunefs).
— DJPH
Removable disks are prevalent in Unix machines; CD-ROMs, DVD-ROMs, Zip disks, and floppies are all removable disks. When a Unix system boots, normal filesystems are all mounted automatically. By definition, removable filesystems may not even be in the machine at boot time, and you certainly don't want to have to reboot your machine just to change CDs.
To do this, you use mount and umount. The -t option allows you to specify the type of filesystem. On my FreeBSD machine, I can mount a FAT-formatted Zip disk with:
# mount -t msdos /dev/afd0s4 /zip
If I've formatted the Zip disk with a BSD ufs filesystem instead, I don't need the -t option, since ufs is the default on FreeBSD, and I would use the BSD partitioning scheme (/dev/afd0c) instead of the BIOS partitions (/dev/afd0s4).
If you use your removable disk regularly, you can add it to your fstab and make this simpler:
/dev/acd0c /cdrom cd9660 ro,noauto 0 0 /dev/afd0c /zip ufs rw,noauto 0 0 /dev/afd0s4 /mszip msdos rw,noauto 0 0
Note that I've set up my fstab for both ufs-formatted and FAT-formatted Zip disks, and that the Zip drive and the CD-ROM are both set noauto to keep them from being automatically mounted. Having these in my fstab means I can just type mount /zip or mount /cdrom to mount a Zip disk or CD-ROM. Don't forget to create the directories /cdrom, /zip, and /mszip!
Generally the mount and umount commands must be run as root. However, you'd often like normal users to be able to mount and unmount removable disks. Linux has an easy way to do this: just add user to the options field in /etc/fstab and normal users will be able to mount and unmount that device. (Incidentally, Linux also has an auto filesystem type, which is very handy for removable devices, because it does its best to dynamically figure out what filesystem is on the removable media.) On other platforms, it can be a little more complex. Generally, the trick is to set the permissions on the device file properly. On FreeBSD you also need to use sysctl to set vfs.usermount, which will allow users to mount properly chmoded devices on directories they own; similar tricks may be needed on other platforms. To set the floppy drive to allow anyone to mount it and the CD-ROM to allow anyone in the cdrom group to mount it, you'd do something like this:
# chmod 666 /dev/fd0 # chgrp cdrom /dev/acd0c # chmod 640 /dev/acd0c
Then, as a normal user in group cdrom, you could:
% mkdir ~/cdrom % mount -t cd9660 /dev/acd0c ~/cdrom
Solaris has a daemon, vold, which handles all of the messy details of removable media for you. At the time of this writing, very current versions of Linux have automount daemons and devfsd to handle such things; check your platform's current documentation.
— DJPH
Some platforms provide the capability to mount a file as if it were a block device (like a disk partition (Section 44.4)). This allows mounting a file as if it were a hard disk, CD-ROM, or any other physical media. The primary advantage to this is that it's a simple way to create or work with a floppy, Zip, or CD-ROM image without needing the physical device. You can mount a CD image without having to burn an actual CD or manipulate a floppy boot image. Of course, different platforms call it different things and use different tools.
Mounting file images on Linux uses the loop device and is called a loop mount or a loopback mount. To mount an existing image as a filesystem, use the loop option to mount:
% mount -t iso9660 -o loop image.iso /mnt % ls /mnt
To create a new image, you first create an empty file of the correct size (this is effectively creating a partition (Section 44.4) — in this case, a 100 megabyte image. You then attach the image to one of the available loop device and use mkfs to create a new filesystem in the image. Then you can mount the image normally. In this example, we'll release the loop device we had to allocate specifically and let the mount find an available loop device automatically.
% dd if=/dev/zero of= image.file bs=1k count=100000 % losetup /dev/loop image.file % mkfs -c /dev/loop 100000 % losetup -d /dev/loop % mount -o loop image.file /mnt
FreeBSD has a similar capability, called vnode disks, with very similar syntax, but you use /dev/vn instead of /dev/loop and vnconfig instead of losetup. See FreeBSD's vnconfig(8) manpage.
Solaris also has loop devices as of Solaris 8. The device is /dev/lofi instead of /dev/loop, and you use lofiadm to configure it. See Solaris's lofiadm(1M) and lofi(7D) manpages.
FreeBSD and Solaris don't provide an equivalent to the loop option to mount; instead you just use vnconfig or lofiadm to explicitly associate a particular block device with the file and mount the specific block device just like any other device.
— DJPH
ifconfig is used to configure network devices such as Ethernet cards. While booting, the kernel will find a device driver for the actual device, but it will still need to be assigned an IP address, and any protocol options need to be configured. Various platforms have different ways to store this configuration information, but most use ifconfig somewhere in the startup scripts to do the actual work.
The primary use of ifconfig is to set up a network device to use a particular IP address. ifconfig can also be used to set network options and aliases. To bring up an interface (in this case, rl0) on 192.168.1.1 with normal settings for a /24 network:
# ifconfig rl0 inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up
To temporarily bring a network interface down and then back up later, something that can be useful for maintenance:
# ifconfig rl0 down # ...maintenance operations... # ifconfig rl0 up
— DJPH
Network filesystems provide the illusion that files on a remote host are on your disk. Except for mounting and unmounting such a filesystem and but for a few low-level details, they can be treated like any local filesystem, albeit on a very slow disk. The two most common network filesystems available on Unix platforms are the Network File System (NFS) and Server Message Block File System (SMBFS).
NFS has been around for a long time and is available on every Unix system I've seen in the past ten years. Its interface is simple: an NFS server has a set of exported filesystems (usually listed in /etc/exports), and any permitted client can mount those filesystems using a straightforward mount invocation. Simply specify host:/filesystem as the device, and tell mount that the filesystem is of type nfs:
# mount -t nfs orange:/home /orange
For more details on NFS on your platform, take a look at the manpages for exports(5) and mount_nfs(8) or nfs(5).
NFS mounts can hang up entirely if the NFS server goes down or if you lose your net connection to it. Often this can require rebooting your machine to fix. To avoid this, use the soft option when mounting NFS filesystems. soft tells the NFS client system to use timeouts, so that losing touch with the NFS server just causes I/O requests to time out instead of hanging your machine.
|
SMB is the primary file and printer sharing protocol used by Windows. Chapter 47 details Samba, the primary tool used to deal with SMB on Unix systems. smbfs is the tool used to mount SMB-shared filesystems (including Windows shared drives and the like) as if they were Unix filesystems. Much like NFS, smbfs allows you to use mount; in this case, you provide the share name as the device:
# mount -t smbfs //yellow/Public /yellow
smbfs is only supported on some platforms; check your installation of Samba for details.
Note that both filesystem types can be included in /etc/fstab, just like any other filesystem:
# Device Mountpoint FStype Options Dump Pass# /dev/ad0s1b none swap sw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/acd0c /cdrom cd9660 ro,noauto 0 0 orange:/home /orange nfs rw 0 0 //yellow/Public /yellow smbfs rw 0 0
— DJPH
The word "modem" is a contraction of "modulator-demodulator." The fundamental job of a modem is to turn a digital signal into an analog signal and send that analog signal across a phone line (modulation) and to receive an analog signal from a phone line and turn it back into the original digital signal (demodulation).
Controller-based modems do all of the digital signal processing, D/A and A/D conversion, and phone-line interfacing in hardware. Generally, these modems either are external modems that plug into a serial port or have a serial port chip included and thus just look like an extra serial port to the CPU. Configuring these modems under Unix is easy; just set up whatever program uses the serial port to use the port speed and serial options you want.
Host-based modems, often called "Winmodems," provide some level of hardware support (at a minimum, the physical phone line interface) and then emulate some or all of the hardware modulation and demodulation in software. There are a variety of specifications related to "soft" modems, and current information on things like available drivers, issues, standards, and whether a modem is a hard or soft modem are available at http://www.idir.net/~gromitkc/winmodem.html and http://www.linmodems.org.
The problem that soft modems present to Unix is that the software that makes up the fundamental functionality of the modem is almost always Windows software. These modems are widely available and cheap and do have some advantages, though, so there are efforts to provide Unix software for some set of them. Unix soft-modem software is highly in flux at the time of this writing. Before you buy a modem, be sure that you check the current information on that modem and available drivers for the Unix platform you want to use before you buy. Or spend a bit more and buy a modem that doesn't have these issues.
— DJPH
Point-to-Point Protocol (PPP) is the way ISPs usually provide dialup access (largely because this is the default protocol Windows dialup uses). Unixes that can do dialup provide a PPP client, which you configure to call the ISP and set up a PPP connection. An established connection functions as a network connection — you can use ifconfig (Section 44.8, Section 46.3) to examine it and packets will be routed to the PPP connection by default, and tools like traceroute (Section 46.4) can be used across it.
Unixes provide two ways to run PPP: kernel PPP, where the PPP code resides in the kernel and is therefore very fast but limited in features, and user PPP, where packets have to be copied back and forth between kernel space and user space, but a wide feature set can be provided. We'll give a quick overview of both.
Kernel PPP uses pppd and a fairly simple set of configuration commands. You provide pppd with the information needed to dial your modem appropriately and with whatever login information your ISP has provided you, and it connects. Generally you then have to set up /etc/resolv.conf to point to your ISP's DNS (Section 46.9) server. Some implementations of pppd don't even know how to dial the phone, and you'll have to use something like kermit to dial the phone first. pppd must also be run as root. Look at your platform's documentation for pppd for details on setting up kernel PPP on that platform.
Platforms that provide a user-space PPP client are a little easier to work with. User-space PPP clients can be run by users other than root (usually limited to a specific group); they tend to configure default routes, /etc/resolv.conf, and other details automatically; and they generally deal with PAP or CHAP authentication (which many ISPs use) a little more easily. Usually the user-space PPP client is just called ppp; look for its manpage to see what it requires to configure it.
— DJPH
Many PCs support the Universal Serial Bus (USB). USB is a hot-swappable standard; devices can be plugged in and unplugged while the machine is running, and the system is supposed to recognize the new device or no longer recognize the now disconnected device.
Unixes deal with this requirement with low-level device drivers to actually interface with the devices and with a daemon, usbd, to monitor for changes on the fly or, on Linux, the hotplug facility (http://linux-hotplug.sourceforge.net).
Generally, there is very little configuration required for supported USB devices. If you have the correct kernel modules (Section 44.3) loaded (and on many platforms they're loaded by default), just plug in the device. Check your platform's supported hardware before buying a USB device, as such devices are changing rapidly at the time of this writing and may or may not have Unix drivers implemented yet.
Specific issues you might run into include that USB disks may need to use a special filesystem type (usbdevfs) and that specific devices may require tools to actually use the device. Webcams and scanners are a good example, as the device driver provides only low-level access to the device; you still need a tool that can pull images off of the device and do something useful with them. Extensive information is available on the Web about using many USB devices on the free Unixes (http://www.linux-usb.org for Linux and the USB chapter in the FreeBSD handbook are places to start), and it stays fairly up to date.
— DJPH
There are a lot of devices available for PCs that were never designed for an operating system like Unix to use. Often these devices' manufacturers simply provide Windows drivers and never expect you to need anything else. Luckily, there is a large community of developers for the various free Unixes, and they implement device drivers for many of these devices. Availability of a driver for a particular piece of hardware, however, depends entirely on whether someone happened to write a driver for it.
Sound cards are one bit of hardware that commonly has this problem. Most free Unixes have a set of drivers that support a selection of sound cards and one or two other drivers that support a lowest common denominator to get minimal functionality out of most sound cards. If you want real support for your sound card, look at the supported devices list for the OS you want to install before you buy a card, and pick one that someone's written a full driver for.
On Linux, take a look at the sndconfig utility, which can probably configure your sound card for you. Take a peek at http://www.linuxheadquarters.com/howto/basic/sndconfig.shtml for details.
Other hardware that falls into the "check your supported hardware list before buying" includes frame grabbers, multi-serial boards, AD/DA converters, X-10 controllers and any hardware that's brand new (and thus may not have had time for someone to create a Unix driver). All of the free Unixes have extensive supported hardware lists — check before you buy.
— DJPH
Often server machines are placed in a rack in a colocation facility, in some back closet, or in some other out of the way place. This can make it really inconvenient to access the server's console should something go wrong or need diagnosing; hauling a monitor and keyboard into your server storage area is a real pain. If you've got your server mounted in a rack, there are devices that are essentially a flat screen monitor, keyboard, and mouse mounted in a sliding rack shelf, which work well, but they're expensive.
A simple and cheap solution is to change the console from the normal monitor/keyboard/mouse to one of the serial ports. The serial port can be hooked via null modem to a terminal server or another machine, allowing controlled access, or you can just plug your laptop into it with a null modem when you need to diagnose problems or reboot.
Linux has a howto describing details of dealing with serial consoles at http://www.linuxdoc.org/HOWTO/Remote-Serial-Console-HOWTO/. Essentially, you provide options to the boot loader and kernel to tell them to use your serial port as a console, and then configure getty to accept logins on that serial port. The HOWTO shows various potential configurations and demonstrates proper setup on each.
FreeBSD's handbook has a chapter on setting up serial consoles. Again, you have to tell the boot loader and the kernel to use the serial port, and then edit /etc/ttys to enable getty on that serial port. FreeBSD can also be configured to decide whether to use a normal console or serial console based on whether or not a keyboard is plugged in. NetBSD and OpenBSD are configured similarly.
Solaris is even easier: just unplug the keyboard before you boot the machine. Solaris uses a serial console by default if no keyboard is plugged in at boot time. If you want to set it explicitly to use a serial console even if the keyboard is plugged in, just set input-device and output-device to ttya (or ttyb if you want it on the second serial port) in the boot eeprom.
— DJPH
| CONTENTS | |
