diff --git a/handbook/booting.sgml b/handbook/booting.sgml index 774c606431..723f0a9da1 100644 --- a/handbook/booting.sgml +++ b/handbook/booting.sgml @@ -1,173 +1,173 @@ The FreeBSD Booting Process

Contributed by &a.phk;. v1.1, April 26th. Booting FreeBSD is essentially a three step: Load the kernel, determine the root filesystem and initialize user-land things. This leads to some interesting possibilities shown below. Loading a kernel

We presently have three basic mechanisms for loading the kernel as described below: They all pass some information to the kernel to help the kernel decide what to do next. Biosboot Biosboot is our ``bootblocks'', it consists of two files, which will be installed in the first 8Kbytes of the floppy or hard-disk slice to be booted from. Biosboot can load a kernel from a FreeBSD filesystem. Dosboot Dosboot was written by DI. Christian Gusenbauer, and is unfortunately at this time one of the few pieces of code that isn't compilable under FreeBSD itself because it is written for Microsoft compilers. Dosboot will boot the kernel from a MS-DOS file or from a FreeBSD filesystem partition on the disk. It attempts to negotiate with the various and strange kinds of memory manglers that lurk in - high memory on MS/DOS systems and usually wins them for it's + high memory on MS/DOS systems and usually wins them for its case. Netboot Netboot will try to find a supported Ethernet card, and use BOOTP, TFTP and NFS to find a kernel file to boot. Determine the root filesystem

Once the kernel is loaded and the boot-code jumps to it, the kernel will initialize itself, trying to determine what hardware is present and so on, and then it needs to find a root filesystem. Presently we support the following types of root filesystems: UFS This is the most normal type of root filesystem. It can reside on a floppy or on hard disk. MSDOS While this is technically possible, it isn't particular useful, because of ``FAT'' filesystems inability to make links, device nodes and such ``UNIXisms''. MFS This is actually a UFS filesystem which has been compiled into the kernel. That means that the kernel does not really need any disks/floppies or other HW to function. CD9660 This is for using a CD-ROM as root filesystem. NFS This is for using a fileserver as root filesystem, basically making it a diskless machine. Initialize user-land things

To get the user-land going, when the kernel has finished initialization, it will create a process with ``/sbin/init''. You can substitute any program for /sbin/init, as long as you keep in mind that: there is no stdin/out/err unless you open it yourself, if you exit, the machine panics, signal handling is special for ``/stand/sysinstall'' program on the installation floppy. Interesting combinations

Boot a kernel with a MFS in it with a special /sbin/init which... mounts your /C: Attaches C:/freebsd.fs on /dev/vn0 mounts /dev/vn0 as /rootfs makes symlinks /rootfs/bin -> /bin /rootfs/etc -> /etc /rootfs/sbin -> /sbin (etc...) Now you run FreeBSD without repartitioning your hard disk... server:˜you/FreeBSD as /nfs, chroots to /nfs and executes /sbin/init there Now you run FreeBSD diskless, even though you don't control the NFS server... /dev/rwd0 and writes it to a remote tape station or fileserver. Now you finally got that backup you should have made a year ago... E -- Acts as a firewall/web-server/what do I know... This is particular interesting since you can boot from a write- protected floppy, but still write to your root filesystem... diff --git a/handbook/esdi.sgml b/handbook/esdi.sgml index 3251187472..ee14bdb91d 100644 --- a/handbook/esdi.sgml +++ b/handbook/esdi.sgml @@ -1,421 +1,421 @@ - + Using ESDI hard disks

Copyright © 1995, &a.wilko;.24 September 1995. ESDI is an acronym that means Enhanced Small Device Interface. It is loosely based on the good old ST506/412 interface originally devised by Seagate Technology, the makers of the first affordable 5.25" winchester disk. The acronym says Enhanced, and rightly so. In the first place the speed of the interface is higher, 10 or 15 Mbits/second instead of the 5 Mbits/second of ST412 interfaced drives. Secondly some higher level commands are added, making the ESDI interface somewhat 'smarter' to the operating system driver writers. It is by no means as smart as SCSI by the way. ESDI is standardized by ANSI. Capacities of the drives are boosted by putting more sectors on each track. Typical is 35 sectors per track, high capacity drives I've seen were up to 54 sectors/track. Although ESDI has been largely obsoleted by IDE and SCSI interfaces, the availability of free or cheap surplus drives makes them ideal for low (or now) budget systems. Concepts of ESDI

Physical connections

The ESDI interface uses two cables connected to each drive. One cable is a 34 pin flat cable edge connector that carries the command and status signals from the controller to the drive and vice-versa. The command cable is daisy chained between all the drives. So, it forms a bus onto which all drives are connected. The second cable is a a 20 pin flat cable edge connector that carries the data to and from the drive. This cable is radially - connected, so each drive has it's own direct connection to the + connected, so each drive has its own direct connection to the controller. To the best of my knowledge PC ESDI controllers are limited to using a maximum of 2 drives per controller. This is compatibility feature(?) left over from the WD1003 standard that reserves only a single bit for device addressing. Device addressing

On each command cable a maximum of 7 devices and 1 controller can be present. To enable the controller to uniquely identify which drive it addresses, each ESDI device is equipped with jumpers or switches to select the devices address. On PC type controllers the first drive is set to address 0, the second disk to address 1. Always make sure you - set each disk to an unique address! So, on a PC with it's + set each disk to an unique address! So, on a PC with its two drives/controller maximum the first drive is drive 0, the second is drive 1. Termination

The daisy chained command cable (the 34 pin cable remember?) needs to be terminated at the last drive on the chain. For this purpose ESDI drives come with a termination resistor network that can be removed or disabled by a jumper when it is not used. So, one and only one drive, the one at the farthest end of the command - cable has it's terminator installed/enabled. The controller + cable has its terminator installed/enabled. The controller automatically terminates the other end of the cable. Please note that this implies that the controller must be at one end of the cable and not in the middle. Using ESDI disks with FreeBSD

Why is ESDI such a pain to get working in the first place? People who tried ESDI disks with FreeBSD are known to have developed a profound sense of frustration. A combination of factors works against you to produce effects that are hard to understand when you have never seen them before. This has also led to the popular legend ESDI and FreeBSD is a plain NO-GO. The following sections try to list all the pitfalls and solutions. ESDI speed variants

As briefly mentioned before, ESDI comes in two speed flavors. The older drives and controllers use a 10 Mbits/second data transfer rate. Newer stuff uses 15 Mbits/second. It is not hard to imagine that 15 Mbits/second drive cause problems on controllers laid out for 10 Mbits/second. As always, consult your controller and drive documentation to see if things match. Stay on track

Mainstream ESDI drives use 34 to 36 sectors per track. Most (older) controllers cannot handle more than this number of sectors. Newer, higher capacity, drives use higher numbers of sectors per track. For instance, I own a 670 Mb drive that has 54 sectors per track. In my case, the controller could not handle this number of sectors. It proved to work well except that it only used 35 sectors on each track. This meant losing a lot of disk space. Once again, check the documentation of your hardware for more info. Going out-of-spec like in the example might or might not work. Give it a try or get another more capable controller. Hard or soft sectoring

Most ESDI drives allow hard or soft sectoring to be selected using a jumper. Hard sectoring means that the drive will produce a sector pulse on the start of each new sector. The controller uses this pulse to tell when it should start to write or read. Hard sectoring allows a selection of sector size (normally 256, 512 or 1024 bytes per formatted sector). FreeBSD uses 512 byte sectors. The number of sectors per track also varies while still using the same number of bytes per formatted sector. The number of unformatted bytes per sector varies, dependent on your controller it needs more or less overhead bytes to work correctly. Pushing more sectors on a track of course gives you more usable space, but might give problems if your controller needs more bytes than the drive offers. In case of soft sectoring, the controller itself determines where to start/stop reading or writing. For ESDI hard sectoring is the default (at least on everything I came across). I never felt the urge to try soft sectoring. In general, experiment with sector settings before you install FreeBSD because you need to re-run the low-level format after each change. Low level formatting

ESDI drives need to be low level formatted before they are usable. A reformat is needed whenever you figgle with the number of sectors/track jumpers or the physical orientation of the drive (horizontal, vertical). So, first think, then format. The format time must not be underestimated, for big disks it can take hours. After a low level format, a surface scan is done to find and flag bad sectors. Most disks have a manufacturer bad block list listed on a piece of paper or adhesive sticker. In addition, on most disks the list is also written onto the disk. Please use the manufacturer's list. It is much easier to remap a defect now than after FreeBSD is installed. Stay away from low-level formatters that mark all sectors of a track as bad as soon as they find one bad sector. Not only does this waste space, it also and more importantly causes you grief with bad144 (see the section on bad144). Translations

Translations, although not exclusively a ESDI-only problem, might give you real trouble. Translations come in multiple flavors. Most of them have in common that they attempt to work around the limitations posed upon disk geometries by the original IBM PC/AT design (thanks IBM!). First of all there is the (in)famous 1024 cylinder limit. For a system to be able to boot, the stuff (whatever operating system) must be in the first 1024 cylinders of a disk. Only 10 bits are available to encode the cylinder number. For the number of sectors the limit is 64 (0-63). When you combine the 1024 cylinder limit with the 16 head limit (also a design feature) you max out at fairly limited disk sizes. To work around this problem, the manufacturers of ESDI PC controllers added a BIOS prom extension on their boards. This BIOS extension handles disk I/O for booting (and for some operating systems all disk I/O) by using translation. For instance, a big drive might be presented to the system as having 32 heads and 64 sectors/track. The result is that the number of cylinders is reduced to something below 1024 and is therefore usable by the system without problems. - It is noteworthy to know that FreeBSD after it's kernel has - started no longer uses the BIOS. More on this later. + It is noteworthy to know that FreeBSD does not use the + BIOS after its kernel has started. More on this later. A second reason for translations is the fact that most older system BIOSes could only handle drives with 17 sectors per track (the old ST412 standard). Newer system BIOSes usually have a user-defined drive type (in most cases this is drive type 47). Whatever you do to translations after reading this document, keep in mind that if you have multiple operating systems on the same disk, all must use the same translation While on the subject of translations, I've seen one controller type (but there are probably more like this) offer the option to logically split a drive in multiple partitions as a BIOS option. I had select 1 drive == 1 partition because this controller wrote this info onto the disk. On power-up it read the info and presented itself to the system based on the info from the disk. Spare sectoring

Most ESDI controllers offer the possibility to remap bad sectors. During/after the low-level format of the disk bad sectors are marked as such, and a replacement sector is put in place (logically of course) of the bad one. In most cases the remapping is done by using N-1 sectors on each track for actual data storage, and sector N itself is the spare sector. N is the total number of sectors physically available on the track. The idea behind this is that the operating system sees a 'perfect' disk without bad sectors. In the case of FreeBSD this concept is not usable. The problem is that the translation from bad to good is performed by the BIOS of the ESDI controller. FreeBSD, being a true 32 bit operating system, does not use the BIOS after it has been booted. Instead, it has device drivers that talk directly to the hardware. So: don't use spare sectoring, bad block remapping or whatever it may be called by the controller manufacturer when you want to use the disk for FreeBSD. Bad block handling

The preceding section leaves us with a problem. The controller's bad block handling is not usable and still FreeBSD's filesystems assume perfect media without any flaws. To solve this problem, FreeBSD use the bad144 tool. Bad144 (named after a Digital Equipment standard for bad block handling) scans a FreeBSD slice for bad blocks. Having found these bad blocks, it writes a table with the offending block numbers to the end of the FreeBSD slice. When the disk is in operation, the disk accesses are checked against the table read from the disk. Whenever a block number is requested that is in the bad144 list, a replacement block (also from the end of the FreeBSD slice) is used. In this way, the bad144 replacement scheme presents 'perfect' media to the FreeBSD filesystems. There are a number of potential pitfalls associated with the use of bad144. First of all, the slice cannot have more than 126 bad sectors. If your drive has a high number of bad sectors, you might need to divide it into multiple FreeBSD slices each containing less than 126 bad sectors. Stay away from low-level format programs that mark every sector of a track as bad when they find a flaw on the track. As you can imagine, the 126 limit is quickly reached when the low-level format is done this way. Second, if the slice contains the root filesystem, the slice should be within the 1024 cylinder BIOS limit. During the boot process the bad144 list is read using the BIOS and this only succeeds when the list is within the 1024 cylinder limit. Note that the restriction is not that only the root filesystem must be within the 1024 cylinder limit, but rather the entire slice that contains the root filesystem. Kernel configuration

ESDI disks are handled by the same wddriver as IDE and ST412 MFM disks. The wd driver should work for all WD1003 compatible interfaces. Most hardware is jumperable for one of two different I/O address ranges and IRQ lines. This allows you to have two wd type controllers in one system. When your hardware allows non-standard strappings, you can use these with FreeBSD as long as you enter the correct info into the kernel config file. An example from the kernel config file (they live in /sys/i386/conf BTW). # First WD compatible controller controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 # Second WD compatible controller controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 Particulars on ESDI hardware

Adaptec 2320 controllers

I successfully installed FreeBSD onto a ESDI disk controlled by a ACB-2320. No other operating system was present on the disk. To do so I low level formatted the disk using NEFMT.EXE (ftpable from www.adaptec.com) and answered NO to the question whether the disk should be formatted with a spare sector on each track. The BIOS on the ACD-2320 was disabled. I used the 'free configurable' option in the system BIOS to allow the BIOS to boot it. Before using NEFMT.EXE I tried to format the disk using the ACB-2320 BIOS builtin formatter. This proved to be a show stopper, because it didn't give me an option to disable spare sectoring. With spare sectoring enabled the FreeBSD installation process broke down on the bad144 run. Please check carefully which ACB-232xy variant you have. The x is either 0 or 2, indicating a controller without or with a floppy controller on board. The y is more interesting. It can either be a blank, a "A-8" or a "D". A blank indicates a plain 10 Mbits/second controller. An "A-8" indicates a 15 Mbits/second controller capable of handling 52 sectors/track. A "D" means a 15 Mbits/second controller that can also handle drives with > 36 sectors/track (also 52 ?). All variations should be capable of using 1:1 interleaving. Use 1:1, FreeBSD is fast enough to handle it. Western Digital WD1007 controllers

I successfully installed FreeBSD onto a ESDI disk controlled by a WD1007 controller. To be precise, it was a WD1007-WA2. Other variations of the WD1007 do exist. To get it to work, I had to disable the sector translation and the WD1007's onboard BIOS. This implied I could not use the low-level formatter built into this BIOS. Instead, I grabbed WDFMT.EXE from www.wdc.com Running this formatted my drive just fine. Ultrastor U14F controllers

According to multiple reports from the net, Ultrastor ESDI boards work OK with FreeBSD. I lack any further info on particular settings. Further reading

If you intend to do some serious ESDI hacking, you might want to have the official standard at hand: The latest ANSI X3T10 committee document is: Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11] On Usenet the newsgroup is a noteworthy place to look for more info. The World Wide Web (WWW) also proves to be a very handy info source: For info on Adaptec ESDI controllers see . For info on Western Digital controllers see . Thanks to...

Andrew Gordon for sending me an Adaptec 2320 controller and ESDI disk for testing. diff --git a/handbook/firewalls.sgml b/handbook/firewalls.sgml index efa4dde884..1d8884f13c 100644 --- a/handbook/firewalls.sgml +++ b/handbook/firewalls.sgml @@ -1,525 +1,525 @@ - + Firewalls

Contributed by &a.gpalmer;.4th of October 1995 Firewalls are an area of increasing interest for people who are connected to the Internet, and are even finding applications on private networks to provide enhanced security. This section will hopefully explain what firewalls are, how to use them, and how to use the facilities provided in the FreeBSD kernel to implement them. Note: People often think that having a firewall between your companies internal network and the ``Big Bad Internet'' will solve all your security problems. It may help, but a poorly setup firewall system is more of a security risk than not having one at all. A firewall can only add another layer of security to your systems, but they will not be able to stop a really determined hacker from penetrating your internal network. If you let internal security lapse because you believe your firewall to be impenetrable, you have just made the hackers job that bit easier. What is a firewall?

There are currently two distinct types of firewalls in common use on the Internet today. The first type is more properly called a packet filtering router, where the kernel on a multi-homed machine chooses whether to forward or block packets based on a set of rules. The second type, known as proxy servers, rely on daemons to provide authentication and to forward packets, possibly on a multi-homed machine which has kernel packet forwarding disabled.

Sometimes sites combine the two types of firewalls, so that only a certain machine (known as a bastion host) is allowed to send packets through a packet filtering router onto an internal network. Proxy services are run on the bastion host, which are generally more secure than normal authentication mechanisms.

FreeBSD comes with a kernel packet filter (known as IPFW), which is what the rest of this section will concentrate on. Proxy servers can be built on FreeBSD from third party software, but there is such a variety of proxy servers available that it would be impossible to cover them in this document. Packet filtering routers

