2.1.1 Native threads

Native thread support has been added, based on Scheduler Activations. Applications which support native threads can now take full advantage of the high-performance NetBSD POSIX threads implementation.

Multi-threading provides application-level parallelism; multiple threads within the same process can run concurrently on different CPUs; concurrency requires kernel support for threads, which is what Scheduler Activations provides.

Scheduler Activations is an efficient method of mapping N userland threads to M kernel threads which avoids both the concurrency problems of N:1 implementations and the scalability problems of 1:1 implementations.

2.1.2 Kernel events notification framework - kqueue

kqueue provides a stateful and efficient event notification framework. Currently supported events include socket, file, directory, fifo, pipe, tty and device changes, and monitoring of processes and signals.

kqueue is supported by all writable filesystems in the NetBSD tree (with the exception of Coda) and all device drivers supporting poll(2).

2.1.3 systrace

systrace monitors and controls an application access to the system by enforcing access policies for system calls. The systrace utility might be used to trace an untrusted application's access to the system. In addition, it can be used to protect the system from software bugs (such as buffer overflows) by constraining a daemon's access to the system.

The privilege elevation feature of systrace can be used to obviate the need to run large, untrusted programs as root when only one or two system calls require the elevated privilege.

2.1.4 UFSv2

FreeBSD's UFS2 has been ported to NetBSD. UFS2 is an extension to FFS, adding 64 bit block pointers and support for extended file storage. Among other enhancements, UFS2 allows for file systems larger than 1Terabyte.

2.1.5 Java support

Improvements have been made to NetBSD's Linux emulation to support the latest Sun JDK/JRE for Linux. Testing has shown that it now runs as well as it does on Linux natively.

2.1.6 Verified Exec

As the name suggests, Verified Exec verifies a cryptographic hash before allowing execution of binaries and scripts.

This can be used to prevent a system from running binaries or scripts which have been illegally modified or installed. In addition, Verified Exec can also be used to limit the use of script interpreters to authorized scripts only and disallow interactive use.

2.1.7 Cryptographic disk driver

The cryptographic disk driver (cgd) can be used to encrypt disks or partitions, using some strong encryption algorithms, like AES (Rijndael) and Blowfish. cgd can be configured to encrypt swap.

2.1.8 Non-executable stack and heap

NetBSD 2.0 has support for non-executable mappings on many platforms. If enabled, parts of the stack and heap are made non-executable when they are marked writable. This makes exploiting potential buffer overflows harder.

2.1.9 New toolchain

NetBSD 2.0 sports a new toolchain based on gcc 3.3.1 and binutils 2.13.2.1. gcc 3.3.1 adds support for a number of CPU targets and greatly improved support for i386 and other targets. New platforms supported by gcc 3.3.1 has enabled the porting of NetBSD to even more architectures.

2.2.1 amd64

New port to AMD's 64-bit Opteron CPU, including SMP support.

2.2.2 evbsh5

The SuperH SH-5 is a bi-endian, 32 and 64-bit capable CPU, and this is a new port to the SH-5 Cayman evaluation board. Support for a number of generic, machine-independent device drivers including audio, SCSI and ethernet cards is present.

2.2.3 i386

The i386 port now supports SMP and has a new ACPI and power management framework which takes advantage of Intel's ACPI implementation.

2.2.4 macppc

SMP is now supported on macppc. Hardware support for newer G4 models has been added.

2.2.5 sparc

SMP is now supported on sparc.

3.3.1 Keyboard

sysinst will not allow you to change the keyboard layout during the installation: if you use a US keyboard it's OK, but for the rest of the world it's a minor annoyance, though not a big problem. If you install from CD-ROM you only need to use alphanumeric keys (which have the same layout on most, if not all, national keyboards) and only in a couple of places you need to press other keys. I hope that the next releases of the installation program will allow to change the keyboard layout; for the present, you can use the map in the following table.

If you use a non US keyboard, one of the first things that you will do after installation will be to change the keyboard layout. Until then, please be patient.

3.3.2 Geometries

The installation program mentions two types of hard disk geometries; you should understand what they mean:

• real geometry

• BIOS geometry

real geometry is the real geometry of the hard disk, detected by the system. BIOS geometry is the geometry used by the BIOS and it could be different from the real one (for example, BIOS could remap the disk using LBA).

The disk used in the installation example is an IDE disk with the following geometries:

real:  6232 cyl,   16 heads,  63 sec
BIOS:   779 cyl,  128 heads,  63 sec   (LBA)

