Create branch 'RELENG_2_2'.

14 files changed, 1116 insertions, 0 deletions

diff --git a/handbook/cvsup.sgml b/handbook/cvsup.sgml
new file mode 100644
index 0000000000..ca342ea31f
--- /dev/null
+++ b/handbook/cvsup.sgml
@@ -0,0 +1,392 @@
+<!-- $Id: cvsup.sgml,v 1.2 1996-12-20 00:05:01 jkh Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+<sect><heading>CVSup<label id="cvsup"></heading>
+
+<p><em>Contributed by &a.jdp;</em>.
+
+<sect1><heading>Introduction<label id="cvsup:intro"></heading>
+
+<p>CVSup is a software package for distributing and updating source
+trees from a master CVS repository on a remote server host.  The
+FreeBSD sources are maintained in a CVS repository on a central
+development machine in California.  With CVSup, FreeBSD users can
+easily keep their own source trees up to date.
+
+<p>CVSup uses the so-called "pull" model of updating.  Under the pull
+model, each client asks the server for updates, if and when they are
+wanted.  The server waits passively for update requests from its
+clients.  Thus all updates are instigated by the client.  The server
+never sends unsolicited updates.  Users must either run the CVSup client
+manually to get an update, or they must set up a cron job to run it
+automatically on a regular basis.
+
+<p>The term "CVSup", capitalized just so, refers to the entire software
+package.  Its main components are the client "cvsup" which runs on each
+user's machine, and the server "cvsupd" which runs at each of the
+FreeBSD mirror sites.
+
+<p>As you read the FreeBSD documentation and mailing lists, you may
+see references to <ref id="sup">.  Sup was the predecessor to CVSup,
+and it served a similar purpose.  CVSup is in used in much the same
+way as sup and, in fact, uses configuration files which are
+backward-compatible with sup's.  Sup is no longer used in the FreeBSD
+project, however, because CVSup is both faster and more flexible.
+
+<sect1><heading>Installation<label id="cvsup:install"></heading>
+
+<p>The easiest way to install CVSup if you are running FreeBSD 2.2 or
+later is to use either <url
+url="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/ports/net/cvsup/"
+name="the port"> from the FreeBSD <ref id="ports" name="ports
+collection"> or the corresponding <url
+url="ftp://ftp.freebsd.org/pub/FreeBSD/packages-2.2/net/cvsup-14.0.tgz"
+name="binary package">, depending on whether you prefer to roll your
+own or not.
+
+<p>If you are running FreeBSD-2.1.6, you unfortunately cannot use the
+binary package versions due to the fact that it requires a version of
+the C library that did not yet exist in FreeBSD-2.1.6.  You can easily
+use <url url="ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/net/cvsup/"
+name="the port">, however, just as with FreeBSD 2.2.  Simply unpack
+the tar file, cd to the cvsup subdirectory and type "make install"
+
+<p>Because CVSup is written in <url
+url="http://www.research.digital.com/SRC/modula-3/html/home.html"
+name="Modula-3">, both the package and the port require that the
+Modula-3 runtime libraries be installed.  These are available as the
+<url
+url="ftp://ftp.freebsd.org/pub/FreeBSD/ports-current/lang/modula-3-lib"
+name="lang/modula-3-lib"> port and the <url
+url="ftp://ftp.freebsd.org/pub/FreeBSD/packages-current/lang/modula-3-lib-3.6.tgz"
+name="lang/modula-3-lib-3.6"> package.  If you follow the same
+directions as for cvsup, these libraries will be compiled and/or
+installed automatically when you install the CVSup port or package.
+
+<p>The Modula-3 libraries are rather large, and fetching and compiling
+them is not an instantaneous process.  For that reason, a third option
+is provided.  You can get <em>statically linked</em> FreeBSD
+executables for CVSup from:
+
+<itemize>
+  <item><url url="ftp://freefall.freebsd.org/pub/CVSup/cvsup-bin-14.0.tar.gz"
+  name="ftp://freefall.freebsd.org/pub/CVSup/cvsup-bin-14.0.tar.gz">
+  (client).
+  <item><url url="ftp://freefall.freebsd.org/pub/CVSup/cvsupd-bin-14.0.tar.gz"
+  name="ftp://freefall.freebsd.org/pub/CVSup/cvsupd-bin-14.0.tar.gz">
+  (server).
+</itemize>
+
+<p>Most users will need only the client.  These executables are entirely
+self-contained, and they will run on any version of FreeBSD from
+FreeBSD-2.1.0 to FreeBSD-current.
+
+<p>In summary, your options for installing CVSup are:
+
+<itemize>
+  <item>FreeBSD-2.2 or later:		static binary, port, or package
+  <item>FreeBSD-2.1.6:			static binary or port
+  <item>FreeBSD-2.1.5 or earlier:	static binary
+</itemize>
+
+<sect1><heading>Configuration<label id="cvsup:config"></heading>
+
+<p>CVSup's operation is controlled by a configuration file called the
+"supfile".  Beginning with FreeBSD-2.2, there are some sample supfiles
+in the directory <url url="file:/usr/share/examples/cvsup"
+name="/usr/share/examples/cvsup">.  These examples are also available
+from <url url="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/" name="ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/"> if you are on a pre-2.2 system.
+
+<p>The information in a supfile answers the following questions for cvsup:
+
+<itemize>
+ <item><ref id="cvsup:config:files" name="Which files do you want to receive?">
+ <item><ref id="cvsup:config:vers" name="Which versions of them do you want?">
+ <item><ref id="cvsup:config:where" name="Where do you want to get them from?">
+ <item><ref id="cvsup:config:dest" name="Where do you want to put them on your own machine?">
+ <item><ref id="cvsup:config:status" name="Where do you want to put your status files?">
+</itemize>
+
+<p>In the following sections, we will construct a typical supfile by
+answering each of these questions in turn.  First, we describe the
+overall structure of a supfile.
+
+<p>A supfile is a text file.  Comments begin with "#" and extend to
+the end of the line.  Lines that are blank and lines that contain only
+comments are ignored.
+
+<p>Each remaining line describes a set of files that the user wishes
+to receive.  The line begins with the name of a "collection", a
+logical grouping of files defined by the server.  The name of the
+collection tells the server which files you want.  After the
+collection name come zero or more fields, separated by white space.
+These fields answer the questions listed above.  There are two types
+of fields: flag fields and value fields.  A flag field consists of a
+keyword standing alone, e.g., "delete" or "compress".  A value field
+also begins with a keyword, but the keyword is followed without
+intervening white space by "=" and a second word.  For example,
+"release=cvs" is a value field.
+
+<p>A supfile typically specifies more than one collection to receive.
+One way to structure a supfile is to specify all of the relevant
+fields explicitly for each collection.  However, that tends to make
+the supfile lines quite long, and it is inconvenient because most
+fields are the same for all of the collections in a supfile.  CVSup
+provides a defaulting mechanism to avoid these problems.  Lines
+beginning with the special pseudo-collection name "*default" can be
+used to set flags and values which will be used as defaults for the
+subsequent collections in the supfile.  A default value can be
+overridden for an individual collection, by specifying a different
+value with the collection itself.  Defaults can also be changed or
+augmented in mid-supfile by additional "*default" lines.
+
+<p>With this background, we will now proceed to construct a supfile
+for receiving and updating the main source tree of <ref id="current"
+name="FreeBSD-current">.
+
+<itemize>
+<item>Which files do you want to receive?<label id="cvsup:config:files">
+
+<p>As with sup, the files available via CVSup are organized into named
+groups called "collections".  The collections making up the FreeBSD
+source tree are described in <ref id="sup:dists" name="the sup
+collections document">.  In this example, we wish to receive the
+entire main source tree for the FreeBSD system.  There is a single
+large collection "src-all" which will give us all of that, except the
+export-controlled cryptography support.  Let us assume for this
+example that we are in the USA or Canada.  Then we can get the
+cryptography code with two additional collections, "src-eBones" and
+"src-secure".  As a first step toward constructing our supfile, we
+simply list these collections, one per line:
+
+<verb>
+  src-all
+  src-eBones
+  src-secure
+</verb>
+
+<p><item>Which version(s) of them do you want?<label id="cvsup:config:vers">
+
+<p>With CVSup, you can receive virtually any version of the sources
+that ever existed.  That is possible because the cvsupd server works
+directly from the CVS repository, which contains all of the versions.
+You specify which one of them you want using the "tag=" and "date="
+value fields.
+
+<p>The "tag=" field names a symbolic tag in the repository.  There are
+two kinds of tags, revision tags and branch tags.  A revision tag
+refers to a specific revision.  Its meaning stays the same from day to
+day.  A branch tag, on the other hand, refers to the latest revision
+on a given line of development, at any given time.  Because a branch
+tag does not refer to a specific revision, it may mean something
+different tomorrow than it means today.
+
+<p>Here are the branch tags that users might be interested in:
+
+<descrip>
+  <tag/tag=./
+    The main line of development, also known as FreeBSD-current.
+    Note:  the "." is not punctuation; it's the name of the tag.
+  <tag/tag=RELENG_2_2/
+    The line of development leading up to FreeBSD-2.2.
+  <tag/tag=RELENG_2_1_0/
+    The line of development for FreeBSD-2.1.x, also known as
+    FreeBSD-stable.
+</descrip>
+
+<p>Here are the revision tags that users might be interested in:
+
+<descrip>
+  <tag/tag=RELENG_2_1_6_1_RELEASE/
+  FreeBSD-2.1.6.1.
+  <tag/tag=RELENG_2_1_6_RELEASE/
+  FreeBSD-2.1.6.
+  <tag/tag=RELENG_2_1_5_RELEASE/
+  FreeBSD-2.1.5.
+  <tag/tag=RELENG_2_1_0_RELEASE/
+  FreeBSD-2.1.0.
+</descrip>
+
+<p>Be very careful to type the tag name exactly as shown.  CVSup cannot
+distinguish between valid and invalid tags.  If you misspell the tag,
+CVSup will behave as though you had specified a valid tag which happens
+to refer to no files at all.  It will delete your existing sources in
+that case.
+
+<p>When you specify a branch tag, you normally receive the latest versions
+of the files on that line of development.  If you wish to receive some
+past version, you can do so by specifying a date with the "date=" value
+field.  The cvsup(1) manual page explains how to do that.
+
+<p>For our example, we wish to receive FreeBSD-current.  We add this line
+at the beginning of our supfile:
+
+<verb>
+  *default tag=.
+</verb>
+
+<p>There is an important special case that comes into play if you specify
+neither a "tag=" field nor a "date=" field.  In that case, you receive
+the actual RCS files directly from the server's CVS repository, rather
+than receiving a particular version.  Developers generally prefer this
+mode of operation.  By maintaining a copy of the repository itself on
+their systems, they gain the ability to browse the revision histories
+and examine past versions of files.  This gain is achieved at a large
+cost in terms of disk space, however.
+
+<p><item>Where do you want to get them from?<label id="cvsup:config:where">
+
+<p>This one is easy.  We use the "host=" field to tell cvsup to get
+its updates from the primary FreeBSD distribution site,
+"cvsup.FreeBSD.org":
+
+<verb>
+  *default host=cvsup.FreeBSD.org
+</verb>
+
+<p>On any particular run of cvsup, we can override this setting on the
+command line, with "-h hostname".
+
+<p><item>Where do you want to put them on your own machine?<label id="cvsup:config:dest">
+
+<p>The "prefix=" field tells cvsup where to put the files it receives.
+In this example, we'll put the source files directly into our main
+source tree, "/usr/src".  The "src" directory is already implicit in the
+collections we've chosen to receive, so this is the correct
+specification:
+
+<verb>
+  *default prefix=/usr
+</verb>
+
+<p><item>Where should cvsup maintain its status files?<label id="cvsup:config:status">
+
+<p>The cvsup client maintains certain status files in what is called
+the "base" directory.  These files help CVSup to work more
+efficiently, by keeping track of which updates you've already
+received.  We will use the standard base directory,
+"/usr/local/etc/cvsup":
+
+<verb>
+  *default base=/usr/local/etc/cvsup
+</verb>
+
+<p>This setting is used by default if it's not specified in the
+supfile, so we actually don't need the above line.
+
+<p>If your base directory doesn't already exist, now would be a good
+time to create it.  The cvsup client will refuse to run if the base
+directory doesn't exist.
+
+<p><item>Miscellaneous supfile settings:
+
+<p>There is one more line of boiler plate that normally needs to be
+present in the supfile:
+
+<verb>
+  *default release=cvs delete use-rel-suffix compress
+</verb>
+
+<p>"release=cvs" indicates that the server should get its information
+out of the main FreeBSD CVS repository.  This is virtually always the
+case, but there are other possibilities which are beyond the scope of
+this discussion.
+
+<p>"delete" gives CVSup permission to delete files.  You should always
+specify this, so that CVSup can keep your source tree fully up to
+date.  CVSup is careful to delete only those files for which it is
+responsible.  Any extra files you happen to have will be left strictly
+alone.
+
+<p>"use-rel-suffix" is ... arcane.  If you really want to know about
+it, see the cvsup(1) manual page.  Otherwise, just specify it and
+don't worry about it.
+
+<p>"compress" enables the use of gzip-style compression on the
+communication channel.  If your network link is T1 speed or faster,
+you probably shouldn't use compression.  Otherwise, it helps
+substantially.
+
+<p><item>Putting it all together:
+
+<p>Here is the entire supfile for our example:
+
+<verb>
+  *default tag=.
+  *default host=cvsup.FreeBSD.org
+  *default prefix=/usr
+  *default base=/usr/local/etc/cvsup
+  *default release=cvs delete use-rel-suffix compress
+  src-all
+  src-eBones
+  src-secure
+</verb>
+</itemize>
+
+<sect1><heading>Running CVSup</heading>
+
+<p>You are now ready to try an update.  The command line for doing this is
+quite simple:
+
+<verb>
+  cvsup supfile
+</verb>
+
+<p>where "supfile" is of course the name of the supfile you've just created.
+Assuming you are running under X11, cvsup will display a GUI window with
+some buttons to do the usual things.  Press the "go" button, and watch
+it run.
+
+<p>Since you are updating your actual "/usr/src" tree in this example, you
+will need to run the program as root so that cvsup has the permissions
+it needs to update your files.  Having just created your configuration
+file, and having never used this program before, that might
+understandably make you nervous.  There is an easy way to do a trial run
+without touching your precious files.  Just create an empty directory
+somewhere convenient, and name it as an extra argument on the command
+line:
+
+<verb>
+  mkdir /var/tmp/dest
+  cvsup supfile /var/tmp/dest
+</verb>
+
+<p>The directory you specify will be used as the destination directory
+for all file updates.  CVSup will examine your usual files in
+"/usr/src", but it will not modify or delete any of them.  Any file
+updates will instead land in "/var/tmp/dest/usr/src".  CVSup will also
+leave its base directory status files untouched when run this way.
+The new versions of those files will be written into the specified
+directory.  As long as you have read access to "/usr/src", you don't
+even need to be root to perform this kind of trial run.
+
+<p>If you are not running X11 or if you just don't like GUIs, you
+should add a couple of options to the command line when you run cvsup:
+
+<verb>
+  cvsup -g -L 2 supfile
+</verb>
+
+<p>The "-g" tells cvsup not to use its GUI.  This is automatic if you are
+not running X11, but otherwise you have to specify it.
+
+<p>The "-L 2" tells cvsup to print out the details of all the file updates
+it is doing.  There are three levels of verbosity, from "-L 0" to "-L 2".
+The default is 0, which means total silence except for error messages.
+
+<p>There are plenty of other options available.  For a brief list of them,
+type "cvsup -H".  For more detailed descriptions, see the manual page.
+
+<p>Once you are satisfied with the way updates are working, you can arrange
+for regular runs of cvsup using cron(8).  Obviously, you shouldn't let
+cvsup use its GUI when running it from cron.
+
+<sect1><heading>Announcements, Questions, and Bug Reports</heading>
+
+<p>Most FreeBSD-related discussion of CVSup takes place on the
+&a.hackers;.  New versions of the software are announced there, as
+well as on the &a.announce;.
+
+<p>Questions and bug reports should be addressed to the author of the
+program at <url url="mailto:cvsup-bugs@polstra.com"
+name="cvsup-bugs@polstra.com">.
diff --git a/handbook/dialout.sgml b/handbook/dialout.sgml
new file mode 100644
index 0000000000..0964e8f5a7
--- /dev/null
+++ b/handbook/dialout.sgml
@@ -0,0 +1,249 @@
+<!-- This is an SGML document in the linuxdoc DTD of the Tutorial for
+     Configuring a FreeBSD for Dialout Services.
+     $Id: dialout.sgml,v 1.2 1996-11-30 23:51:45 mpp Exp $
+
+     The FreeBSD Documentation Project
+
+<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
+
+<linuxdoc>
+  <article>
+      <title>Dialout
+      <author>FAQ
+      <date>24 Nov 1996, (c) 1996
+
+      <abstract> This section contains some basic information on being able to dialout from your FreeBSD box with a modem.  This information is really a stepping stone into PPP.  
+      </abstract>
+	
+    <toc>
+-->
+
+<sect><heading>Dialout service<label id="dialout"></heading>
+
+<p><em>Information integrated from FAQ.</em>
+
+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.  
+<p>This is useful to log onto a BBS.
+<p>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. 
+<sect1>
+	<heading>Why cannot I run <tt/tip/ or <tt/cu/?</heading>
+        <p>
+          On your system, the programs <tt/tip/ and <tt/cu/ are probably
+          executable only by <tt/uucp/ and group <tt/dialer/.  You can use
+          the group <tt/dialer/ to control who has access to your modem or
+          remote systems.  Just add yourself to group dialer.
+
+          Alternatively, you can let everyone on your system run <tt/tip/
+          and <tt/cu/ by typing:
+          <verb>
+            chmod 4511 /usr/bin/tip
+          </verb>
+          You do not have to run this command for <tt/cu/, since <tt/cu/ is
+          just a hard link to <tt/tip/.
+
+      <sect1>
+	<heading>My stock Hayes modem is not supported&mdash;what can I do?</heading>
+        <p>
+          Actually, the man page for <tt/tip/ is out of date.  There is a
+          generic Hayes dialer already built in.  Just use
+          ``<tt/at=hayes/'' in your <tt>/etc/remote</tt> file.
+
+          The Hayes driver is not smart enough to recognize some of the
+          advanced features of newer modems&mdash;messages like <tt/BUSY/,
+          <tt/NO DIALTONE/, or <tt/CONNECT 115200/ will just confuse it.
+          You should turn those messages off when you use <tt/tip/ (using
+          <tt/ATX0&amp;W/).
+
+          Also, the dial timeout for <tt/tip/ is 60 seconds.  Your modem
+          should use something less, or else tip will think there is a
+          communication problem.  Try <tt/ATS7=45&amp;W/.
+
+          Actually, as shipped <tt/tip/ does not yet support it fully. The
+          solution is to edit the file <tt/tipconf.h/ in the directory
+          <tt>/usr/src/usr.bin/tip/tip</tt> Obviously you need the source
+          distribution to do this.
+
+          Edit the line ``<tt/#define HAYES 0/'' to ``<tt/#define HAYES
+          1/''. Then ``<tt/make/'' and ``<tt/make install/''. Everything
+          works nicely after that.
+
+      <sect1>
+        <heading>How am I expected to enter these AT commands?<label id="direct-at"></heading>
+        <p>
+          Make what is called a ``<tt/direct/'' entry in your
+          <tt>/etc/remote</tt> file.  For example, if your modem is hooked
+          up to the first serial port, <tt>/dev/cuaa0</tt>, then put in the
+          following line:
+          <verb>
+            cuaa0:dv=/dev/cuaa0:br#19200:pa=none
+          </verb>
+          Use the highest bps rate your modem supports in the br
+          capability.  Then, type ``<tt/tip cuaa0/'' and you will be
+          connected to your modem.
+
+          If there is no <tt>/dev/cuaa0</tt> on your system, do this:
+          <verb>
+            cd /dev
+            MAKEDEV cuaa0
+          </verb>
+        <p>
+          Or use cu as root with the following command:
+          <verb>
+            cu -l``line'' -s``speed''
+          </verb>
+          with line being the serial port (e.g.<tt>/dev/cuaa0</tt>)
+          and speed being the speed (e.g.<tt>57600</tt>).
+          When you are done entering the AT commands hit <tt>~.</tt> to exit.
+
+      <sect1>
+        <heading>The <tt/@/ sign for the pn capability does not work!</heading>
+        <p>
+          The <tt/@/ sign in the phone number capability tells tip to look in
+          <tt>/etc/phones</tt> for a phone number.  But the <tt/@/ sign is
+          also a special character in capability files like
+          <tt>/etc/remote</tt>.  Escape it with a backslash:
+          <verb>
+            pn=\@
+          </verb>
+
+      <sect1>
+	<heading>How can I dial a phone number on the command line?</heading>
+        <p>
+          Put what is called a ``<tt/generic/'' entry in your
+          <tt>/etc/remote</tt> file.  For example:
+          <verb>
+            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:
+          </verb>
+
+          Then you can things like ``<tt/tip -115200 5551234/''.  If you
+          prefer <tt/cu/ over <tt/tip/, use a generic cu entry:
+          <verb>
+            cu115200|Use cu to dial any number at 115200bps:\
+            :dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:
+          </verb>
+          and type ``<tt/cu 5551234 -s 115200/''.
+
+      <sect1>
+        <heading>Do I have to type in the bps rate every time I do that?</heading>
+        <p>
+          Put in an entry for <tt/tip1200/ or <tt/cu1200/, but go ahead and
+          use whatever bps rate is appropriate with the br
+          capability. <tt/tip/ thinks a good default is 1200 bps which is
+          why it looks for a ``<tt/tip1200/'' entry.  You do not have to use
+          1200 bps, though.
+
+      <sect1>
+        <heading>I access a number of hosts through a terminal server.</heading>
+        <p>
+          Rather than waiting until you are connected and typing 
+          ``<tt/CONNECT &lt;host&gt;/'' each time, use tip's <tt/cm/
+          capability. For example, these entries in
+          <tt>/etc/remote</tt>:
+          <verb>
+            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:
+          </verb>
+
+          will let you type ``<tt/tip pain/'' or ``<tt/tip muffin/'' to
+          connect to the hosts pain or muffin; and ``<tt/tip deep13/'' to
+          get to the terminal server.
+
+      <sect1>
+        <heading>Can tip try more than one line for each site?</heading>
+        <p>
+          This is often a problem where a university has several modem lines
+          and several thousand students trying to use them...
+        <p>
+          Make an entry for your university in <tt>/etc/remote</tt>
+          and use <tt>\@</tt> for the <tt/pn/ capability:
+          <verb>
+            big-university:\
+            :pn=\@:tc=dialout
+            dialout:\
+            :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none:
+          </verb>
+
+          Then, list the phone numbers for the university in
+          <tt>/etc/phones</tt>:
+          <verb>
+            big-university 5551111
+            big-university 5551112
+            big-university 5551113
+            big-university 5551114
+          </verb>
+
+          <tt/tip/ will try each one in the listed order, then give up.  If
+          you want to keep retrying, run <tt/tip/ in a while loop.
+
+      <sect1>
+	<heading>Why do I have to hit CTRL+P twice to send CTRL+P once?</heading>
+        <p>
+          CTRL+P is the default ``force'' character, used to tell <tt/tip/
+          that the next character is literal data.  You can set the force
+          character to any other character with the <tt/~s/ escape, which
+          means ``set a variable.''
+
+          Type ``<tt/~sforce=&lt;single-char&gt;/'' followed by a newline.
+          <tt/&lt;single-char&gt;/ is any single character.  If you leave
+          out <tt/&lt;single-char&gt;/, then the force character is the nul
+          character, which you can get by typing CTRL+2 or CTRL+SPACE.  A
+          pretty good value for <tt/&lt;single-char&gt;/ is SHIFT+CTRL+6,
+          which I have seen only used on some terminal servers.
+
+          You can have the force character be whatever you want by
+          specifying the following in your <tt>&dollar;HOME/.tiprc</tt>
+          file:
+          <verb>
+            force=<single-char>
+          </verb>
+
+      <sect1>
+        <heading>Suddenly everything I type is in UPPER CASE??</heading>
+        <p>
+          You must have pressed CTRL+A, <tt/tip/'s ``raise character,''
+          specially designed for people with broken caps-lock keys. Use
+          <tt/~s/ as above and set the variable ``raisechar'' to something
+          reasonable.  In fact, you can set it to the same as the force
+          character, if you never expect to use either of these features.
+
+          Here is a sample .tiprc file perfect for Emacs users who need to
+          type CTRL+2 and CTRL+A a lot:
+          <verb>
+            force=^^
+            raisechar=^^
+          </verb>
+          The ^^ is SHIFT+CTRL+6.
+
+      <sect1>
+	<heading>How can I do file transfers with <tt/tip/?</heading>
+        <p>
+          If you are talking to another UNIX system, you can send and
+          receive files with <tt/~p/ (put) and <tt/~t/ (take).  These
+          commands run ``<tt/cat/'' and ``<tt/echo/'' on the remote system
+          to accept and send files.  The syntax is:
+          <verb>
+            ~p <local-file> [<remote-file>]
+            ~t <remote-file> [<local-file>]
+          </verb>
+
+          There is no error checking, so you probably should use another
+          protocol, like zmodem.
+
+      <sect1>
+	<heading>How can I run zmodem with <tt/tip/?</heading>
+        <p>
+          To receive files, start the sending program on the remote end.
+          Then, type ``<tt/~C rz/'' to begin receiving them locally.
+
+          To send files, start the receiving program on the remote end.
+          Then, type ``<tt/~C sz &lt;files&gt;/'' to send them to the
+          remote system.
+
+    </sect>
diff --git a/handbook/mail.sgml b/handbook/mail.sgml
new file mode 100644
index 0000000000..b34aac5969
--- /dev/null
+++ b/handbook/mail.sgml
@@ -0,0 +1,359 @@
+<!--  $Id: mail.sgml,v 1.2 1996-11-30 23:35:43 mpp Exp $
+      The FreeBSD Documentation Project
+
+<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
+
+<linuxdoc>
+  <article>
+      <title> Mail
+      <author>  &a.wlloyd;
+      <date> 24 Nov 1996, (c) 1996
+
+      <abstract> This section contains basic information on setting up E-Mail for you FreeBSD box.
+      </abstract>
+	
+    <toc>
+-->
+
+<chapt><heading>Electronic Mail<label id="mail"></heading>
+<sect><heading>Basic Information</heading>
+
+<p><em>Contributed by &a.wlloyd;.</em>
+
+<p>   E-mail, as simple as the concept sounds, can be extremely complicated.  If you plan on doing anything beyond setting up a simple one machine E-mail system, you should buy and refer to a book on Sendmail.
+
+   <sect1><heading>Introduction</heading>
+        <p>
+	These are the major programs or components of an e-mail exchange.
+	<sect2><heading>User program</heading>
+	<p> This is a program like <tt /elm, pine, mail/ , or something more sophisticated like a WWW browser.  This program will simply pass off all e-mail transactions to the local mailhost, either by calling <tt>sendmail</tt> or delivering it over TCP to your mailhost.
+	<sect2><heading>Transport Agent - Sendmail</heading>
+	<p> Usually this program is <tt /sendmail or smail/ running in the background.  Turn it off or change the command line options in <tt> /etc/sysconfig </tt>.  It is best to leave it on unless you have a specific reason to want it off.  Ie: Firewall 
+<p>
+You should be aware that <tt>sendmail</tt> is a potential weak link in a secure site.  Some versions of <tt>sendmail</tt> have known security problems.
+ 
+	<p> <tt> sendmail </tt> will look up in the DNS to determine the actual host that will receive mail for the destination.
+	<p> Sendmail will take the message from the local queue and deliver it across the Internet to another sendmail on the receivers computer. 
+	<p> Sendmail will also be able to do the reverse.  It will accept messages and save them on your local machine. 
+	<sect2><heading>POP Servers</heading>
+	<p> 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.
+<itemize>
+<item>Get pop software from the ports or packages collection.
+<item>Modify <tt>/etc/inetd.conf</> to load POP server.
+</itemize>
+
+The pop program you get will have instructions with it.  Read them.
+   
+<sect1><heading>Configuration</heading>
+<p>
+As your FreeBSD system comes "out of the box" you should be able to send e-mail to external hosts.  The problem is no mail will be able to get back to your host.  This is not a problem if you are willing to make sure you hand edit the automatic <tt>reply to address</tt> every time you send a message.
+<p>
+It is relatively simple to get another host to receive your e-mail under the same username.  You can then pick it up over POP or telnet.  
+
+A user account with the SAME USERNAME should exist on both machines.  Please use <tt/adduser/ to do this if needed.  If you set the <tt/shell/ to <tt>/nonexistent</tt> the user will not be allowed to login.
+
+The mailhost that you will be using must be designated the Mail exchange for your host.  This must be arranged in DNS (ie BIND, named).  Please refer to a Networking book for more information.
+
+You basically need to add these lines in your DNS server.
+<verb> 
+myhost.smalliap.com	A	xxx.xxx.xxx.xxx		; Your ip 
+			MX  10	smtp.smalliap.com	; your mailhost
+</verb>
+
+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 your host to the MX (Mail eXchange) host.  It does not matter what machine the A record points to, the mail will be sent to the MX host.
+<p>
+This feature is used to implement Virtual Hosting. 
+<p>Example
+<p>
+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:
+
+<verb> 
+myhost.smalliap.com	MX  10	smtp.smalliap.com	; your mailhost
+</verb>
+The A record is not needed if you only want e-mail for the domain.
+
+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.
+
+<p>Add myhost.smalliap.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.
+	  
+<p>To actually receive mail on your host, you need to have the MX entry above changed to point to your host.  You also move the Cw line above in your <tt>sendmail.cf</tt>.
+
+<p>
+This is a Bad Idea if your connection to the Internet is not permanent.  Mail will bounce.
+
+<p>
+If you plan on doing anything serious with <tt/sendmail/ you should install the sendmail source.  The source has plenty of documentation with it.  You will find information on getting <tt/sendmail/ source from <ref name="UUCP and sendmail" id="sendmailuucp">.
+</sect>
+
+<sect><heading>FAQ<label id="mailfaq"></heading>     
+ <sect1>
+        <heading>Why do I have to use the FQDN for hosts on my site?</heading>
+        <p>
+	  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''.     
+	<p>
+	  Traditionally, this was allowed by BSD BIND resolvers. However
+	  the current version of <em>BIND</em> 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 <tt>mumble</tt> must either be found
+	  as <tt>mumble.foo.bar.edu</tt>, or it will be searched for
+	  in the root domain.
+	<p>
+	  This is different from the previous behavior, where the
+	  search continued across <tt>mumble.bar.edu</tt>, and
+	  <tt>mumble.edu</tt>.  Have a look at RFC 1535 for why this
+	  was considered bad practice, or even a security hole.
+	<p>
+	  As a good workaround, you can place the line
+<p><tt>
+search foo.bar.edu bar.edu
+</tt><p>
+	  instead of the previous
+
+<p><tt>
+domain foo.bar.edu
+</tt><p>
+	  into your <tt>/etc/resolv.conf</tt>.  However, make sure
+	  that the search order does not go beyond the ``boundary
+	  between local and public administration'', as RFC 1535
+	  calls it.
+
+      </sect1>
+
+      <sect1><heading>Sendmail says ``mail loops back to myself''</heading>
+	<p>
+	  This is answered in the sendmail FAQ as follows:-
+	  <verb>
+          * I'm getting "Local configuration error" messages, such as:
+
+          553 relay.domain.net config error: mail loops back to myself
+          554 <user@domain.net>... 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 doesn't 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.
+	  </verb>
+	<p>
+	  The sendmail FAQ is in <tt>/usr/src/usr.sbin/sendmail</tt>
+	  and is recommended reading if you want to do any
+	  ``tweaking'' of your mail setup.
+
+      <sect1>
+        <heading>How do I use sendmail for mail delivery with UUCP?<label id="sendmailuucp"></heading>
+
+        <p>
+          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.
+
+        <p>
+          Tweaking <tt>/etc/sendmail.cf</tt> manually is considered
+          something for purists.  Sendmail version 8 comes with a
+          new approach of generating config files via some <tt>m4</tt>
+          preprocessing, where the actual hand-crafted configuration
+          is on a higher abstraction level.  You should use the
+          configuration files under
+
+<verb>
+     /usr/src/usr.sbin/sendmail/cf
+</verb>
+
+          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:
+
+<verb>
+     cd /usr/src
+     tar -xvzf /cdrom/dists/src/ssmailcf.aa
+</verb>
+
+          Do not panic, this is only a few hundred kilobytes in size.
+          The file <tt>README</tt> in the <tt>cf</tt> directory can
+          serve as a basic introduction to m4 configuration.
+
+        <p>
+          For UUCP delivery, you are best advised to use the
+          <em>mailertable</em> feature.  This constitutes a database
+          that sendmail can use to base its routing decision upon.
+
+        <p>
+	  First, you have to create your <tt>.mc</tt> file.  The
+          directory <tt>/usr/src/usr.sbin/sendmail/cf/cf</tt> is the
+          home of these files.  Look around, there are already a few
+          examples.  Assuming you have named your file <tt>foo.mc</tt>,
+          all you need to do in order to convert it into a valid
+          <tt>sendmail.cf</tt> is:
+
+<verb>
+     cd /usr/src/usr.sbin/sendmail/cf/cf
+     make foo.cf
+     cp foo.cf /etc/sendmail.cf
+</verb>
+
+          A typical <tt>.mc</tt> file might look like:
+
+<verb>
+     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
+</verb>
+
+          The <em>nodns</em> and <em>nocanonify</em> features will
+          prevent any usage of the DNS during mail delivery.  The
+          <em>UUCP_RELAY</em> 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.
+
+        <p>
+          Once you have this, you need this file called
+          <tt>/etc/mailertable</tt>.  A typical example of this
+          gender again:
+
+<verb>
+     #
+     # 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
+</verb>
+
+          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 <tt>uucp-dom:</tt> keyword must
+          be valid UUCP neighbors, as you can verify using the
+          command <tt>uuname</tt>.
+
+        <p>
+          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.
+
+        <p>
+          Final hint: if you are uncertain whether some particular
+          mail routing would work, remember the <tt>-bt</tt> option to
+          sendmail.  It starts sendmail in <em>address test mode</em>;
+          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.
+
+<verb>
+     j@uriah 191% sendmail -bt
+     ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
+     Enter <ruleset> <address>
+     > 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% 
+</verb>
+ 
+<sect1><heading>How can I do e-mail with a dialup PPP host</heading>
+<p>
+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:
+<verb>
+bigco.com.			MX	10	bigco.com.
+				MX	20	smalliap.com.
+</verb>
+
+Only one host should be specified as the final recipient ( add ``Cw bigco.com'' in <tt>/etc/sendmail.cf</tt> 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 (<tt>sendmail_flags = "-bd -q15m"</tt> in <tt>/etc/sysconfig</tt> ) 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.
+<verb>
+#!/bin/sh
+# Put me in /usr/local/bin/pppbigco
+( sleep 60 ; /usr/sbin/sendmail -q ) &  
+/usr/sbin/ppp -direct pppbigco
+</verb>
+If you are going to create a separate login script for a user you could use <tt>sendmail -qRbigco.com</tt> 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.
+<verb>
+> 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'.
+</verb>
+
+      </sect1>
diff --git a/handbook/serial.sgml b/handbook/serial.sgml
new file mode 100644
index 0000000000..ee7fe60fab
--- /dev/null
+++ b/handbook/serial.sgml
@@ -0,0 +1,64 @@
+<!-- This is an SGML document in the linuxdoc DTD of the Tutorial for
+     Configuring a FreeBSD for Dialup Services by Guy Helmer.
+     $Id: serial.sgml,v 1.1 1996-11-28 18:09:30 jfieber Exp $
+
+     The FreeBSD Documentation Project
+
+<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
+
+<linuxdoc>
+  <article>
+      <title> Serial Basics
+      <author>  FAQ
+      <date> 24 Nov 1996, (c) 1996
+
+      <abstract> This section outlines some of the basics to get your serial ports working.  This is really just a stepping stone into the section on PPP or Dialout if you are interested in modems.
+      </abstract>
+	
+    <toc>
+-->
+
+<sect><heading>Serial Basics<label id="serial"></heading>
+
+<p><em>Assembled from FAQ.</em>
+
+This section should give you some general information about serial ports.  If you do not find what you want here, check into the Terminal and Dialup sections of the handbook.
+
+
+        <p>
+          The <tt/ttydX/ (or <tt/cuaaX/) device is the regular device
+          you will want to open for your applications.  When a process opens
+          the device, it will have a default set of terminal I/O settings.
+          You can see these settings with the command
+          <verb>
+            stty -a -f /dev/ttyd1
+          </verb>
+
+          When you change the settings to this device, the settings are in
+          effect until the device is closed.  When it is reopened, it goes
+          back to the default set.  To make changes to the default set, you
+          can open and adjust the settings of the ``initial state'' device.
+          For example, to turn on <tt/CLOCAL/ mode, 8 bits, and
+          <tt>XON/XOFF</tt> flow control by default for ttyd5, do:
+          <verb>
+            stty -f /dev/ttyid5 clocal cs8 ixon ixoff
+          </verb>
+
+          A good place to do this is in <tt>/etc/rc.serial</tt>. Now, an
+          application will have these settings by default when it opens
+          <tt/ttyd5/.  It can still change these settings to its liking,
+          though.
+
+          You can also prevent certain settings from being changed by an
+          application by making adjustments to the ``lock state'' device.
+          For example, to lock the speed of <tt/ttyd5/ to 57600 bps, do
+          <verb>
+            stty -f /dev/ttyld5 57600
+          </verb>
+
+          Now, an application that opens <tt/ttyd5/ and tries to change the
+          speed of the port will be stuck with 57600 bps.
+
+          Naturally, you should make the initial state and lock state
+          devices writable only by <tt/root/. The <tt/MAKEDEV/ script does
+          <bf/NOT/ do this when it creates the device entries.
diff --git a/ja/Makefile b/ja/Makefile
new file mode 100644
index 0000000000..c7f9709b0d
--- /dev/null
+++ b/ja/Makefile
@@ -0,0 +1,6 @@
+#       From: @(#)Makefile      8.1 (Berkeley) 6/5/93
+#       $Id: Makefile,v 1.1 1996-12-18 07:14:37 asami Exp $
+
+SUBDIR= handbook
+
+.include <bsd.subdir.mk>
diff --git a/ja/handbook/cvsup.sgml b/ja/handbook/cvsup.sgml
new file mode 100644
index 0000000000..1b1587e02a
--- /dev/null
+++ b/ja/handbook/cvsup.sgml
@@ -0,0 +1,5 @@
+<!-- $Id: cvsup.sgml,v 1.1 1996-12-20 07:28:18 max Exp $ -->
+<!-- The FreeBSD Japanese Documentation Project -->
+<!-- Original revision: 0 -->
+
+<sect><heading>* CVSup<label id="cvsup"></heading>
diff --git a/ja/handbook/dialout.sgml b/ja/handbook/dialout.sgml
new file mode 100644
index 0000000000..9248801288
--- /dev/null
+++ b/ja/handbook/dialout.sgml
@@ -0,0 +1,5 @@
+<!-- $Id: dialout.sgml,v 1.1 1996-12-02 07:23:46 max Exp $ -->
+<!-- The FreeBSD Japanese Documentation Project -->
+<!-- Original revision: 0 -->
+
+<sect><heading>* Dialout service<label id="dialout"></heading>
diff --git a/ja/handbook/mail.sgml b/ja/handbook/mail.sgml
new file mode 100644
index 0000000000..b286968957
--- /dev/null
+++ b/ja/handbook/mail.sgml
@@ -0,0 +1,5 @@
+<!-- $Id: mail.sgml,v 1.1 1996-12-02 07:23:47 max Exp $ -->
+<!-- The FreeBSD Japanese Documentation Project -->
+<!-- Original revision: 0 -->
+
+<chapt><heading>*Electronic Mail<label id="mail"></heading>
diff --git a/ja/handbook/serial.sgml b/ja/handbook/serial.sgml
new file mode 100644
index 0000000000..3c0c9ff0c1
--- /dev/null
+++ b/ja/handbook/serial.sgml
@@ -0,0 +1,5 @@
+<!-- $Id: serial.sgml,v 1.1 1996-12-02 07:23:45 max Exp $ -->
+<!-- The FreeBSD Japanese Documentation Project -->
+<!-- Original revision: 0 -->
+
+<sect><heading>* Serial Basics<label id="serial"></heading>
diff --git a/ja_JP.EUC/Makefile b/ja_JP.EUC/Makefile
new file mode 100644
index 0000000000..c7f9709b0d
--- /dev/null
+++ b/ja_JP.EUC/Makefile
@@ -0,0 +1,6 @@
+#       From: @(#)Makefile      8.1 (Berkeley) 6/5/93
+#       $Id: Makefile,v 1.1 1996-12-18 07:14:37 asami Exp $
+
+SUBDIR= handbook
+
+.include <bsd.subdir.mk>
diff --git a/ja_JP.EUC/handbook/cvsup.sgml b/ja_JP.EUC/handbook/cvsup.sgml
new file mode 100644
index 0000000000..1b1587e02a
--- /dev/null
+++ b/ja_JP.EUC/handbook/cvsup.sgml
@@ -0,0 +1,5 @@
+<!-- $Id: cvsup.sgml,v 1.1 1996-12-20 07:28:18 max Exp $ -->
+<!-- The FreeBSD Japanese Documentation Project -->
+<!-- Original revision: 0 -->
+
+<sect><heading>* CVSup<label id="cvsup"></heading>
diff --git a/ja_JP.EUC/handbook/dialout.sgml b/ja_JP.EUC/handbook/dialout.sgml
new file mode 100644
index 0000000000..9248801288
--- /dev/null
+++ b/ja_JP.EUC/handbook/dialout.sgml
@@ -0,0 +1,5 @@
+<!-- $Id: dialout.sgml,v 1.1 1996-12-02 07:23:46 max Exp $ -->
+<!-- The FreeBSD Japanese Documentation Project -->
+<!-- Original revision: 0 -->
+
+<sect><heading>* Dialout service<label id="dialout"></heading>
diff --git a/ja_JP.EUC/handbook/mail.sgml b/ja_JP.EUC/handbook/mail.sgml
new file mode 100644
index 0000000000..b286968957
--- /dev/null
+++ b/ja_JP.EUC/handbook/mail.sgml
@@ -0,0 +1,5 @@
+<!-- $Id: mail.sgml,v 1.1 1996-12-02 07:23:47 max Exp $ -->
+<!-- The FreeBSD Japanese Documentation Project -->
+<!-- Original revision: 0 -->
+
+<chapt><heading>*Electronic Mail<label id="mail"></heading>
diff --git a/ja_JP.EUC/handbook/serial.sgml b/ja_JP.EUC/handbook/serial.sgml
new file mode 100644
index 0000000000..3c0c9ff0c1
--- /dev/null
+++ b/ja_JP.EUC/handbook/serial.sgml
@@ -0,0 +1,5 @@
+<!-- $Id: serial.sgml,v 1.1 1996-12-02 07:23:45 max Exp $ -->
+<!-- The FreeBSD Japanese Documentation Project -->
+<!-- Original revision: 0 -->
+
+<sect><heading>* Serial Basics<label id="serial"></heading>