A router is a machine which forwards packets between two or more -networks. A packet filtering router has an extra piece of code in it's +networks. A packet filtering router has an extra piece of code in its kernel, which compares each packet to a list of rules before deciding if it should be forwarded or not. Most modern IP routing software has packet filtering code in it, which defaults to forwarding all packets. To enable the filters, you need to define a set of rules for the filtering code, so that it can decide if the packet should be allowed to pass or not.

To decide if a packet should be passed on or not, the code looks -through it's set of rules for a rule which matches the contents of +through its set of rules for a rule which matches the contents of this packets headers. Once a match is found, the rule action is obeyed. The rule action could be to drop the packet, to forward the packet, or even to send an ICMP message back to the originator. Only the first match counts, as the rules are searched in order. Hence, the list of rules can be referred to as a ``rule chain''.

The packet matching criteria varies depending on the software used, but typically you can specify rules which depend on the source IP address of the packet, the destination IP address, the source port number, the destination port number (for protocols which support ports), or even the packet type (UDP, TCP, ICMP, etc). Proxy servers

Proxy servers are machines which have had the normal system daemons (telnetd, ftpd, etc) replaced with special servers. These servers are called proxy servers as they normally only allow onward connections to be made. This enables you to run (for example) a proxy telnet server on your firewall host, and people can telnet in to your firewall from the outside, go through some authentication mechanism, and then gain access to the internal network (alternatively, proxy servers can be used for signals coming from the internal network and heading out).

Proxy servers are normally more secure than normal servers, and often have a wider variety of authentication mechanisms available, including ``one-shot'' password systems so that even if someone manages to discover what password you used, they will not be able to use it to gain access to your systems as the password instantly expires. As they do not actually give users access to the host machine, it becomes a lot more difficult for someone to install backdoors around your security system.

Proxy servers often have ways of restricting access further, so that only certain hosts can gain access to the servers, and often they can be set up so that you can limit which users can talk to which destination machine. Again, what facilities are available depends largely on what proxy software you choose. What does IPFW allow me to do?

IPFW, the software supplied with FreeBSD, is a packet filtering and accounting system which resides in the kernel, and has a user-land control utility, ipfw(8). Together, they allow you to define and query the rules currently used by the kernel in its routing decisions.

There are two related parts to IPFW. The firewall section allows you to perform packet filtering. There is also an IP accounting section which allows you to track usage of your router, based on similar rules to the firewall section. This allows you to see (for example) how much traffic your router is getting from a certain machine, or how much WWW (World Wide Web) traffic it is forwarding.

As a result of the way that IPFW is designed, you can use IPFW on non-router machines to perform packet filtering on incoming and outgoing connections. This is a special case of the more general use of IPFW, and the same commands and techniques should be used in this situation. Enabling IPFW on FreeBSD

As the main part of the IPFW system lives in the kernel, you will need to add one or more options to your kernel configuration file, depending on what facilities you want, and recompile your kernel. See for more details on how to recompile your kernel.

There are currently three kernel configuration options relevant to IPFW: syslogd(8). Without this option, even if you specify that packets should be logged in the filter rules, nothing will happen. Configuring IPFW

The configuration of the IPFW software is done through the ipfw(8) utility. The syntax for this command looks quite complicated, but it is relatively simple once you understand -it's structure. +its structure.

There are currently two different command line formats for the utility, depending on what you are doing. The first form is used when adding/deleting entries from the firewall or accounting chains, or when clearing the counters for an entry on the accounting chain. The second form is used for more general actions, such as flushing the rule chains, listing the rule chains or setting the default policy. Altering the IPFW rules

The syntax for this form of the command is: ipfw [-n] command action protocol addresses

There is one valid flag when using this form of the command: The command given can be shortened to the shortest unique form. The valid commands are: If no command is given, it will default addfirewall or addaccounting depending on the arguments given.

Currently, the firewall support in the kernel applies a set of weights to the rule being added. This means that the rules will not be evaluated in the order that they are given to the system. The weighting system is designed so that rules which are very specific are evaluated first, and rules which cover very large ranges are evaluated last. In other words, a rule which applies to a specific port on a specific host will have a higher priority than a rule which applies to that same port, but on a range of hosts, or that host on a range of ports.

The weighting system is not perfect, however, and can lead to problems. The best way to see what order it has put your rules in is to use the list command, as that command lists the rules in the order that they are evaluated, not the order that they were fed to the system.

The actions available depend on which rule chain the entry is destined for. For the firewall chain, valid actions are: reject, but also log the packet details. deny, but also log the packet details. accept. For the accounting chain, valid actions are:

Each action will be recognized by the shortest unambiguous prefix. The protocols which can be specified are:

The address specification is: [from <address/mask>[port]] [to <address/mask>[port]] [via <interface>]

You can only specify port in conjunction with protocols which support ports (UDP, TCP and SYN).

The order of the from, to, and via keywords is unimportant. Any of them can be omitted, in which case a default entry for that keyword will be supplied which matches everything.

The via is optional and may specify the IP address or domain name of a local IP interface, or an interface name (e.g. ed0) to match only packets coming through this interface. The keyword via can be substituted by on, for readability reasons.

The syntax used to specify an <address/mask> is: <address> or <address>/mask-bits or <address>:mask-pattern

A valid hostname may be specified in place of the IP address. mask-bits is a decimal number representing how many bits in the address mask should be set. e.g. specifying 192.216.222.1/24 will create a mask which will allow any address in a class C subnet (in this case, 192.216.222) to be matched. mask-pattern is an IP address which will be logically AND'ed with the address given. The keyword any may be used to specify ``any IP address''.

The port numbers to be blocked are specified as: port[,port[,port[...]]] to specify either a single port or a list of ports, or port:port to specify a range of ports. The name of a service (from /etc/services) can be used instead of a numeric port value. Listing/flushing the IPFW rules

The syntax for this form of the command is: ipfw [-ans] command [argument]

There are three valid flags when using this form of the command: -s. -a to see accounting counters. The short form listing is incompatible with the input syntax used by the ipfw(8) utility. The command given can be shortened to the shortest unique form. The valid commands are: -s flag is given, the format is compatible with the command line syntax. The list and flush commands may optionally be passed an argument to specify which chain to flush. Valid arguments are:

The policy command can be given one of two arguments: As usual, the arguments can be shortened to the shortest unique form (in this case, the first letter). Example commands for ipfw

This command will deny all packets from the host evil.hacker.org to the telnet port of the host nice.people.org by being forwarded by the router: ipfw addf deny tcp from evil.hacker.org to nice.people.org telnet

The next example denies and logs any TCP traffic from the entire hacker.org network (a class C) to the nice.people.org machine (any port). ipfw addf ldeny tcp from evil.hacker.org/24 to nice.people.org If you do not want people sending X sessions to your internal network (a subnet of a class C), the following command will do the necessary filtering: ipfw addf deny syn to my.org/28 6000 To allow access to the SUP server on sup.FreeBSD.ORG, use the following command: ipfw addf accept syn to sup.FreeBSD.ORG supfilesrv To see the accounting records: ipfw -sa list accounting or in the short form ipfw -sa l a Building a packet filtering firewall

Note: The following suggestions are just that: suggestions. The requirements of each firewall are different and I cannot tell you how to build a firewall to meet your particular requirements.

When initially setting up your firewall, unless you have a test bench setup where you can configure your firewall host in a controlled environment, I strongly recommend you use the logging version of the commands and enable logging in the kernel. This will allow you to quickly identify problem areas and cure them without too much disruption. Even after the initial setup phase is complete, I recommend using the logging for of `deny' as it allows tracing of possible attacks and also modification of the firewall rules if your requirements alter. Note: If you use the logging versions of the accept command, it can generate large amounts of log data as one log line will be generated for every packet that passes through the firewall, so large ftp/http transfers, etc, will really slow the system down. It also increases the latencies on those packets as it requires more work to be done by the kernel before the packet can be passed on. syslogd with also start using up a lot more processor time as it logs all the extra data to disk, and it could quite easily fill the partition /var/log is located on.

As currently supplied, FreeBSD does not have the ability to load firewall rules at boot time. My suggestion is to put a call to a shell script in the /etc/netstart script. Put the call early enough in the netstart file so that the firewall is configured before any of the IP interfaces are configured. This means that there is no window during which time your network is open.

The actual script used to load the rules is entirely up to you. There is currently no support in the ipfw utility for loading multiple rules in the one command. The system I use is to use the command: # ipfw list to write a list of the current rules out to a file, and then use a text editor to prepend ``ipfw '' before all the lines. This will allow the script to be fed into /bin/sh and reload the rules into the kernel. Perhaps not the most efficient way, but it works.

The next problem is what your firewall should actually DO! This is largely dependent on what access to your network you want to allow from the outside, and how much access to the outside world you want to allow from the inside. Some general rules are: Block all incoming access to ports below 1000 for TCP. This is where most of the security sensitive services are, like finger, SMTP (mail) and telnet. Block incoming SYN connections to ports between 1001 and 1024 (this will allow internal users to rsh/rlogin to the outside). If you do not want to allow rsh/rlogin connections from the inside to the outside, then extend the above suggestion to cover ports 1-1024. Block all incoming UDP traffic. There are very few useful services that travel over UDP, and what useful traffic there is is normally a security threat (e.g. Suns RPC and NFS protocols). This has its disadvantages also, since UDP is a connectionless protocol, denying incoming UDP traffic also blocks the replies to outgoing UDP traffic. This can cause a problem for people (on the inside) using external archie (prospero) servers. If you want to allow access to archie, you'll have to allow packets coming from ports 191 and 1525 to any internal UDP port through the firewall. ntp is another service you may consider allowing through, which comes from port 123. Block traffic to port 6000 from the outside. Port 6000 is the port used for access to X11 servers, and can be a security threat (especially if people are in the habit of doing xhost + on their workstations). X11 can actually use a range of ports starting at 6000, the upper limit being how many X displays you can run on the machine. The upper limit as defined by RFC 1700 (Assigned Numbers) is 6063. Check what ports any internal servers use (e.g. SQL servers, etc). It's probably a good idea to block those as well, as they normally fall outside the 1-1024 range specified above.

Of course, if you want to make sure that no un-authorized traffic gets through the firewall, change the default policy to ``deny''. This will mean that any traffic which is allowed through has to be specified explicitly in an ``accept'' or ``allow'' filter rule. Which ports you allow through is again something that you will have to decide for yourself. If you do set the default policy to be deny, you will probably want to install proxy servers, as no traffic will be able to get OUT either unless you allow TCP SYN connections going form the inside out.

As I said above, these are only guidelines. You will have to decide what filter rules you want to use on your firewall yourself. I cannot accept ANY responsibility if someone breaks into your network, even if you follow the advice given above. diff --git a/handbook/install.sgml b/handbook/install.sgml index d5166cda3c..23db9c43a1 100644 --- a/handbook/install.sgml +++ b/handbook/install.sgml @@ -1,877 +1,877 @@ - + Installing FreeBSD

So, you would like to try out FreeBSD on your system? This section is a quick-start guide for what you need to do. FreeBSD can be installed from a variety of media including CD-ROM, floppy disk, magnetic tape, an MS-DOS partition, and if you have a network connection, via anonymous ftp or NFS. Regardless of the installation media you choose, you can get started by downloading the installation disk as described below. Booting your computer with disk will provide important information about compatibility between FreeBSD and your hardware which could dictate which installation options are possible. It can also provide early clues to compatibility problems that could prevent FreeBSD running on your system at all. If you plan on installing via anonymous FTP, then this installation disk is all you need to download. For more information on obtaining the FreeBSD distribution itself, please see in the Appendix. So, to get the show on the road, follow these steps: Review the section of this installation guide to be sure that your hardware is supported by FreeBSD. It may be helpful to make a list of any special cards you have installed, such as SCSI controllers, Ethernet adapters or sound cards. This list should include relevant configuration parameters such as interrupts (IRQ) and IO port addresses. Download the file to your hard drive, and be sure to tell your browser to save rather than display. Note: This disk image can be used for both 1.44 megabyte 3.5 inch floppy disks and 1.2 megabyte 5.25 inch floppy disks. Make the installation boot disk from the image file: If you are using MS-DOS download , then run it: C:\> rawrite The program will prompt you for the floppy drive containing the disk you want to write to (A: or B:) and the name of the file to put on disk (boot.flp). If you are using a UNIX system: % dd if=boot.flp of=disk_device where disk_device is the /dev entry for the floppy drive. On FreeBSD systems, this is /dev/fd0 for the A: drive and /dev/fd1 for the B: drive. With the installation disk in the A: drive, reboot your computer. You should get a boot prompt something like this: >> FreeBSD BOOT ... Use hd(1,a)/kernel to boot sd0 when wd0 is also installed. Usage: [[hd(1,a)]/kernel][-abcCdhrsv] Use ? for file list or press Enter for defaults Boot: If you do not type anything, FreeBSD will automatically boot with its default configuration after a delay of about five seconds. As FreeBSD boots, it probes your computer to determine what hardware is installed. The results of this probing is displayed on the screen. When the booting process is finished, The main FreeBSD installation menu will be displayed.

If something goes wrong...

Due to limitations of the PC architecture, it is impossible for probing to be 100 percent reliable. In the event that your hardware is incorrectly identified, or that the probing causes your computer to lock up, first check the section of this installation guide to be sure that your hardware is indeed supported by FreeBSD.

If your hardware is supported, reset the computer and when the Boot: prompt comes up, type -c. This puts FreeBSD into a configuration mode where you can supply hints about your hardware. The FreeBSD kernel on the installation disk is configured assuming that most hardware devices are in their factory default configuration in terms of IRQs, IO addresses and DMA channels. If your hardware has been reconfigured, you will most likely need to use the -c option at boot to tell FreeBSD where things are.

It is also possible that a probe for a device not present will cause a later probe for another device that is present to fail. In that case, the probes for the conflicting driver(s) should be disabled.

In the configuration mode, you can: List the device drivers installed in the kernel. Disable device drivers for hardware not present in your system. Change the IRQ, DRQ, and IO port addresses used by a device driver.

While at the config> prompt, type help for more information on the available commands. After adjusting the kernel to match how you have your hardware configured, type quit at the config> prompt to continue booting with the new settings. After FreeBSD has been installed, changes made in the configuration mode will be permanent so you do not have to reconfigure every time you boot. Even so, it is likely that you will want to build a custom kernel to optimize the performance of your system. See for more information on creating custom kernels. Supported Configurations

FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus based PC's, ranging from 386sx to Pentium class machines (though the 386sx is not recommended). Support for generic IDE or ESDI drive configurations, various SCSI controller, network and serial cards is also provided. A minimum of five megabytes of RAM is required to run FreeBSD. To run the X-window system, eight megabytes of RAM is the recommended minimum. Following is a list of all disk controllers and Ethernet cards currently known to work with FreeBSD. Other configurations may very well work, and we have simply not received any indication of this. Disk Controllers

WD1003 (any generic MFM/RLL) WD1007 (any generic IDE/ESDI) IDE ATA Adaptec 152x series ISA SCSI controllers Adaptec 154x series ISA SCSI controllers Adaptec 174x series EISA SCSI controller in standard and enhanced mode. Adaptec 274x/284x/2940/3940 (Narrow/Wide/Twin) series EISA/VLB/PCI SCSI controllers Adaptec AIC-6360 based boards, which includes the AHA-152x and SoundBlaster SCSI cards. Note: You cannot boot from the SoundBlaster cards as they have no on-board BIOS, which is necessary for mapping the boot device into the system BIOS I/O vectors. They are perfectly usable for external tapes, CDROMs, etc, however. The same goes for any other AIC-6x60 based card without a boot ROM. Some systems DO have a boot ROM, which is generally indicated by some sort of message when the system is first powered up or reset. Check your system/board documentation for more details. Buslogic 545S & 545c Note: that Buslogic was formerly known as "Bustek". Buslogic 445S/445c VLB SCSI controller Buslogic 742A/747S/747c EISA SCSI controller. Buslogic 946c PCI SCSI controller Buslogic 956c PCI SCSI controller NCR 53C810/53C815/53C825/53C860/53C875 PCI SCSI controller. NCR5380/NCR53400 (``ProAudio Spectrum'') SCSI controller. DTC 3290 EISA SCSI controller in 1542 emulation mode. UltraStor 14F/24F/34F SCSI controllers. Seagate ST01/02 SCSI controllers. Future Domain 8xx/950 series SCSI controllers. WD7000 SCSI controllers. With all supported SCSI controllers, full support is provided for SCSI-I & SCSI-II peripherals, including Disks, tape drives (including DAT) and CD ROM drives. The following CD-ROM type systems are supported at this time: SoundBlaster SCSI and ProAudio Spectrum SCSI (cd) Mitsumi (all models) proprietary interface (mcd) Matsushita/Panasonic (Creative) CR-562/CR-563 proprietary interface (matcd) Sony proprietary interface (scd) ATAPI IDE interface (experimental and should be considered ALPHA quality!) (wcd) Ethernet cards

Allied-Telesis AT1700 and RE2000 cards SMC Elite 16 WD8013 Ethernet interface, and most other WD8003E, WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT based clones. SMC Elite Ultra is also supported. DEC EtherWORKS III NICs (DE203, DE204, and DE205) DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422) DEC DC21140/DC21141 based NICs: ASUS PCI-L101-TB Accton ENI1203 Cogent EM960PCI Compex CPXPCI/32C D-Link DE-530 DEC DE435 Danpex EN-9400P3 JCIS Condor JC1260 Linksys EtherPCI Mylex LNP101 SMC EtherPower 10/100 (Model 9332) SMC EtherPower (Model 8432) Zynx ZX342 DEC FDDI (DEFPA/DEFEA) NICs Fujitsu FMV-181 and FMV-182 Intel EtherExpress Isolan AT 4141-0 (16 bit) Isolink 4110 (8 bit) Novell NE1000, NE2000, and NE2100 ethernet interface. 3Com 3C501 cards 3Com 3C503 Etherlink II 3Com 3c505 Etherlink/+ 3Com 3C507 Etherlink 16/TP 3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III Toshiba ethernet cards PCMCIA ethernet cards from IBM and National Semiconductor are also supported.

Note: FreeBSD does not currently support PnP (plug-n-play) features present on some ethernet cards. If your card has PnP and is giving you problems, try disabling its PnP features. Miscellaneous devices

AST 4 port serial card using shared IRQ. ARNET 8 port serial card using shared IRQ. BOCA IOAT66 6 port serial card using shared IRQ. BOCA 2016 16 port serial card using shared IRQ. Cyclades Cyclom-y Serial Board. STB 4 port card using shared IRQ. SDL Communications Riscom/8 Serial Board. Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound, Gravis UltraSound MAX and Roland MPU-401 sound cards. FreeBSD currently does not support IBM's microchannel (MCA) bus, but support is apparently close to materializing. Details will be posted as the situation develops. Preparing for the installation

There are a number of different methods by which FreeBSD can be installed. The following describes what preparation needs to be done for each type. Before installing from CDROM

If your CDROM is of an unsupported type, such as an IDE CDROM, then please skip to . There is not a lot of preparatory work that needs to be done to successfully install from one of Walnut Creek's FreeBSD CDROMs (other CDROM distributions may work as well, though we cannot say for certain as we have no hand or say in how they're created). You can either boot into the CD installation directly from DOS using Walnut Creek's supplied ``install.bat'' batch file or you can make a boot floppy with the ``makeflp.bat'' command [NOTE: If you're using an IDE CDROM, use the inst_ide.bat or atapiflp.bat batch files instead]. For the easiest interface of all (from DOS), type ``view''. This will bring up a DOS menu utility that leads you through all the available options. If you are creating the boot floppy from a UNIX machine, see for examples. of how to create the boot floppy. Once you have booted from DOS or floppy, you should then be able to select CDROM as the media type in the Media menu and load the entire distribution from CDROM. No other types of installation media should be required. After your system is fully installed and you have rebooted from the hard disk, you can mount the cdrom at any time by typing: mount /cdrom Before removing the CD again, also note that it's necessary to first type: umount /cdrom. Don't just remove it from the drive! Special note: Before invoking the installation, be sure that the CDROM is in the drive so that the install probe can find it. This is also true if you wish the CDROM to be added to the default system configuration automatically during the install (whether or not you actually use it as the installation media). Finally, if you would like people to be able to FTP install FreeBSD directly from the CDROM in your machine, you will find it quite easy. After the machine is fully installed, you simply need to add the following line to the password file (using the vipw command): ftp:*:99:99::0:0:FTP:/cdrom:/nonexistent Anyone with network connectivity to your machine (and permission to log into it) can now chose a Media type of FTP and type in: ftp://your machine after picking ``Other'' in the ftp sites menu. Before installing from Floppy

If you must install from floppy disks, either due to unsupported hardware or just because you enjoy doing things the hard way, you must first prepare some floppies for the install. - The first floppy you'll need in addition to the boot.flp image is - ``floppies/root.flp'', which is somewhat special in that it's not a - DOS filesystem floppy at all, but rather a floppy "image" (it's - actually a gzip'd cpio file). You can create this floppy in the same - way that you created the boot floppy . Once this floppy is made, you can go on to make the distribution set floppies using ordinary DOS or UFS (if you're preparing the floppies on another FreeBSD machine) formatted diskettes. You will need, at minimum, as many 1.44MB or 1.2MB floppies as it takes to hold all files in the bin (binary distribution) directory. If you're preparing these floppies under DOS, then THESE floppies *must* be formatted using the MS-DOS FORMAT command. If you're using Windows, use the Windows File Manager format command. Do not trust Factory Preformatted floppies! Format them again yourself, just to make sure. Many problems reported by our users in the past have resulted from the use of improperly formatted media, which is why I'm taking such special care to mention it here! If you're creating the floppies from another FreeBSD machine, a format is still not a bad idea though you don't need to put a DOS filesystem on each floppy. You can use the `disklabel' and `newfs' commands to put a UFS filesystem on them instead, like so: disklabel -w -r fd0 floppy3 (use floppy5 for 1.2MB disks) newfs /dev/rfd0 Then you can mount and write to them like any other file system. After you have DOS formatted the floppies, you will need to copy the files onto them. The distribution files are split into chunks conveniently sized so that 5 of them will fit on a conventional 1.44MB floppy. Go through all your floppies, packing as many files as will fit on each one, until you have got all the distributions you want packed up in this fashion. Each distribution should go into a subdirectory on the floppy, e.g.: a:\bin\bin.aa, a:\bin\bin.ab, and so on. Once you come to the Media screen of the install, select ``Floppy'' and you will be prompted for the rest. Before installing from a MS-DOS partition

