diff --git a/handbook/dialout.sgml b/handbook/dialout.sgml index 0964e8f5a7..3d1bf46bd7 100644 --- a/handbook/dialout.sgml +++ b/handbook/dialout.sgml @@ -1,249 +1,249 @@ Dialout service

Information integrated from FAQ. The following are tips to getting your host to be able to connect over the modem to another computer. This is appropriate for establishing a terminal session with a remote host.

This is useful to log onto a BBS.

This kind of connection can be extremely helpful to get a file on the Internet if you have problems with PPP. If you need to ftp something and PPP is broken, use the terminal session to ftp it. Then use zmodem to transfer it to your machine. Why cannot I run

On your system, the programs chmod 4511 /usr/bin/tip You do not have to run this command for - My stock Hayes modem is not supported—what can I do? + My stock Hayes modem is not supported, what can I do?

Actually, the man page for /etc/remote file. The Hayes driver is not smart enough to recognize some of the advanced features of newer modems—messages like /usr/src/usr.bin/tip/tip Obviously you need the source distribution to do this. Edit the line `` How am I expected to enter these AT commands?

Make what is called a ``/etc/remote file. For example, if your modem is hooked up to the first serial port, /dev/cuaa0, then put in the following line: cuaa0:dv=/dev/cuaa0:br#19200:pa=none Use the highest bps rate your modem supports in the br capability. Then, type ``/dev/cuaa0 on your system, do this: cd /dev MAKEDEV cuaa0

Or use cu as root with the following command: cu -l``line'' -s``speed'' with line being the serial port (e.g./dev/cuaa0) and speed being the speed (e.g.57600). When you are done entering the AT commands hit ~. to exit. The

The /etc/phones for a phone number. But the /etc/remote. Escape it with a backslash: pn=\@ How can I dial a phone number on the command line?

Put what is called a ``/etc/remote file. For example: tip115200|Dial any phone number at 115200 bps:\ :dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du: tip57600|Dial any phone number at 57600 bps:\ :dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du: Then you can things like `` cu115200|Use cu to dial any number at 115200bps:\ :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du: and type `` Do I have to type in the bps rate every time I do that?

Put in an entry for I access a number of hosts through a terminal server.

Rather than waiting until you are connected and typing ``/etc/remote: pain|pain.deep13.com|Forrester's machine:\ :cm=CONNECT pain\n:tc=deep13: muffin|muffin.deep13.com|Frank's machine:\ :cm=CONNECT muffin\n:tc=deep13: deep13:Gizmonics Institute terminal server:\ :dv=/dev/cua02:br#38400:at=hayes:du:pa=none:pn=5551234: will let you type `` Can tip try more than one line for each site?

This is often a problem where a university has several modem lines and several thousand students trying to use them...

Make an entry for your university in /etc/remote - and use \@ for the @ for the big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: Then, list the phone numbers for the university in /etc/phones: big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 Why do I have to hit CTRL+P twice to send CTRL+P once?

CTRL+P is the default ``force'' character, used to tell $HOME/.tiprc file: force= Suddenly everything I type is in UPPER CASE??

You must have pressed CTRL+A, force=^^ raisechar=^^ The ^^ is SHIFT+CTRL+6. How can I do file transfers with

If you are talking to another UNIX system, you can send and receive files with ~p [] ~t [] There is no error checking, so you probably should use another protocol, like zmodem. How can I run zmodem with

To receive files, start the sending program on the remote end. Then, type `` diff --git a/handbook/kernelopts.sgml b/handbook/kernelopts.sgml index 19011f501b..392803a09d 100644 --- a/handbook/kernelopts.sgml +++ b/handbook/kernelopts.sgml @@ -1,149 +1,149 @@ - + Adding New Kernel Configuration Options

Contributed by &a.joerg; before reading here. What's a kernel option, anyway?

The use of kernel options is basically described in the section. There's also an explanation about ``historic'' and ``new-style'' options. The ultimate goal is to eventually turn all the supported options in the kernel into new-style ones, so for people who correctly did a Basically, a kernel option is nothing else than the definition of a C preprocessor macro for the kernel compilation process. To make the build truly optional, the corresponding part of the kernel source (or kernel #ifndef THIS_OPTION #define THIS_OPTION (some_default_value) #endif /* THIS_OPTION */