As you can see the BIOS remaps the disk using LBA, effectively reducing the number of cylinders and increasing the number of tracks (but the result is the same: 6232 * 16 = 779 * 128 = 99712). A sector contains 512 bytes, which means that the disk size is 6232 * 16 * 63 * 512 = 3 GB. NetBSD does not need to remap the disk geometry (and in fact won't do it). During the installation it is possible to change manually the geometry if sysinst got it wrong.

3.3.3 Partitions

The terminology used by NetBSD for partitioning is different from the typical DOS/Windows terminology; in fact, there are two partitioning schemes. NetBSD installs in one of the four primary BIOS partitions (the partitions defined in the hard disk partition table).

Within its BIOS partition (also called slice) NetBSD defines the BSD partitions using a disklabel: these partitions can be seen only by NetBSD and are identified by lowercase letters (starting with "a"). For example, wd0a refers to the "a" partition of the first IDE disk (wd0) and sd0a refers to the "a" partition of the first SCSI disk. In Figure 3-1 there are two primary BIOS partitions, one used by DOS and the other by NetBSD. NetBSD describes the disk layout through the disklabel.

3.3.4 Hard disk space requirements

The space required by a NetBSD installation depends on the use that you plan to do with it (eg. server or workstation). For example, consider a home desktop system with a 420 MB hard disk (rather small by today's standards) with X, the kernel sources and some applications (Netscape, ...). The swap partition is 32 MB. df shows the following:

Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
/dev/wd1a       31887    16848    13444    56%    /
/dev/wd1e      363507   173202   172129    50%    /usr

As you can see there are 180 MB left on the system.

3.3.5 Retry

When you install an OS for the first time it is seldom a success and NetBSD is no exception. Even if everything goes well, as soon as you start using the system you usually realize that (for example) you could have chosen a better layout for your partitions. It is important not to give up; if you try again you'll realize that what was difficult to understand the first time gradually becomes clearer by virtue of the accumulated experience and numerous rereads of the INSTALL document.

During the first installations it is wiser to accept the defaults suggested by sysinst and avoid, for example, changing the disklabel. The only thing that you must decide is the disk space for the NetBSD fdisk partition.

4.1.1 Preparing the installation

Before installing it is a good idea to make a detailed plan of the steps that you will need to perform. First, read the INSTALL file (I promise it's the last time that I say it) reading the description of the installation and checking the hardware compatibilities. Next, if there is already something on the hard disk, think how you can free some space for NetBSD; if NetBSD will share the disk with other operating systems you will probably need to create a new partition (which you will do with sysinst) and, maybe, to resize an existing one. It is not possible to resize an existing partition with sysinst, but there are some commercial products (like Partition Magic) and some free tools (FIPS, pfdisk) available for this.

The installation is divided logically in two steps. In the first part you create a partition for NetBSD and you write the diklabel for that partition. In the second part you decide which binary sets you want to install and extract the files in the newly created partitions. The first part is independent of the intallation method (CD-ROM, ftp, NFS, ...); at the end of the first part nothing has yet been written to the hard disk and you are prompted to confirm the installation. If you confirm, the installation goes on, else you are brought back to the main menu and the hard disk remains unchanged.

4.1.2 Creating the installation floppy

Before installing you need to create the installation floppy, i.e. to copy the floppy image from the CD-ROM to a diskette. To perform this operation in DOS you can use the rawrite program in the i386/installation/misc directory. The image file is i386/installation/floppy/boot.fs.

If you create the boot floppy in a Unix environment, you can use the dd command. For example:

# cd i386/installation/floppy
# dd if=boot.fs of=/dev/fd0a bs=36b

dd copies blocks of 512 bytes: the bs=36b option copies 36 blocks at a time, effectively making the operation faster.

4.1.3 Last preparatory steps

Everything is now ready for the installation but, before beginning, it is better to gather some information on the hardware of the PC.

The most important thing to check is the type of hard disk (IDE, SCSI) and its geometry. You can find this information on the hard disk manual or using a diagnostic program. Some hard disks have a label on which this data is written. Another option is to connect to the web site of the producer of your disk and look for the product info.

If you install via ftp or NFS remember to check your network card settings: if the installation kernel expects your card to be on an IRQ but the card's settings are different you won't be able to install. For example, the install kernel can recognize an NE2000 compatible network card with one of the following two settings:

ne0     at isa? port 0x280 irq 9        # NE[12]000 ethernet cards
ne1     at isa? port 0x300 irq 10

If your NE2000 network card has different settings it will not be detected. (After the installation you will be able to compile a customized kernel with your own settings.)

While you are at it you should check some other hardware details like, for example, the number of serial and parallel ports, etc.; this is not required for installation but it can turn out useful later. Check your settings (IRQ, I/O ports, ...) against the ones written in the INSTALL file.

4.1.4 Beginning the installation

Insert the newly created installation floppy in drive A: and reboot the computer (or boot from CD-ROM). The kernel on the floppy is booted and starts displaying a lot of messages on the screen, most of which say something about hardware not being found or not being configured. This is normal: the kernel on the floppy tries to detect almost all the hardware supported by NetBSD; you probably (!) don't have all these devices in your machine.

When the boot procedure is over you will find yourself in the main menu of the installation program, shown in Figure 4-1. Don't be deceived by the spartan look of sysinst: it is a rather powerful and flexible program. From here on you should follow the instructions displayed on the screen, using the INSTALL document as a reference. The sysinst screens all have more or less the same layout: the upper part of the screen shows a short description of the current operation or a short help message; the central part of the screen shows the current settings as detected by NetBSD; the bottom part displays a menu of available choices. Choosing the Install option ("a") brings you to the next screen (Figure 4-2) where you confirm the operation.

After choosing to continue with option "b", it is time to select on which hard disk you want to install NetBSD. If more than one disk is available, sysinst displays a list of disks from which you can pick one. In this example there is only one hard disk and the installation program only displays an informational message, shown in Figure 4-3.

Next (Figure 4-4) sysinst displays the BIOS geometry for the chosen disk; you can confirm that it is correct or, if the installation program got it wrong, you can modify it by entering new values manually.

4.1.5 Partitions

The first important step of the installation has come: the partitioning of the hard disk. First you must specify if NetBSD will use a partition (suggested choice) or the whole disk ("dangerous" choice). In the former case it is still possible to create a partition that uses the whole hard disk (Figure 4-5) so I recommend to select this option which, if I understand correctly, keeps the BIOS partition table in a format compatible with other operating systems.

In the this example we will use a disk with the following "real" geometry, corresponding to the BIOS geometry of Figure 4-4.

6232 cyl, 16 heads, 63 sec  (6232 x 16 x 63 = 6281856 total sectors)
1 sector = 512 bytes
1 track = 63 sectors = 63 * 512 bytes = 32 K
1 cylinder = 16 * 63 * 512 bytes = 504 K

The next step, depicted in Figure 4-6, is the selection of a unit of measure to be used for hard disk partitioning: sectors give the most flexibility and precision (note that it is usually better to align partition on cylinder boundaries for performance reasons, at least on older hard disks.) Megabytes are easier to use because they don't require manual calculations and are more "intuitive".

This tutorial will use sectors because they are more useful for teaching purposes. Chosing option "c" you are taken to the fdisk interface screen.

Figure 4-7 shows the current situation of the hard disk before the installation of NetBSD; there are four primary partitions: one is used by DOS/Windows and two by GNU/Linux; the last one is unused. There is no free space on the disk: the End(sec) column of partition 2 shows that the 6281856 sectors of the hard disk are all occupied.

To make room the two Debian GNU/Linux partitions will have to sacrificed, starting with the last one. Sysinst displays a screen that can be used to modify the existing data for a partition and Figure 4-8 shows the current data for partition 2.

To delete the partition, select type unused using option "a" and than choose option "b" leaving the fields "Start" and "Size" empty (press Enter leaving the fields blank). Finally, confirm everything with option "d" and you are back in the main fdisk screen, where partition 3 is now empty. Use the same method to delete partitions 2 and 1, leaving only partition 0 on the disk (Figure 4-9.)

Only the DOS/Windows partition is left, using 2088516 sectors which are equal to 1029 MB (about 1 GB). The free space is calculated as the difference between the already calculated total number of sectors and the end sector of the DOS partition (the number in the End(sec) column.)

6281856 - 2088579 = 4193277 sectors = 2047 MB free on disk

Now, using option "b", a new partition for NetBSD will be created, starting at the end of the DOS partition. To create a new partition the following information must be supplied:

• the type of the new partition

• the first sector of the new partition

• the size (in sectors) of the new partition

Choose the partition type "NetBSD" for the new partition (option "a: Kind") and input the data that we have calculated: start = 2088579 and size = 4193277 using option "b". Check that everything is correct and confirm the creation with option "d", which brings you back to the main fdisk menu. The result is shown in Figure 4-10 which displays the final layout of the partition table. Now, selecting option "x" you proceed to the next menu.

If you have made an error in partitioning (for example you have created overlapping partitions) sysinst will display a message and suggest to go back to the fdisk menu (you are also allowed to continue). If the data is correct but the NetBSD partition lies outside the range of sectors which is bootable by the BIOS, sysinst warns you and asks if you want to proceed anyway. This could lead to problems on older PC's: the PC used in the example received this warning but boots perfectly. It is not possible to give a general rule (it is BIOS dependent); if the PC is not very old I suggest to ignore the warning and continue.

If the data is correct and sysinst detects that you have more than one operating system on your hard disk, it will offer to install a boot selector on the hard disk. Using the installation program you can both install the boot selector and configure it; you can specify what strings will be displayed on the boot menu for each operating system, which partition is booted by default and the timeout used when the user does not select anything. This screen is shown in Figure 4-11.

Select the partitions that will appear in the boot manager menu and define a menu item string for each one using the options from "a" to "d". In the "Menu entry" column you should see an entry for each bootable partition, as shown in Figure 4-12.

Option "e" enables you to choose a timeout for the boot menu: once the timeout is elapsed without a choice from the user, the default partition (defined with option "f") is booted. You can specify one of the following as default:

• a partition

• another hard disk

• the first active partition

After finishing the boot manager configuration, the first part of the installation, namely disk partitioning, is over.

The BIOS partitions, also called slices by BSD, have been created; there are now two slices: DOS and NetBSD. It's time to define the BSD partitions.

4.1.6 Disklabel

There are three alternatives for the creation of the BSD partitions, as shown by Figure 4-13.

For a first time installation I suggest choosing options "a" or "b" and leaving to sysinst the partitioning decisions. In this example life will be a little more complicated by modifying manually the disklabel (only for teaching purposes, of course).

4.1.7 Creating a disklabel

First, let the installation program automatically create a disklabel. Choosing option "b" from Figure 4-13 we are taken to Figure 4-14.

Having done this you could just confirm everything (with option "b") and your work would be over. Instead, let's see what you need to do to modify the size of the swap partition to make it smaller and increase the size of the /usr partition. To change the size of the swap partition, choose option "a": in the new screen we change the unit of measure to sectors. The result is shown in Figure 4-15.

The sequence of partition identifiers is standard: some letters are reserved for predefined uses.

• a is usually the root partition.

• b is the swap partition.

• c covers the whole NetBSD slice.

• d covers the whole hard disk: extending outside the NetBSD slice. With a similar method you will be able to make a DOS or a Linux partition visible to NetBSD, by creating a BSD partition which is outside the NetBSD slice.

• e is the first free partition. Usually /usr is mounted on "e".

You normally don't want to modify partitions b and c. You are free to change the size and mount point of the remaining partitions and to create new ones (with a maximum of 8, using the letters from e to h.)

To modify the swap partition you need to modify partition b. You will also need to modify partition "e", so that it begins right after the end of "b". Partitions "c" and "d" will be left unchanged.

You will now create a 150 MB (307200 sectors) swap partition; this means that "b" will start at sector 2524032 and end at sector 2831231 (2524032+307200-1).

id:      Size    Offset       End FStype Bsize Fsize Mount point
---      ----    ------       --- ------ ----- ----- -----------
 a:    435453   2088579   2524031 4.2BSD  8192  1024 /
 b:    307200   2524032   2831231   swap
 ...

The newly freed space will be assigned to partition "e", which will have: start = 2831232, size = 3450624 and end = 6281855. These values have been calculated as follows: "start" is the sector immediately following the end sector of partition "b"; "end" is equal to the last sector of the NetBSD partition; "size" is given by: End - Offset + 1.

id:      Size    Offset       End FStype Bsize Fsize Mount point
---      ----    ------       --- ------ ----- ----- -----------
 a:    435453   2088579   2524031 4.2BSD  8192  1024 /
 b:    307200   2524032   2831231   swap
 ...
 e:   3450624   2831232   6281855 4.2BSD  8192  1024 /usr

The preceding example shows the disklabel that you want. With option "b" and "e" you can input the data that you have calculated.

This is depicted in Figure 4-16.

Figure 4-17 shows the modified disklabel.

When you are happy with the result, you can select option "x" to save and exit. You are now back in Figure 4-14 where you can choose option "b".

4.1.8 Final operations

The difficult part (creating the BIOS and the BSD partitions) is now over; the remaining part of the installation is much simpler. Now you can choose a name for the hard disk (the default name is mydisk) and confirm the operations that you have done.

sysinst will now create the partitions and the file systems with fdisk, newfs, fsck and installboot and then we will install the NetBSD sets.

4.1.9 Choosing the installation media

You have finished the first and most difficult part of the installation. In the next step you will choose the type of installation, which can be full, which installs all the sets, or custom, which enables you to choose the sets to be installed. If you don't have a shortage of space on the hard disk I suggest to choose the former option. In this example option custom will be used only to show what it looks like. This brings you to Figure 4-18.

The first three sets are mandatory: without them the system can't work. You can toggle the installation of the remaining sets using the menu options. Initially all sets are selected for installation, which is the same as the aforementioned full option. Leave all the sets on and proceed to the next step with option "x: Exit".

sysinst then asks if you want to see filenames during the extraction from the sets.

Now sysinst needs to find the NetBSD sets (the .tgz files) and you must supply this information. The menu offers several choiches:

The options are explained in detail in the INSTALL document. It is also possible to install from an unmounted filesystem (provided that it is of a type recognised by the install kernel): this means that, for example, it is possible to copy all the sets to an existing MS-DOS partition and install from there.

Selecting "cdrom", sysinst asks the name of the device (for example cd0) and mounts it automatically. You should also input the pathname to the installation sets on the CD-ROM if it is different from the default value. If, for example, the NetBSD distribution is in the NetBSD-1.5 directory you must modify the pathname, using option "b", like this:

/NetBSD-1.5/i386/binary/sets

At the end of the installation sysinst displays a message saying that everything went well. Selecting option "a: ok" the device files are created.

The installation is over. Sysinst can now do some system configuration before rebooting. First you can configure the timezone and, in the following screen, you can choose a password for root. Now it's tiem to reboot. Select "a: ok" and go back to the main menu, then remove the floppy from the drive and select option "d: Reboot the computer".

8.4.1 Changing the Destination Directory

Many people like to track current and perform cross compiles of architectures that they use. The logic for this is simple, sometimes a new feature or device becomes available and someone may wish to use it. By keeping track of changes and building every now and again, one can be assured that they can create their own release.

It is reasonable to assume that if one is tracking and building for more than one architecture, they might want to keep the builds in a different location than the default. There are two ways to go about this, use a script to set the new DESTDIR, or simply do so interactively. In any case, it can be set the same way as any other variable (depending on your shell of course).

For the bourne or korn shells:

# export DESTDIR=/usr/builds/sparc64
     

For the c shell:

# setenv DESTDIR /usr/builds/shark
     

Simple enough. When the build is run, the binaries and files will be sent to /usr/builds.

8.4.2 Static Builds

The NetBSD Toolchain builds dynamically by default. Many users still prefer to be able to build statically. Sometimes a small system can be created without having libs is a good example of a full static build. If a particular build machine will always need one environment variable set in a particular way, then it is easiest to simply add the changed setting to /etc/mk.conf.

To make sure a build box always builds statically, simply add the following line to /etc/mk.conf:

LDSTATIC=-static
     

10.3.1 Downloading the sources

If you are connected to the Internet, the Makefile will automatically fetch the required sources and you don't need to read this section.

Otherwise you should take care of getting the tarballs yourself. In this case you need to know the name(s) of the tarball(s); look in the Makefile for the line

DISTNAME = cdrtools-2.0

The full name of the package is cdrtools-2.0.tar.gz.

You can achieve the same result in an easier way with the following commands:

# cd /usr/pkgsrc/sysutils/cdrecord
# make fetch-list

which also show a list of sites from where the package can be downloaded.

10.3.2 Compiling and installing

To compile the package write

# cd /usr/pkgsrc/sysutils/cdrecord
# make

The previous command fetches the source archive (if it is not already present in the distfiles directory), extracts the sources, applies the patches necessary to compile it on NetBSD and then builds the package.

To install it

# make install

The installation of the new program is recorded on your system: you can check with the pkg_info -a command.

Then cdrecord package is ready for use; you can make some room removing the intermediate files created by the compiler:

# make clean
# make clean-depends

The second command is needed if some dependent packages have been installed. The same result can be achieved with one command:

# make clean CLEANDEPENDS=1

10.6.1 Tools

There are three primary tools for rapidly building a small package addition to NetBSD:

10.6.2 Getting Started

Starting the process is fairly simple. It is important that the builder (e.g. you) have already tested building the package from the sources on a NetBSD system. Otherwise setting up a new package could be problematic if if fails to build. It should be noted that most often, a patch can be written for the sources and included in the package to fix any build problems. That is beyond the scope of this quick start guide (see the pkgsrc documentation for details).

10.6.3 Filling in the Rest

Now that the Makefile has been generated, the remaining files must be created. Using your template package, copy over the following files from the template package's pkg subdirectory:

10.6.4 Checking with pkglint

With all of the files ready, it is time to check the package with the pkglint tool. Often the Makefile needs a section moved, changed or added, however, for the first time around it is helpful just to run pkglint before hand so you know exactly what you may need to change, following is some sample output taken from the pkgsrc documentation pkglint session:

$ pkglint
OK: checking pkg/COMMENT.
OK: checking pkg/DESCR.
OK: checking Makefile.
OK: checking files/md5.
OK: checking patches/patch-aa.
looks fine.

If an error occured, it is normally pretty straightforward, here is a sample error I got while building a package:

extract suffix not required

I did not need to define an extract suffix in the Makefile.

10.6.5 Running and Checking Build/Installs

At this point if pkglint has passed, I normally run a complete check of the fetch, build and installation. To do this properly I must delete the work subdirectory and the distfile(s) from /usr/pkgsrc/distfiles. This way I can ensure I will be doing a full and complete test.

10.6.6 Submitting a Package Using send-pr

First make an archive of the package tree itself (including the pkg/work subdirectory) like so:

$ tar -czf packagename.tgz package_dir

Next, upload the archive to a location that NetBSD package maintainers can access it from, if you cannot upload the archive, contact NetBSD to see if there is some other method you might try to make your archive available to package maintainers.

The preferred method of notifying NetBSD package maintainers is to use the send-pr utility with a category of "pkg", a synopsis which includes the package name and version number, a short description of the package and the URL of the tar file.

You can use either the send-pr utility on your NetBSD system or the online form at http://www.NetBSD.org/cgi-bin/sendpr.cgi?gndb=netbsd if for some reason you cannot get send-pr to work locally.

10.6.7 Final Notes

Again this little guide is for small packages that contain only a few files to be installed on a NetBSD system. It makes the assumption that the package does not require any patches and can build with no dependancies.

For more advanced issues, be sure to read the full pkgsrc documentation.

11.1.1 Audience

This networking section of this guide explains various aspects of networking and is intended to help people with little knowledge about networks to get started. It is devided into three sections. We start by giving a general overview of how networking works and introduce the basic concepts. Then we go into details for setting up various types of networking in the second section, and the third section covers any "advanced" topics that go beyond the scope of basic operation as introduced in the first two sections.

The reader is assumed to know about basic system administration tasks: how to become root, edit files, change permissions, stop processes, etc. See [AeleenFrisch] for further information on this topic. Besides that, you should know how to handle the utilities we're going to set up here, i. e. you should know how to use telnet, FTP, ... I will not explain the basic features of those utilities, please refer to the appropriate man-pages, the references listed or of course the other parts of this document instead.

This Introduction to TCP/IP Networking was written with the intention in mind to give starters a basic knowledge. If you really want to know what's it all about, read [CraigHunt]. This book does not only cover the basics, but goes on and explains all the concepts, services and how to set them up in detail. It's great, I love it! :-)

11.1.2 Supported Networking Protocols

There are several protocol suites supported by NetBSD, most of which were inherited from NetBSD's predecessor, 4.4BSD, and subsequently enhanced and improved. The first and most important one today is DARPA's Transmission Control Protocoll/Internet Protocoll (TCP/IP). Other protocol suites available in NetBSD include the Xerox Network System (XNS) which was only implemented at UCB to connect isolated machines to the net, Apple's AppleTalk protocol suite and the ISO protocol suite, CCITT X.25 and ARGO TP. They are only used in some special applications these days.

Today, TCP/IP is the most widespread protocol of the ones mentioned above. It is implemented on almost every hardware and operating system, and it is also the most-used protocol in heterogenous environments. So, if you just want to connect your computer running NetBSD to some other machine at home, or you want to integrate it into your company's or university's network, TCP/IP is the right choice.

IPv6 (TCP/IP protocol issue 6, current version IPv4) is still under development, and the KAME project's IPv6 code was merged into NetBSD and shipped starting with the NetBSD 1.5 release.

There are other protocol suites such as DECNET, Novell's IPX/SPX or Microsoft's NetBIOS, but these are not currently supported by NetBSD. These two protocols differ from the protocols mentioned above in that they are proprietary, in contrast to the others, which are well-defined in several RFCs and other open standards.

11.1.3 Supported Media

TCP/IP can be used on a wide range of media. Among the ones supported by NetBSD are Ethernet (10/100/1000MBd), Arcnet, serial line, ATM, FDDI, Fiber Channel, USB, HIPPI, FireWire (IEEE 1394), Token Ring, serial lines and others.

11.1.4 TCP/IP Address Format

TCP/IP uses 4-byte (32-bit) addresses in the current implementations (IPv4), also called IP-numbers (Internet-Protocol numbers), to address hosts.

TCP/IP allows any two machines to communicate directly. To permit this all hosts on a given network must have a unique IP address. To assure this, IP addresses are administrated by one central organisation, the InterNIC. They give certain ranges of addresses (network-addresses) directly to sites which want to participate in the internet or to internet-providers, which give the addresses to their customers.

If your university or company is connected to the Internet, it has (at least) one such network-address for it's own use, usually not assigned by the InterNIC directly, but rather through an Internet Service Provider (ISP).

If you just want to run your private network at home, see below on how to "build" your own IP addresses. However, if you want to connect your machine to the (real :-) Internet, you should get an IP addresses from your local network-administrator or -provider.

IP addresses are usually written in "dotted quad"-notation - the four bytes are written down in decimal (most significant byte first), separated by dots. For example, 132.199.15.99 would be a valid address. Another way to write down IP-addresses would be as one 32-bit hex-word, e.g. 0x84c70f63. This is not as convenient as the dotted-quad, but quite useful at times, too. (See below!)

Being assigned a network means nothing else but setting some of the above-mentioned 32 address-bits to certain values. These bits that are used for identifying the network are called network-bits. The remaining bits can be used to address hosts on that network, therefore they are called host-bits.

In the above example, the network-address is 132.199.0.0 (host-bits are set to 0 in network-addresses), the host's address is 15.99 on that network.

How do you know that the host's address is 16 bit wide? Well, this is assigned by the provider from which you get your network-addresses. In the classless inter-domain routing (CIDR) used today, host fields are usually between as little as 2 to 16 bits wide, and the number of network-bits is written after the network address, seperated by a "/", e.g. 132.199.0.0/16 tells that the network in question has 16 network-bits. When talking about the "size" of a network, it's usual to only talk about it as "/16", "/24", etc.

Before CIDR was used, there used to be four classes of networks. Each one starts with a certain bit-pattern identifying it. Here are the four classes:

• Class A starts with "0" as most significant bit. The next seven bits of a class A address identify the network, the remaining 24 bit can be used to address hosts. So, within one class A network there can be 2²⁴ hosts. It's not very likely that you (or your university, or company, or whatever) will get a whole class A address.

  The CIDR notation for a class A network with it's eight network bits is an "/8".

• Class B starts with "10" as most significant bits. The next 14 bits are used for the networks address, the remaining 16 bits can be used to address more than 65000 hosts. Class B addresses are very rarely given out today, they used to be common for companies and universities before IPv4 address space went scarce.

  The CIDR notation for an class B network with it's 16 network bits is an "/16".

  Returning to our above example, you can see that 132.199.15.99 (or 0x84c70f63, which is more appropriate here!) is on a class B network, as 0x84... = 1000... (base 2).

  Therefore, the address 132.199.15.99 can be split into an network-address of 132.199.0.0 and an host-address of 15.99.

• Class C is identified by the MSBs being "110", allowing only 256 (actually: only 254, see below) hosts on each of the 2²¹ possible class C networks. Class C addresses are usually found at (small) companies.

  The CIDR notation for an class C network with it's 24 network bits is an "/24".

• There are also other addresses, starting with "111". Those are used for special purposes (e. g. multicast-addresses) and are not of interrest here.

Please note that the bits which are used for identifying the network-class are part of the network-address.

When seperating host-addresses from network-addresses, the "netmask" comes in handy. In this mask, all the network-bits are set to "1", the host-bits are "0". Thus, putting together IP-address and netmask with a locical AND-function, the network-address remains.

To continue our example, 255.255.0.0 is a possible netmask for 132.199.15.99. When applying this mask, the network-address 132.199.0.0 remains.

For addresses in CIDR notation, the number of network-bits given also says how many of the most significant bits of the address must be set to "1" to get the netmask for the corresponding network. For classfull addressing, every network-class has a fixed default netmask assigned:

• Class A (/8): default-netmask: 255.0.0.0, first byte of address: 1-127

• Class B (/16): default-netmask: 255.255.0.0, first byte of address: 128-191

• Class C (/24): default-netmask: 255.255.255.0, first byte of address: 192-223

Another thing to mention here is the "broadcast-address". When sending to this address, all hosts on the corresponding network will receive the message sent. The broadcast address is characterized by having all host-bits set to "1".

Taking 132.199.15.99 with its netmask 255.255.0.0 again, the broadcast-address would result in 132.199.255.255.

You'll ask now: But what if I want a hosts address to be all bits "0" or "1"? Well, this doesn't work, as network- and broadcast-address must be present! Because of this, a class B (/16) network can contain at most 2¹⁶-2 hosts, a class C (/24) network can hold no more than 2⁸-2 = 254 hosts.

Besides all those categories of addresses, there's the special IP-address 127.0.0.1 which always refers to the "local" host, i. e. if you talk to 127.0.0.1 you'll talk to yourself without starting any network-activity. This is sometimes useful to use services installed on your own machine or to play around if you don't have other hosts to put on your network.

Let's put together the things we've introduced in this section:

11.1.5 Subnetting and Routing

After talking so much about netmasks, network-, host- and other addresses, I have to admit that this is not the whole truth.

Imagine the situation at your university, which usually has a class B (/16) address, allowing it to have up to 2¹⁶ ~= 65534 hosts on that net. Maybe it would be a nice thing to have all those hosts on one single network, but it's simply not possible due to limitations in the transport media commonly used today.

For example, when using thinwire ethernet, the maximum length of the cable is 185 meters. Even with repeaters in between, which refresh the signals, this is not enough to cover all the locations where machines are located. Besides that, there is a maximum number of 1024 hosts on one ethernet wire, and you'll loose quite a bit of performance if you go to this limit.

So, are you hosed now? Having an address which allows more than 60000 hosts, but being bound to media which allows far less than that limit?

Well, of course not! :-)

The idea is to divide the "big" class B net into several smaller networks, commonly called sub-networks or simply subnets. Those subnets are only allowed to have, say, 254 hosts on them (i.e. you divide one big class B network into several class C networks!).

To do this, you adjust your netmask to have more network- and less host-bits on it. This is usually done on a byte-boundary, but you're not forced to do it there. So, commonly your netmask will not be 255.255.0.0 as supposed by a class B network, but it will be set to 255.255.255.0.

In CIDR notation, you now write a "/24" instead of the "/16" to show that 24 bits of the address are used for identifying the network and subnet, instead of the 16 that were used before.

This gives you one additional network-byte to assign to each (physical!) network. All the 254 hosts on that subnet can now talk directly to each other, and you can build 256 such class C nets. This should fit your needs.

To explain this better, let's continue our above example. Say our host 132.199.15.99 (I'll call him dusk from now; we'll talk about assigning hostnames later) has a netmask of 255.255.255.0 and thus is on the subnet 132.199.15.0/24. Let's furthermore introduce some more hosts so we have something to play around with, see Figure 11-1.

In the above network, dusk can talk directly to dawn, as they are both on the same subnet. (There are other hosts attached to the 132.199.15.0/24-subnet but they are not of importance for us now)

But what, if dusk wants to talk to a host on another subnet?

Well, the traffic will then go through one or more gateways (routers), which are attached to two subnets. Because of this, a router always has two different addresses, one for each of the subnets it is on. The router is functionally transparent, i.e. you don't have to address it to reach hosts on the "other" side. Instead, you address that host directly and the packets will be routed to it correctly.

Example. Let's say dusk wants to get some files from the local ftp-server. As dusk can't reach ftp directly (because it's on a different subnet), all its packets will be forwarded to it's "defaultrouter" rzi (132.199.15.1), which knows where to forward the packets to.

Dusk knows the address of it's defaultrouter in its network (rzi, 132.199.15.1), and it will forward any packets to it which are not on the same subnet, i.e. it will forward all IP-packets in which the third address-byte isn't 15.

The (default)router then gives the packets to the appropriate host, as it's also on the FTP-server's network.

In this example, all packets are forwarded to the 132.199.1.0/24-network, simply because it's the network's backbone, the most important part of the network, which carries all the traffic that passes between several subnets. Almost all other networks besides 132.199.15.0/24 are attached to the backbone in a similar manner.

But what, if we had hooked up another subnet to 132.199.15.0/24 instead of 132.199.1.0/24? Maybe something the situation displayed in Figure 11-2.

When we now want to reach a host which is located in the 132.199.16.0/24-subnet from dusk, it won't work routing it to rzi, but you'll have to send it directly to route2 (132.199.15.2). Dusk will have to know to forward those packets to route2 and send all the others to rzi.

When configuring dusk, you tell it to forward all packets for the 132.199.16.0/24-subnet to route2, and all others to rzi. Instead of specifying this default as 132.199.1.0/24, 132.199.2.0/24, etc., 0.0.0.0 can be used to set the default-route.

Returning to Figure 11-1, there's a similar problem when dawn wants to send to noon, which is connected to dusk via a serial line running. When looking at the IP-addresses, noon seems to be attached to the 132.199.15.0-network, but it isn't really. Instead, dusk is used as gateway, and dawn will have to send its packets to dusk, which will forward them to noon then. The way dusk is forced into accepting packets that aren't destined at it but for a different host (noon) instead is called "proxy arp".

The same goes when hosts from other subnets want to send to noon. They have to send their packets to dusk (possibly routed via rzi),

11.1.6 Name Service Concepts

In the previous sections, when we talked about hosts, we referred to them by their IP-addresses. This was necessary to introduce the different kinds of addresses. When talking about hosts in general, it's more convenient to give them "names", as we did when talking about routing.

Most applications don't care whether you give them an IP address or an hostname. However, they'll use IP addresses internally, and there are several methods for them to map hostnames to IP addresses, each one with its own way of configuration. In this section we'll introduce the idea behind each method, in the next chapter, we'll talk about the configuration-part.

The mapping from hostnames (and domainnames) to IP-addresses is done by a piece of software called the "resolver". This is not an extra service, but some library routines which are linked to every application using networking-calls. The resolver will then try to resolve (hence the name ;-) the hostnames you give into IP addresses. See [RFC1034] and [RFC1035] for details on the resolver.

Hostnames are usually up to 10 characters long, and contain letters, numbers and dashes ("-"); case is ignorred.

Just as with networks and subnets, it's possible (and desirable) to group hosts into domains and subdomains. When getting your network-address, you usually also obtain a domainname by your provider. As with subnets, it's up to you to introduce subdomains. Other as with IP-addresses, (sub)domains are not directly related to (sub)nets; for example, one domain can contain hosts from several subnets.

Figure 11-1 shows this: Both subnets 132.199.1.0/24 and 132.199.15.0/24 (and others) are part of the subdomain "rz.uni-regensburg.de". The domain the University of Regensburg got from it's IP-provider is "uni-regensburg.de" (".de" is for Deutschland, Germany), the subdomain "rz" is for Rechenzentrum, computing center.

Hostnames, subdomain- and domainnames are separated by dots ("."). It's also possible to use more than one stage of subdomains, although this is not very common. An example would be fox_in.socs.uts.edu.au.

A hostname which includes the (sub)domain is also called a fully qualified domain name (FQDN). For example, the IP-address 132.199.15.99 belongs to the host with the FQDN dusk.rz.uni-regensburg.de.

Further above I told you that the IP-address 127.0.0.1 always belongs to the local host, regardless what's the "real" IP-address of the host. Therefore, 127.0.0.1 is always mapped to the name "localhost".

The three different ways to translate hostnames into IP addresses are: /etc/hosts, the Domain Name Service (DNS) and the Network Information Service (NIS).

IP-address        hostname [nickname [...]]

11.1.7 Next generation Internet protocol - IPv6

127.0.0.1               localhost
::1                     localhost

noon            IN      AAAA    3ffe:400:430:2:240:95ff:fe40:4385

zone "0.3.4.0.0.0.4.0.e.f.f.3.IP6.INT" {
        type master;
        file "db.reverse";
};

5.8.3.4.0.4.e.f.f.f.5.9.0.4.2.0.2.0.0.0 IN   PTR   noon.ipv6.example.com.

11.2.1 A walk throught the kernel configuration

Before we dive into configuring various aspects of network setup, we want to walk through the necessary bits that have to or can be present in the kernel. See Chapter 9 for more details on compiling the kernel, we will concentrate on the configuration of the kernel here. We will take the i386/GENERIC config file as an example here. Config files for other platforms should contain similar information, the comments in the config files give additional hints. Besides the information given here, each kernel option is also documented in the options(4) manpage, and there is usually a manpage for each driver too, e.g. tlp(4).

#       $NetBSD: GENERIC,v 1.354.2.15 2001/05/06 15:18:54 he Exp $

The first line of each config file shows the version, which is 1.354.2.15 here. It can be used to compare against other versions via CVS, or when reporting bugs.

options         NTP             # NTP phase/frequency locked loop

If you want to run the Network Time Protocol (NTP), this option can be enabled for maximum precision. If the option is not present, NTP will still work. See ntpd(8) for more information.

file-system     NFS             # Network File System client

If you want to use another machine's harddisk via the Network File System (NFS), this option is needed. Section 11.3.2 gives more information on NFS.

options         NFSSERVER       # Network File System server

This option includes the server side of the NFS remote file sharing protocol. Enable if you want to allow other machines to use your harddisk. Section 11.3.2 contains more information on NFS.

#options        GATEWAY         # packet forwarding

If you want to setup a router that forwards packets between networks or network interfaces, setting this option is needed. If doesn't only switch on packet forwarding, but also increases some buffers. See options(4) for details.

options         INET            # IP + ICMP + TCP + UDP

This enables the TCP/IP code in the kernel. Even if you don't want/use networking, you will still need this for machine-internal communication of subsystems like the X Window System. See inet(4) for more details.

options         INET6           # IPV6

If you want to use IPv6, this is your option. If you don't want IPv6, which is part of NetBSD since the 1.5 release, you can remove/comment out that option. See the inet6(4) manpage and Section 11.1.7 for more information on the next generation Internet protocol.

#options        IPSEC           # IP security

Includes support for the IPsec protocol, including key and policy management, authentication and compression. This option can be used without the previous option INET6, if you just want to use IPsec with IPv4, which is possible. See ipsec(4) for more information.

#options        IPSEC_ESP       # IP security (encryption part; define w/IPSEC)

This option is needed in addition to IPSEC if encryption is wanted in IPsec.

#options        MROUTING        # IP multicast routing

If multicast services like the MBone services should be routed, this option needs to be included. Note that the routing itself is controlled by the mrouted(8) daemon.

options         NS              # XNS
#options        NSIP            # XNS tunneling over IP

These options enables the Xerox Network Systems(tm) protocol family. It's not related to the TCP/IP protocol stack, and in rare use today. The ns(4) manpage has some details.

options         ISO,TPIP        # OSI
#options        EON             # OSI tunneling over IP

These options include the OSI protocol stack, that was said for a long time to be the future of networking. It's mostly history these days. :-) See the iso(4) manpage for more information.

options         CCITT,LLC,HDLC  # X.25

These options enable the X.25 protocol set for transmission of data over serial lines. It is/was used mostly in conjunction with the OSI protocols and in WAN networking.

options         NETATALK        # AppleTalk networking protocols

Include support for the AppleTalk protocol stack. Userland server programs are needed to make use of that. See pkgsrc/net/netatalk and pkgsrc/net/netatalk-asun for such packages. More information on the AppleTalk protocol and protocol stackk are available in the atalk(4) manpage.

options         PPP_BSDCOMP     # BSD-Compress compression support for PPP
options         PPP_DEFLATE     # Deflate compression support for PPP
options         PPP_FILTER      # Active filter support for PPP (requires bpf)

These options tune various aspects of the Point-to-Point protocol. The first two determine the compression algorithms used and available, while the third one enables code to filter some packets.

options         PFIL_HOOKS      # pfil(9) packet filter hooks
options         IPFILTER_LOG    # ipmon(8) log support

These options enable firewalling in NetBSD, using IPfilter. See the ipf(4) and ipf(8) manpages for more information on operation of IPfilter, and Section 11.3.1.1 for a configuration example.

# Compatibility with 4.2BSD implementation of TCP/IP.  Not recommended.
#options        TCP_COMPAT_42

This option is only needed if you have machines on the network that still run 4.2BSD or a network stack derived from it. If you've got one or more 4.2BSD-systems on your network, you've to pay attention to set the right broadcast-address, as 4.2BSD has a bug in its networking code, concerning the broadcast address. This bug forces you to set all host-bits in the broadcast-address to "0". The TCP_COMPAT_42 option helps you ensuring this.

options         NFS_BOOT_DHCP,NFS_BOOT_BOOTPARAM

These options enable lookup of data via DHCP or the BOOTPARAM protocol if the kernel is told to use a NFS root file system. See the diskless(8) manpage for more information.

# Kernel root file system and dump configuration.
config          netbsd  root on ? type ?
#config         netbsd  root on sd0a type ffs
#config         netbsd  root on ? type nfs

These lines tell where the kernel looks for it's root file system, and which filesystem type it is expected to have. If you want to make a kernel that uses a NFS root filesystem via the tlp0 interface, you can do this with "root on tlp0 type nfs". If a ? is used instead of a device/type, the kernel tries to figure one out on it's own.

# ISA serial interfaces
com0    at isa? port 0x3f8 irq 4        # Standard PC serial ports
com1    at isa? port 0x2f8 irq 3
com2    at isa? port 0x3e8 irq 5

If you want to use PPP or SLIP, you will need some serial (com) interfaces. Others with attachment on USB, PCMCIA or PUC will do as well.

# Network Interfaces

This rather long list contains all sort of network drivers. Please pick the one that matches your hardware, according to the comments. For most drivers, there's also a manual page available, e.g. tlp(4), ne(4), etc.

# MII/PHY support

This section lists media independent interfaces for network cards. Pick one that matches your hardware. If in doubt, enable them all and see what the kernel picks. See the mii(4) manpage for more information.

# USB Ethernet adapters
aue*    at uhub? port ?         # ADMtek AN986 Pegasus based adapters
cue*    at uhub? port ?         # CATC USB-EL1201A based adapters
kue*    at uhub? port ?         # Kawasaki LSI KL5KUSB101B based adapters

USB-ethernet adapters only have about 2MBit/s bandwidth, but they are very convenient to use. Of course this needs other USB related options which we won't cover here, as well as the necessary hardware. See the corresponding manpages for more information.

# network pseudo-devices
pseudo-device   bpfilter        8       # Berkeley packet filter

This pseudo-device allows sniffing packets of all sorts. It's needed for tcpdump, but also rarpd and some other applications that need to know about network traffic. See bpf(4) for more information.

pseudo-device   ipfilter                # IP filter (firewall) and NAT

This one enables the IPfilter's packet filtering kernel interface used for firewalling, NAT (IP Masquerading) etc. See ipf(4) and Section 11.3.1.1 for more information.

pseudo-device   loop                    # network loopback

This is the "lo0" software loopback network device which is used by some programs these days, as well as for routing things. Should not be omited. See lo(4) for more details.

pseudo-device   ppp             2       # Point-to-Point Protocol

If you want to use PPP either over a serial interface or ethernet (PPPoE), you will need this option. See ppp(4) for details on this interface.

pseudo-device   sl              2       # Serial Line IP

Serial Line IP is a simple encapsulation for IP over (well :) serial lines. It does not include negotiation of IP addresses and other options, which is the reason that it's not in widespread use today any more. See sl(4).

pseudo-device   strip           2       # Starmode Radio IP (Metricom)

If you happen to have one of the old Metricon Ricochet packet radio wireless network devices, use this pseudo-device to use it. See the strip(4) manpage for detailled information.

pseudo-device   tun             2       # network tunneling over tty

This network device can be used to tunnel network packets to a device file, /dev/tun*. Packets routed to the tun0 interface can be read from /dev/tun0, and data written to /dev/tun0 will be sent out the tun0 network interface. This can be used to implement e.g. QoS routing in userland. See tun(4) for details.

pseudo-device   gre             2       # generic L3 over IP tunnel

The GRE encapsulation can be used to tunnel arbitrary layer 3 packets over IP, e.g. to implement VPNs. See gre(4) for more.

pseudo-device   ipip            2       # IP Encapsulation within IP (RFC 2003)

Another IP-in-IP encapsulation device, with a different encapsulation format. See the ipip(4) manpage for details.

pseudo-device   gif             4       # IPv[46] over IPv[46] tunnel (RFC 1933)

Using the GIF interface allows to tunnel e.g. IPv6 over IPv4, which can be used to get IPv6 connectivity if no IPv6-capable uplink (ISP) is available. Other mixes of operations are possible, too. See the gif(4) manpage for some examples.

#pseudo-device  faith           1       # IPv[46] tcp relay translation i/f

The faith interface captures IPv6 TCP traffic, for implementing userland IPv6-to-IPv4 TCP relays e.g. for protocol transitions. See the faith(4) manpage for more details on this device.

#pseudo-device  stf             1       # 6to4 IPv6 over IPv4 encapsulation

This add a network device that can be used to tunnel IPv6 over IPv4 without setting up a configured tunnel before. The source address of outgoing packets contains the IPv4 address, which allows routing replies back via IPv4. See the stf(4) manpage and Section 11.3.4 for more details.

pseudo-device   vlan                    # IEEE 802.1q encapsulation

This interface provides support for IEEE 802.1Q Virtual LANs, which allows tagging Ethernet frames with a "vlan" ID. Using properly configured switchens (that also have to support VLAN, of course), this can be used to build virtual LANs where one set of machines doesn't see traffic from the other (broadcast and other). The vlan(4) manpage tells more about this.

11.2.2 Overview of the network configuration files

The following is a list of the files used to configure the network. The usage of these files, some of which have already been met the first chapters, will be described in the following sections.

11.2.3 Connecting to the Internet

There are many types of Internet connections: this section explains how to connect to a provider using a modem over a telephone line using the PPP protocol, a very common setup. In order to have a working connection, the following steps must be done:

Judging from the previous list it looks like a complicated procedure that requires a lot of work. Actually, the single steps are very easy: it's just a matter of modifying, creating or simply checking some small text files. In the following example it will be assumed that the modem is connected to the second serial port /dev/tty01 (COM2 in DOS.)

nameserver 194.109.123.2
nameserver 191.200.4.52
#lookup file bind

# /etc/nsswitch.conf
group:         compat
group_compat:  nis
hosts:         files dns 
netgroup:      files [notfound=return] nis
networks:      files
passwd:        compat
passwd_compat: nis

# /etc/ppp/peers/bignet
connect '/usr/sbin/chat -v -f /etc/ppp/peers/bignet.chat'
noauth
user alan
remotename bignet.it

# /etc/ppp/peers/bignet.chat
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
'' ATDT0299999999
CONNECT ''

user * password

alan * pZY9o

# /etc/ppp/peers/bignet.chat
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
'' ATDT0299999999
CONNECT ''
TIMEOUT 50
ogin: alan
ssword: pZY9o

/dev/tty01
lock
crtscts
57600
modem
defaultroute
noipdefault

# pppd call bignet

# tail -f /var/log/messages

#!/bin/sh
MODEM=tty01
POP=bignet
if [ -f /var/spool/lock/LCK..$MODEM ]; then
  echo ppp is already running...
else
  pppd call $POP
  tail -f /var/log/messages
fi

#!/bin/sh
MODEM=tty01
if [ -f /var/spool/lock/LCK..$MODEM ]; then
  echo -f killing pppd...
  kill -HUP `cat /var/spool/lock/LCK..$MODEM`
  echo done
else
  echo ppp is not active
fi

# chmod u+x ppp-up ppp-down

11.2.4 Creating a small home network

Networking is one of the main strengths of Unix and NetBSD is no exception: networking is both powerful and easy to set up and inexpensive too, because there is no need to buy additional software to communicate or to build a server. Section 11.3.1 explains how to configure a NetBSD machine to act as a gateway for a network: with IPNAT all the hosts of the network can reach the Internet with a single connection to a provider made by the gateway machine. The only thing to be checked before creating the network is to buy network cards supported by NetBSD (check the INSTALL file for a list of supported devices.)

First, the network cards must be installed and connected to a hub, switch or directly (see Figure 11-6.)

Next, check that the network cards are recognized by the kernel, studying the output of the dmesg command. In the following example the kernel recognized correctly an NE2000 clone:

...
ne0 at isa0 port 0x280-0x29f irq 9
ne0: NE2000 Ethernet
ne0: Ethernet address 00:c2:dd:c1:d1:21
...

If the card is not recognized by the kernel, check that it is enabled in the kernel configuration file and then that the card's IRQ matches the one that the kernel expects. For example, this is the isa NE2000 line in the configuration file; the kernel expects the card to be at IRQ 9.

...
ne0 at isa? port 0x280 irq 9 # NE[12]000 ethernet cards
...

If the card's configuration is different, it will probably not be found at boot. In this case, either change the line in the kernel configuration file and compile a new kernel or change the card's setup (usually through a setup disk or, for old cards, a jumper on the card.)

The following command shows the network card's current configuration:

# ifconfig ne0
ne0: flags=8822<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 media: Ethernet 10base2

The software configuration of the network card is very easy. The IP address "192.168.1.1" (which is reserved for internal networks) is assigned to the card.

# ifconfig ne0 inet 192.168.1.1 netmask 0xffffff00

Repeating the previous command now gives a different result:

# ifconfig ne0
ne0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          media: Ethernet 10base2
          inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255

The output of ifconfig has now changed: the IP address is now printed and there are two new flags, "UP" and "RUNNING" If the interface isn't "UP", it will not be used by the system to send packets.

The host was given the IP address 192.168.1.1, which belongs to the set of addresses reserved for internal networks which are not reachable from the Internet. The configuration is finished and must now be tested; if there is another active host on the network, a ping can be tried. For example, if 192.168.1.2 is the address of the active host:

# ping 192.168.1.2
PING ape (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=1.286 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=0.649 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=0.681 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=0.656 ms
^C
----ape PING Statistics----
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.649/0.818/1.286/0.312 ms

With the current setup, at the next boot it will be necessary to repeat the configuration of the network card. In order to avoid repeating the card's configuration at each boot, two things need to be done: first, create the file /etc/ifconfig.ne0 containing the following line:

inet 192.168.1.1 netmask 0xffffff00

Next, in the /etc/rc.conf file, set the following option

auto_ifconfig=YES

At the next boot the network card will be configured automatically.

The /etc/hosts file is a database of IP addresses and textual aliases: it should contain the addresses of all the hosts belonging to the internal network. For example:

#     $NetBSD: hosts,v 1.6 2000/08/15 09:33:05 itojun Exp $
#
# Host Database
# This file should contain the addresses and aliases
# for local hosts that share this file.
# It is used only for "ifconfig" and other operations
# before the nameserver is started.
#
#
127.0.0.1             localhost
#
# RFC 1918 specifies that these networks are "internal".
# 10.0.0.0    10.255.255.255
# 172.16.0.0  172.31.255.255
# 192.168.0.0 192.168.255.255
192.168.1.1   ape.insetti.net ape
192.168.1.2   vespa.insetti.net vespa
192.168.1.0   insetti.net

The /etc/nsswitch.conf should be modified as explained in Example 11-2.

Summing up, to configure the network the following must be done: the network adapters must be installed and physically connected. Next they must be configured (with ifconfig) and, finally, the /etc/hosts and /etc/nsswitch.conf files must be modified. This type of network management in very simplified and is suited only for small networks without sophisticated needs.

11.2.5 Connecting two PCs through a serial line

If you need to transfer files between two PCs which are not networked there is a simple solution which is particularly handy when copying the files to a floppy is not practical: the two machines can be networked with a serial cable (a null modem cable.) The following sections describe some configurations.

# slattach /dev/tty00
# ifconfig sl0 inet 192.168.1.1 192.168.1.2

# slattach /dev/tty00
# ifconfig sl0 inet 192.168.1.2 192.168.1.1

# ping 192.168.1.1

connect '/usr/sbin/chat -v CLIENT CLIENTSERVER'
local
tty00  
115200
crtscts
lock   
noauth
nodefaultroute
:192.168.1.2

11.3.1 IPNAT

The mysterious acronym IPNAT hides the Internet Protocol Network Address Translation, which enables the routing of an internal network on a real network (Internet.) This means that with only one "real" IP, static or dynamic, belonging to a gateway running IPNAT, it is possible to create simultaneous connections to the Internet for all the hosts of the internal network.

Some usage examples of IPNAT can be found in the subdirectory /usr/share/examples/ipf: look at the files BASIC.NAT and nat-setup.

The setup for the example described in this section is detailed in Figure 11-6: host 1 can connect to the Internet calling a provider with a modem and getting a dynamic IP address. host 2 and host 3 can't communicate with the Internet with a normal setup: IPNAT allows them to do it: host 1 will act as a gateway for hosts 2 and 3.

# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding = 1

map ppp0 192.168.1.0/24 -> 0/32 proxy port ftp ftp/tcp
map ppp0 192.168.1.0/24 -> 0/32 portmap tcp/udp 40000:60000
map ppp0 192.168.1.0/24 -> 0/32

#!/bin/sh
# /etc/ppp/ip-up
/etc/rc.d/ipnat forcestart

#!/bin/sh
# /etc/ppp/ip-down
/etc/rc.d/ipnat forcestop

# chmod u+x ip-up ip-down

# route add default 192.168.1.1

11.3.2 NFS

Now that the network is working it is possible to share files and directories over the network using NFS. From the point of view of file sharing, the computer which gives access to its files and directories is called the server, and the computer using these files and directories is the client. A computer can be client and server at the same time.

• A kernel must be compiled with the appropriate options for the client and the server (the options are easy to find in the kernel configuration file. See Section 11.2.1 for more information on NFS related kernel options.

• The server must enable its RPC services in /etc/inetd.conf.

• In /etc/rc.conf the server must enable the inetd and portmap daemons and the nfs_server option.

• In /etc/rc.conf the client must enable inetd and nfs_client.

• The server must list the exported directories in /etc/exports and then run the command kill -HUP `cat /var/run/mountd.pid.

A client host can access a remote directory through NFS if:

• The server host exports the directory.

• The client host mounts the remote directory with the command mount server:/xx/yy /mnt

The mount command has a rich set of options for remote directories which are not very intuitive (to say the least.)

/dev/ra0a on /
/dev/ra0f on /usr
/dev/ra1a on /usr/src
/dev/ra2a on /export

buzz:/export/cli?/root on /
buzz:/export/common/usr on /usr
buzz:/usr/src on /usr/src

# /etc/exports
/usr/src -network 123.45.67.0 -mask 255.255.255.0
/export  -alldirs -maproot=root -network 123.45.67.0 -mask 255.255.255.0

buzz:/export/cli?/root / nfs rw
buzz:/export/common/usr /usr nfs rw,nodev,nosuid
buzz:/usr/src /usr/src rw,nodev,nosuid

11.3.3 Setting up /net with amd

$ showmount -e wuarchive.wustl.edu
Exports list on wuarchive.wustl.edu:
/export/home                       onc.wustl.edu 
/export/local                      onc.wustl.edu 
/export/adm/log                    onc.wustl.edu 
/usr                               onc.wustl.edu 
/                                  onc.wustl.edu 
/archive                           Everyone

$ cd /net/wuarchive.wustl.edu/archive/systems/unix/NetBSD

11.3.4 IPv6 Connectivity & Transition via 6to4

This section will concentrate on how to get network connectivity for IPv6 and - as that's still not easy to get native today - talk in length about the alternatives to native IPv6 connectivity as a transitional method until native IPv6 peers are available.

Finding an ISP that offers IPv6 natively needs quite some luck. What you need next is a router that will be able to handle the traffic. To date, not all router manufacturers offer IPv6 support for their machines, and even if they do, it's unlikely that they offer hardware accelerated IPv6 routing or switching. A rather cheap alternative to the router hardware commonly in use today is using a standard PC and configure it as a router, e.g. by using some Linux or BSD derived operating system like NetBSD, and use software like Zebra for handling the routing protocols. This solution is rather common today for sites that want IPv6 connectivity today. The drawbacks are that you need an ISP that supports IPv6, and that you need dedicated uplink only for IPv6.

If this is not an option for you, you can still get IPv6 connectivity by using tunnels. Instead of talking IPv6 on the wire, the IPv6 packets are encapsulated in IPv4 packets, as shown in Figure 11-7. Using existing IPv4 infrastructure, the encapsulated packets are sent to a IPv6-capable uplink that will then remove the encapsulation, and forward the IPv6 packets via native IPv6.

When using tunnels, there are two possibilities. One is to use a so-called "configured" tunnel, the other is called an "automatic" tunnel. A "configured" tunnel is one that required preparation from both ends of the tunnel, usually connected with some kind of registration to exchange setup information. An example for such a configured tunnel is the IPv6-over-IPv4 encapsulation described in [RFC1933], and that's implemented e.g. by the gif(4) device found in NetBSD.

An "automatic" tunnel consists of a public server that has some kind of IPv6 connectivity, e.g. via 6Bone. That server has made it's connectivity data public, and also runs a tunneling protocol that does not require an explicit registration of the sites using it as uplink. A well-used example of such a protocol is the 6to4 mechanism described in [RFC3056], and that is implemented in the stf(4) device found in NetBSD's. Another mechanism that does not require registration of IPv6-information is the 6over4 mechanism, which implements transporting of IPv6 over a multicast-enabled IPv4 network, instead of e.g. ethernet or FDDI. 6over4 is documented in [RFC2529]. It's main drawback is that you do need existing multicast infrastructure. If you don't have that, setting it up is about as much effort as setting up a configured IPv6 tunnel directly, so it's usually not worth bothering in that case.

options INET6                 # IPv6
pseudo-device stf             # 6to4 IPv6 over IPv4 encapsulation

# ifconfig stf0 inet6 2002:3ee0:3972:1::1 prefixlen 16 alias  (local)

# route add -inet6 default 2002:cdb2:5ac2::1 (remote)

# /sbin/ping6 www.kame.net

# ifconfig ne0 inet6 alias 2002:3ee0:3972:2:1234:56ff:fe78:9abc

# sysctl -w net.inet6.ip6.forwarding=1

# rtadvd

12.3.1 /etc/namedb/named.conf

The NetBSD Operating System provides a set of default files for you to use or go from, they are stored in /etc/namedb, I strongly suggest making a backup copy of this directory for reference purposes.

The default directory contains the following files:

• 127

• localhost

• loopback.v6

• named.conf

• root.cache

You will see modified versions of these files in my configuration.

The first file we want to look at is /etc/namedb/named.conf. This file is the config file for bind (hence the catchy name). Setting up system like the one we are doing is relatively simple. First, here is what mine looks like:

options {
        directory "/etc/namedb";
        allow-transfer { 192.168.1.0/24; };
        recursion yes;
        allow-query { 192.168.1.0/24; };
        listen-on port 53 { 192.168.1.1; };
};
zone "localhost" {
   type master;
   notify no;
   file "localhost";
};
zone "127.IN-ADDR.ARPA" {
   type master;
   notify no;
   file "127";
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {
   type master;
   file "loopback.v6";
};
zone "diverge.org" {
   type master;
   notify no;
   file "diverge.org";
};
zone "1.168.192.in-addr.arpa" {
   type master;
   notify no;
   file "1.168.192";
};
zone "." in {
   type hint;
   file "root.cache";
};

Note that in my named.conf the root section is last, that is because there is another domain called diverge.org on the internet (I happen to own it) so I want the resolver to look out on the internet last. This is not normally the case on most systems.

Another very important thing to remember here is that if you have an internal setup, in other words no live internet connection and/or no need to do root server lookups, comment out the root zone. It may cause lookup problems if a particular client decides it wants to reference a domain on the internet.

Looks like a pretty big mess, upon closer examination it is revealed that many of the lines in each section are somewhat redundant. So we should only have to explain them a few times.

Lets go through the sections of named.conf:

12.3.2 /etc/namedb/localhost

For the most part, the zone files look quite similar, however, each one does have some unique properties. Here is what the localhost file looks like:

 1|$TTL    3600
 2|@              IN SOA  strider.diverge.org. hostmaster.diverge.org. (
 3|                        1       ; Serial
 4|                        8H      ; Refresh
 5|                        2H      ; Retry
 6|                        1W      ; Expire
 7|                        1D)     ; Minimum TTL
 8|                        IN NS   localhost.
 9|localhost.              IN      A       127.0.0.1
10|                        IN      AAAA    ::1

Line by line:

12.3.3 /etc/named/zone.127.0.0

This is the reverse lookup file (or zone) for the localhost. It looks like this:

 1| $TTL    3600
 2| @              IN SOA  strider.diverge.org. root.diverge.org. (
 3|                        1       ; Serial
 4|                        8H      ; Refresh
 5|                        2H      ; Retry
 6|                        1W      ; Expire
 7|                        1D)     ; Minimum TTL
 8|                 IN NS   localhost.
 9| 1.0.0           IN PTR  localhost.

In this file, all of the lines are the same as the localhost zonefile with exception of line 9, this is the reverse lookup record. It is defined in a separate file because it is the localhost and has a totally different address than the remaining zones. Something we will discuss after looking at all of the zone files.

12.3.4 /etc/namedb/diverge.org

This zone file is populated by records for all of our hosts on the 192.168.1.0/24 network. Here is what it looks like:

 1| $TTL    3600
 2| @              IN SOA  strider.diverge.org. root.diverge.org. (
 3|                         1       ; serial
 4|                         8H      ; refresh
 5|                         2H      ; retry
 6|                         1W      ; expire
 7|                         1D )    ; minimum seconds
 8|                 IN NS   strider.diverge.org.
 9|                 IN MX   10 maila.diverge.org.   ; primary mail server
10|                 IN MX   20 mailb.diverge.org.   ; secondary mail server
11| strider         IN A     192.168.1.1
12| maila           IN CNAME strider.diverge.org.
13| samwise         IN A     192.168.1.2
14| www             IN CNAME samwise.diverge.org.
15| mailb
16| worm            IN A     192.168.1.3

There is a lot of new stuff here, so lets just look over each line that is new here:

The rest of the records are simply mappings of IP address to a full name.

12.3.5 /etc/namedb/1.168.192

This zone file is the reverse file for all of the host records, the format is similar to that of the localhost version with the obvious exception being the addresses are different:

 1|$TTL    3600
 2|@              IN SOA  strider.diverge.org. root.diverge.org. (
 3|                     1       ; serial
 4|                     8H      ; refresh
 5|                     2H      ; retry
 6|                     1W      ; expire
 7|                     1D )    ; minimum seconds
 8|                IN NS   strider.diverge.org.
 9|1               IN PTR  strider.diverge.org.
10|2               IN PTR  samwise.diverge.org.
11|3               IN PTR  worm.diverge.org.

12.3.6 /etc/namedb/root.cache

This file is a list of root servers for your server to query when it gets requests outside of it's own domain. Here are first few lines of a root zone file:

;       $NetBSD: root.cache,v 1.8 1997/08/24 15:50:47 perry Exp $
;
;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  file"
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC registration services
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.RS.INTERNIC.NET
;       -OR- under Gopher at    RS.INTERNIC.NET
;           under menu          InterNIC Registration Services (NSI)
;              submenu          InterNIC Registration Archives
;           file                named.root
;
;       last update:    Aug 22, 1997
;       related version of root zone:   1997082200
;
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
;
; formerly NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
;
; formerly C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
. . .

This file can be obtained from ISC at http://www.isc.org/ and usually comes with a distribution of BIND. A root.cache file is included with the NetBSD core Operating System.

12.5.1 Testing the server

Now that the server is running we can test it using the nslookup program.

# nslookup
Default server: localhost
Address: 127.0.0.1
>

Let's try to resolve an host name, for example www.mclink.it (try a site near you.)

> www.mclink.it
Server:  localhost
Address:  127.0.0.1
Name:    www.mclink.it
Address:  195.110.128.8

If you repeat the query a second time, the result is slightly different:

> www.mclink.it
Server:  localhost
Address:  127.0.0.1
Non-authoritative answer:
Name:    www.mclink.it
Address:  195.110.128.8

As you've probably noticed, the address is the same, but the message "Non-authoritative answer", has appeared. This message indicates that the answer is not coming from an authoritative server for the domain mclink.it but from the cache of our own server.

The results of this first test confirm that the server is working correctly.

We can also try the host command, which gives the following result.

# host www.mclink.it
www.mclink.it has address 195.110.128.8

13.1.1 Configuration with genericstable

This type of configuration uses the file /etc/mail/genericstable which contains the mapping used by sendmail to rewrite the internal hostnames.

The first step is therefore to write the genericstable file. For example:

carlo:         alan@bignet.it
root:          alan@bignet.it
news:          alan@bignet.it

For the sake of efficiency, genericstable must be transformed with the following command:

# /usr/sbin/sendmail -bi -oA/etc/mail/genericstable

Now it's time to create the prototype configuration file which we'll use to create the sendmail configuration file.

# cd /usr/share/sendmail/m4

The new sendmail configuration file, which we'll call mycf.mc, contains:

divert(-1)dnl
include(`../m4/cf.m4')dnl
VERSIONID(`mycf.mc created by carlo@ape.insetti.net May 18 2001')dnl
OSTYPE(bsd4.4)dnl
dnl # Settings for masquerading.  Addresses of the following types
dnl # are rewritten
dnl #     carlo@ape.insetti.net
dnl #     carlo@ape
GENERICS_DOMAIN(ape.insetti.net ape)dnl
FEATURE(genericstable)dnl
FEATURE(masquerade_envelope)dnl
define(`SMART_HOST',`mail.bignet.it')dnl
FEATURE(redirect)dnl
FEATURE(nocanonify)dnl
dnl # The following feature is useful if sendmail is called by
dnl # fetchmail (which is usually the case.)  If sendmail cannot
dnl # resolve the name of the sender, the mail will not be delivered.
dnl # For example:
dnl #   MAIL FROM:<www-owner@NetBSD.org> SIZE=2718
dnl #   501 <www-owner@NetBSD.org>... Sender domain must exist
FEATURE(`accept_unresolvable_domains')dnl
dnl # accept_unqualified_senders is useful with some MUA, which send
dnl # mail as, for example:
dnl #   MAIL FROM:<carlo>
FEATURE(`accept_unqualified_senders')dnl
dnl # Mail for `smtp' mailer is marked `expensive' (`e' flag):
dnl # instead of connecting with the relay, sendmail puts it in
dnl # a queue for delayed processing.
dnl # Sendmail starts complaining about undelivered messages after
dnl # 16 hours.
define(`SMTP_MAILER_FLAGS',`e')dnl
define(`confCON_EXPENSIVE',`True')dnl
define(`confTO_QUEUEWARN', `16h')dnl
dnl # For european users
define(`confDEF_CHAR_SET',`ISO-8859-1')dnl
dnl # Enable the following three lines to use procmail as a local
dnl # delivery agent.  The third line is optional, only the first
dnl # two are required.
dnl # define(`PROCMAIL_MAILER_PATH', /usr/pkg/bin/procmail)dnl
dnl # FEATURE(local_procmail)dnl
dnl # MAILER(procmail)dnl
dnl # The following two mailers must always be defined
MAILER(local)dnl
MAILER(smtp)dnl

This configuration tells sendmail to rewrite the addresses of type "ape.insetti.net" using the real names found in the /etc/mail/genericstable file. It also says that mail should be sent to the "mail.bignet.it" server. The meaning of the options is described in detail in the file /usr/share/sendmail/README.

In order to create your own version of the example configuration file, you must change only two lines, substituting your real data:

GENERICS_DOMAIN(ape.insetti.net ape)dnl
define(`SMART_HOST',`mail.bignet.it')dnl

Finally, the new configuration file must be generated, after having saved the previous version:

# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.bak
# m4 mycf.mc > /etc/mail/sendmail.cf

Another important file is /etc/mail/aliases, which can be left in the default configuration, although it is still necessary to give the following command:

# newaliases

Now everything is ready to start sending mail.

13.1.2 Testing the configuration

Sendmail is finally configured and ready to work, but before sending real mail it is better to do some simple tests. First let's try sending a local e-mail with the following command:

$ sendmail -v carlo
Subject: test
Prova
.
carlo... Connecting to local...
carlo... Sent

Please follow exactly the example above: leave a blank line after Subject: and end the message with a line containing only one dot. Now you should be able to read the message with your mail client and verify that the From: field has been correctly rewritten.

From: alan@bignet.it

Next you can verify the address rewriting rules directly, using sendmail in address test mode with option -bt. This mode shows the parsing performed by sendmail for an address and how it gets rewritten according to the rules in the configuration file. It is also possible to perform other tests and view some information.

$ sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
>

You can display the help with the "?" command.

First, let's verify that the generictable map file works correctly:

/map generics carlo
map_lookup: generics (carlo) returns alan@bignet.it

Everything's ok here; sendmail found the local name and its real counterpart in the map.

Now we can test the rewriting of the envelope's sender address with the following commands:

/tryflags ES
/try smtp carlo@ape.insetti.net

The result should be similar to the following:

Trying envelope sender address carlo@ape.insetti.net for mailer smtp
rewrite: ruleset   3   input: carlo @ ape . insetti . net
rewrite: ruleset  96   input: carlo < @ ape . insetti . net >
rewrite: ruleset  96 returns: carlo < @ ape . insetti . net . >
rewrite: ruleset   3 returns: carlo < @ ape . insetti . net . >
rewrite: ruleset   1   input: carlo < @ ape . insetti . net . >
rewrite: ruleset   1 returns: carlo < @ ape . insetti . net . >
rewrite: ruleset  11   input: carlo < @ ape . insetti . net . >
rewrite: ruleset  51   input: carlo < @ ape . insetti . net . >
rewrite: ruleset  51 returns: carlo < @ ape . insetti . net . >
rewrite: ruleset  61   input: carlo < @ ape . insetti . net . >
rewrite: ruleset  61 returns: carlo < @ ape . insetti . net . >
rewrite: ruleset  94   input: carlo < @ ape . insetti . net . >
rewrite: ruleset  93   input: carlo < @ ape . insetti . net . >
rewrite: ruleset   3   input: alan @ bignet . it
rewrite: ruleset  96   input: alan < @ bignet . it >
rewrite: ruleset  96 returns: alan < @ bignet . it >
rewrite: ruleset   3 returns: alan < @ bignet . it >
rewrite: ruleset  93 returns: alan < @ bignet . it >
rewrite: ruleset  94 returns: alan < @ bignet . it >
rewrite: ruleset  11 returns: alan < @ bignet . it >
rewrite: ruleset   4   input: alan < @ bignet . it >
rewrite: ruleset   4 returns: alan @ bignet . it
Rcode = 0, addr = alan@bignet.it
>

As you can see, the local address has been rewritten to the real address, which will appear in your e-mails when they leave your system.

You can achieve a similar result with the following command:

/try smtp carlo

We can also verify the rewriting of the header's sender with the following commands:

/tryflags HS
/try smtp carlo@ape.insetti.net

13.1.3 Using an alternative MTA

Starting from version 1.4 of NetBSD sendmail is not called directly:

$ ls -l /usr/sbin/sendmail
lrwxr-xr-x  1 root  wheel  21 Nov  1 01:14 /usr/sbin/sendmail@ -> /usr/sbin/mailwrapper

The purpose of mailwrapper is to allow the usage of an alternative MTA instead of sendmail (for example, postfix). If you plan to use a different mailer I suggest that you read the mailwrapper(8) and the mailer.conf(5) manpages, which are very clear.

14.1.1 50 lines text mode with wscons

A text mode with 50 lines can be used starting with version 1.4.1 of NetBSD. This mode is activated in the /etc/wscons.conf. The following line must be uncommented:

font ibm  -  8  ibm  /usr/share/pcvt/fonts/vt220l.808

Then the following lines must be modified:

#screen 0       80x50   vt100
screen  1       80x50   vt100
screen  2       80x50   vt100
screen  3       80x50   vt100
screen  4       80x50   vt100
screen  5       80x50   vt100
screen  6       80x50   vt100
screen  7       80x50   vt100

This configuration enables eight screens, which can be accessed with the key combination Ctrl-Alt-Fn (where n varies from 1 to 8); the corresponding devices are ttyE0..ttyE7. To enable them and get a login prompt, /etc/ttys must be modified:

ttyE0   "/usr/libexec/getty Pc"         vt220   on secure
ttyE1   "/usr/libexec/getty Pc"         vt220   on secure
ttyE2   "/usr/libexec/getty Pc"         vt220   on secure
ttyE3   "/usr/libexec/getty Pc"         vt220   on secure
ttyE4   "/usr/libexec/getty Pc"         vt220   on secure
ttyE5   "/usr/libexec/getty Pc"         vt220   on secure
ttyE6   "/usr/libexec/getty Pc"         vt220   on secure
ttyE7   "/usr/libexec/getty Pc"         vt220   on secure

It is not possible to modify the 80x25 setting of screen 0, probably to guarantee that even in case of problems there is always a working screen.

14.1.2 wsmouse

14.3.1 Changing the screen size

With pcvt you can change the number of lines and columns on the screen. The following example script can be used to automatically switch between different configurations:

#!/bin/sh
# Set the screen to # lines
case $1 in
  25)
    /usr/local/bin/scon -s 25
    /usr/local/bin/cursor -s13 -e14
    ;;
  28)  
    /usr/local/bin/loadfont -c1 -f
    /usr/share/misc/pcvtfonts/vt220l.814
    /usr/local/bin/loadfont -c2 -f
    /usr/share/misc/pcvtfonts/vt220h.814
    /usr/local/bin/scon -s 28
    /usr/local/bin/cursor -s12 -e14
    ;; 
  40) 
    /usr/local/bin/loadfont -c3 -f
    /usr/share/misc/pcvtfonts/vt220l.810
    /usr/local/bin/loadfont -c4 -f
    /usr/share/misc/pcvtfonts/vt220h.810
    /usr/local/bin/scon -s 40
    /usr/local/bin/cursor -s8 -e10
    ;;
  50) 
    /usr/local/bin/loadfont -c5 -i
    /usr/share/misc/pcvtfonts/vt220l.808
    /usr/local/bin/loadfont -c6 -i
    /usr/share/misc/pcvtfonts/vt220h.808
    /usr/local/bin/scon -s 50
    /usr/local/bin/cursor -s6 -e8
    ;;
  *)
    echo "Invalid # of lines (25/28/40/50)"
    ;;
esac

15.1.1 The vi interface

Using the vi editor really is not much different than any other terminal based software with one exception, it does not use a tab type (or curses if you will) style interface, although many versions of vi do use curses it does not give the same look and feel of the typical curses based interface. Instead it works in two modes, command and edit. While this may seem strange, it is not much different than windows based editing if you think about it. Take this as an example, if you are using say gedit and you take the mouse, highlight some text, select cut and then paste, the whole time you are using the mouse you are not editing (even though you can). In vi, the same action is done by simply deleting the whole line wi