To prepare for installation from an MS-DOS partition, copy the files from the distribution into a directory called C:\FREEBSD. The directory tree structure of the CDROM must be partially reproduced within this directory so we suggest using the DOS xcopy command. For example, to prepare for a minimal installation of FreeBSD: C> MD C:\FREEBSD C> XCOPY /S E:\DISTS\BIN C:\FREEBSD\BIN\ C> XCOPY /S E:\FLOPPIES C:\FREEBSD\FLOPPIES\ assuming that C: is where you have free space and E: is where your CDROM is mounted. Note that you need the FLOPPIES directory because the root.flp image is needed during an MS-DOS installation. For as many `DISTS' you wish to install from MS-DOS (and you have free space for), install each one under C:\FREEBSD - the BIN dist is only the minimal requirement. If you have room on your MS-DOS partition for all the distributions, you could replace the last line above with: C> XCOPY /S E:\DISTS C:\FREEBSD\ which would copy all the subdirectories of E:\DISTS to C:\FREEBSD. Before installing from QIC/SCSI Tape

Installing from tape is probably the easiest method, short of an on-line install using FTP or a CDROM install. The installation program expects the files to be simply tar'ed onto the tape, so after getting all of the files for distribution you are interested in, simply tar them onto the tape with a command like: cd /freebsd/distdir tar cvf /dev/rwt0 (or /dev/rst0) dist1 .. dist2 Make sure that the `floppies/' directory is one of the ``dists'' given above, since the installation will look for `floppies/root.flp' on the tape. When you go to do the installation, you should also make sure that you leave enough room in some temporary directory (which you will be allowed to choose) to accommodate the full contents of the tape you have created. Due to the non-random access nature of tapes, this method of installation requires quite a bit of temporary storage. You should expect to require as much temporary storage as you have stuff written on tape. Note: When going to do the installation, the tape must be in the drive before booting from the boot floppy. The installation probe may otherwise fail to find it. Before installing over a network

You can do network installations over 3 types of communications links: Serial port SLIP or PPP Parallel port PLIP (laplink cable) Ethernet A standard ethernet controller (includes some PCMCIA). SLIP support is rather primitive, and limited primarily to hard-wired links, such as a serial cable running between a laptop computer and another computer. The link should be hard-wired as the SLIP installation does not currently offer a dialing capability; that facility is provided with the PPP utility, which should be used in preference to SLIP whenever possible. If you are using a modem, then PPP is almost certainly your only choice. Make sure that you have your service provider's information handy as you will need to know it fairly soon in the installation process. You will need to know, at the minimum, your service provider's IP address and possibly your own (though you can also leave it blank and allow PPP to negotiate it with your ISP). You also need to know how to use the various ``AT commands'' to dial the ISP with your particular modem as the PPP dialer provides only a very simple terminal emulator. If a hard-wired connection to another FreeBSD (2.0R or later) machine is available, you might also consider installing over a ``laplink'' parallel port cable. The data rate over the parallel port is much higher than what is typically possible over a serial line (up to 50k/sec), thus resulting in a quicker installation. Finally, for the fastest possible network installation, an ethernet adaptor is always a good choice! FreeBSD supports most common PC ethernet cards, a table of supported cards (and their required settings) is provided in . If you are using one of the supported PCMCIA ethernet cards, also be sure that it is plugged in before the laptop is powered on! FreeBSD does not, unfortunately, currently support hot insertion of PCMCIA cards. You will also need to know your IP address on the network, the netmask value for your address class, and the name of your machine. Your system administrator can tell you which values to use for your particular network setup. If you will be referring to other hosts by name rather than IP address, you will also need a name server and possibly the address of a gateway (if you are using PPP, it is your provider's IP address) to use in talking to it. If you do not know the answers to all or most of these questions, then you should really probably talk to your system administrator first before trying this type of installation. Once you have a network link of some sort working, the installation can continue over NFS or FTP. Preparing for NFS installation

NFS installation is fairly straight-forward: Simply copy the FreeBSD distribution files you want onto a server somewhere and then point the NFS media selection at it. If this server supports only ``privileged port'' access (as is generally the default for Sun workstations), you will need to set this option in the Options menu before installation can proceed. If you have a poor quality ethernet card which suffers from very slow transfer rates, you may also wish to toggle the appropriate Options flag. In order for NFS installation to work, the server must support subdir mounts, e.g., if your FreeBSD 2.1 distribution directory lives on: ziggy:/usr/archive/stuff/FreeBSD Then ziggy will have to allow the direct mounting of /usr/archive/stuff/FreeBSD, not just /usr or /usr/archive/stuff. In FreeBSD's /etc/exports file, this is controlled by the ``-alldirs'' option. Other NFS servers may have different conventions. If you are getting `Permission Denied' messages from the server then it is likely that you do not have this enabled properly. Preparing for FTP Installation

FTP installation may be done from any mirror site containing a reasonably up-to-date version of FreeBSD 2.1. A full menu of reasonable choices from almost anywhere in the world is provided by the FTP site menu. If you are installing from some other FTP site not listed in this menu, or you are having troubles getting your name server configured properly, you can also specify your own URL by selecting the ``Other'' choice in that menu. A URL can also be a direct IP address, so the following would work in the absence of a name server: ftp://192.216.222.4/pub/FreeBSD/2.1.0-RELEASE There are two FTP installation modes you can use: FTP Active For all FTP transfers, use ``Active'' mode. This will not work through firewalls, but will often work with older ftp servers that do not support passive mode. If your connection hangs with passive mode (the default), try active! FTP Passive For all FTP transfers, use ``Passive'' mode. This allows the user to pass through firewalls that do not allow incoming connections on random port addresses. Note: ACTIVE AND PASSIVE MODES ARE NOT THE SAME AS A `PROXY' CONNECTION, WHERE A PROXY FTP SERVER IS LISTENING ON A DIFFERENT PORT! In such instances, you should specify the URL as something like: ftp://foo.bar.com:1234/pub/FreeBSD Where ``1234'' is the port number of the proxy ftp server. Installing FreeBSD

Once you have taken note of the appropriate preinstallation steps, you should be able to install FreeBSD without any further trouble. Should this not be true, then you may wish to go back and re-read the relevant preparation section above for the installation media type you are trying to use, perhaps there is a helpful hint there that you missed the first time? If you are having hardware trouble, or FreeBSD refuses to boot at all, read the Hardware Guide provided on the boot floppy for a list of possible solutions. The FreeBSD boot floppy contains all the on-line documentation you should need to be able to navigate through an installation and if it does not then we would like to know what you found most confusing. Send your comments to . It is the objective of the FreeBSD installation program (sysinstall) to be self-documenting enough that painful ``step-by-step'' guides are no longer necessary. It may take us a little while to reach that objective, but that is the objective! Meanwhile, you may also find the following ``typical installation sequence'' to be helpful: Boot the boot floppy. After a boot sequence which can take anywhere from from 30 seconds to 3 minutes, depending on your hardware, you should be presented with a menu of initial choices. If the floppy does not boot at all, or the boot hangs at some stage, go read the Q&A section of the Hardware Guide for possible causes. Press F1. You should see some basic usage instructions on the menu system and general navigation. If you have not used this menu system before then PLEASE read this thoroughly! Select the Options item and set any special preferences you may have. Select a Custom or Express install, depending on whether or not you would like the installation to give you a high degree of control over each step of the installation or simply lead you through it, choosing reasonable defaults when possible. See details on both installation types below. The Configure menu choice allows you to further configure your FreeBSD installation by giving you menu-driven access to various system defaults. Some items, like networking, may be especially important if you did a CDROM/Tape/Floppy installation and have not yet configured your network interfaces (assuming you have any). Properly configuring such interfaces here will allow FreeBSD to come up on the network when you first reboot from the hard disk. Express installation

The express installation is not too much different than the Custom one except that it leads you through the required stages in the proper order and presents you with various helpful prompts along the way. The first step is the `Partition Editor', which allows you to chose how your drives will be used for FreeBSD. If you are dedicating an entire drive to FreeBSD, the `A' command is probably all you need to type here. Next, with the `Label Editor', you can specify how the space in any allocated FreeBSD partitions should be used by FreeBSD, or where to mount a non-FreeBSD partition (such as DOS). If you want the standard layout, simply type `A' here. Next, the `Distributions' menu allows you to specify which parts of FreeBSD you wish to load. A good choice is ``User'' for a small system or ``Developer'' for someone wanting a bit more out of FreeBSD. If none of the existing collections sound applicable, select Custom. Next, the `Media' menu allows you to specify what kind of media you wish to install from. If a desired media choice is found and configured automatically then this menu will simply return, otherwise you will be asked for additional details on the media device type. Finally, you will be prompted to commit all of these actions at once (nothing has been written to your disk so far, nor will it until you give the final confirmation). All new or changed partition information will be written out, file systems will be created and/or non-destructively labeled (depending on how you set their newfs flags in the Label Editor) and all selected distributions will be extracted. At this point, you are generally done with the sysinstall utility and can select the final `Quit'. If you are running it as an installer (e.g., before the system is all the way up) then the system will now reboot after you press return one last time. If you selected the boot manager option, you will see a small boot menu with an `F?' prompt. Press the function key for BSD (it will be shown) and you should boot up into FreeBSD off the hard disk. If this fails to happen for some reason, see the Q&A section of the Hardware Guide for possible clues! Custom installation

You can do anything you like in this menu without altering your system except for ``Commit'', which will perform any requests to alter your system you may have made. Some of the menu options will also have direct `Write' commands available for committing an operation immediately, but they should only be used if you are absolutely sure it is necessary. It is generally better to make your changes and then commit them all at once so that you are left with the option of changing your mind up to the very last minute. If you are confused at any point, the F1 key usually pulls up the right information for the screen you are in. MS-DOS user's Questions and Answers

Many FreeBSD users wish to install FreeBSD on PCs inhabited by MS-DOS. Here are some commonly asked questions about installing FreeBSD on such systems.

Help! I have no space! Do I need to delete everything first? If your machine is already running MS-DOS and has little or no free space available for FreeBSD's installation, all is not lost! You may find the FIPS utility, provided in the tools directory on the FreeBSD CDROM or on the various FreeBSD ftp sites, to be quite useful. FIPS allows you to split an existing MS-DOS partition into two pieces, preserving the original partition and allowing you to install onto the second free piece. You first defragment your MS-DOS partition, using the DOS 6.xx DEFRAG utility or the Norton Disk tools, then run FIPS. It will prompt you for the rest of the information it needs. Afterwards, you can reboot and install FreeBSD on the new free slice. See the Distributions menu for an estimation of how much free space you will need for the kind of installation you want. Can I use compressed MS-DOS filesystems from FreeBSD? No. If you are using a utility such as Stacker(tm) or DoubleSpace(tm), FreeBSD will only be able to use whatever portion of the filesystem you leave uncompressed. The rest of the filesystem will show up as one large file (the stacked/dblspaced file!). Do not remove that file! You will probably regret it greatly! It is probably better to create another uncompressed MS-DOS primary partition and use this for communications between MS-DOS and FreeBSD. Can I run MS-DOS binaries under FreeBSD? Not yet! We would like to add support for this someday, but are still lacking anyone to actually do the work. Ongoing work with Linux's DOSEMU utility may bring this much closer to being a reality sometime soon. Send mail to hackers@freebsd.org if you're interested in joining this effort! However, there is a nice application available in the called pcemu, that allows you to run many basic MS-DOS text-mode binaries by entirely emulating an 8088 CPU. diff --git a/handbook/kerneldebug.sgml b/handbook/kerneldebug.sgml index 6de50a5f04..1d28aa51b1 100644 --- a/handbook/kerneldebug.sgml +++ b/handbook/kerneldebug.sgml @@ -1,424 +1,424 @@ - + Kernel Debugging

Contributed by &a.paul; and &a.joerg; Debugging a kernel crash dump with kgdb

Here are some instructions for getting kernel debugging working on a crash dump, it assumes that you have enough swap space for a crash dump. If you have multiple swap partitions and the first one is too small to hold the dump, you can configure your kernel to use an alternate dump device (in the config kernel line), or you can specify an alternate using the dumpon(8) command. Dumps to non-swap devices, tapes for example, are currently not supported. Config your kernel using config -g. See for details on configuring the FreeBSD kernel. Use the dumpon(8) command to tell the kernel where to dump to (note that this will have to be done after configuring the partition in question as swap space via swapon(8)). This is normally arranged via /etc/sysconfig and /etc/rc. Alternatively, you can hard-code the dump device via the `dump' clause in the `config' line of your kernel config file. This is deprecated, use only if you want a crash dump from a kernel that crashes during booting. Note: In the following, the term `kgdb' refers to gdb run in `kernel debug mode'. This can be accomplished by either starting the gdb with the option -k, or by linking and starting it under the name kgdb. This is not being done by default, however. When the kernel has been built make a copy of it, say kernel.debug, and then run strip -x on the original. Install the original as normal. You may also install the unstripped kernel, but symbol table lookup time for some programs will drastically increase, and since the whole kernel is loaded entirely at boot time and cannot be swapped out later, several megabytes of physical memory will be wasted. If you are testing a new kernel, for example by typing the new kernel's name at the boot prompt, but need to boot a different one in order to get your system up and running again, boot it only into single user state using the -s flag at the boot prompt, and then perform the following steps: fsck -p mount -a -t ufs # so your file system for /var/crash is writable savecore -N /kernel.panicked /var/crash exit # ...to multi-user This instructs savecore(8) to use another kernel for symbol name extraction. It would otherwise default to the currently running kernel and most likely not do anything at all since the crash dump and the kernel symbols differ. Now, after a crash dump, go to /sys/compile/WHATEVER and run kgdb. From kgdb do: symbol-file kernel.debug exec-file /var/crash/kernel.0 core-file /var/crash/vmcore.0 and voila, you can debug the crash dump using the kernel sources just like you can for any other program. Here's a script log of a kgdb session illustrating the procedure. Long lines have been folded to improve readability, and the lines are - numbered for reference. Despite of this, it's a real-world error + numbered for reference. Despite this, it's a real-world error trace taken during the development of the pcvt console driver. 1:Script started on Fri Dec 30 23:15:22 1994 2:uriah # cd /sys/compile/URIAH 3:uriah # kgdb kernel /var/crash/vmcore.1 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done. 5:IdlePTD 1f3000 6:panic: because you said to! 7:current pcb at 1e3f70 8:Reading in symbols for ../../i386/i386/machdep.c...done. 9:(kgdb) where 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) 11:#1 0xf0115159 in panic () 12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) 13:#3 0xf010185e in db_fncall () 14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) 15:#5 0xf0101711 in db_command_loop () 16:#6 0xf01040a0 in db_trap () 17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) 18:#8 0xf019d2eb in trap_fatal (...) 19:#9 0xf019ce60 in trap_pfault (...) 20:#10 0xf019cb2f in trap (...) 21:#11 0xf01932a1 in exception:calltrap () 22:#12 0xf0191503 in cnopen (...) 23:#13 0xf0132c34 in spec_open () 24:#14 0xf012d014 in vn_open () 25:#15 0xf012a183 in open () 26:#16 0xf019d4eb in syscall (...) 27:(kgdb) up 10 28:Reading in symbols for ../../i386/i386/trap.c...done. 29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ 31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ 32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ 33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ 34:ss = -266427884}) (../../i386/i386/trap.c line 283) 35:283 (void) trap_pfault(&frame, FALSE); 36:(kgdb) frame frame->tf_ebp frame->tf_eip 37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. 38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) 40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 41:(kgdb) list 42:398 43:399 tp->t_state |= TS_CARR_ON; 44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ 45:401 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) 47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 48:404 #else 49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ 51:407 } 52:(kgdb) print tp 53:Reading in symbols for ../../i386/i386/cons.c...done. 54:$1 = (struct tty *) 0x1bae 55:(kgdb) print tp->t_line 56:$2 = 1767990816 57:(kgdb) up 58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) 60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); 61:(kgdb) up 62:#2 0xf0132c34 in spec_open () 63:(kgdb) up 64:#3 0xf012d014 in vn_open () 65:(kgdb) up 66:#4 0xf012a183 in open () 67:(kgdb) up 68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ 69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ 70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ 71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ 72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) 73:673 error = (*callp->sy_call)(p, args, rval); 74:(kgdb) up 75:Initial frame selected; you cannot go up. 76:(kgdb) quit 77:uriah # exit 78:exit 79: 80:Script done on Fri Dec 30 23:18:04 1994 Comments to the above script: trap() in the stack trace. tp->t_line refers to the line discipline of the console device here, which must be a rather small integer number.) Post-mortem analysis of a dump

What do you do if a kernel dumped core but you did not expect it, and it's therefore not compiled using config -g? Not everything is lost here. Don't panic! Of course, you still need to enable crash dumps. See above on the options you've got in order to do this. Go to your kernel compile directory, and edit the line containing COPTFLAGS?=-O. Add the -g option there (but don't change anything on the level of optimization). If you do already know roughly the probable location of the failing piece of code (e.g., the pcvt driver in the example above), remove all the object files for this code. Rebuild the kernel. Due to the time stamp change on the Makefile, there will be some other object files rebuild, for example trap.o. With a bit of luck, the added -g option won't change anything for the generated code, so you'll finally get a new kernel with similar code to the faulting one but some debugging symbols. You should at least verify the old and new sizes with the size(1) command. If there is a mismatch, you probably need to give up here. Go and examine the dump as described above. The debugging symbols might be incomplete for some places, as can be seen in the stack trace in the example above where some functions are displayed without line numbers and argument lists. If you need more debugging symbols, remove the appropriate object files and repeat the kgdb session until you know enough. All this is not guaranteed to work, but it will do it fine in most cases. On-line kernel debugging using DDB