This way, an administrator mentioning another value for the option in his config file will take the default out of effect, and replace it with his new value. Apparently, the new value will be substituted into the source code during the preprocessor run, so it must be a valid C expression in whatever context the default value would have been used.

It is also possible to create value-less options that simply enable or disable a particular piece of code by embracing it in #ifdef THAT_OPTION -... +[your code here] #endif

Simply mentioning People familiar with the C language will immediately recognize that everything could be counted as a ``config option'' where there is at least a single options notyet,notdef

in their config file however, and watch the kernel compilation fall over. :-)

Apparently, using arbitrary names for the options makes it very hard to track their usage throughout the kernel source tree. That is the rationale behind the opt_foo.h. This way, the usual Makefile dependencies could be applied, and The old-style option mechanism still has one advantage for local options or maybe experimental options that have a short anticipated lifetime: since it is easy to add a new Now what do I have to do for it?

First, edit sys/conf/options (or sys/i386/conf/options.<arch>, e. g. sys/i386/conf/options.i386), and select an opt_foo.h file where your new option would best go into.

If there is already something that comes close to the purpose of the new option, pick this. For example, options modifying the overall behaviour of the SCSI subsystem can go into If there is no opt_foo.h already available for the intended new option, invent a new name. Make it meaningful, and comment the new section in the options[.<arch>] file. Packing too many options into a single opt_foo.h will cause too many kernel files to be rebuilt when one of the options has been changed in the config file.

Finally, find out which kernel files depend on the new option. Unless you have just invented your option, and it does not exist anywhere yet, find /usr/src/sys -name type f | xargs fgrep NEW_OPTION

is your friend in finding them. Go and edit all those files, and add #include "opt_foo.h"

on top, before all the #ifndef NEW_OPTION #define NEW_OPTION (something) #endif

in the regular header.

Adding an option that overrides something in a system header file (i. e., a file sitting in /usr/include/sys/) is almost always a mistake. opt_foo.h cannot be included into those files since it would break the headers more seriously, but if it is not included, then places that include it may get an inconsistent value for the option. Yes, there are precedents for this right now, but that does not make them more correct. diff --git a/handbook/mail.sgml b/handbook/mail.sgml index d6dbb88887..1f84ee2597 100644 --- a/handbook/mail.sgml +++ b/handbook/mail.sgml @@ -1,430 +1,430 @@ - Electronic Mail

Contributed by &a.wlloyd;.

Electronic Mail configuration is the subject of many books. If you plan on doing anything beyond setting up one mailhost for your network, you need industrial strength help. Some parts of E-Mail configuration are controlled in the Domain Name System (DNS). If you are going to run your own own DNS server check out /etc/namedb and ' man -k named ' for more information. Basic Information

These are the major programs involved in an E-Mail exchange. A User program

This is a program like sendmail or delivering it over TCP. Mailhost Server Daemon

Usually this program is /etc/sysconfig . It is best to leave it on, unless you have a specific reason to want it off. Example: You are building a .

You should be aware that sendmail is a potential weak link in a secure site. Some versions of sendmail have known security problems.

sendmail does two jobs. It looks after delivering and receiving mail. If needs to delivery mail off your site it will look up in the DNS to determine the actual host that will receive mail for the destination.

If it is acting as a delivery agent DNS - Name Service

The Domain Name System and its daemon POP Servers

This program gets the mail from your mailbox and gives it to your browser. If you want to run a POP server on your computer, you will need to do 2 things. Get pop software from the that can be found in /usr/ports or packages collection. This handbook section has a complete reference on the system. Modify /etc/inetd.conf to load the POP server. The pop program will have instructions with it. Read them. Configuration Basic

As your FreeBSD system comes "out of the box"[TM], you should be able to send E-mail to external hosts as long as you have /etc/resolv.conf setup or are running a name server. If you want to have mail for your host delivered to your specific host,there are two methods:

- Run a name server ( man -k named ) and have your own domain smallminingco.com

- Get mail delivered to the current DNS name for your host. Ie: dorm6.ahouse.school.edu