While kgdb as an offline debugger provides a very high level of user interface, there are some things it cannot do. The most important ones being breakpointing and single-stepping kernel code. If you need to do low-level debugging on your kernel, there's an on- line debugger available called DDB. It allows to setting breakpoints, single-steping kernel functions, examining and changing kernel variables, etc. However, it cannot not access kernel source files, and only has access to the global and static symbols, not to the full debug information like kgdb. To configure your kernel to include DDB, add the option line options DDB to your config file, and rebuild. (See for details on configuring the FreeBSD kernel. Note that if you have an older version of the boot blocks, your debugger symbols might not be loaded at all. Update the boot blocks, the recent ones do load the DDB symbols automagically.) Once your DDB kernel is running, there are several ways to enter DDB. The first, and earliest way is to type the boot flag -d right at the boot prompt. The kernel will start up in debug mode and enter DDB prior to any device probing. Hence you are able to even debug the device probe/attach functions. The second scenario is a hot-key on the keyboard, usually Ctrl-Alt-ESC. For syscons, this can be remapped, and some of the distributed maps do this, so watch out. There's an option available for serial consoles that allows the use of a serial line BREAK on the console line to enter DDB (``options BREAK_TO_DEBUGGER'' in the kernel config file). It is not the default since there are a lot of crappy serial adapters around that gratuitously generate a BREAK condition for example when pulling the cable. The third way is that any panic condition will branch to DDB if the kernel is configured to use it. For this reason, it is not wise to configure a kernel with DDB for a machine running unattended. The DDB commands roughly resemble some gdb commands. The first you probably need is to set a breakpoint: b function-name b address Numbers are taken hexadecimal by default, but to make them distinct from symbol names, hexadecimal numbers starting with the letters a-f need to be preceded with 0x (for other numbers, this is optional). Simple expressions are allowed, for example: function-name + 0x103. To continue the operation of an interrupted kernel, simply type c To get a stack trace, use trace Note that when entering DDB via a hot-key, the kernel is currently servicing an interrupt, so the stack trace might be not of much use for you. If you want to remove a breakpoint, use del del address-expression The first form will be accepted immediately after a breakpoint hit, and deletes the current breakpoint. The second form can remove any breakpoint, but you need to specify the exact address, as it can be obtained from show b To single-step the kernel, try s This will step into functions, but you can make DDB trace them until the matching return statement is reached by n Note: this is different from gdb's `next' statement, it's like gdb's `finish'. To examine data from memory, use (for example): x/wx 0xf0133fe0,40 x/hd db_symtab_space x/bc termbuf,10 x/s stringbuf for word/halfword/byte access, and hexadecimal/decimal/character/ string display. The number after the comma is the object count. To display the next 0x10 items, simply use x ,10 Similarly, use x/ia foofunc,10 to disassemble the first 0x10 instructions of foofunc, and display them along with their offset from the beginning of foofunc. To modify the memory, use the write command: w/b termbuf 0xa 0xb 0 w/w 0xf0010030 0 0 The command modifier (b/h/w) specifies the size of the data to be written, the first following expression is the address to write to, the remainder is interpreted as data to write to successive memory locations. If you need to know the current registers, use show reg Alternatively, you can display a single register value by e.g. p $eax and modify it by set $eax new-value Should you need to call some kernel functions from DDB, simply say call func(arg1, arg2, ...) The return value will be printed. For a ps(1) style summary of all running processes, use ps Now you have now examined why your kernel failed, and you wish to reboot. Remember that, depending on the severity of previous malfunctioning, not all parts of the kernel might still be working as expected. Perform one of the following actions to shut down and reboot your system: call diediedie() will cause your kernel to dump core and reboot, so you can later analyze the core on a higher level with kgdb. This command usually must be followed by another `continue' statement. There is now an alias for this: `panic'. call boot(0) might be a good way to cleanly shut down the running system, sync() all disks, and finally reboot. As long as the disk and file system interfaces of the kernel are not damaged, this might be a good way for an almost clean shutdown. call cpu_reset() is the final way out of disaster and almost the same as hitting the Big Red Button. If you need a short command summary, simply type help However, it's highly recommended to have a printed copy of the ddb(4) manual page ready for a debugging session. Remember that it's hard to read the on-line manual while single-stepping the kernel. Debugging a console driver

Since you need a console driver to run DDB on, things are more complicated if the console driver itself is failing. You might remember the use of a serial console (either with modified boot blocks, or by specifying -h at the Boot: prompt), and hook up a standard terminal onto your first serial port. DDB works on any configured console driver, of course also on a serial console. diff --git a/handbook/memoryuse.sgml b/handbook/memoryuse.sgml index 65e6c653c4..a54eb68f6f 100644 --- a/handbook/memoryuse.sgml +++ b/handbook/memoryuse.sgml @@ -1,50 +1,50 @@ - + PC memory utilization

Contributed by &a.joerg;. 16 Apr 1995. A short description of how FreeBSD uses the memory on the i386 platform The boot sector will be loaded at 0:0x7c00, and relocates itself immediately to 0x7c0:0. (This is nothing magic, just an adjustment for the %cs selector, done by an ljmp.) It then loads the first 15 sectors at 0x10000 (segment BOOTSEG in the biosboot Makefile), and sets up the stack to work below 0x1fff0. After this, it jumps to the entry of boot2 within that code. I.e., it jumps over itself and the (dummy) partition table, and it's going to adjust the %cs selector---we are still in 16-bit mode there. boot2 asks for the boot file, and examines the a.out header. It masks the file entry point (usually 0xf0100000) by 0x00ffffff, and loads the file there. Hence the usual load point is 1 MB (0x00100000). During load, the boot code toggles back and forth between real and protected mode, to use the BIOS in real mode. The boot code itself uses segment selectors 0x18 and 0x20 for %cs and %ds/%es in protected mode, and 0x28 to jump back into real mode. The kernel is finally started with %cs 0x08 and %ds/%es/%ss 0x10, which refer to dummy descriptors covering the entire address space. -The kernel will be started at its load point. Since it's been linked +The kernel will be started at its load point. Since it has been linked for another (high) address, it will have to execute PIC until the page table and page directory stuff is setup properly, at which point paging will be enabled and the kernel will finally run at the address for which it was linked. Contributed by &a.davidg;. 16 Apr 1995. The physical pages immediately following the kernel BSS contain proc0's page directory, page tables, and upages. Some time later when the VM system is initialized, the physical memory between 0x1000-0x9ffff and the physical memory after the kernel (text+data+bss+proc0 stuff+other misc) is made available in the form of general VM pages and added to the global free page list. diff --git a/handbook/printing.sgml b/handbook/printing.sgml index d4f7f40c74..ac5cbd8394 100644 --- a/handbook/printing.sgml +++ b/handbook/printing.sgml @@ -1,3876 +1,3876 @@ Printing

Contributed by &a.kelly;30 September 1995 In order to use printers with FreeBSD, you'll need to set them up to work with the Berkeley line printer spooling system, also known as the LPD spooling system. It's the standard printer control system in FreeBSD. This section introduces the LPD spooling system, often simply called LPD. If you're already familiar with LPD or another printer spooling system, you may wish to skip to section . What the Spooler Does

LPD controls everything about a host's printers. It's responsible for a number of things: It controls access to attached printers and printers attached to other hosts on the network. It enables users to submit files to be printed; these submissions are known as It prevents multiple users from accessing a printer at the same time by maintaining a It can print It takes care of communications parameters for printers connected on serial ports. It can send jobs over the network to another LPD spooler on another host. It can run special filters to format jobs to be printed for various printer languages or printer capabilities. It can account for printer usage. Through a configuration file, and by providing the special filter programs, you can enable the LPD system to do all or some subset of the above for a great variety of printer hardware. Why You Should Use the Spooler

If you're the sole user of your system, you may be wondering why you should bother with the spooler when you don't need access control, header pages, or printer accounting. While it's possible to enable direct access to a printer, you should use the spooler anyway since LPD prints jobs in the background; you don't have to wait for data to be copied to the printer. LPD can conveniently run a job to be printed through filters to add date/time headers or convert a special file format (such as a TeX DVI file) into a format the printer will understand. You won't have to do these steps manually. Many free and commercial programs that provide a print feature usually expect to talk to the spooler on your system. By setting up the spooling system, you'll more easily support other software you may later add or already have. Setting Up the Spooling System

To use printers with the LPD spooling system, you'll need to set up both your printer hardware and the LPD software. This document describes two levels of setup: See section to learn how to connect a printer, tell LPD how to communicate with it, and print plain text files to the printer. See section to find out how to print a variety of special file formats, to print header pages, to print across a network, to control access to printers, and to do printer accounting. Simple Printer Setup

This section tells how to configure printer hardware and the LPD software to use the printer. It teaches the basics: Section gives some hints on connecting the printer to a port on your computer. Section shows how to setup the LPD spooler configuration file /etc/printcap. If you're setting up a printer that uses a network protocol to accept data to print instead of a serial or parallel interface, see . Although this section is called ``Simple Printer Setup,'' it's actually fairly complex. Getting the printer to work with your computer and the LPD spooler is the hardest part. The advanced options like header pages and accounting are fairly easy once you get the printer working. Hardware Setup

This section tells about the various ways you can connect a printer to your PC. It talks about the kinds of ports and cables, and also the kernel configuration you may need to enable FreeBSD to speak to the printer. If you've already connected your printer and have successfully printed with it under another operating system, you can probably skip to section . Ports and Cables

Nearly all printers you can get for a PC today support one or both of the following interfaces: Parallel interfaces are sometimes known as ``Centronics'' interfaces, named after the connector type on the printer. In general, serial interfaces are slower than parallel interfaces. Parallel interfaces usually offer just one-way communication (computer to printer) while serial gives you two-way. Many newer parallel ports can also receive data from the printer, but only few printers need to send data back to the computer. And FreeBSD doesn't support two-way parallel communication yet. Usually, the only time you need two-way communication with the printer is if the printer speaks PostScript. PostScript printers can be very verbose. In fact, PostScript jobs are actually programs sent to the printer; they needn't produce paper at all and may return results directly to the computer. PostScript also uses two-way communication to tell the computer about problems, such as errors in the PostScript program or paper jams. Your users may be appreciative of such information. Furthermore, the best way to do effective accounting with a PostScript printer requires two-way communication: you - ask the printer for its page count (how many pages it's + ask the printer for its page count (how many pages it has printed in its lifetime), then send the user's job, then ask again for its page count. Subtract the two values and you know how much paper to charge the user. So, which interface should you use? If you need two-way communication, use a serial port. FreeBSD does not yet support two-way communication over a parallel port. If you don't need two-way communication and can pick parallel or serial, prefer the parallel interface. It keeps a serial port free for other peripherals---such as a terminal or a modem---and is faster most of the time. It's also easier to configure. Finally, use whatever works. Parallel Ports

To hook up a printer using a parallel interface, connect the Centronics cable between the printer and the computer. The instructions that came with the printer, the computer, or both should give you complete guidance. Remember which parallel port you used on the computer. The first parallel port is /dev/lpt0 to FreeBSD; the second is /dev/lpt1, and so on. Serial Ports

To hook up a printer using a serial interface, connect the proper serial cable between the printer and the computer. The instructions that came with the printer, the computer, or both should give you complete guidance. If you're unsure what the ``proper serial cable'' is, you may wish to try one of the following alternatives: A A A You should also set up the communications parameters for the printer, usually through front-panel controls or DIP switches on the printer. Choose the highest bps (bits per second, sometimes Software Setup

This section describes the software setup necessary to print with the LPD spooling system in FreeBSD. Here's an outline of the steps involved: Configure your kernel, if necessary, for the port you're using for the printer; section tells you what you need to do. Set the communications mode for the parallel port, if you're using a parallel port; section gives details. Test if the operating system can send data to the printer. Section gives some suggestions on how to do this. Set up LPD for the printer by modifying the file /etc/printcap. Section shows you how. Kernel Configuration

The operating system kernel is compiled to work with a specific set of devices. The serial or parallel interface for your printer is a part of that set. Therefore, it might be necessary to add support for an additional serial or parallel port if your kernel isn't already configured for one. To find out if the kernel you're currently using supports a serial interface, type dmesg | grep sio where sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A then the kernel supports the port. To find out if the kernel supports a parallel interface, type dmesg | grep lpt where lpt0 at 0x378-0x37f on isa then the kernel supports the port. You might have to reconfigure your kernel in order for the operating system to recognize and use the parallel or serial port you're using for the printer. To add support for a serial port, see the section on kernel configuration. To add support for a parallel port, see that section Adding /dev Entries for the Ports

Even though the kernel may support communication along a serial or parallel port, you'll still need a software interface through which programs running on the system can send and receive data. That's what entries in the /dev directory are for. To add a /dev entry for a port: Become root with the Change to the /dev directory: cd /dev Type ./MAKEDEV where Type ls -l to make sure the device entry got created. Setting the Communication Mode for the Parallel Port

When you're using the parallel interface, you can choose whether FreeBSD should use interrupt-driven or polled communication with the printer. The The The interrupt-driven method is somewhat faster but uses up a precious IRQ line. You should use whichever one works. You can set the communications mode in two ways: by configuring the kernel or by using the To set the communications mode by configuring the kernel: Edit your kernel configuration file. Look for or add an If you want interrupt-driven mode, add the device lpt0 at isa? port? tty irq where If you want polled mode, don't add the device lpt0 at isa? port? tty vector lptintr Save the file. Then configure, build, and install the kernel, then reboot. See for more details. To set the communications mode with Type lptcontrol -i -u to set interrupt-driven mode for Type lptcontrol -p -u to set polled-mode for You could put these commands in your /etc/rc.local file to set the mode each time your system boots. See lptcontrol(8) for more information. Checking Printer Communications

Before proceeding to configure the spooling system, you should make sure the operating system can successfully send data to your printer. It's a lot easier to debug printer communication and the spooling system separately. To test the printer, we'll send some text to it. For printers that can immediately print characters sent to them, the program %!PS 100 100 moveto 300 300 lineto stroke 310 310 moveto /Helvetica findfont 12 scalefont setfont (Is this thing working?) show showpage Checking a Parallel Printer

This section tells you how to check if FreeBSD can communicate with a printer connected to a parallel port. To test a printer on a parallel port: Become root with Send data to the printer. If the printer can print plain text, then use lptest > /dev/lpt where If the printer understands PostScript or other printer language, then send a small program to the printer. Type cat > /dev/lpt Then, line by line, type the program Alternatively, you can put the program in a file and type cat /dev/lpt where You should see something print. Don't worry if the text doesn't look right; we'll fix such things later. Checking a Serial Printer

This section tells you how to check if FreeBSD can communicate with a printer on a serial port. To test a printer on a serial port: Become root with Edit the file /etc/remote. Add the following entry: printer:dv=/dev/ where Here's a sample entry for a printer connected via a serial line to the third serial port at 19200 bps with no parity: printer:dv=/dev/ttyd2:br#19200:pa=none Connect to the printer with tip printer If this step doesn't work, edit the file /etc/remote again and try using /dev/cuaa instead of /dev/ttyd. Send data to the printer. If the printer can print plain text, then use ~$lptest If the printer understands PostScript or other printer language, then send a small program to the printer. Type the program, line by line, Alternatively, you can put the program in a file and type ˜> where You should see something print. Don't worry if the text doesn't look right; we'll fix that later. Enabling the Spooler: The /etc/printcap File

At this point, your printer should be hooked up, your kernel configured to communicate with it (if necessary), and you've been able to send some simple data to the printer. Now, we're ready to configure LPD to control access to your printer. You configure LPD by editing the file /etc/printcap. The LPD spooling system reads this file each time the spooler is used, so updates to the file take immediate effect. The format of the /etc/printcap. The format is identical to other capability files like /usr/share/misc/termcap and /etc/remote. For complete information about the format, see the cgetent(3). The simple spooler configuration consists of the following steps: Pick a name (and a few convenient aliases) for the printer, and put them in the /etc/printcap file; see . Turn off header pages (which are on by default) by inserting the . Make a spooling directory, and specify its location with the . Set the /dev entry to use for the printer, and note it in /etc/printcap with the . Also, if the printer is on a serial port, set up the communication parameters with the . Install a plain text input filter; see Test the setup by printing something with the and . tells how to do this. Naming the Printer

The first (easy) step is to pick a name for your printer. It really doesn't matter whether you choose functional or whimsical names since you can also provide a number aliases for the printer. At least one of the printers specified in the /etc/printcap should have the alias /etc/printcap file. The name of the printer should start in the leftmost column. Separate each alias with a vertical bar and put a colon after the last alias. In the following example, we start with a skeletal /etc/printcap that defines two printers (a Diablo 630 line printer and a Panasonic KX-P4455 PostScript laser printer): # # /etc/printcap for host rose # rattan|line|diablo|lp|Diablo 630 Line Printer: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4: In this example, the first printer is named Suppressing Header Pages

The LPD spooling system will by default print a /etc/printcap. Here's the example /etc/printcap with # # /etc/printcap for host rose - no header pages anywhere # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh: Note how we used the correct format: the first line starts in the leftmost column, and subsequent lines are indented with a single TAB. Every line in an entry except the last ends in a backslash character. Making the Spooling Directory

The next step in the simple spooler setup is to make a /var/spool. It's not necessary to backup the contents of spooling directories, either. Recreating them is as simple as running mkdir /var/spool/printer-name However, if you have a lot of printers on your network, you might want to put the spooling directories under a single directory that you reserve just for printing with LPD. We'll do this for our two example printers mkdir /var/spool/lpd mkdir /var/spool/lpd/rattan mkdir /var/spool/lpd/bamboo chown daemon.daemon /var/spool/lpd/rattan chown daemon.daemon /var/spool/lpd/bamboo chmod 770 /var/spool/lpd/rattan chmod 770 /var/spool/lpd/bamboo Finally, you need to tell LPD about these directories using the /etc/printcap file. You specify the pathname of the spooling directory with the # # /etc/printcap for host rose - added spooling directories # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo: Note that the name of the printer starts in the first column but all other entries describing the printer should be indented with a tab and each line escaped with a backslash. If you don't specify a spooling directory with /var/spool/lpd as a default. Identifying the Printer Device

In section , we identified which entry in the /dev directory FreeBSD will use to communicate with the printer. Now, we tell LPD that information. When the spooling system has a job to print, it will open the specified device on behalf of the filter program (which is responsible for passing data to the printer). List the /dev entry pathname in the /etc/printcap file using the /etc/printcap: # # /etc/printcap for host rose - identified what devices to use # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5: If you don't specify the /etc/printcap file, LPD uses /dev/lp as a default. /dev/lp currently doesn't exist in FreeBSD. If the printer you're installing is connected to a parallel port, skip to the section . Otherwise, be sure to follow the instructions in the next section. Configuring Spooler Communication Parameters

For printers on serial ports, LPD can set up the bps rate, parity, and other serial communication parameters on behalf of the filter program that sends data to the printer. This is advantageous since It lets you try different communication parameters by simply editing the /etc/printcap file; you don't have to recompile the filter program. It enables the spooling system to use the same filter program for multiple printers which may have different serial communication settings. The following /etc/printcap capabilities control serial communication parameters of the device listed in the br#/ Sets the communications speed of the device to fc#/ Clears the flag bits fs#/ Sets the flag bits xc#/ Clears local mode bits xs#/ Sets local mode bits For more information on the bits for the /usr/include/sys/ioctl_compat.h. When LPD opens the device specified by the bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000c1:xs#0x820: Installing the Text Filter

We're now ready to tell LPD what text filter to use to send jobs to the printer. A . For our simple printer setup, the text filter can be a small shell script that just executes /bin/cat to send the job to the printer. FreeBSD comes with another filter called . First, let's make the shell script /usr/local/libexec/if-simple be a simple text filter. Put the following text into that file with your favorite text editor: #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. /bin/cat &ero;&ero; exit 0 exit 2 Make the file executable: chmod 555 /usr/local/libexec/if-simple And then tell LPD to use it by specifying it with the /etc/printcap. We'll add it to the two printers we have so far in the example /etc/printcap: # # /etc/printcap for host rose - added text filter # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:\ :if=/usr/local/libexec/if-simple: Trying It Out

You've reached the end of the simple LPD setup. Unfortunately, congratulations are not quite yet in order, since we've still got to test the setup and correct any problems. To test the setup, try printing something. To print with the LPD system, you use the command to generate some test text. To test the simple LPD setup:

Type: lptest 20 5 | lpr -P where /etc/printcap. To test the default printer, type !"#$%&ero;'()*+,-./01234 "#$%&ero;'()*+,-./012345 #$%&ero;'()*+,-./0123456 $%&ero;'()*+,-./01234567 %&ero;'()*+,-./012345678 To further test the printer, try downloading larger programs (for language-based printers) or running . Troubleshooting

After performing the simple test with /usr/local/libexec/if-simple prints a form feed after it sends the job to the printer: #!/bin/sh # # if-simple - Simple text input filter for lpd # Installed in /usr/local/libexec/if-simple # # Simply copies stdin to stdout. Ignores all filter arguments. # Writes a form feed character (\f) after printing job. /bin/cat &ero;&ero; printf "\f" &ero;&ero; exit 0 exit 2 !"#$%&ero;'()*+,-./01234 "#$%&ero;'()*+,-./012345 #$%&ero;'()*+,-./0123456 You've become another victim of the Printer received CR Printer prints CR Printer received LF Printer prints CR + LF Here are some ways to achieve this: Use the printer's configuration switches or control panel to alter its interpretation of these characters. Check your printer's manual to find out how to do this.

Have FreeBSD's serial line driver automatically convert LF to CR+LF. Of course, this works with printers on serial ports /etc/printcap file for the printer. Send an Here's an example text filter for printers that understand the Hewlett-Packard PCL escape codes. This filter makes the printer treat LF characters as a LF and CR; then it sends the job; then it sends a form feed to eject the last page of the job. It should work with nearly all Hewlett Packard printers. #!/bin/sh # # hpif - Simple text input filter for lpd for HP-PCL based printers # Installed in /usr/local/libexec/hpif # # Simply copies stdin to stdout. Ignores all filter arguments. # Tells printer to treat LF as CR+LF. Writes a form feed character # after printing job. printf "\033&ero;k2G" &ero;&ero; cat &ero;&ero; printf "\f" &ero;&ero; exit 0 exit 2 Here's an example /etc/printcap from a host called orchid. It has a single printer attached to its first parallel port, a Hewlett Packard LaserJet 3Si named # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif: Printer received CR Printer prints CR Printer received LF Printer prints CR + LF If the printer supports XON/XOFF flow control, have FreeBSD use it by specifying the TANDEM bit in the If the printer supports carrier flow control, specify the MDMBUF bit in the If the printer doesn't support any flow control, use some combination of the NLDELAY, TBDELAY, CRDELAY, VTDELAY, and BSDELAY bits in the /etc/printcap file. /etc/printcap file. For example, here's the entry for rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple:\ :lf=/var/log/rattan.log Then, try printing again. Check the log file (in our example, /var/log/rattan.log) to see any error messages that might appear. Based on the messages you see, try to correct the problem. If you don't specify a /dev/console as a default. Using Printers

This section tells you how to use printers you've setup with FreeBSD. Here's an overview of the user-level commands: There's also an administrative command, , used to control printers and their queues. All three of the commands /etc/printcap file. This enables you to submit, remove, and check on jobs for various printers. If you don't use the Printing Jobs

To print files, type lpr This prints each of the listed files to the default printer. If you list no files, lpr /etc/host.conf /etc/hosts.equiv To select a specific printer, type lpr -P This example prints a long listing of the current directory to the printer named ls -l | lpr -P rattan Because no files were listed for the . Checking Jobs

When you print with lpq -P bamboo shows the queue for the printer named bamboo is ready and printing Rank Owner Job Files Total Size active kelly 9 /etc/host.conf, /etc/hosts.equiv 88 bytes 2nd kelly 10 (standard input) 1635 bytes 3rd mary 11 ... 78519 bytes This shows three jobs in the queue for for details. Job number nine consists of two files; multiple files given on the waiting for bamboo to become ready (offline ?) kelly: 1st [job 009rose] /etc/host.conf 73 bytes /etc/hosts.equiv 15 bytes kelly: 2nd [job 010rose] (standard input) 1635 bytes mary: 3rd [job 011rose] /home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytes Removing Jobs

If you change your mind about printing a job, you can remove the job from the queue with the To remove the job from a specific printer, add the lprm -P bamboo 10 The Just use the lprm -P rattan - rose% lpr -P rattan myfile rose% rlogin orchid orchid% lpq -P rattan Rank Owner Job Files Total Size active seeyan 12 ... 49123 bytes 2nd kelly 13 myfile 12 bytes orchid% lprm -P rattan 13 rose: Permission denied orchid% logout rose% lprm -P rattan 13 dfA013rose dequeued cfA013rose dequeued rose% Beyond Plain Text: Printing Options

The Formatting and Conversion Options

The following lpr -P bamboo -d fish-report.dvi These options apply to every file in the job, so you can't mix (say) DVI and ditroff files together in a job. Instead, submit the files as separate jobs, using a different conversion option for each job. gives details. Here's an example: this command prints a nicely formatted version of the zcat /usr/share/man/man1/ls.1.gz | troff -t -man | lpr -t The Job Handling Options

The following options to .

This example prints three copies of lpr -#3 parser.c parser.h Header Page Options

These options to for information about setting up header pages. for details. Administrating Printers

As an administrator for your printers, you've had to install, set up, and test them. Using the Start and stop the printers Enable and disable their queues Rearrange the order of the jobs in each queue. First, a note about terminology: if a printer is /etc/printcap. Advanced Printer Setup

This section describes filters for printing specially formatted files, header pages, printing across networks, and restricting and accounting for printer usage. Filters

Although LPD handles network protocols, queuing, access control, and other aspects of printing, most of the ). However, in order to take advantage of format conversion, printer accounting, specific printer quirks, and so on, you should understand how filters work. It will ultimately be the filter's responsibility to handle these aspects. And the bad news is that most of the time /usr/libexec/lpr/lpf, that works with many printers that can print plain text. (It handles backspacing and tabs in the file, and does accounting, but that's about all it does.) There are also several filters and filter components in the FreeBSD ports collection. Here's what you'll find in this section: Section , tries to give an overview of a filter's role in the printing process. You should read this section to get an understanding of what's happening ``under the hood'' when LPD uses filters. This knowledge could help you anticipate and debug problems you might encounter as you install more and more filters on each of your printers. LPD expects every printer to be able to print plain text by default. This presents a problem for PostScript (or other language-based printers) which can't directly print plain text. Section tells you what you should do to overcome this problem. I recommend reading this section if you have a PostScript printer. PostScript is a popular output format for many programs. Even some people (myself included) write PostScript code directly. But PostScript printers are expensive. Section tells how you can further modify a printer's text filter to accept and print PostScript data on a Section tells about a way you can automate the conversion of specific file formats, such as graphic or typesetting data, into formats your printer can understand. After reading this section, you should be able to set up your printers such that users can type Section tells all about a not often used feature of LPD: output filters. Unless you're printing header pages (see ), you can probably skip that section altogether. Section describes How Filters Work

As mentioned before, a filter is an executable program started by LPD to handle the device-dependent part of communicating with the printer. When LPD wants to print a file in a job, it starts a filter program. It sets the filter's standard input to the file to print, its standard output to the printer, and its standard error to the error logging file (specified in the /etc/printcap, or /dev/console by default). Which filter LPD starts and the filter's arguments depend on what's listed in the /etc/printcap file and what arguments the user specified for the job on the for details). There are three kinds filters you can specify in /etc/printcap: The [-c] -w where /etc/printcap, default 132 A tells all about them. Conversion filters also need to do accounting, if you need printer accounting. Conversion filters are started with the following arguments: -x where The describe them. There are only two arguments to an output filter: -w which are identical to the text filters Filters should also The text filter that comes with the FreeBSD release, /usr/libexec/lpr/lpf, takes advantage of the page width and length arguments to determine when to send a form feed and how to account for printer usage. It uses the login, host, and accounting file arguments to make the accounting entries. If you're shopping for filters, see if they're LPD-compatible. If they are, they must support the argument lists described above. If you plan on writing filters for general use, then have them support the same argument lists and exit codes. Accommodating Plain Text Jobs on PostScript Printers