No matter what option you choose, to have mail delivered directly to your host, you must be a full Internet host. You must have a permanent IP address. IE: NO dynamic PPP. If you are behind a firewall, the firewall must be passing on smtp traffic to you. From /etc/services smtp 25/tcp mail #Simple Mail Transfer If you want to receive mail at your host itself, you must make sure that the DNS MX entry points to your hosts address, or there is no MX entry for your DNS name. Try this newbsdbox# hostname newbsdbox.freebsd.org newbsdbox# host newbsdbox.freebsd.org newbsdbox.freebsd.org has address 204.216.27.xx If that is all that comes out for your machine, mail directory to root@newbsdbox.freebsd.org will work no problems. If instead, you have this newbsdbox# host newbsdbox.freebsd.org newbsdbox.FreeBSD.org has address 204.216.27.xx newbsdbox.FreeBSD.org mail is handled (pri=10) by freefall.FreeBSD.org All mail sent to your host directly will end up on freefall, under the same username. This information is setup in your domain name server. This should be the same host that is listed as your primary nameserver in /etc/resolv.conf The DNS record that carries mail routing information is the Mail eXchange entry. If no MX entry exists, mail will be delivered directly to the host by way of the Address record. The MX entry for freefall.freebsd.org at one time. freefall MX 30 mail.crl.net freefall MX 40 agora.rdrop.com freefall HINFO Pentium FreeBSD freefall MX 10 freefall.FreeBSD.org freefall MX 20 who.cdrom.com freefall A 204.216.27.xx freefall CNAME www.FreeBSD.org freefall has many MX entries. The lowest MX number gets the mail in the end. The others will queue mail temporarily, if freefall is busy or down. Alternate MX sites should have separate connections to the Internet, to be most useful. An Internet Provider or other friendly site can provide this service. dig, nslookup, and host are your friends. Mail for your Domain (Network).

To setup up a network mailhost, you need to direct the mail from arriving at all the workstations. In other words, you want to hijack all mail for *.smallminingco.com and divert it to one machine, your mailhost. The network users on their workstations will most likely pick up their mail over POP or telnet. A user account with the SAME USERNAME should exist on both machines. Please use /nonexistent the user will not be allowed to login. The mailhost that you will be using must be designated the Mail eXchange for each workstation. This must be arranged in DNS (ie BIND, named). Please refer to a Networking book for in-depth information. You basically need to add these lines in your DNS server. pc24.smallminingco.com A xxx.xxx.xxx.xxx ; Workstation ip MX 10 smtp.smallminingco.com ; Your mailhost You cannot do this yourself unless you are running a DNS server. If you do not want to run a DNS server, get somebody else like your Internet Provider to do it. This will redirect mail for the workstation to the Mail eXchange host. It does not matter what machine the A record points to, the mail will be sent to the MX host.

This feature is used to implement Virtual E-Mail Hosting.

Example

I have a customer with domain foo.bar and I want all mail for foo.bar to be sent to my machine smtp.smalliap.com. You must make an entry in your DNS server like: foo.bar MX 10 smtp.smalliap.com ; your mailhost The A record is not needed if you only want E-Mail for the domain. IE: Don't expect ping foo.bar to work unless an Address record for foo.bar exists as well. On the mailhost that actually accepts mail for final delivery to a mailbox, sendmail must be told what hosts it will be accepting mail for.

Add pc24.smallminingco.com to /etc/sendmail.cw (if you are using FEATURE(use_cw_file)), or add a "Cw myhost.smalliap.com" line to /etc/sendmail.cf

If you plan on doing anything serious with . Setting up UUCP.

Stolen from the FAQ.

The sendmail configuration that ships with FreeBSD is suited for sites that connect directly to the Internet. Sites that wish to exchange their mail via UUCP must install another sendmail configuration file.

Tweaking /etc/sendmail.cf manually is considered something for purists. Sendmail version 8 comes with a new approach of generating config files via some m4 preprocessing, where the actual hand-crafted configuration is on a higher abstraction level. You should use the configuration files under /usr/src/usr.sbin/sendmail/cf If you did not install your system with full sources, the sendmail config stuff has been broken out into a separate source distribution tarball just for you. Assuming you have your CD-ROM mounted, do: cd /usr/src tar -xvzf /cdrom/dists/src/ssmailcf.aa Do not panic, this is only a few hundred kilobytes in size. The file README in the cf directory can serve as a basic introduction to m4 configuration.