If you're the only user of your computer and PostScript (or other language-based) printer, and you promise to never send plain text to your printer and to never use features of various programs that will want to send plain text to your printer, then you don't need to worry about this section at all. But, if you would like to send both PostScript and plain text jobs to the printer, then you're urged to augment your printer setup. To do so, we have the text filter detect if the arriving job is plain text or PostScript. All PostScript jobs must start with ); if not, it should be shortly. You can fetch, build and install it yourself, of course. After installing /etc/printcap: :if=/usr/local/libexec/psif: You should also specify the #!/bin/sh # # psif - Print PostScript or plain text on a PostScript printer # Script version; NOT the version that comes with lprps # Installed in /usr/local/libexec/psif # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # PostScript job, print it. # echo $first_line &ero;&ero; cat &ero;&ero; printf "\004" &ero;&ero; exit 0 exit 2 else # # Plain text, convert it, then print it. # ( echo $first_line; cat ) | /usr/local/bin/textps &ero;&ero; printf "\004" &ero;&ero; exit 0 exit 2 fi In the above script, ) includes a full featured text-to-PostScript program called Simulating PostScript on Non-PostScript Printers

PostScript is the #!/bin/sh # # ifhp - Print Ghostscript-simulated PostScript on a DesJet 500 # Installed in /usr/local/libexec/hpif # # Treat LF as CR+LF: # printf "\033&ero;k2G" || exit 2 # # Read first two characters of the file # read first_line first_two_chars=`expr "$first_line" : '\(..\)'` if [ "$first_two_chars" = "%!" ]; then # # It's PostScript; use Ghostscript to scan-convert and print it # /usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 -sOutputFile=- - \ &ero;&ero; exit 0 else # # Plain text or HP/PCL, so just print it directly; print a form # at the end to eject the last page. # echo $first_line &ero;&ero; cat &ero;&ero; printf "\f" &ero;&ero; exit 2 fi exit 2 Finally, you need to notify LPD of the filter via the :if=/usr/local/libexec/hpif: That's it. You can type Conversion Filters

After completing the simple setup described in , the first thing you'll probably want to do is install conversion filters for your favorite file formats (besides plain ASCII text). Why Install Conversion Filters?

Conversion filters make printing various kinds of files easy. As an example, suppose we do a lot of work with the TeX typesetting system, and we have a PostScript printer. Every time we generate a DVI file from TeX, we can't print it directly until we convert the DVI file into PostScript. The command sequence goes like this: dvips seaweed-analysis.dvi lpr seaweed-analysis.ps By installing a conversion filter for DVI files, we can skip the hand conversion step each time by having LPD do it for us. Now, each time we get a DVI file, we're just one step away from printing it: lpr -d seaweed-analysis.dvi We got LPD to do the DVI file conversion for us by specifying the lists the conversion options. For each of the conversion options you want a printer to support, install a /etc/printcap. A conversion filter is like the text filter for the simple printer setup (see section ) except that instead of printing plain text, the filter converts the file into a format the printer can understand. Which Conversions Filters Should I Install?

You should install the conversion filters you expect to use. If you print a lot of DVI data, then a DVI conversion filter is in order. If you've got plenty of troff to print out, then you probably want a troff filter. The following table summarizes the filters that LPD works with, their capability entries for the /etc/printcap file, and how to invoke them with the /etc/printcap File type Capability lpr option ------------ ------------- ---------- cifplot cf -c DVI df -d plot gf -g ditroff nf -n FORTRAN text rf -f troff tf -t raster vf -v plain text if none, -p, or -l In our example, using /etc/printcap. Despite what others might contend, formats like FORTRAN text and plot are probably obsolete. At your site, you can give new meanings to these or any of the formatting options just by installing custom filters. For example, suppose you'd like to directly print Printerleaf files (files from the Interleaf desktop publishing program), but will never print plot files. You could install a Printerleaf conversion filter under the Installing Conversion Filters

Since conversion filters are programs you install outside of the base FreeBSD installation, they should probably go under /usr/local. The directory /usr/local/libexec is a popular location, since they they're specialized programs that only LPD will run; regular users shouldn't ever need to run them. To enable a conversion filter, specify its pathname under the appropriate capability for the destination printer in /etc/printcap. In our example, we'll add the DVI conversion filter to the entry for the printer named /etc/printcap file again, with the new # # /etc/printcap for host rose - added df filter for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: The DVI filter is a shell script named /usr/local/libexec/psdf. Here's that script: #!bin/sh # # DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@" This script runs ) with the arguments LPD passed to this script. More Conversion Filter Examples

Since there's no fixed set of steps to install conversion filters, let me instead provide more examples. Use these as guidance to making your own filters. Use them directly, if appropriate. This example script is a raster (well, GIF file, actually) conversion filter for a Hewlett Packard LaserJet III-Si printer: #!/bin/sh # # hpvf - Convert GIF files into HP/PCL, then print # Installed in /usr/local/libexec/hpvf PATH=/usr/X11R6/bin:$PATH; export PATH giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \ && exit 0 \ || exit 2 It works by converting the GIF file into a portable anymap, converting that into a portable graymap, converting that into a portable bitmap, and converting that into LaserJet/PCL-compatible data. Here's the /etc/printcap file with an entry for a printer using the above filter: # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf: The following script is a conversion filter for troff data from the groff typesetting system for the PostScript printer named #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops | /usr/local/libexec/lprps "$@" The above script makes use of #!/bin/sh # # pstf - Convert groff's troff data into PS, then print. # Installed in /usr/local/libexec/pstf # exec grops That's it. Here's the entry we need to add to /etc/printcap to enable the filter: :tf=/usr/local/libexec/pstf: Here's an example that might make old hands at FORTRAN blush. It's a FORTRAN-text filter for any printer that can directly print plain text. We'll install it for the printer #!/bin/sh # # hprf - FORTRAN text filter for LaserJet 3si: # Installed in /usr/local/libexec/hprf # printf "\033&ero;k2G" &ero;&ero; fpr &ero;&ero; printf "\f" &ero;&ero; exit 0 exit 2 And we'll add this line to the /etc/printcap for the printer :rf=/usr/local/libexec/hprf: Here's one final, somewhat complex example. We'll add a DVI filter to the LaserJet printer /etc/printcap with the location of the DVI filter: :df=/usr/local/libexec/hpdf: Now, for the hard part: making the filter. For that, we need a DVI-to-LaserJet/PCL conversion program. The FreeBSD ports collection (see ) has one: /dev/fd/0 for standard input is problematic. We can get around that problem by linking (symbolically) a temporary file name (one that ends in /dev/fd/0, thereby forcing /tmp directory has the sticky bit set. The filter can create the link, but it won't be able clean up when done and remove it since the link will belong to a different user. Instead, the filter will make the symbolic link in the current working directory, which is the spooling directory (specified by the /etc/printcap). This is a perfect place for filters to do their work, especially since there's (sometimes) more free disk space in the spooling directory than under /tmp. Here, finally, is the filter: #!/bin/sh # # hpdf - Print DVI data on HP/PCL printer # Installed in /usr/local/libexec/hpdf PATH=/usr/local/bin:$PATH; export PATH # # Define a function to clean up our temporary files. These exist # in the current directory, which will be the spooling directory # for the printer. # cleanup() { rm -f hpdf$$.dvi } # # Define a function to handle fatal errors: print the given message # and exit 2. Exiting with 2 tells LPD to don't try to reprint the # job. # fatal() { echo "$@" 1>&ero;2 cleanup exit 2 } # # If user removes the job, LPD will send SIGINT, so trap SIGINT # (and a few other signals) to clean up after ourselves. # trap cleanup 1 2 15 # # Make sure we're not colliding with any existing files. # cleanup # # Link the DVI input file to standard input (the file to print). # ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0" # # Make LF = CR+LF # printf "\033&ero;k2G" || fatal "Cannot initialize printer" # # Convert and print. Return value from dvilj2p doesn't seem to be # reliable, so we ignore it. # dvilj2p -M1 -q -e- dfhp$$.dvi # # Clean up and exit # cleanup exit 0 Automated Conversion: An Alternative To Conversion Filters

All these conversion filters accomplish a lot for your printing environment, but at the cost forcing the user to specify (on the Output Filters

The LPD spooling system supports one other type of filter that we've not yet explored: an output filter. An output filter is intended for printing plain text only, like the text filter, but with many simplifications. If you're using an output filter but no text filter, then LPD starts an output filter once for the entire job instead of once for each file in the job. LPD doesn't make any provision to identify the start or the end of files within the job for the output filter. LPD doesn't pass the user's login or host to the filter, so it's not intended to do accounting. In fact, it gets only two arguments: -w where Don't be seduced by an output filter's simplicity. If you'd like each file in a job to start on a different page an output filter . Furthermore, an output filter is actually ) only. LPD then expects the output filter to

The program /usr/libexec/lpr/lpf that comes with FreeBSD binary distribution is a text filter (input filter) that can indent output (job submitted with /etc/printcap file. It uses these values to determine how much text can fit on a page and how many pages were in a user's job. For more information on printer accounting, see . Header Pages -

If you've got If you have . Enabling Header Pages

In the , we turned off header pages by specifying /etc/printcap file. To enable header pages for a printer, just remove the #!/bin/sh # # hpof - Output filter for Hewlett Packard PCL-compatible printers # Installed in /usr/local/libexec/hpof printf "\033&ero;k2G" || exit 2 exec /usr/libexec/lpr/lpf Specify the path to the output filter in the for more information. Here's an example /etc/printcap file for the printer # # /etc/printcap for host orchid # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/hpif:\ :vf=/usr/local/libexec/hpvf:\ :of=/usr/local/libexec/hpof: Now, when users print jobs to for more /etc/printcap. Controlling Header Pages

By enabling header pages, LPD will produce a k ll ll k l l k l l k k eeee l l y y k k e e l l y y k k eeeeee l l y y kk k e l l y y k k e e l l y yy k k eeee lll lll yyy y y y y yyyy ll t l i t l oooo u u ttttt l ii n nnn eeee o o u u t l i nn n e e o o u u t l i n n eeeeee o o u u t l i n n e o o u uu t t l i n n e e oooo uuu u tt lll iii n n eeee r rrr oooo ssss eeee rr r o o s s e e r o o ss eeeeee r o o ss e r o o s s e e r oooo ssss eeee Job: outline Date: Sun Sep 17 11:04:58 1995 LPD appends a form feed after this text so the job starts - on a new page (unless you've got /etc/printcap). If you prefer, LPD can make a /etc/printcap file. The header page will look like this: rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995 Also by default, LPD prints the header page first, then the job. To reverse that, specify /etc/printcap. Accounting for Header Pages

Using LPD's built-in header pages enforces a particular paradigm when it comes to printer accounting: header pages must be Accept LPD's paradigm and make header pages free. Install an alternative to LPD, such as LPDng or PLP. Section tells more about other spooling software you can substitute for LPD. Write a /etc/printcap. Then again, all that might be too much trouble, and users will certainly appreciate the more generous system administrator who makes header pages free. Header Pages on PostScript Printers

As described above, LPD can generate a plain text header page suitable for many printers. Of course, PostScript can't directly print plain text, so the header page feature of LPD is useless---or mostly so. One obvious way to get header pages is to have every conversion filter and the text filter generate the header page. The filters should should use the user and host arguments to generate a suitable header page. The drawback of this method is that users will always get a header page, even if they submit jobs with #!/bin/sh # # make-ps-header - make a PostScript header page on stdout # Installed in /usr/local/libexec/make-ps-header # # # These are PostScript units (72 to the inch). Modify for A4 or # whatever size paper you're using: # page_width=612 page_height=792 border=72 # # Check arguments # if [ $# -ne 3 ]; then echo "Usage: `basename $0` " 1>&ero;2 exit 1 fi # # Save these, mostly for readability in the PostScript, below. # user=$1 host=$2 job=$3 date=`date` # # Send the PostScript code to stdout. # exec cat < Now, each of the conversion filters and the text filter can call this script to first generate the header page, and then print the user's job. Here's the DVI conversion filter from earlier in this document, modified to make a header page: #!/bin/sh # # DVI to PostScript printer filter # Installed in /usr/local/libexec/psdf # # Invoked by lpd when user runs lpr -d # orig_args="$@" fail() { echo "$@" 1>&ero;2 exit 2 } while getopts "x:y:n:h:" option; do case $option in x|y) ;; # Ignore n) login=$OPTARG ;; h) host=$OPTARG ;; *) echo "LPD started `basename $0` wrong." 1>&ero;2 exit 2 ;; esac done [ "$login" ] || fail "No login name" [ "$host" ] || fail "No host name" ( /u/kelly/freebsd/printing/filters/make-ps-header $login $host "DVI File" /usr/local/bin/dvips -f ) | eval /usr/local/libexec/lprps $orig_args Notice how the filter has to parse the argument list in order to determine the user and host name. The parsing for the other conversion filters is identical. The text filter takes a slightly different set of arguments, though (see section ). As we've mentioned before, the above scheme, though fairly simple, disables the ``suppress header page'' option (the : write an output filter that parses the LPD-generated header page and produces a PostScript version. If the user submits the job with Networked Printing

FreeBSD supports networked printing: sending jobs to remote printers. Networked printing generally refers to two different things: Accessing a printer attached to a remote host. You install a printer that has a conventional serial or parallel interface on one host. Then, you set up LPD to enable access to the printer from other hosts on the network. Section tells how to do this. Accessing a printer attached directly to a network. The printer has a network interface in addition (or in place of) a more conventional serial or parallel interface. Such a printer might work as follows: It might understand the LPD protocol and can even queue jobs from remote hosts. In this case, it acts just like a regular host running LPD. Follow the same procedure in section to set up such a printer. It might support a data stream network connection. In this case, you ``attach'' the printer to one host on the network by making that host responsible for spooling jobs and sending them to the printer. Section gives some suggestions on installing such printers. Printers Installed on Remote Hosts

The LPD spooling system has built-in support for sending jobs to other hosts also running LPD (or are compatible with LPD). This feature enables you to install a printer on one host and make it accessible from other hosts. It also works with printers that have network interfaces that understand the LPD protocol. To enable this kind of remote printing, first install a printer on one host, the . Do any advanced setup in that you need. Make sure to test the printer and see if it works with the features of LPD you've enabled. If you're using a printer with a network interface that's compatible with LPD, then the /etc/printcap files with the following: Name the entry anything you want. For simplicity, though, you probably want to use the same name and aliases as on the printer host. Leave the Make a spooling directory and specify its location in the Place the name of the printer host in the Place the printer name on the That's it. You don't need to list conversion filters, page dimensions, or anything else in the /etc/printcap file. Here's an example. The host rose has two printers, /etc/printcap file for orchid (back from section ). It already had the entry for the printer # # /etc/printcap for host orchid - added (remote) printers on rose # # # teak is local; it's connected directly to orchid: # teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: # # rattan is connected to rose; send jobs for rattan to rose: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: # # bamboo is connected to rose as well: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo: Then, we just need to make spooling directories on orchid: mkdir -p /var/spool/lpd/rattan /var/spool/lpd/bamboo chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo chown daemon.daemon /var/spool/lpd/rattan /var/spool/lpd/bamboo Now, users on orchid can print to lpr -P bamboo -d sushi-review.dvi the LPD system on orchid would copy the job to the spooling directory /var/spool/lpd/bamboo and note that it was a DVI job. As soon as the host rose has room in its Printers with Networked Data Stream Interfaces

Often, when you buy a network interface card for a printer, you can get two versions: one which emulates a spooler (the more expensive version), or one which just lets you send data to it as if you were using a serial or parallel port (the cheaper version). This section tells how to use the cheaper version. For the more expensive one, see the previous section . The format of the /etc/printcap file lets you specify what serial or parallel interface to use, and (if you're using a serial interface), what baud rate, whether to use flow control, delays for tabs, conversion of newlines, and more. But there's no way to specify a connection to a printer that's listening on a TCP/IP or other network port. To send data to a networked printer, you need to develop a communications program that can be called by the text and conversion filters. Here's one such example: the script #!/usr/bin/perl # # netprint - Text filter for printer attached to network # Installed in /usr/local/libexec/netprint # $#ARGV eq 1 || die "Usage: $0 "; $printer_host = $ARGV[0]; $printer_port = $ARGV[1]; require 'sys/socket.ph'; ($ignore, $ignore, $protocol) = getprotobyname('tcp'); ($ignore, $ignore, $ignore, $ignore, $address) = gethostbyname($printer_host); $sockaddr = pack('S n a4 x8', &ero;AF_INET, $printer_port, $address); socket(PRINTER, &ero;PF_INET, &ero;SOCK_STREAM, $protocol) || die "Can't create TCP/IP stream socket: $!"; connect(PRINTER, $sockaddr) || die "Can't contact $printer_host: $!"; while () { print PRINTER; } exit 0; We can then use this script in various filters. Suppose we had a Diablo 750-N line printer connected to the network. The printer accepts data to print on port number 5100. The host name of the printer is scrivener. Here's the text filter for the printer: #!/bin/sh # # diablo-if-net - Text filter for Diablo printer `scrivener' listening # on port 5100. Installed in /usr/local/libexec/diablo-if-net # exec /usr/libexec/lpr/lpf "$@" | /usr/local/libexec/netprint scrivener 5100 Restricting Printer Usage

This section gives information on restricting printer usage. The LPD system lets you control who can access a printer, both locally or remotely, whether they can print multiple copies, how large their jobs can be, and how large the printer queues can get. Restricting Multiple Copies

The LPD system makes it easy for users to print multiple copies of a file. Users can print jobs with /etc/printcap file. When users submit jobs with the lpr: multiple copies are not allowed Note that if you've set up access to a printer remotely (see section ), you need the /etc/printcap files as well, or else users will still be able to submit multiple-copy jobs by using another host. Here's an example. This is the /etc/printcap file for the host rose. The printer # # /etc/printcap for host rose - restrict multiple copies on bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Now, we also need to add the /etc/printcap (and while we're at it, let's disable multiple copies for the printer # # /etc/printcap for host orchid - no multiple copies for local # printer teak or remote printer bamboo teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc: By using the lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.sign There are many ways to prevent this abuse (including ignoring it) which you are free to explore. Restricting Access To Printers

You can control who can print to what printers by using the UNIX group mechanism and the /etc/printcap. Just place the users you want to have access to a printer in a certain group, and then name that group in the lpr: Not a member of the restricted group if they try to print to the controlled printer. As with the ). For example, we'll let anyone access the printer /etc/printcap for host rose: # # /etc/printcap for host rose - restricted group for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Let's leave the other example /etc/printcap file (for the host orchid) alone. Of course, anyone on orchid can print to Controlling Sizes of Jobs Submitted

If you have many users accessing the printers, you probably need to put an upper limit on the sizes of the files users can submit to print. After all, there's only so much free space on the filesystem that houses the spooling directories, and you also need to make sure there's room for the jobs of other users. LPD enables you to limit the maximum byte size a file in a job can be with the # # /etc/printcap for host rose # # # No limit on job size: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: # # Limit of five megabytes: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: Again, the limits apply to the local users only. If you've set up access to your printers remotely, remote users won't get those limits. You'll need to specify the /etc/printcap files as well. See section for more information on remote printing. There's another specialized way to limit job sizes from remote printers; see section . Restricting Jobs from Remote Printers

The LPD spooling system provides several ways to restrict print jobs submitted from remote hosts: /etc/hosts.equiv and /etc/hosts.lpd. LPD checks to see if an incoming request is from a host listed in either one of these files. If not, LPD refuses the request. The format of these files is simple: one host name per line. Note that the file /etc/hosts.equiv is also used by the ruserok(3) protocol, and affects programs like /etc/hosts.lpd file on the host rose: orchid violet madrigal.fishbaum.de This means rose will accept requests from the hosts orchid, violet, and madrigal.fishbaum.de. If any other host tries to access rose's LPD, LPD will refuse them. /etc/printcap to find the spooling directory for this printer; here's bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:mx#5000:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf: The spooling directory is the given in the echo 6144 > /var/spool/lpd/bamboo/minfree /etc/printcap. When /usr/bin/false. Accounting for Printer Usage

So, you need to charge for printouts. And why not? Paper and ink cost money. And then there are maintenance costs---printers are loaded with moving parts and tend to break down. You've examined your printers, usage patterns, and maintenance fees and have come up with a per-page (or per-foot, per-meter, or per-whatever) cost. Now, how do you actually start accounting for printouts? Well, the bad news is the LPD spooling system doesn't provide much help in this department. Accounting is highly dependent on the kind of printer in use, the formats being printed, and . Generally, there are two ways to do accounting: The LPD spooling system supports both methods easily: since you have to provide the filters (well, most of the time), you also have to provide the accounting code. But there is a bright side: you have enormous flexibility in your accounting methods. For example, you choose whether to use periodic or timely accounting. You choose what information to log: user names, host names, job types, pages printed, square footage of paper used, how long the job took to print, and so forth. And you do so by modifying the filters to save this information. Quick and Dirty Printer Accounting

FreeBSD comes with two programs that can get you set up with simple periodic accounting right away. They are the text filter , and ), LPD starts the text and the conversion filters with the name of the accounting file to use on the filter command line. The filters can use this argument to know where to write an accounting file entry. The name of this file comes from the /etc/printcap, and if not specified as an absolute path, is relative to the spooling directory. LPD starts 2.00 rose:andy 3.00 rose:kelly 3.00 orchid:mary 5.00 orchid:mary 2.00 orchid:zhang You should use a separate accounting file for each printer, as /etc/printcap. Then, each accounting file will be in the spooling directory for a printer, in a file named Login pages/feet runs price orchid:kelly 5.00 1 $ 0.10 orchid:mary 31.00 3 $ 0.62 orchid:zhang 9.00 1 $ 0.18 rose:andy 2.00 1 $ 0.04 rose:kelly 177.00 104 $ 3.54 rose:mary 87.00 32 $ 1.74 rose:root 26.00 12 $ 0.52 total 337.00 154 $ 6.74 These are the arguments /etc/printcap. /etc/printcap, or two cents (the default). You can specify In the default summary that Login pages/feet runs price andy 2.00 1 $ 0.04 kelly 182.00 105 $ 3.64 mary 118.00 35 $ 2.36 root 26.00 12 $ 0.52 zhang 9.00 1 $ 0.18 total 337.00 154 $ 6.74 To compute the dollar amount due, /etc/printcap file (default of 200, or 2 cents per page). Specify, in hundreths of cents, the price per page or per foot you want to charge for printouts in this capability. You can override this value when you run pac -p1.50 makes each page cost one dollar and fifty cents. You can really rake in the profits by using this option. Finally, running How Can You Count Pages Printed?

In order to perform even remotely accurate accounting, you need to be able to determine how much paper a job uses. This is the essential problem of printer accounting. For plain text jobs, the problem's not that hard to solve: you count how many lines are in a job and compare it to how many lines per page your printer supports. Don't forget to take into account backspaces in the file which overprint lines, or long logical lines that wrap onto one or more additional physical lines. The text filter ) takes into account these things when it does accounting. If you're writing a text filter which needs to do accounting, you might want to examine Alternatives to the Standard Spooler

If you've been reading straight through this manual, by now you've learned just about everything there is to know about the LPD spooling system that comes with FreeBSD. You can probably appreciate many of its shortcomings, which naturally leads to the question: ``What other spooling systems are out there (and work with FreeBSD)?'' Unfortunately, I've located only . There's also a . It's quite similar to the BSD LPD spooler, but boasts a host of features, including: Better network support, including built-in support for networked printers, NIS-maintained printcaps, and NFS-mounted spooling directories Sophisticated queue management, allowing multiple printers on a queue, transfer of jobs between queues, and queue redirection Remote printer control functions Prioritization of jobs Expansive security and access options . Acknowledgments

I'd like to thank the following people who have assisted in the development of this document: diff --git a/handbook/scsi.sgml b/handbook/scsi.sgml index 532b8cea38..892e1ff084 100644 --- a/handbook/scsi.sgml +++ b/handbook/scsi.sgml @@ -1,798 +1,798 @@ - + What is SCSI?

Copyright © 1995, &a.wilko;.3 September 1995. SCSI is an acronym for Small Computer Systems Interface. It is an ANSI standard that has become one of the leading I/O buses in the computer industry. The foundation of the SCSI standard was laid by Shugart Associates (the same guys that gave the world the first mini floppy disks) when they introduced the SASI bus (Shugart Associates Standard Interface). After some time an industry effort was started to come to a more strict standard allowing devices from different vendors to work together. This effort was recognized in the ANSI SCSI-1 standard. The SCSI-1 standard (approx 1985) is now more or less obsolete. The current standard is SCSI-2 (see ), with SCSI-3 on the drawing boards. In addition to a physical interconnection standard, SCSI defines a logical (command set) standard to which disk devices must adhere. This standard is called the Common Command Set (CCS) and was developed more or less in parallel with ANSI SCSI-1. SCSI-2 includes the (revised) CCS as part of the standard itself. The commands are dependent on the type of device at hand. It does not make much sense of course to define a Write command for a scanner. The SCSI bus is a parallel bus, which comes in a number of variants. The oldest and most used is an 8 bit wide bus, with single-ended signals, carried on 50 wires. (If you don't know what single-ended means, don't worry, that is what this document is all about.) Modern designs also use 16 bit wide buses, with differential signals. This allows transfer speeds of 20Mbytes/second, on cables lengths of up to 25 meters. SCSI-2 allows a maximum bus width of 32 bits, using an additional cable. Of course the SCSI bus not only has data lines, but also a number of control signals. A very elaborate protocol is part of the standard to allow multiple devices to share the bus in an efficient manner. In SCSI-2, the data is always checked using a separate parity line. In pre-SCSI-2 designs parity was optional. In SCSI-3 even faster bus types are introduced, along with a serial SCSI bus that reduces the cabling overhead and allows a higher maximum bus length. As you could have guessed from the description above, SCSI devices are intelligent. They have to be to adhere to the SCSI standard (which is over 2 inches thick BTW). So, for a hard disk drive for instance you do not specify a head/cylinder/sector to address a particular block, but simply the number of the block you want. Elaborate caching schemes, automatic bad block replacement etc are all made possible by this 'intelligent device' approach. On a SCSI bus, each possible pair of devices can communicate. Whether their function allows this is another matter, but the standard does not restrict it. To avoid signal contention, the 2 devices have to arbitrate for the bus before using it. The philosophy of SCSI is to have a standard that allows older-standard devices to work with newer-standard ones. So, an old SCSI-1 device should normally work on a SCSI-2 bus. I say Normally, because it is not absolutely sure that the implementation of an old device follows the (old) standard closely enough to be acceptable on a new bus. Modern devices are usually more well-behaved, because the standardization has become more strict and is better adhered to by the device manufacturers. Generally speaking, the chances of getting a working set of devices on a single bus is better when all the devices are SCSI-2 or newer. This does not imply that you have to dump all your old stuff when you get that shiny 2Gb disk: I own a system on which a pre-SCSI-1 disk, a SCSI-2 QIC tape unit, a SCSI-1 helical scan tape unit and 2 SCSI-1 disks work together quite happily. Components of SCSI

As said before, SCSI devices are smart. The idea is to put the knowledge about intimate hardware details onto the SCSI device itself. In this way, the host system does not have to worry about things like how many heads are hard disks has, or how many tracks there are on a specific tape device. If you are curious, the standard specifies commands with which you can query your devices on their hardware particulars. The advantage of intelligent devices is obvious: the device drivers on the host can be made in a much more generic fashion, there is no longer a need to change (and qualify!) drivers for every odd new device that is introduced. For cabling and connectors there is a golden rule: get good stuff. With bus speeds going up all the time you will save yourself a lot of grief by using good material. So, gold plated connectors, shielded cabling, sturdy connector hoods with strain reliefs etc are the way to go. Second golden rule: don't use cables longer than necessary. I once spent 3 days hunting down a problem with a flaky machine only to discover that shortening the SCSI bus by 1 meter solved the problem. And the original bus length was well within the SCSI specification. SCSI bus types

From an electrical point of view, there are two incompatible bus types: single-ended and differential. This means that there are two different main groups of SCSI devices and controllers, which cannot be mixed on the same bus. It is possible however to use special converter hardware to transform a single-ended bus into a differential one (and vice versa). The differences between the bus types are explained in the next sections. In lots of SCSI related documentation there is a sort of jargon in use to abbreviate the different bus types. A small list: FWD: Fast Wide Differential FND: Fast Narrow Differential SE: Single Ended FN: Fast Narrow etc. With a minor amount of imagination one can usually imagine what is meant. Wide is a bit ambiguous, it can indicate 16 or 32 bit buses. As far as I know, the 32 bit variant is not (yet) in use, so wide normally means 16 bit. Fast means that the timing on the bus is somewhat different, so that on a narrow (8 bit) bus 10 Mbytes/sec are possible instead of 5 Mbytes/sec for 'slow' SCSI. More on this later. It should be noted that the data lines > 8 are only used for data transfers and device addressing. The transfers of commands and status messages etc are only performed on the lowest 8 data lines. The standard allows narrow devices to operate on a wide bus. The usable bus width is negotiated between the devices. You have to watch your device addressing closely when mixing wide and narrow. Single ended buses

A single-ended SCSI bus uses signals that are either 5 Volts or 0 Volts (indeed, TTL levels) and are relative to a COMMON ground reference. A singled ended 8 bit SCSI bus has approximately 25 ground lines, who are all tied to a single `rail' on all devices. A standard single ended bus has a maximum length of 6 meters. If the same bus is used with fast-SCSI devices, the maximum length allowed drops to 3 meters. Fast-SCSI means that instead of 5Mbytes/sec the bus allows 10Mbytes/sec transfers. Please note that this means that if some devices on your bus use 'fast' to communicate your bus must adhere to the length restrictions for fast buses! It is obvious that with the newer fast-SCSI devices the bus length can become a real bottleneck. This is why the differential SCSI bus was introduced in the SCSI-2 standard. For connector pinning and connector types please refer to the SCSI-2 standard (see ) itself, connectors etc are listed there in painstaking detail. Beware of devices using non-standard cabling. For instance Apple uses a 25pin D-type connecter (like the one on serial ports and parallel printers). Considering that the official SCSI bus needs 50 pins you can imagine the use of this connector needs some 'creative cabling'. The reduction of the number of ground wires they used is a bad idea, you better stick to 50 pins cabling in accordance with the SCSI standard. Differential buses

A differential SCSI bus has a maximum length of 25 meters. Quite a difference from the 3 meters for a single-ended fast-SCSI bus. The idea behind differential signals is that - each bus signal has it's own return wire. So, each signal is + each bus signal has its own return wire. So, each signal is carried on a (preferably twisted) pair of wires. The voltage difference between these two wires determines whether the signal is asserted or de-asserted. To a certain extent the voltage difference between ground and the signal wire pair is not relevant (don't try 10 kVolts though..). It is beyond the scope of this document to explain why this differential idea is so much better. Just accept that electrically seen the use of differential signals gives a much better noise margin. You will normally find differential buses in use for inter-cabinet connections. Because of the lower cost single ended is mostly used for shorter buses like inside cabinets. There is nothing that stops you from using differential stuff with FreeBSD, as long as you use a controller that has device driver support in FreeBSD. As an example, Adaptec marketed the AH1740 as a single ended board, whereas the AH1744 was differential. The software interface to the host is identical for both. Terminators

Terminators in SCSI terminology are resistor networks that are used to get a correct impedance matching. Impedance matching is important to get clean signals on the bus, without reflections or ringing. If you once made a long distance telephone call on a bad line you probably know what reflections are. With 20Mbytes/sec traveling over your SCSI bus, you don't want signals echoing back. Terminators come in various incarnations, with more or less sophisticated designs. Of course, there are internal and external variants. Almost every SCSI device comes with a number of sockets in which a number of resistor networks can (must be!) installed. If you remove terminators from a device, carefully store 'm. You will need them when you ever decide to reconfigure your SCSI bus. There is enough variation in even these simple tiny things to make finding the exact replacement a frustrating business. There are also SCSI devices that have a single jumper to enable or disable a built-in terminator. There are special terminators you can stick onto a flat cable bus. Others look like external connectors, or a connector hood without a cable. So, lots of choice as you can see. There is much debate going on if and when you should switch from simple resistor (passive) terminators to active terminators. Active terminators contain slightly more elaborate circuit to give cleaner bus signals. The general consensus seems to be that the usefulness of active termination increases when you have long buses and/or fast devices. If you ever have problems with your SCSI buses you might consider trying an active terminator. Try to borrow one first, they reputedly are quite expensive. Please keep in mind that terminators for differential and single-ended buses are not identical. You should not mix the two variants. OK, and now where should you install your terminators? This is by far the most misunderstood part of SCSI. And it is by far the simplest.. The rule is: every SCSI bus has 2 (two) terminators, one at each end of the bus. So, two and not one or three or whatever. Do yourself a favor and stick to this rule. It will save you endless grief, because wrong termination has the potential to introduce highly mysterious bugs. A common pitfall is to have an internal (flat)cable in a machine and also an external cable attached to the controller. It seems almost everybody forgets to remove the terminators from the controller. The terminator must now be on the last external device, and not on the controller! In general, every reconfiguration of a SCSI bus must pay attention to this. What I did myself is remove all terminators from my SCSI devices and controllers. I own a couple of external terminators, for both the Centronics-type external cabling and for the internal flat cable connectors. This makes reconfiguration much easier. Terminator power

The terminators discussed in the previous chapter need power to operate properly. On the SCSI bus, a line is dedicated to this purpose. So, simple huh? - Not so. Each device can provide it's own terminator power to + Not so. Each device can provide its own terminator power to the terminator sockets it has on-device. But if you have external terminators, or when the device supplying the terminator power to the SCSI bus line is switched off you are in trouble. The idea is that initiators (these are devices that initiate actions on the bus, a discussion follows) must supply terminator power. All SCSI devices are allowed (but not required) to supply terminator power. To allow for switched-off devices on a bus, the terminator power must be supplied to the bus via a diode. This prevents the backflow of current to switched-off devices. To prevent all kinds of nastiness, the terminator power is usually fused. As you can imagine, fuses might blow. This can, but does not have to, lead to a non functional bus. If multiple devices supply terminator power, a single blown fuse will not put you out of business. A single supplier with a blown fuse certainly will. Clever external terminators sometimes have a LED indication that shows whether terminator power is present. In newer designs auto-restoring fuses that 'reset' themselves after some time are sometimes used. On modern devices, sometimes integrated terminators are used. These things are special purpose integrated circuits that can be dis/en-abled with a control pin. It is not necessary to physically remove them from a device. You may find them on newer host adapters, sometimes they even are software configurable, using some sort of setup tool. Consult you documentation! Device addressing

Because the SCSI bus is, ehh, a bus there must be a way to distinguish or address the different devices connected to it. This is done by means of the SCSI or target ID. Each device has a unique target ID. You can select the ID to which a device must respond using a set of jumpers, or a dip switch, or something similar. Consult the documentation of your device for more information. Beware of multiple devices configured to use the same ID. Chaos normally reigns in this case. For an 8 bit bus, a maximum of 8 targets is possible. The maximum is 8 because the selection is done bitwise using the 8 data lines on the bus. For wide this increases to the number of data lines. The higher the SCSI target ID, the higher the priority the devices has. When it comes to arbitration between devices that want to use the bus at the same time, the device that has the highest SCSI ID will win. This also means that the SCSI host adapter usually uses target ID 7 (for narrow buses). For a further subdivision, the standard allows for Logical Units or LUNs for short. A single target ID may have multiple LUNs. For example, a tape device including a tape changer may have LUN 0 for the tape device itself, and LUN 1 for the tape changer. In this way, the host system can address each of the parts of the tape unit as desired. Bus layout

SCSI buses are linear. So, not shaped like Y-junctions, star topologies, cobwebs or whatever else people might want to invent. You might notice that the terminator issue discussed earlier becomes rather hairy if your bus is not linear.. - The electrical characteristics, it's noise margins and + The electrical characteristics, its noise margins and ultimately the reliability of it all are tightly related to linear bus rule. Stick to the linear bus rule! Using SCSI with FreeBSD

About translations, BIOSes and magic...

As stated before, you should first make sure that you have a electrically sound bus. When you want to use a SCSI disk on your PC as boot disk, you must aware of some quirks related to PC BIOSes. The PC BIOS in - it's first incarnation used a low level physical interface to the + its first incarnation used a low level physical interface to the hard disk. So, you had to tell the BIOS (using a setup tool or a BIOS built-in setup) how your disk physically looked like. This involved stating number of heads, number of cylinders, number of sectors per track, obscure things like precompensation and reduced write current cylinder etc. One might be inclined to think that since SCSI disks are smart you can forget about this. Alas, the arcane setup issue is still present today. The system BIOS needs to know how to access your SCSI disk with the head/cyl/sector method in order to load the FreeBSD kernel during boot. The SCSI host adapter or SCSI controller you have put in your - AT/EISA/PCI/whatever bus to connect your disk therefore has it's + AT/EISA/PCI/whatever bus to connect your disk therefore has its own on-board BIOS. During system startup, the SCSI BIOS takes over the hard disk interface routines from the system BIOS. To fool the system BIOS, the system setup is normally set to No hard disk present. Obvious, isn't it? The SCSI BIOS itself presents to the system a so called translated drive. This means that a fake drive table is constructed that allows the PC to boot the drive. This translation is often (but not always) done using a pseudo drive with 64 heads and 32 sectors per track. By varying the number of cylinders, the SCSI BIOS adapts to the actual drive size. It is useful to note that 32 * 64 / 2 = the size of your drive in megabytes. The division by 2 is to get from disk blocks that are normally 512 bytes in size to Kbytes. Right.. All is well now?! No, it isn't. The system BIOS has another quirk you might run into. The number of cylinders of a bootable hard disk cannot be greater than 1024. Using the translation above, this is a show-stopper for disks greater than 1 Gb. With disk capacities going up all the time this is causing problems. Fortunately, the solution is simple: just use another translation, e.g. with 128 heads instead of 32. In most cases new SCSI BIOS versions are available to upgrade older SCSI host adapters. Some newer adapters have an option, in the form of a jumper or software setup selection, to switch the translation the SCSI BIOS uses. It is very important that all operating systems on the disk use the same translation to get the right idea about where to find the relevant partitions. So, when installing FreeBSD you must answer any questions about heads/cylinders etc using the translated values your host adapter uses. Failing to observe the translation issue might lead to un-bootable systems or operating systems overwriting each others partitions. Using fdisk you should be able to see all partitions. You might have heard some talk of 'lying' devices? Older FreeBSD kernels used to report the geometry of SCSI disks when booting. An example from one of my systems: aha0 targ 0 lun 0: sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512 Newer kernels usually don't report this information.. e.g. (bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2 sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors) Why has this changed? This info is retrieved from the SCSI disk itself. Newer disks often use a technique called zone bit recording. The idea is that on the outer cylinders of the drive there is more space so more sectors per track can be put on them. This results in disks that have more tracks on outer cylinders than on the inner cylinders and, last but not least, have more capacity. You can imagine that the value reported by the drive when inquiring about the geometry now becomes suspect at best, and nearly always misleading. When asked for a geometry , it is nearly always better to supply the geometry used by the BIOS, or if the BIOS is never going to know about this disk, (e.g. it is not a booting disk) to supply a fictitious geometry that is convenient. SCSI subsystem design

FreeBSD uses a layered SCSI subsystem. For each different controller card a device driver is written. This driver knows all the intimate details about the hardware it controls. The driver has a interface to the upper layers of the - SCSI subsystem through which it receives it's commands and + SCSI subsystem through which it receives its commands and reports back any status. On top of the card drivers there are a number of more generic drivers for a class of devices. More specific: a driver for tape devices (abbreviation: st), magnetic disks (sd), cdroms (cd) etc. In case you are wondering where you can find this stuff, it all lives in /sys/scsi. See the man pages in section 4 for more details. The multi level design allows a decoupling of low-level bit banging and more high level stuff. Adding support for another piece of hardware is a much more manageable problem. Kernel configuration

Dependent on your hardware, the kernel configuration file must contain one or more lines describing your host adapter(s). This includes I/O addresses, interrupts etc. Consult the man page for your adapter driver to get more info. Apart from that, check out /sys/i386/conf/LINT for an overview of a kernel config file. LINT contains every possible option you can dream of. It does not imply LINT will actually get you to a working kernel at all. Although it is probably stating the obvious: the kernel config file should reflect your actual hardware setup. So, interrupts, I/O addresses etc must match the kernel config file. During system boot messages will be displayed to indicate whether the configured hardware was actually found. An example loosely based on the FreeBSD 2.0.5-Release kernel config file LINT with some added comments (between []): # SCSI host adapters: `aha', `ahb', `aic', `bt', `nca' # # aha: Adaptec 154x # ahb: Adaptec 174x # ahc: Adaptec 274x/284x/294x # aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!) # bt: Most Buslogic controllers # nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130 # uha: UltraStore 14F and 34F # sea: Seagate ST01/02 8 bit controller (slow!) # wds: Western Digital WD7000 controller (no scatter/gather!). # [For an Adaptec AHA274x, 284x etc controller] controller ahc0 at isa? bio irq ? vector ahcintr # port??? iomem? [For an Adaptec AHA174x controller] controller ahb0 at isa? bio irq ? vector ahbintr [For an Ultrastor adapter] controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr # Map SCSI buses to specific SCSI adapters controller scbus0 at ahc0 controller scbus2 at ahb0 controller scbus1 at uha0 # The actual SCSI devices disk sd0 at scbus0 target 0 unit 0 [SCSI disk 0 is at scbus 0, LUN 0] disk sd1 at scbus0 target 1 [implicit LUN 0 if omitted] disk sd2 at scbus1 target 3 [SCSI disk on the uha0] disk sd3 at scbus2 target 4 [SCSI disk on the ahb0] tape st1 at scbus0 target 6 [SCSI tape at target 6] device cd0 at scbus? [the first ever CDROM found, no wiring] The example above tells the kernel to look for a ahc (Adaptec 274x) controller, then for an Adaptec 174x board, and so on. The lines following the controller specifications tell the kernel to configure specific devices but only attach them when they match the target ID and LUN specified on the corresponding bus. Wired down devices get 'first shot' at the unit numbers so the first non 'wired down' device, is allocated the unit number one greater than the highest 'wired down' unit number for that kind of device. So, if you had a SCSI tape at target ID 2 it would be configured as st2, as the tape at target ID 6 is wired down to unit number 1. Note that wired down devices need not be found to get their unit number. The unit number for a wired down device is reserved for that device, even if it is turned off at boot time. This allows the device to be turned on and brought on-line at a later time, without rebooting. Notice that a device's - unit number has no relationship with it's target ID on + unit number has no relationship with its target ID on the SCSI bus. Below is another example of a kernel config file as used by FreeBSD version < 2.0.5. The difference with the first example is that devices are not 'wired down'. 'Wired down' means that you specify which SCSI target belongs to which device. A kernel built to the config file below will attach the first SCSI disk it finds to sd0, the second disk to sd1 etc. If you ever removed or added a disk, all other devices of the same type (disk in this case) would 'move around'. This implies you have to change /etc/fstab each time. Although the old style still works, you are strongly recommended to use this new feature. It will save you a lot of grief whenever you shift your hardware around on the SCSI buses. So, when you re-use your old trusty config file after upgrading from a pre-FreeBSD2.0.5.R system check this out. [driver for Adaptec 174x] controller ahb0 at isa? bio irq 11 vector ahbintr [for Adaptec 154x] controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr [for Seagate ST01/02] controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device sd0 [support for 4 SCSI harddisks, sd0 up sd3] device st0 [support for 2 SCSI tapes] [for the cdrom] device cd0 #Only need one of these, the code dynamically grows Both examples support SCSI disks. If during boot more devices of a specific type (e.g. sd disks) are found than are configured in the booting kernel, the system will simply allocate more devices, incrementing the unit number starting at the last number 'wired down'. If there are no 'wired down' devices then counting starts at unit 0. Use man 4 scsi to check for the latest info on the SCSI subsystem. For more detailed info on host adapter drivers use eg man 4 aha for info on the Adaptec 154x driver. Tuning your SCSI kernel setup

Experience has shown that some devices are slow to respond to INQUIRY commands after a SCSI bus reset (which happens at Boot time). An INQUIRY command is sent by the kernel on boot to see what kind of device (disk, tape, cdrom etc) is connected to a specific target ID. This process is called device probing by the way. To work around this problem, FreeBSD allows a tunable delay time before the SCSI devices are probed following a SCSI bus reset. You can set this delay time in your kernel configuration file using a line like: options "SCSI_DELAY=15" #Be pessimistic about Joe SCSI device This line sets the delay time to 15 seconds. On my own system I had to use 3 seconds minimum to get my trusty old CDROM drive to be recognized. Start with a high value (say 30 seconds or so) when you have problems with device recognition. If this helps, tune it back until it just stays working. Rogue SCSI devices

Although the SCSI standard tries to be complete and concise, it is a complex standard and implementing things correctly is no easy task. Some vendors do a better job then others. This is exactly where the 'rogue' devices come into view. Rogues are devices that are recognized by the FreeBSD kernel as behaving slightly (...) non-standard. Rogue devices are reported by the kernel when booting. An example for two of my cartridge tape units: Feb 25 21:03:34 yedi /386bsd: ahb0 targ 5 lun 0: Feb 25 21:03:34 yedi /386bsd: st0: Tandberg tdc3600 is a known rogue Mar 29 21:16:37 yedi /386bsd: aha0 targ 5 lun 0: Mar 29 21:16:37 yedi /386bsd: st1: Archive Viper 150 is a known rogue For instance, there are devices that respond to all LUNs on a certain target ID, even if they are actually only one device. It is easy to see that the kernel might be fooled into believing that there are 8 LUNs at that particular target ID. The confusion this causes is left as an exercise to the reader. The SCSI subsystem of FreeBSD recognizes devices with bad habits by looking at the INQUIRY response they send when probed. Because the INQUIRY response also includes the version number of the device firmware, it is even possible that for different firmware versions different workarounds are used. This scheme works fine, but keep in mind that it of course only works for devices that are KNOWN to be weird. If you are the first to connect your bogus Mumbletech SCSI cdrom you might be the one that has to define which workaround is needed. Busmaster host adapters

Most, but not all, SCSI host adapters are bus mastering controllers. This means that they can do I/O on their own without putting load onto the host CPU for data movement. This is of course an advantage for a multitasking operating system like FreeBSD. It must be noted however that there might be some rough edges. For instance an Adaptec 1542 controller can be set to use different transfer speeds on the host bus (ISA or AT in this case). The controller is settable to different rates because not all motherboards can handle the higher speeds. Problems like hangups, bad data etc might be the result of using a higher data transfer rate then your motherboard can stomach. The solution is of course obvious: switch to a lower data transfer rate and try if that works better. In the case of a Adaptec 1542, there is an option that can be put into the kernel config file to allow dynamic determination of the right, read: fastest feasible, transfer rate. This option is disabled by default: options "TUNE_1542" #dynamic tune of bus DMA speed Check the man pages for the host adapter that you use. Or better still, use the ultimate documentation (read: driver source). Tracking down problems

The following list is an attempt to give a guideline for the most common SCSI problems and their solutions. It is by no means complete. Check for loose connectors and cables. Check and double check the location and number of your terminators. Check if your bus has at least one supplier of terminator power (especially with external terminators. Check if no double target IDs are used. Check if at least one device provides terminator power to the bus. Check if all devices to be used are powered up. Make a minimal bus config with as little devices as possible. If possible, configure your host adapter to use slow bus speeds. If you can compile a kernel, make one with the SCSIDEBUG option, and try accessing the device with debugging turned on for that device. If your device doesn't even probe at startup, you may have to define the address of the device that is failing, and the desired debug level in /sys/scsi/scsidebug.h. If it probes but just doesn't work, you can use the scsi(8) command to dynamically set a debug level to it in a running kernel (if SCSIDEBUG is defined). This will give you COPIOUS debugging output with which to confuse the gurus. see man 4 scsi for more exact information. Also look at man 8 scsi. Further reading

If you intend to do some serious SCSI hacking, you might want to have the official standard at hand: Approved American National Standards can be purchased from ANSI at 11 West 42nd Street, 13th Floor, New York, NY 10036, Sales Dept: (212) 642-4900. You can also buy many ANSI standards and most committee draft documents from Global Engineering Documents, 15 Inverness Way East, Englewood, CO 80112-5704, Phone: (800) 854-7179, Outside USA and Canada: (303) 792-2181, FAX: (303) 792- 2192. Many X3T10 draft documents are available electronically on the SCSI BBS (719-574-0424) and on the ncrinfo.ncr.com anonymous ftp site. Latest X3T10 committee documents are: AT Attachment (ATA or IDE) [X3.221-1994] (Approved) ATA Extensions (ATA-2) [X3T10/948D Rev 2i] Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] (Approved) Small Computer System Interface - 2 (SCSI-2) [X3.131-1994] (Approved) SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM) [X3T10/792D Rev 11] Other publications that might provide you with additional information are: "SCSI: Understanding the Small Computer System Interface", written by NCR Corporation. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-796855-8 "Basics of SCSI", a SCSI tutorial written by Ancot Corporation Contact Ancot for availability information at: Phone: (415) 322-5322 Fax: (415) 322-0455 "SCSI Interconnection Guide Book", an AMP publication (dated 4/93, Catalog 65237) that lists the various SCSI connectors and suggests cabling schemes. Available from AMP at (800) 522-6752 or (717) 564-0100 "Fast Track to SCSI", A Product Guide written by Fujitsu. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-307000-X "The SCSI Bench Reference", "The SCSI Encyclopedia", and the "SCSI Tutor", ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070 Phone: (408) 867-6642 "Zadian SCSI Navigator" (quick ref. book) and "Discover the Power of SCSI" (First book along with a one-hour video and tutorial book), Zadian Software, Suite 214, 1210 S. Bascom Ave., San Jose, CA 92128, (408) 293-0800 On Usenet the newsgroups and are noteworthy places to look for more info. You can also find the SCSI-Faq there, which is posted periodically. Most major SCSI device and host adapter suppliers operate ftp sites and/or BBS systems. They may be valuable sources of information about the devices you own.