For UUCP delivery, you are best advised to use the mailertable feature. This constitutes a database that sendmail can use to base its routing decision upon.

First, you have to create your .mc file. The directory /usr/src/usr.sbin/sendmail/cf/cf is the home of these files. Look around, there are already a few examples. Assuming you have named your file foo.mc, all you need to do in order to convert it into a valid sendmail.cf is: cd /usr/src/usr.sbin/sendmail/cf/cf make foo.cf cp foo.cf /etc/sendmail.cf A typical .mc file might look like: include(`../m4/cf.m4') VERSIONID(`Your version number') OSTYPE(bsd4.4) FEATURE(nodns) FEATURE(nocanonify) FEATURE(mailertable) define(`UUCP_RELAY', your.uucp.relay) define(`UUCP_MAX_SIZE', 200000) MAILER(local) MAILER(smtp) MAILER(uucp) Cw your.alias.host.name Cw youruucpnodename.UUCP The nodns and nocanonify features will prevent any usage of the DNS during mail delivery. The UUCP_RELAY clause is needed for bizarre reasons, do not ask. Simply put an Internet hostname there that is able to handle .UUCP pseudo-domain addresses; most likely, you will enter the mail relay of your ISP there.

Once you have this, you need this file called /etc/mailertable. A typical example of this gender again: # # makemap hash /etc/mailertable.db < /etc/mailertable # horus.interface-business.de uucp-dom:horus .interface-business.de uucp-dom:if-bus interface-business.de uucp-dom:if-bus .heep.sax.de smtp8:%1 horus.UUCP uucp-dom:horus if-bus.UUCP uucp-dom:if-bus . uucp-dom:sax As you can see, this is part of a real-life file. The first three lines handle special cases where domain-addressed mail should not be sent out to the default route, but instead to some UUCP neighbor in order to ``shortcut'' the delivery path. The next line handles mail to the local Ethernet domain that can be delivered using SMTP. Finally, the UUCP neighbors are mentioned in the .UUCP pseudo-domain notation, to allow for a ``uucp-neighbor!recipient'' override of the default rules. The last line is always a single dot, matching everything else, with UUCP delivery to a UUCP neighbor that serves as your universal mail gateway to the world. All of the node names behind the uucp-dom: keyword must be valid UUCP neighbors, as you can verify using the command uuname.

As a reminder that this file needs to be converted into a DBM database file before being usable, the command line to accomplish this is best placed as a comment at the top of the mailertable. You always have to execute this command each time you change your mailertable.

Final hint: if you are uncertain whether some particular mail routing would work, remember the -bt option to sendmail. It starts sendmail in address test mode; simply enter ``0 '', followed by the address you wish to test for the mail routing. The last line tells you the used internal mail agent, the destination host this agent will be called with, and the (possibly translated) address. Leave this mode by typing Control-D. j@uriah 191% sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

> 0 foo@interface-business.de rewrite: ruleset 0 input: foo @ interface-business . de ... rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \ < @ interface-business . de > > ^D j@uriah 192% FAQ

Migration from FAQ. Why do I have to use the FQDN for hosts on my site?

You will probably find that the host is actually in a different domain; for example, if you are in foo.bar.edu and you wish to reach a host called ``mumble'' in the bar.edu domain, you will have to refer to it by the fully-qualified domain name, ``mumble.bar.edu'', instead of just ``mumble''.

Traditionally, this was allowed by BSD BIND resolvers. However the current version of BIND that ships with FreeBSD no longer provides default abbreviations for non-fully qualified domain names other than the domain you are in. So an unqualified host mumble must either be found as mumble.foo.bar.edu, or it will be searched for in the root domain.

This is different from the previous behavior, where the search continued across mumble.bar.edu, and mumble.edu. Have a look at RFC 1535 for why this was considered bad practice, or even a security hole.

As a good workaround, you can place the line

search foo.bar.edu bar.edu

instead of the previous

domain foo.bar.edu

into your /etc/resolv.conf. However, make sure that the search order does not go beyond the ``boundary between local and public administration'', as RFC 1535 calls it. Sendmail says ``mail loops back to myself''

This is answered in the sendmail FAQ as follows:- * I am getting "Local configuration error" messages, such as: 553 relay.domain.net config error: mail loops back to myself 554 ... Local configuration error How can I solve this problem? You have asked mail to the domain (e.g., domain.net) to be forwarded to a specific host (in this case, relay.domain.net) by using an MX record, but the relay machine does not recognize itself as domain.net. Add domain.net to /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" to /etc/sendmail.cf.

The sendmail FAQ is in /usr/src/usr.sbin/sendmail and is recommended reading if you want to do any ``tweaking'' of your mail setup. How can I do E-Mail with a dialup PPP host?

You want to connect a FreeBSD box on a lan, to the Internet. The FreeBSD box will be a mail gateway for the lan. The PPP connection is non-dedicated. There are at least two way to do this. The other is to use UUCP. The key is to get a Internet site to provide secondary MX services for your domain. For example: bigco.com. MX 10 bigco.com. MX 20 smalliap.com. Only one host should be specified as the final recipient ( add ``Cw bigco.com'' in /etc/sendmail.cf on bigco.com). When the senders sendmail is trying to deliver the mail it will try to connect to you over the modem link. It will most likely time out because you are not online. Sendmail will automatically deliver it to the secondary MX site, ie your Internet provider. The secondary MX site will try every (sendmail_flags = "-bd -q15m" in /etc/sysconfig ) 15 minutes to connect to your host to deliver the mail to the primary MX site. You might wat to use something like this as a login script. #!/bin/sh # Put me in /usr/local/bin/pppbigco ( sleep 60 ; /usr/sbin/sendmail -q ) & /usr/sbin/ppp -direct pppbigco If you are going to create a separate login script for a user you could use sendmail -qRbigco.com instead in the script above. This will force all mail in your queue for bigco.com to be processed immediately. A further refinement of the situation is as follows. Message stolen from the freebsd-isp mailing list. > we provide the secondary mx for a customer. The customer connects to > our services several times a day automatically to get the mails to > his primary mx (We do not call his site when a mail for his domains > arrived). Our sendmail sends the mailqueue every 30 minutes. At the > moment he has to stay 30 minutes online to be sure that all mail is > gone to the primary mx. > > Is there a command that would initiate sendmail to send all the mails > now? The user has not root-privileges on our machine of course. In the 'privacy flags' section of sendmail.cf, there is a definition Opgoaway,restrictqrun Remove restrictqrun to allow non-root users to start the queue processing. You might also like to rearrange the MXs. We are the 1st MX for our customers like this, and we have defined: # If we are the best MX for a host, try directly instead of generating # local config error. OwTrue That way a remote site will deliver straight to you, without trying the customer connection. You then send to your customer. Only works for -'hosts', so you need to get your customer to name their mail machine -'customer.com' as well as 'hostname.customer.com' in the DNS. Just put -an A record in the DNS for 'customer.com'. +"hosts", so you need to get your customer to name their mail machine +"customer.com" as well as "hostname.customer.com" in the DNS. Just put +an A record in the DNS for "customer.com". diff --git a/handbook/term.sgml b/handbook/term.sgml index ae1aca84a4..c801549ece 100644 --- a/handbook/term.sgml +++ b/handbook/term.sgml @@ -1,539 +1,539 @@ Terminals

Contributed by &a.kelly;28 July 1996 Terminals provide a convenient and low-cost way to access the power of your FreeBSD system when you are not at the computer's console or on a connected network. This section describes how to use terminals with FreeBSD. Uses and Types of Terminals

The original Unix systems did not have consoles. Instead, people logged in and ran programs through terminals that were connected to the computer's serial ports. It is quite similar to using a modem and some terminal software to dial into a remote system to do text-only work. Today's PCs have consoles capable of high quality graphics, but the ability to establish a login session on a serial port still exists in nearly every Unix-style operating system today; FreeBSD is no exception. By using a terminal attached to a unused serial port, you can log in and run any text program that you would normally run on the console or in an The remaining subsections describe each kind. Dumb Terminals

Dumb terminals are specialized pieces of hardware that let you connect to computers over serial lines. They are called ``dumb'' because they have only enough computational power to display, send, and receive text. You cannot run any programs on them. It is the computer to which you connect them that has all the power to run text editors, compilers, email, games, and so forth. There are hundreds of kinds of dumb terminals made by many manufacturers, including Digital Equipment Corporation's VT-100 and Wyse's WY-75. Just about any kind will work with FreeBSD. Some high-end terminals can even display graphics, but only certain software packages can take advantage of these advanced features. Dumb terminals are popular in work environments where workers do not need access to graphic applications such as those provided by the X Window System. PCs Acting As Terminals

If a has just enough ability to display, send, and receive text, then certainly any spare personal computer can be a dumb terminal. All you need is the proper cable and some X Terminals

X terminals are the most sophisticated kind of terminal available. Instead of connecting to a serial port, they usually connect to a network like Ethernet. Instead of being relegated to text-only applications, they can display any X application. We introduce X terminals just for the sake of completeness. However, this chapter does Cables and Ports

To connect a terminal to your FreeBSD system, you need the right kind of cable and a serial port to which to connect it. This section tells you what to do. If you are already familiar with your terminal and the cable it requires, skip to . Cables

Because terminals use serial ports, you need to use serial---also known as RS-232C---cables to connect the terminal to the FreeBSD system. There are a couple of kinds of serial cables. Which one you'll use depends on the terminal you want to connect: If you are connecting a personal computer to act as a terminal, use a cable. A null-modem cable connects two computers or terminals together. If you have an actual terminal, your best source of information on what cable to use is the documentation that accompanied the terminal. If you do not have the documentation, then try a cable. If that does not work, then try a cable. Also, the serial port on Null-modem cables

A null-modem cable passes some signals straight through, like ``signal ground,'' but switches other signals. For example, the ``send data'' pin on one end goes to the ``receive data'' pin on the other end. If you like making your own cables, here is a table showing a recommended way to construct a null-modem cable for use with terminals. This table shows the RS-232C signal names and the pin numbers on a DB-25 connector. Signal Pin# Pin# Signal TxD 2 ----------------------- 3 RxD RxD 3 ----------------------- 2 TxD DTR 20 ----------------------- 6 DSR DSR 6 ----------------------- 20 DTR SG 7 ----------------------- 7 SG DCD 8 ----------------------+ 4 RTS* *RTS 4 + + 5 CTS* *CTS 5 +---------------------- 8 DCD * Connect pins 4 to 5 internally in the connector hood, and then to pin 8 in the remote hood. Standard RS-232C Cables

A standard serial cable passes all the RS-232C signals straight-through. That is, the ``send data'' pin on one end of the cable goes to the ``send data'' pin on the other end. This is the type of cable to connect a modem to your FreeBSD system, and the type of cable needed for some terminals. Ports

Serial ports are the devices through which data is transferred between the FreeBSD host computer and the terminal. This section describes the kinds of ports that exist and how they are addressed in FreeBSD. Kinds of Ports

Several kinds of serial ports exist. Before you purchase or construct a cable, you need to make sure it will fit the ports on your terminal and on the FreeBSD system. Most terminals will have DB25 ports. Personal computers, including PCs running FreeBSD, will have DB25 or DB9 ports. If you have a multiport serial card for your PC, you may have RJ-12 or RJ-45 ports. See the documentation that accompanied the hardware for specifications on the kind of port in use. A visual inspection of the port often works, too. Port Names

In FreeBSD, you access each serial port through an entry in the /dev directory. There are two different kinds of entries: Callin ports are named /dev/ttyd where Callout ports are named /dev/cuaa. You usually do not use the callout port for terminals, just for modems. You may use the callout port if the serial cable or the terminal does not support the carrier detect signal. See the sio(4) manual page for more information. If you have connected a terminal to the first serial port (COM1 in DOS parlance), then you want to use /dev/ttyd0 to refer to the terminal. If it is on the second serial port (also known as COM2), it is /dev/ttyd1, and so forth. Note that you may have to configure your kernel to support each serial port, especially if you have a multiport serial card. See for more information. Configuration

This section describes what you need to configure on your FreeBSD system to enable a login session on a terminal. It assumes you have already configured your kernel to support the serial port to which the terminal is connected---and that you have connected it. In a nutshell, you need to tell the /etc/ttys file. First, use the /etc/ttys: Add an line to /etc/ttys for the entry in the /dev directory for the serial port if it is not already there. Specify that /usr/libexec/getty be run on the port, and specify the appropriate /etc/gettytab file. Specify the default terminal type. Set the port to ``on.'' Specify whether the port should be ``secure.'' Force /etc/ttys file. As an optional step, you may wish to create a custom /etc/gettytab. This document does not explain how to do so; you are encouraged to see the gettytab(5) and the getty(8) manual pages for more information. The remaining sections detail how to do these steps. We will use a running example throughout these sections to illustrate what we need to do. In our example, we will connect two terminals to the system: a Wyse-50 and a old 286 IBM PC running Procomm terminal software emulating a VT-100 terminal. We connect the Wyse to the second serial port and the 286 to the sixth serial port (a port on a multiport serial card). For more information on the /etc/ttys file, see the ttys(5) manual page. Adding an Entry to /etc/ttys

First, you need to add an entry to the /etc/ttys file, unless one is already there. The /etc/ttys file lists all of the ports on your FreeBSD system where you want to allow logins. For example, the first virtual console ttyv0 has an entry in this file. You can log in on the console using this entry. This file contains entries for the other virtual consoles, serial ports, and pseudo-ttys. For a hardwired terminal, just list the serial port's /dev entry without the /dev part. When you installed your FreeBSD system, the /etc/ttys file included entries for the first four serial ports: /etc/ttys file after we add the new entry: ttyd1 "/usr/libexec/getty std.9600" unknown off secure ttyd5 Specifying the

Next, we need to specify what program will be run to handle the logins on a terminal. For FreeBSD, the standard program to do that is /usr/libexec/getty. It is what provides the login: prompt. The program /etc/gettytab. The file /etc/gettytab contains lots of entries for terminal lines both old and new. In almost all cases, the entries that start with the text /etc/ttys file, make sure that the communications settings on the terminal match. For our example, the Wyse-50 uses no parity and connects at 38400 bps. The 286 PC uses no parity and connects at 19200 bps. Here is the /etc/ttys file so far (showing just the two terminals in which we are interested): ttyd1 "/usr/libexec/getty std.38400" unknown off secure ttyd5 "/usr/libexec/getty std.19200" Note that the second field---where we specify what program to run---appears in quotes. This is important, otherwise the type argument to Specifying the Default Terminal Type

The third field in the /etc/ttys file lists the default terminal type for the port. For dialup ports, you typically put /etc/ttys file, users can forego such prompting. To find out what terminal types FreeBSD supports, see the file /usr/share/misc/termcap. It lists about 600 terminal types. You can add more if you wish. See the termcap(5) manual page for information. In our example, the Wyse-50 is a Wyse-50 type of terminal (although it can emulate others, we will leave it in Wyse-50 mode). The 286 PC is running Procomm which will be set to emulate a VT-100. Here are the pertinent yet unfinished entries from the /etc/ttys file: ttyd1 "/usr/libexec/getty std.38400" wy50 off secure ttyd5 "/usr/libexec/getty std.19200" vt100 Enabling the Port

The next field in /etc/ttys, the fourth field, tells whether to enable the port. Putting /etc/ttys file. We have turned each port ttyd1 "/usr/libexec/getty std.38400" wy50 on secure ttyd5 "/usr/libexec/getty std.19200" vt100 on Specifying Secure Ports

We have arrived at the last field (well, almost: there is an optional /etc/ttys file, with comments added to describe where the terminals are: ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroom Force /etc/ttys

When you boot FreeBSD, the first process, /etc/ttys file and start the programs listed for each enabled port to prompt for logins. After you edit /etc/ttys, you do not want to have to reboot your system to get /etc/ttys if it receives a SIGHUP (hangup) signal. So, after you have saved your changes to /etc/ttys, send SIGHUP to kill -HUP 1 (The Debugging your connection

Even with the most meticulous attention to detail, something could still go wrong while setting up a terminal. Here is a list of symptoms and some suggested fixes. ps -axww|grep getty to get a list of running 22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1 shows that a /etc/gettytab. If no /etc/ttys. Make sure you have run /etc/ttys and run