os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Create branch 'RELENG_2_1_0'.

Browse source
This commit is contained in:
Doc Manager 1996-06-11 18:05:48 +00:00
parent ab87b86033
commit 31444442c3
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/branches/RELENG_2_1_0/; revision=367
10 changed files with 2675 additions and 0 deletions

57
handbook/cyclades.sgml Normal file
View file

@ -0,0 +1,57 @@
<!-- $Id: cyclades.sgml,v 1.1 1996-06-07 15:56:35 alex Exp $ -->
<!-- The FreeBSD Documentation Project -->
<!--
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
<!ENTITY % authors SYSTEM "authors.sgml">
%authors;
]>
-->
<sect2><heading>Configuring the <tt>cy</tt> driver<label id="cy"></heading>
<p><em>Contributed by &a.alex;.<newline>6 June 1996.</em>
The Cyclades multiport cards are based on the <tt>cy</tt>
driver instead of the usual <tt>sio</tt> driver used by
other multiport cards. Configuration is a simple matter
of:
<enum>
<item>Add the <tt>cy</tt> device to your
<ref id="kernelconfig:config" name="kernel configuration">
(note that your irq and iomem settings may differ).
<tscreen><verb>
device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr
</verb></tscreen>
<item><ref id="kernelconfig:building" name="Rebuild and install">
the new kernel.
<item>Make the <ref id="kernelconfig:nodes" name="device nodes">
by typing (the following example assumes an 8-port board):
<tscreen><verb>
# cd /dev
# for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done
</verb></tscreen>
<item>If appropriate, add <ref id="dialup" name="dialup">
entries to <ref id="dialup:ttys" name="/etc/ttys"> by
duplicating serial device (<tt>ttyd</tt>) entries and
using <tt>ttyc</tt> in place of <tt>ttyd</tt>. For
example:
<tscreen><verb>
ttyc0 "/usr/libexec/getty std.38400" unknown on insecure
ttyc1 "/usr/libexec/getty std.38400" unknown on insecure
ttyc2 "/usr/libexec/getty std.38400" unknown on insecure
[...]
ttyc7 "/usr/libexec/getty std.38400" unknown on insecure
</verb></tscreen>
<item>Reboot with the new kernel.
</enum>

9
handbook/goals.sgml Normal file
View file

@ -0,0 +1,9 @@
<!-- $Id: goals.sgml,v 1.1 1995-12-07 13:22:13 jkh Exp $ -->
<!-- The FreeBSD Documentation Project -->
<sect><heading>FreeBSD Project goals<label id="goals"></heading>
<p><em>Contributed by &a.jkh;</em>.
<p><em>Note: This section is under construction.</em>

700
handbook/linuxemu.sgml Normal file
View file

@ -0,0 +1,700 @@
<!-- $Id: linuxemu.sgml,v 1.8 1996-05-24 19:33:32 jfieber Exp $ -->
<!-- The FreeBSD Documentation Project -->
<chapt><heading>Linux Emulation<label id="linuxemu"></heading>
<p><em>Contributed by &a.brian and &a.rich;</em>
<sect><heading>How to install the Linux emulator</heading>
<p>Linux emulation in FreeBSD has reached a point where it is possible
to run a large fraction of Linux binaries in both a.out and ELF
format. The linux emulation in the -STABLE branch is capable of
running Linux DOOM and Mathematica; the version present in
FreeBSD-CURRENT is vastly more capable and runs all these as well as
Quake, Abuse, IDL, netrek for Linux and a whole host of other
programs.
There are some Linux-specific operating system features that are not
supported on FreeBSD. Linux binaries will not work on FreeBSD if they
use the Linux /proc filesystem (which is different from the optional
FreeBSD /proc filesystem) or i386-specific calls, such as enabling
virtual 8086 mode.
<p>To tell whether your kernel is configured for Linux
compatibility simply run any Linux binary. If it
prints the error message
<tscreen>
<verb>
linux-executable: Exec format error. Wrong Architecture.
</verb>
</tscreen>
then you do not have linux compatibility support and
you need to configure and install a new kernel.
Depending on which version of FreeBSD you are running, how you get
Linux-emulation up will vary slightly:
<sect1><heading>Installing Linux Emulation in 2.1-STABLE</heading>
<p>The GENERIC kernel in 2.1-stable is not configured for linux
compatibility so you you must reconfigure your kernel for it. There
are two ways to do this: 1. linking the emulator statically in the
kernel itself and 2. configuring your kernel to dynamically load the
linux loadable kernel module (LKM).
<p>To enable the emulator, add the following to your configuration file
(c.f. /sys/i386/conf/LINT):
<tscreen>
<verb>
options "COMPAT_LINUX"
</verb>
</tscreen>
If you want to run doom or other applications
that need shared memory
also add the following.
<tscreen>
<verb>
options SYSVSHM
</verb>
</tscreen>
The linux system calls require 4.3 BSD system call compatibility. So
make sure you have the following.
<tscreen>
<verb>
options "COMPAT_43"
</verb>
</tscreen>
If you prefer to statically link the emulator in the kernel rather than
use the loadable kernel module (LKM), then add
<tscreen>
<verb>
options LINUX
</verb>
</tscreen>
Then run config and install the new kernel as described in the
<ref id="kernelconfig" name="kernel configuration"> section.
If you decide to use the LKM you must also install the loadable
module. A mismatch of versions between the kernel and loadable
module can cause the kernel to crash, so the safest thing to do is to
reinstall the LKM when you install the kernel.
<tscreen>
<verb>
% cd /usr/src/lkm/linux
% make all install
</verb>
</tscreen>
Once you have installed the kernel and the LKM, you can invoke
`linux' as root to load the LKM.
<tscreen>
<verb>
% linux
Linux emulator installed
Module loaded as ID 0
%
</verb>
</tscreen>
To see whether the LKM is loaded, run `modstat'.
<tscreen>
<verb>
% modstat
Type Id Off Loadaddr Size Info Rev Module Name
EXEC 0 3 f0baf000 0018 f0bb4000 1 linux_emulator
%
</verb>
</tscreen>
You can cause the LKM to be loaded when the system boots in either of
two ways. On FreeBSD-CURRENT and FreeBSD-STABLE enable it in
/etc/sysconfig
<tscreen>
<verb>
linux=YES
</verb>
</tscreen>
by changing it from NO to YES. FreeBSD 2.1 RELEASE and earlier do not
have such a line and on those you will need to edit /etc/rc.local to
add the following line.
<tscreen>
<verb>
linux
</verb>
</tscreen>
<sect1><heading>Installing Linux Emulation in 2.2-CURRENT</heading>
<p>In -current it is no longer necessary to specify options "LINUX"
or options "COMPAT_LINUX". Linux emulation is done with an LKM
(``Loadable Kernel Module'') so it can be installed on the fly without
having to reboot. You will need the following things in your startup files,
however:
<enum>
<item> In /etc/sysconfig, you need the following line:
<tscreen>
<verb>
linux=YES
</verb>
</tscreen>
<item> This, in turn, triggers the following action in /etc/rc.i386:
<tscreen>
<verb>
# Start the Linux binary emulation if requested.
if [ "X${linux}" = X"YES" ]; then
echo -n ' '; linux
# XXX BOGUS - Linux script shouldn't make any output on success
fi
</verb>
</tscreen>
</enum>
<p>If you want to verify it is running, modstat will do that:
<tscreen>
<verb>
% modstat
Type Id Off Loadaddr Size Info Rev Module Name
EXEC 0 4 f09e6000 001c f09ec010 1 linux_mod
%
</verb>
</tscreen>
However, there have been reports that this fails on some
FreeBSD-current systems. If for some reason you cannot load the linux
LKM, then statically link the emulator in the kernel by adding
<tscreen>
<verb>
options LINUX
</verb>
</tscreen>
to your kernel config file. Then run config and install the new
kernel as described in the <ref id="kernelconfig" name="kernel
configuration"> section.
<sect1><heading>Installing Linux Runtime Libraries</heading>
<sect2><heading>Installing using the linux_lib port</heading>
<p>Most linux applications use shared libraries, so you are still not
done until you install the shared libraries. It is possible to do
this by hand, however, it is vastly simpler to just grab the
linux_lib port:
<tscreen>
<verb>
% cd /usr/ports-current/emulators/linux_lib
% make all install
</verb>
</tscreen>
and you should have a working linux emulator. Legend (and the mail
archives :-) seems to hold that Linux emulation works best with
linux binaries linked against the ZMAGIC libraries; QMAGIC libraries
(such as those used in Slackware V2.0) may tend to give the
Linuxulator heartburn. As of this writing (March 1996) ELF emulation
is still in the formulative stages but seems to work pretty well. Also,
expect some programs to complain about incorrect minor versions. In
general this does not seem to be a problem.
<sect2><heading>Installing libraries manually</heading>
<p>If you don't have the ``ports'' distribution, you can install the
libraries by hand instead. You will need the Linux shared libraries
that the program depends on and the runtime linker. Also, you will
need to create a "shadow root" directory, /compat/linux, for Linux
libraries on your FreeBSD system. Any shared libraries opened by
Linux programs run under FreeBSD will look in this tree first. So, if
a Linux program loads, for example, /lib/libc.so, FreeBSD will first
try to open /compat/linux/lib/libc.so, and if that does not exist then
it will try /lib/libc.so. Shared libraries should be installed in the
shadow tree /compat/linux/lib rather than the paths that the Linux
ld.so reports.
FreeBSD-current works slightly differently with respect to
/compat/linux. On -current, all files, not just libraries, are
searched for from the ``shadow root'' /compat/linux.
Generally, you will need to look for the shared libraries that Linux
binaries depend on only the first few times that you install a Linux
program on your FreeBSD system. After a while, you will have a sufficient
set of Linux shared libraries on your system to be able to run newly
imported Linux binaries without any extra work.
<sect2><heading>How to install additional shared libraries</heading>
<p>What if you install the linux_lib port and your application still
complains about missing shared libraries? How do you know which
shared libraries Linux binaries need, and where to get them?
Basically, there are 2 possibilities (when following these
instructions: you will need to be root on your FreeBSD system to do
the necessary installation steps).
<p>If you have access to a Linux system, see what shared libraries
it needs, and copy them to your FreeBSD system. Example: you have
just ftp'ed the Linux binary of Doom. Put it on the Linux
system you have access to, and check which shared libraries it
needs by running `ldd linuxxdoom':
<tscreen>
<verb>
% ldd linuxxdoom
libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0
libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29
</verb>
</tscreen>
<p>You would need go get all the files from the last column, and
put them under /compat/linux, with the names in the first column
as symbolic links pointing to them. This means you eventually have
these files on your FreeBSD system:
<tscreen>
<verb>
/compat/linux/usr/X11/lib/libXt.so.3.1.0
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
/compat/linux/lib/libc.so.4.6.29
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29
</verb>
</tscreen>
<p>Note that if you already have a Linux shared library with a
matching major revision number to the first column of the 'ldd'
output, you will not need to copy the file named in the last column to
your system, the one you already have should work. It is advisable to
copy the shared library anyway if it is a newer version, though. You
can remove the old one, as long as you make the symbolic link point to
the new one. So, if you have these libraries on your system:
<tscreen>
<verb>
/compat/linux/lib/libc.so.4.6.27
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27
</verb>
</tscreen>
and you find a new binary that claims to require a later version
according to the output of ldd:
<tscreen>
<verb>
libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29
</verb>
</tscreen>
If it is only one or two versions out of date in the in the trailing
digit then do not worry about copying /lib/libc.so.4.6.29 too, because
the program should work fine with the slightly older version.
However, if you like you can decide to replace the libc.so anyway, and
that should leave you with:
<tscreen>
<verb>
/compat/linux/lib/libc.so.4.6.29
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29
</verb>
</tscreen>
<p>Please note that the symbolic link mechanism is <em>only</em>
needed for Linux binaries, the FreeBSD runtime linker takes care of
looking for matching major revision numbers itself, you do not need to
worry about that.
<sect2><heading>Configuring the ld.so -- for FreeBSD-current only</heading>
<p>This section applies only to FreeBSD-current only. Those running
FreeBSD-stable should skip this section.
<p>Finally, if you run FreeBSD-current you must make sure that you
have the Linux runtime linker and its config files on your system. You
should copy these files from the Linux system to their appropriate
place on your FreeBSD system (to the /compat/linux tree):
<tscreen>
<verb>
/compat/linux/lib/ld.so
/compat/linux/etc/ld.so.config
</verb>
</tscreen>
<p>If you do not have access to a Linux system, you should get the
extra files you need from various ftp sites. Information on where to
look for the various files is appended below. For now, let us assume
you know where to get the files.
<p>
Retrieve the following files (all from the same ftp site to avoid any
version mismatches), and install them under /compat/linux
(i.e. /foo/bar is installed as /compat/linux/foo/bar):
<tscreen>
<verb>
/sbin/ldconfig
/usr/bin/ldd
/lib/libc.so.x.y.z
/lib/ld.so
</verb>
</tscreen>
<p>ldconfig and ldd do not necessarily need to be under /compat/linux,
you can install them elsewhere in the system too. Just make sure they
do not conflict with their FreeBSD counterparts. A good idea would be
to install them in /usr/local/bin as ldconfig-linux and ldd-linux.
<p>
Create the file /compat/linux/etc/ld.so.conf, containing the
directories in which the Linux runtime linker should look
for shared libs. It is a plain text file, containing a directory
name on each line. /lib and /usr/lib are standard, you could
add the following:
<tscreen>
<verb>
/usr/X11/lib
/usr/local/lib
</verb>
</tscreen>
<p>When a linux binary opens a library such as /lib/libc.so the
emulator maps the name to /compat/linux/lib/libc.so internally. All
linux libraries should be installed under /compat/linux (e.g.
/compat/linux/lib/libc.so, /compat/linux/usr/X11/lib/libX11.so, etc.)
in order for the emulator to find them.
<p>Those running FreeBSD-current should run the Linux ldconfig program.
<tscreen>
<verb>
% cd /compat/linux/lib
% /compat/linux/sbin/ldconfig
</verb>
</tscreen>
<p>Ldconfig is statically linked, so it does not need any shared
libraries to run. It creates the file /compat/linux/etc/ld.so.cache
which contains the names of all the shared libraries. It should rerun
to recreate this file whenever you install additional shared
libraries.
On FreeBSD-stable do not install /compat/linux/etc/ld.so.cache or run
ldconfig becuase in FreeBSD-stable the syscalls are implemented
differently and ldconfig is not needed or used.
<p>You should now be set up for Linux binaries which only need a
shared libc. You can test this by running the Linux ldd on
itself. Suppose that you have it installed as ldd-linux, it should
produce something like:
<tscreen>
<verb>
% ldd-linux `which ldd-linux`
libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29
</verb>
</tscreen>
<p>This being done, you are ready to install new Linux binaries.
Whenever you install a new Linux program, you should check if it needs
shared libraries, and if so, whether you have them installed in the
/compat/linux tree. To do this, you run the Linux version ldd on the
new program, and watch its output. ldd (see also the manual page for
ldd(1)) will print a list of shared libraries that the program depends
on, in the form majorname (jumpversion) => fullname.
<p>If it prints "not found" instead of fullname it means that you
need an extra library. Which library this is, is shown in majorname,
which will be of the form libXXXX.so.N You will need to find a
libXXXX.so.N.mm on a Linux ftp site, and install it on your
system. The XXXX (name) and N (major revision number) should match;
the minor number(s) mm are less important, though it is advised to
take the most recent version.
<sect1><heading>Configuring the host name resolver</heading>
<p>If DNS does not work or you get the messages
<tscreen>
<verb>
resolv+: "bind" is an invalid keyword
resolv+: "hosts" is an invalid keyword
</verb>
</tscreen>
then you need to configure a /compat/linux/etc/host.conf file
containing:
<tscreen>
<verb>
order hosts, bind
multi on
</verb>
</tscreen>
where the order here specifies that /etc/hosts is searched first and
DNS is searched second. When /compat/linux/etc/host.conf is not
installed linux applications find FreeBSD's /etc/host.conf and
complain about the incompatible FreeBSD syntax. You should remove
`bind,' if you have not configured a name-server using the
/etc/resolv.conf file.
<p>Lastly, those who run FreeBSD-stable need to set an the
RESOLV_HOST_CONF environment variable so that applications will know
how to search the host tables. If you run FreeBSD-current you can
skip this. For the /bin/csh shell use:
<tscreen>
<verb>
setenv RESOLV_HOST_CONF /compat/linux/etc/host.conf
</verb>
</tscreen>
For /bin/sh use:
<tscreen>
<verb>
RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF
</verb>
</tscreen>
<sect1><heading>Finding the necessary files</heading>
<p>Note: the information below is valid as of the time this document
was written, but certain details such as names of ftp sites,
directories and distribution names may have changed by the time you
read this.
<p>Linux is distributed by several groups that make their own set
of binaries that they distribute. Each distribution has its own
name, like ``Slackware'' or ``Yggdrasil''. The distributions are
available on a lot of ftp sites. Sometimes the files are unpacked,
and you can get the individual files you need, but mostly they
are stored in distribution sets, usually consisting of subdirectories
with gzipped tar files in them. The primary ftp sites for the
distributions are:
<verb>
sunsite.unc.edu:/pub/Linux/distributions
tsx-11.mit.edu:/pub/linux/distributions
</verb>
<p>
Some European mirrors:
<verb>
ftp.luth.se:/pub/linux/distributions
ftp.demon.co.uk:/pub/linux/distributions
src.doc.ic.ac.uk:/packages/linux/distributions
</verb>
<p>For simplicity, let us concentrate on Slackware here. This
distribution consists of a number of subdirectories, containing
separate packages. Normally, they are controlled by an install
program, but you can retrieve files "by hand" too. First of all, you
will need to look in the "contents" subdir of the distribution. You
will find a lot of small text files here describing the contents of the
separate packages. The fastest way to look something up is to retrieve
all the files in the contents subdirectory, and grep through them for
the file you need. Here is an example of a list of files that you
might need, and in which contents-file you will find it by grepping
through them:
<tabular ca=ll>
Library <colsep>Package <rowsep>
ld.so <colsep>ldso <rowsep>
ldconfig <colsep>ldso <rowsep>
ldd <colsep>ldso <rowsep>
libc.so.4 <colsep>shlibs <rowsep>
libX11.so.6.0 <colsep>xf_lib <rowsep>
libXt.so.6.0 <colsep>xf_lib <rowsep>
libX11.so.3 <colsep>oldlibs <rowsep>
libXt.so.3 <colsep>oldlibs <rowsep>
</tabular>
<p>So, in this case, you will need the packages ldso, shlibs, xf_lib
and oldlibs. In each of the contents-files for these packages, look
for a line saying ``PACKAGE LOCATION'', it will tell you on which `disk'
the package is, in our case it will tell us in which subdirectory we
need to look. For our example, we would find the following locations:
<tabular ca=ll>
Package <colsep>Location <rowsep>
ldso <colsep>diska2 <rowsep>
shlibs <colsep>diska2 <rowsep>
oldlibs <colsep>diskx6 <rowsep>
xf_lib <colsep>diskx9 <rowsep>
</tabular>
<p>The locations called ``diskXX'' refer to the ``slakware/XX''
subdirectories of the distribution, others may be found in the
``contrib'' subdirectory. In this case, we could now retrieve the
packages we need by retrieving the following files (relative to
the root of the Slackware distribution tree):
<tscreen>
<verb>
slakware/a2/ldso.tgz
slakware/a2/shlibs.tgz
slakware/x6/oldlibs/tgz
slakware/x9/xf_lib.tgz
</verb>
</tscreen>
<p>Extract the files from these gzipped tarfiles in your
/compat/linux directory (possibly omitting or afterwards
removing files you don't need), and you are done.
<p><bf>See also:</bf>
<verb>
ftp.freebsd.org:pub/FreeBSD/2.0.5-RELEASE/xperimnt/linux-emu/README
/usr/src/sys/i386/ibcs2/README.iBCS2
</verb>
<sect><heading>How to Install Mathematica on FreeBSD<label id="mathematica"></heading>
<p><em>Contributed by &a.rich and &a.chuck</em>
This document shows how to install the Linux binary
distribution of Mathematica 2.2 on FreeBSD 2.1.
<p>Mathematica supports Linux but not FreeBSD as it stands. So once
you have configured your system for Linux compatibility you have most
of what you need to run Mathematica.
<p>For those who already have the student edition of
Mathematica for DOS the cost of upgrading to the Linux
version at the time this was written, March 1996, was
&dollar;45.00. It can be ordered directly from Wolfram at
(217) 398-6500 and paid for by credit card.
<sect1><heading>Unpacking the Mathematica distribution</heading>
<p>The binaries are currently distributed by Wolfram on CDROM.
The CDROM has about a dozen tar files, each of which is a binary
distribution for one of the supported architectures. The one
for Linux is named LINUX.TAR. You can, for example, unpack this
into /usr/local/Mathematica:
<tscreen>
<verb>
% cd /usr/local
% mkdir Mathematica
% cd Mathematica
% tar -xvf /cdrom/LINUX.TAR
</verb>
</tscreen>
<sect1><heading>Obtaining your Mathematica Password</heading>
<p>Before you can run Mathematica you will have to obtain
a password from Wolfram that corresponds to your
`machine ID.'
<p>Once you have installed the linux compatibility runtime
libraries and unpacked the mathematica you can obtain
the `machine ID' by running the program `mathinfo' in
the Install directory.
<tscreen>
<verb>
% cd /usr/local/Mathematica/Install
% mathinfo
LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented
richc.isdn.bcm.tmc.edu 9845-03452-90255
%
</verb>
</tscreen>
So, for example, the `machine ID' of `richc' is `9845-03452-90255'.
You can ignore the message about the ioctl that is not
implemented. It won't prevent Mathematica from running
in any way and you can safely ignore it, though you
will see the message every time you run Mathematica.
<p>When you register with Wolfram, either by email, phone
or fax, you'll give them the 'machine ID' and they will
respond with a corresponding password consisting of
groups of numbers. You need to add them both along
with the machine name and license number in your
mathpass file.
You can do this by invoking:
<tscreen>
<verb>
% cd /usr/local/Mathematica/Install
% math.install
</verb>
</tscreen>
It will ask you to enter your license number and the
Wolfram supplied password. If you get them mixed up or
for some reason the math.install fails, That's OK,
because you can simply edit the file 'mathpass' in this
same directory to correct the info manually.
<p>After getting past the password, math.install will ask
you if you accept their canned install defaults, or if
you want to use your own. If you are like us and
distrust all install programs, you probably want to
specify the actual directories. Beware. Although the
math.install program asks you to specify directories,
it won't create them for you, so you should perhaps
have a second window open with another shell so that
you can create them before you give them to the install
program. Or, if it fails, you
can create the directories and then restart the
math.install program. The directories we chose to
create beforehand and specify to math.install were:
<tscreen>
<verb>
/usr/local/Mathematica/bin for binaries
/usr/local/Mathematica/man/man1 for man pages
/usr/local/Mathematica/lib/X11 for the XKeysymb file
</verb>
</tscreen>
You can also tell it to use /tmp/math.record for the
system record file, where it puts logs of sessions.
After this math.install will continue on to
unpacking things and placing everything where it should
go.
<p>The Mathematica Notebook feature is included separately,
as the X Front End, and you have to install it separately.
To get the X Front End stuff correctly installed, cd
into the /usr/local/Mathematica/FrontEnd directory and
executed the ./xfe.install shell script. You'll have
to tell it where to put things, but you don't have to
create any directories because it uses all the same
directories that had been created for math.install.
When it finished, there should be a new shell script in
/usr/local/Mathematica/bin called "mathematica".
<p>Lastly, you need to modify each of the shell scripts that
Mathematica has installed. At the beginning of every shell script in
/usr/local/Mathematica/bin add the following line:
<tscreen>
<verb>
XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB
</verb>
</tscreen>
This tells Mathematica were to find it's own version of the key
mapping file XKeysymDB. Without this you will get pages of error
messages about missing key mappings.
On FreeBSD-stable you need to add the following as well:
<tscreen>
<verb>
RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF
</verb>
</tscreen>
This tells Mathematica to use the linux version of host.conf. This
file has a different syntax from FreeBSD's host.conf, so you'll get an
error message about /etc/host.conf if you leave this out.
<p>You might want to also modify your /etc/manpath.config file
to read the new man directory, and you may need to edit your
~/.cshrc file to add /usr/local/Mathematica/bin
to your path.
<p>That's about all it takes, With this you should be able
to type "mathematica" and get a really slick looking
Mathematica Notebook screen up. Mathematica has included
the Motif user interfaces, but it's compiled in statically,
so you don't need the Motif libraries. Good luck doing this
yourself!
<sect1><heading>Bugs</heading>
<p>The Notebook front end is known to hang sometimes when reading
notebook files with an error messages similar to:
<tscreen>
<verb>
File .../Untitled-1.mb appears to be broken for OMPR.257.0
</verb>
</tscreen>
We haven't found the cause for this, but it only affects the
Notebook's X window front end, not the mathematica engine itself. So
the command line interface invoked by 'math' is unaffected by this
bug.
<sect1><heading>Acknowledgments</heading>
<p>A well-deserved thanks should go to &a.sos; and &a.peter;
who made linux emulation what it is today, and Michael Smith who
drove these two guys like dogs to get it to the point where it runs
Linux binaries better than linux! :-)

57
handbook/lists.sgml Normal file
View file

@ -0,0 +1,57 @@
<!-- $Id: lists.sgml,v 1.1 1996-05-16 23:18:06 mpp Exp $ -->
<!-- The FreeBSD Documentation Project -->
<!--
Names and email address of contributing authors and CVS committers
and some of the common FreeBSD mailing lists. Use these
entities when referencing people or mailing lists. Please
note the use of single
and double quotes.
-->
<!ENTITY a.announce "FreeBSD announcments mailing list
<tt><htmlurl url='mailto:freebsd-announce@FreeBSD.ORG'
name='&lt;freebsd-announce@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.doc "FreeBSD documentation project mailing list
<tt><htmlurl url='mailto:freebsd-doc@FreeBSD.ORG'
name='&lt;freebsd-doc@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.bugs "FreeBSD problem reports mailing list
<tt><htmlurl url='mailto:freebsd-doc@FreeBSD.ORG'
name='&lt;freebsd-doc@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.current "FreeBSD-current mailing list
<tt><htmlurl url='mailto:freebsd-current@FreeBSD.ORG'
name='&lt;freebsd-current@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.emulation "FreeBSD-emulation mailing list
<tt><htmlurl url='mailto:freebsd-emulation@FreeBSD.ORG'
name='&lt;freebsd-emulation@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.fs "FreeBSD filesystem project mailing list
<tt><htmlurl url='mailto:freebsd-fs@FreeBSD.ORG'
name='&lt;freebsd-fs@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.hackers "FreeBSD technical discussions mailing list
<tt><htmlurl url='mailto:freebsd-hackers@FreeBSD.ORG'
name='&lt;freebsd-hackers@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.ports "FreeBSD ports mailing list
<tt><htmlurl url='mailto:freebsd-ports@FreeBSD.ORG'
name='&lt;freebsd-ports@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.questions "FreeBSD general questions mailing list
<tt><htmlurl url='mailto:freebsd-questions@FreeBSD.ORG'
name='&lt;freebsd-questions@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.scsi "FreeBSD SCSI subsystem mailing list
<tt><htmlurl url='mailto:freebsd-questions@FreeBSD.ORG'
name='&lt;freebsd-questions@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.stable "FreeBSD-stable mailing list
<tt><htmlurl url='mailto:freebsd-questions@FreeBSD.ORG'
name='&lt;freebsd-questions@FreeBSD.ORG&gt;'></tt>">
<!ENTITY a.majordomo "<tt><htmlurl url='mailto:majordomo@FreeBSD.ORG'
name='&lt;majordomo@FreeBSD.ORG&gt;'></tt>">

200
handbook/pgpkeys.sgml Normal file
View file

@ -0,0 +1,200 @@
<!-- $Id: pgpkeys.sgml,v 1.6 1996-06-11 18:05:47 rich Exp $ -->
<!-- The FreeBSD Documentation Project -->
<chapt><heading>PGP keys<label id="pgpkeys"></heading>
<p> In case you need to verify a signature or send encrypted
email to one of the officers or core team members a
number of keys are provided here for your convenience.
<sect><heading>Officers</heading>
<sect1><heading>
FreeBSD Security Officer &lt;security-officer@freebsd.org&gt;
</heading> <p>
<tscreen><verb>
FreeBSD Security Officer &lt;security-officer@freebsd.org&gt;
Fingerprint = 41 08 4E BB DB 41 60 71 F9 E5 0E 98 73 AF 3F 11
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQCNAzF7MY4AAAEEAK7qBgPuBejER5HQbQlsOldk3ZVWXlRj54raz3IbuAUrDrQL
h3g57T9QY++f3Mot2LAf5lDJbsMfWrtwPrPwCCFRYQd6XH778a+l4ju5axyjrt/L
Ciw9RrOC+WaPv3lIdLuqYge2QRC1LvKACIPNbIcgbnLeRGLovFUuHi5z0oilAAUR
tDdGcmVlQlNEIFNlY3VyaXR5IE9mZmljZXIgPHNlY3VyaXR5LW9mZmljZXJAZnJl
ZWJzZC5vcmc+iQCVAwUQMX6yrOJgpPLZnQjrAQHyowQA1Nv2AY8vJIrdp2ttV6RU
tZBYnI7gTO3sFC2bhIHsCvfVU3JphfqWQ7AnTXcD2yPjGcchUfc/EcL1tSlqW4y7
PMP4GHZp9vHog1NAsgLC9Y1P/1cOeuhZ0pDpZZ5zxTo6TQcCBjQA6KhiBFP4TJql
3olFfPBh3B/Tu3dqmEbSWpuJAJUDBRAxez3C9RVb+45ULV0BAak8A/9JIG/jRJaz
QbKom6wMw852C/Z0qBLJy7KdN30099zMjQYeC9PnlkZ0USjQ4TSpC8UerYv6IfhV
nNY6gyF2Hx4CbEFlopnfA1c4yxtXKti1kSN6wBy/ki3SmqtfDhPQ4Q31p63cSe5A
3aoHcjvWuqPLpW4ba2uHVKGP3g7SSt6AOYkAlQMFEDF8mz0ff6kIA1j8vQEBmZcD
/REaUPDRx6qr1XRQlMs6pfgNKEwnKmcUzQLCvKBnYYGmD5ydPLxCPSFnPcPthaUb
5zVgMTjfjS2fkEiRrua4duGRgqN4xY7VRAsIQeMSITBOZeBZZf2oa9Ntidr5PumS
9uQ9bvdfWMpsemk2MaRG9BSoy5Wvy8VxROYYUwpT8Cf2iQCVAwUQMXsyqWtaZ42B
sqd5AQHKjAQAvolI30Nyu3IyTfNeCb/DvOe9tlOn/o+VUDNJiE/PuBe1s2Y94a/P
BfcohpKC2kza3NiW6lLTp00OWQsuu0QAPc02vYOyseZWy4y3Phnw60pWzLcFdemT
0GiYS5Xm1o9nAhPFciybn9j1q8UadIlIq0wbqWgdInBT8YI/l4f5sf6JAJUDBRAx
ezKXVS4eLnPSiKUBAc5OBACIXTlKqQC3B53qt7bNMV46m81fuw1PhKaJEI033mCD
ovzyEFFQeOyRXeu25Jg9Bq0Sn37ynISucHSmt2tUD5W0+p1MUGyTqnfqejMUWBzO
v4Xhp6a8RtDdUMBOTtro16iulGiRrCKxzVgEl4i+9Z0ZiE6BWlg5AetoF5n3mGk1
lw==
=ipyA
-----END PGP PUBLIC KEY BLOCK-----
</verb></tscreen>
<sect><heading>Core team members</heading>
<sect1><heading>&a.jkh</heading><p>
<tscreen><verb>
Jordan K. Hubbard &lt;jkh@FreeBSD.org&gt;
Fingerprint = 3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2i
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ
jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk
tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR
tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokAlQMFEDF75D1r
WmeNgbKneQEBXtcD+gJIv8JzZRKlDZyTCQanK8iRgE+zMhxptI0kDObaGxT1BrpY
4/EPyiUN10G4k2Jb+DOc8Lg2xDQ3xmvgipFf9NMNV/ThaEuZ3wA31I6tW/arQEqB
Tp8u6T3v20m62t7Afo9HaoE6MBpHQUk2TilxgAd5P57sporL3pgW9YojIO9ziQCV
AwUQMXyV2h9/qQgDWPy9AQEMfgP/RmbSg2WlesATUQ4WuanjcdREduKPyfQatrXD
2xt+jg9X78dTyiNN1YvLqvT6msfs04MKSC0hA2mou6ozw8Xak+1QmP0fBOZKp9pP
8szO188Do9ByzJPvHF1eXT7jFMOXVq8ZIl9iwjxcIDLzlxOz49DC7LO6AT+LKQk7
UGeP+lqJAJUDBRAxe+UG9RVb+45ULV0BAXZ9A/9F9gLpGukVNkeOjaqxQdJGTS+a
xh/Abk0c/nKhAEyxpAl5JyQ3ifYk6BHhPvlTi9LrZoXGA8sk/eU4eRTZVzvGEC4G
+xsavlE/xzku8855QTLPpkCunUpQeu1wzaIrUUE6Zjh05imFbJYyQOBgTFpuqWsC
rsUpl+2mr8IGIxG5rA==
=LW9i
-----END PGP PUBLIC KEY BLOCK-----
</verb></tscreen>
<sect1><heading>&a.phk</heading><p>
<tscreen><verb>
Poul-Henning Kamp &lt;phk@FreeBSD.org&gt;
Fingerprint = A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI
ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA
K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR
tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDF+jX1r
WmeNgbKneQEBCrID/i/ri8/eXUXRJp2fqJqzvrWGTP9Ix1O4vMguah9IILijgpYy
OJYkezZKijjVCVmLX7EwfNXfYkqLAWUa08eov4QfJfJDgfe+Z/3/UoX7RcJoy2Aj
TBZQzOI9JMkrzFdtFGYwMr/QXhOdVVpSGeZ/6Hkrs7pd2Z6MNNrRf81ZyJyYiQCV
AwUQMXyV5/UVW/uOVC1dAQFyfAP/SujU+lS2WQuat4O2wZOQ1rswUt6CthG8MOsc
7A9kfXnZbaM9Sdxj54CtAlqR4eJMOYk2kVqAtmCWETRuonJxr5TAJdf7q6kByVYc
QEyDZvKJYwyrI9UQSelSgczWwiSB01aV9ACaKlEF9iHYvIKBa9HwJu3A9ggW9SYa
AHcxHzuJAJUDBRAxSx5cH3+pCANY/L0BAY+TA/9YQPISXYaS+5r0I60wCJ+i3a9P
C69Zak2ikgTHQi97LhpVtEsP3SAYInDw4YMS2oU9w1XxoiLLd9hUpcZlmO8Ip3vN
F+E2ZCfR4sNzKarY5fdo+sxzatGWRPgnHjbm6RHWCw6qJACDD3VpaFjx2XD8QrOT
yiObnbHhWBdoEAIyNokAlQMFEDE5Q6DvYbnpEdWO1QEBsvgD/0c6flBrSWr20oj8
eRJ1zl8ZAP/rpV0IEBvb3ZFsHsJL8QzTsx1typFFghrT7SDBDc52xY90JWAflEiG
n9aIL5Q+RHVxjw30yDaRPAl9ll82o34GBaWBEw83bsI6Fg2XxDfc2X0KkEutlYAE
XjiM95PQS+9PM//llDtPvkSxgpiJiQCVAwUQMOavJADy2QnruxtBAQE92wQAsKPq
/U4G4ksslOXGaauSoBk9XO3lB147cSpra1w9ZxTSeo+8dgzNlxnugWDnw1mxauFJ
BAMgHl74rrlD+Hp0Ltb9oOyRl3riPG0TOdfaS3T8w6vw52wOKzUrZ/0pB+2sDHzU
qZXBbhOq3OXs1ZMNe3jh8w62JsLBWry/YMWRMnI=
=MDQ9
-----END PGP PUBLIC KEY BLOCK-----
</verb></tscreen>
<sect1><heading>&a.joerg</heading><p>
<tscreen><verb>
Joerg Wunsch &lt;j@uriah.heep.sax.de&gt;
Fingerprint = DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2i
mQCNAzGCFeAAAAEEAKmRBU2Nvc7nZy1Ouid61HunA/5hF4O91cXm71/KPaT7dskz
q5sFXvPJPpawwvqHPHfEbAK42ZaywyFp59L1GaYj87Pda+PlAYRJyY2DJl5/7JPe
ziq+7B8MdvbX6D526sdmcR+jPXPbHznASjkx9DPmK+7TgFujyXW7bjh2o/exAAUR
tCJKb2VyZyBXdW5zY2ggPGpAdXJpYWguaGVlcC5zYXguZGU+iQCVAwUQMalkbHW7
bjh2o/exAQFwwQP+Pa82QeWpJE0m7f4DXd/DiYAvh/DeXWtub1fXQ9yqAL131n8O
zsSLMb0PwG/qyZrpK61sT3bAvtVlNftaxmuD7yaf1SUQ3rNmsBq5/oju/3EKEiFc
4gtuyaXG74y7y1XASIstck/0byfvO2t4z0R7d1RRnKRYeCspMcUjYshsoJeJAJUD
BRAxpL3UPiAdBSUb0JkBAZg7BACE+mKhsrd39/P6NattCCOSg76Pf2CVgZdvbb7q
K4SmsVGz+58pi2OWM1M0rcHgNZKTIg9rBy47gui2KOnqOR7ZuyMVJJqyEZZywmWm
fCy/sR4Ui1PehZNNNBAi09u03ItbozrEH6Msa1oC8mp86XOA70Et8e4DYtj5a9tV
bjjtJYkAlQMFEDGCUB31FVv7jlQtXQEB5KgD/iIJZe5lFkPr2B/Cr7BKMVBot1/J
Su05NsHgJZ3uK15w4mVtNPZcFi/dKbn+qRM6LKDFe/GF0HZD/ZD1FJt8yQjzF2w3
40B+F2GGEOwnClqZDtEAqnIBzM/ECQQqH+6Bi8gpkFZrFgg5eON7ikqmusDnOlYS
tM/CBfgpSbR8kDmFtCZKb2VyZyBXdW5zY2ggPGpAaW50ZXJmYWNlLWJ1c2luZXNz
LmRlPokAlQMFEDGpbnd1u244dqP3sQEBJnQD/RVSAzgf4uorv3fpbosI0LE3LUuf
AYGBSJNJnskeKyudZkNkI5zGGDwVneH/cSkKT4ORooeqcTBxKeMaMuXPVl30Qahg
NwWjfuTvl5OZ8orsQGGWIn5FhqYXsKkjEGxIOBOfvvlVQ0UbcR0N2+5F6Mb5GqrX
ZpIesn7jFJpkQKPU
=46Ab
-----END PGP PUBLIC KEY BLOCK-----
</verb></tscreen>
<sect1><heading>&a.ache</heading><p>
<tscreen><verb>
Andrey A. Chernov &lt;ache@FreeBSD.org&gt;
Fingerprint = 33 03 9F 48 33 7B 4A 15 63 48 88 0A C4 97 FD 49
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAiqUMGQAAAEEAPGhcD6A2Buey5LYz0sphDLpVgOZc/bb9UHAbaGKUAGXmafs
Dcb2HnsuYGgX/zrQXuCi/wIGtXcZWB97APtKOhFsZnPinDR5n/dde/mw9FnuhwqD
m+rKSL1HlN0z/Msa5y7g16760wHhSR6NoBSEG5wQAHIMMq7Q0uJgpPLZnQjrAAUT
tDJBbmRyZXkgQS4gQ2hlcm5vdiwgQmxhY2sgTWFnZSA8YWNoZUBhc3RyYWwubXNr
LnN1PokAlQMFEDArAKOf6xq8qC/IdwEB6tUEAIncjRagPYb65jHI6WO3LCVRZRr4
+e+Fo+Bj2qN6WXrkGjAZrFqmly2J1lPwJXW+pE8+vp0XEF+dMxR9Ex0j3wKcBFu8
sm0kyOWqSZlk96oSjdr5izYNsjc4ai08xyw9ZR94taX0KvFnr6zX4y1HKOUv1bnp
E5mv6LJ8wgsO30MwiQCVAwUQMCr8KGtaZ42Bsqd5AQEYoQQAqF696nxuuYRQsiiS
Epozr2qBq2p8VCJHg0tMkHUx84UPncAdToYSteRNDcK9DCmoyzJvdJ+vmXW+cvxS
I6T64rvHSK5R61mZXsGvPHhAzPkPzcU9YmIPh2igwBNe9Y5i6UqQi9DIibTtIt+i
93pFQ+x7/L33zmRz0h4qyMyTmU2JAJUDBRAwGrusxS1HbQ2/kG0BAUF/A/wMcJGH
hWmMWWDBTgxyL0pNt4QLIwplANlIpdRXlgLrG/qPMUXzw3O056LKyInyamxefn3B
whuVUkxpYQYXdfGFlHmm3/4fTtgbEF+eclkbgdsd3YidcSP1VXRvq8ZTAphOGUdU
5fcfjLbp/SqilaQd/VZZAgWEN4ZYDbf0yVGOK4kAlQMFEDARzJsiUZbZZm0AUQEB
UJMD/2At2obN2TDKK4jpbd2cRjVFD0xe6yBEd4/nO5qhhuOnRJwwebFK5M2nKaC1
+bI9bRkd278/WuL5pNQL9yhTTb62Wd/wWRRqat5gk4gAvc7MjWEPC9AHxiFDuYKA
iI6sDkzUCADqTbCeUvpzAJEAeGJpjZSOhk29w9fM34T2ernIiQCVAgUQMA9LJeLl
u+H7XhUZAQFrAAP/TWKgUQSm5pbUA6ciuPowQGI5FwSZgERVyiWE5Z04DhzKWaqF
clvesZ2muTM8RIru2VpuaC9dEAyKdZK5AT9inJr30jDB2+WhggkHNvz/DZX1wLh7
TRs2IiNFACMIvIof0tZYlX756hfbld3d5KBO1bEPTgOEKNGS9oIFvv4BGmCJAJUD
BRAwDs+qsfyMh3t65eEBASL2A/4yK/F6qP9iOYJ3IIUnhUdNZ9LxCxSL2heHB6Hx
s8swaWLHwPuqYBSNSDPi1Bd5G1JAGP9rkn/VORAnGjAk1gsFYCVTvqBtO+UhxDOG
7oa87rWYjNXU8k2nqWj6U8kTFFMfWTDGCbO7G6iyHdXg8KycVD4awTb3/8NltrGB
0mPHHYkAlQMFEDAM6oB3HZKuiXLHwQEBk8cEALYHixYtq4UjnZZaQ11MM/kkumxI
xU1oEbFhTMvUJznKq8sOy8rhZlnop+I2rI2NN9ybDg31kD4j1TQN1BJ11YPfp/AL
zTDzvCZEbwp9XjYNFWicvSd+vLgK4qPd2oHdmH/0ea/kBLj4yLLFZPIXXMv5bhIU
ol1n+myzFRxANCfjiQCVAwUQMA1IvuJgpPLZnQjrAQGrQQQAhwfqrVvPNLHkQg2S
45f209W9eOaaOtFO7umtzxAZGNDQO9rVg0LkTxfwp/9PlXRTcUFLIJK28GiVjqIt
CkLL5Tpt0a7MSm5/brxCi8RMcih96cae+pL8/5RFsBHirwSvvOD29Zc6Rt1u7tlw
34t1UD04t+UmTAB3OgtArf5ozZWJAJUDBRAwDKzw+8I/jbEzFDkBASXJA/4pOFrG
c5tqjsfRcHqxqu2cHIXPiatWHjeT8ac6kn+ABu/u3RSJ/qHul9hXCM4G2GPiH5oC
SBxFYwxx+frgF8m+peIinPPXkGsDt7fPKXxyyVm085p74M9nDK8bfeB0b4JB373K
RhIG8pXauhAd9zrp2sxXH2RUSHF5NbH8iw72BA==
=ekPo
-----END PGP PUBLIC KEY BLOCK-----
</verb></tscreen>
<sect1><heading>&a.rich</heading><p>
<tscreen><verb>
Rich Murphey &lt;rich@FreeBSD.org&gt;
fingerprint = AF A0 60 C4 84 D6 0C 73 D1 EF C0 E9 9D 21 DB E4
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAy97V+MAAAEEALiNM3FCwm3qrCe81E20UOSlNclOWfZHNAyOyj1ahHeINvo1
FBF2Gd5Lbj0y8SLMno5yJ6P4F4r+x3jwHZrzAIwMs/lxDXRtB0VeVWnlj6a3Rezs
wbfaTeSVyh5JohEcKdoYiMG5wjATOwK/NAwIPthB1RzRjnEeer3HI3ZYNEOpAAUR
tCRSaWNoIE11cnBoZXkgPHJpY2hAbGFtcHJleS51dG1iLmVkdT6JAJUDBRAve15W
vccjdlg0Q6kBAZTZBACcNd/LiVnMFURPrO4pVRn1sVQeokVX7izeWQ7siE31Iy7g
Sb97WRLEYDi686osaGfsuKNA87Rm+q5F+jxeUV4w4szoqp60gGvCbD0KCB2hWraP
/2s2qdVAxhfcoTin/Qp1ZWvXxFF7imGA/IjYIfB42VkaRYu6BwLEm3YAGfGcSw==
=QoiM
-----END PGP PUBLIC KEY BLOCK-----
</verb></tscreen>

208
handbook/quotas.sgml Normal file
View file

@ -0,0 +1,208 @@
<!-- This is an SGML document in the linuxdoc DTD describing
disk quotas under FreeBSD. By Mike Pritchard, 1996.
$Id: quotas.sgml,v 1.3 1996-05-15 19:40:57 mpp Exp $
The FreeBSD Documentation Project
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
<article>
<title> Disk quotas
<author> Mike Pritchard <tt/mpp@FreeBSD.org/
<date> 26 February 1996, (c) 1996
<abstract> This document describes configuration and administration
of disk quotas under FreeBSD. </abstract>
<toc>
-->
<chapt><heading>Disk quotas<label id="quotas"></heading>
<p><em>Contributed by &a.mpp;.<newline>26 February 1996</em>
Quotas are an optional feature of the operating system that allow
you to limit the amount of disk space and/or the number of files
a user, or members of a group, may allocate on a per-file system basis.
This is used most often on timesharing systems where it is desirable
to limit the amount of resources any one user or group of users may
allocate. This will prevent one user from consuming all of
the available disk space.
<sect><heading>Configuring your system to enable disk quotas</heading>
<p>Before attempting to use disk quotas it is
necessary to make sure that quotas are configured in your kernel.
This is done by adding the following line to your kernel configuration file:
<verb>
options QUOTA
</verb>
The stock GENERIC kernel does not have this enabled by default, so you
will have to configure, build and install a custom kernel in order to use
disk quotas. Please refer to the
<ref id="kernelconfig" name="Configuring the FreeBSD Kernel">
section for more information on kernel configuration.
<p>Next you will need to enable disk quotas in <tt>/etc/sysconfig</tt>.
This is done by changing the line:
<verb>
quotas=NO
</verb>
to:
<verb>
quotas=YES
</verb>
<p>Finally you will need to edit <tt>/etc/fstab</tt> to enable
disk quotas on a per-file system basis. This is where you can
either enable user or group quotas or both for all of your file
systems.
<p>To enable per-user quotas on a file system, add the
<tt>userquota</tt> option to the options field in the
<tt>/etc/fstab</tt> entry for the file system you want to
to enable quotas on. For example:
<verb>
/dev/sd1s2g /home ufs rw,userquota 1 2
</verb>
<p>Similarly, to enable group quotas, use the <tt>groupquota</tt>
option instead of the <tt>userquota</tt> keyword. To enable both
user and group quotas, change the entry as follows:
<verb>
/dev/sd1s2g /home ufs rw,userquota,groupquota 1 2
</verb>
<p>By default the quota files are stored in the root directory of the file
system with the names <tt>quota.user</tt> and <tt>quota.group</tt>
for user and group quotas respectively. See <tt>man fstab</tt> for more
information. Even though that man page says that you can specify an
alternate location for the quota files, this is not recommended since
all of the various quota utilities do not seem to handle this
properly.
<p>At this point you should reboot your system with your new kernel.
<tt>/etc/rc</tt> will automatically run the appropriate commands to
create the initial quota files for all of quotas you enabled
in <tt>/etc/fstab</tt>, so there is no need to manually create any
zero length quota files.
<p>In the normal course of operations you should not be required
to run the <tt>quotacheck</tt>, <tt>quotaon</tt>, or <tt>quotaoff</tt>
commands manually. However, you may want to read their man pages
just to be familiar with their operation.
<sect><heading>Setting quota limits</heading>
<p>Once you have configured your system to enable quotas, verify that
they really are enabled. An easy way to do this is to run
<tt>quota -v</tt>. You should see a one line summary of disk
usage and current quota limits for each file system that
quotas are enabled on.
<p>You are now ready to start assigning quota limits
with the <tt>edquota</tt> command.
<p>You have several options on how to enforce limits on the amount of
disk space a user or group may allocate, and how many files they may create.
You may limit allocations based on disk space (block quotas) or
number of files (inode quotas) or a combination of both.
Each of these limits are further broken down into two categories: hard and
soft limits.
<p>A hard limit may not be exceeded. Once a user reaches their hard
limit they may not make any further allocations on the file system
in question. For example, if the user has a hard limit of 500 blocks
on a file system and is currently using 490 blocks, the user can only allocate
an additional 10 blocks. Attempting to allocate an additional 11 blocks
will fail.
<p>Soft limits on the other hand can be exceeded for a limited amount
of time. This period of time is known as the grace period, which is
one week by default. If a user stays over his or her soft limit longer
than their grace period, the soft limit will turn into a hard limit
and no further allocations will be allowed. When the user drops
back below the soft limit, the grace period will be reset.
<p>The following is an example of what you might see when
you run then <tt>edquota</tt> command. When the <tt>edquota</tt>
command is invoked, you are placed into the editor specified by the
<tt>EDITOR</tt> environment variable, or in the <tt>vi</tt> editor
if the <tt>EDITOR</tt> variable is not set, to
allow you to edit the quota limits.
<verb>
# edquota -u test
Quotas for user test:
/usr: blocks in use: 65, limits (soft = 50, hard = 75)
inodes in use: 7, limits (soft = 50, hard = 60)
/usr/var: blocks in use: 0, limits (soft = 50, hard = 75)
inodes in use: 0, limits (soft = 50, hard = 60)
</verb>
You will normally see two lines for each file system that has
quotas enabled. One line for the block limits, and one line
for inode limits. Simply change the value you want updated
to modify the quota limit. For example, to raise this users
block limit from a soft limit of 50 and a hard limit of 75
to a soft limit of 500 and a hard limit of 600, change:
<verb>
/usr: blocks in use: 65, limits (soft = 50, hard = 75)
</verb>
to:
<verb>
/usr: blocks in use: 65, limits (soft = 500, hard = 600)
</verb>
The new quota limits will be in place when you exit the editor.
<p>Sometimes it is desirable to set quota limits on a range
of uids. This can be done by use of the <tt>-p</tt> option
on the <tt>edquota</tt> command. First, assign the desired
quota limit to a user, and then run
<tt>edquota -p protouser startuid-enduid</tt>.
For example, if user <tt>test</tt> has the desired quota
limits, the following command can be used to duplicate
those quota limits for uids 10,000 through 19,999:
<verb>
edquota -p test 10000-19999
</verb>
<p>The ability to specify uid ranges was added to the system
after 2.1 was released. If you need this feature on a 2.1
system, you will need to obtain a newer copy of edquota.
<p>See <tt>man edquota</tt> for more detailed information.
<sect><heading>Checking quota limits and disk usage</heading>
<p>You can use either the <tt>quota</tt> or the <tt>repquota</tt>
commands to check quota limits and disk usage. The <tt>quota</tt>
command can be used to check individual user and group quotas and
disk usage. Only the super-user may examine quotas and usage for
other users, or for groups that they are not a member of.
The <tt>repquota</tt> command can be used to get a summary of all
quotas and disk usage for file systems with quotas enabled.
<p>The following is some sample output from the <tt>quota -v</tt>
command for a user that has quota limits on two file systems.
<verb>
Disk quotas for user test (uid 1002):
Filesystem blocks quota limit grace files quota limit grace
/usr 65* 50 75 5days 7 50 60
/usr/var 0 50 75 0 50 60
</verb>
On the /usr file system in the above example this user is
currently 15 blocks over their soft limit of 50 blocks and has 5 days of
their grace period left. Note the asterisk (*) which indicates that
the user is currently over their quota limit.
<p>Normally file systems that the user is not using any disk space
on will not show up in the output from the <tt>quota</tt> command,
even if they have a quota limit assigned for that file system.
The <tt>-v</tt> option will display those file systems, such as
the <tt>/usr/var</tt> file system in the above example.
<sect><heading>* Quotas over NFS</heading>
<p>This section is still under development.

207
handbook/sio.sgml Normal file
View file

@ -0,0 +1,207 @@
<!-- $Id: sio.sgml,v 1.2 1996-03-26 23:22:03 mpp Exp $ -->
<!-- The FreeBSD Documentation Project -->
<!--
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
<!ENTITY % authors SYSTEM "authors.sgml">
%authors;
]>
-->
<sect2><heading>Configuring the <tt>sio</tt> driver<label id="sio"></heading>
<p>The <tt>sio</tt> driver provides support for NS8250-,
NS16450-, NS16550 and NS16550A-based EIA RS-232C (CCITT
V.24) communications interfaces. Several multiport
cards are supported as well. See the <tt>sio(4)</tt>
manual page for detailed technical documentation.
<sect3><heading>Digi International (DigiBoard) PC/8</heading>
<p><em>Contributed by &a.awebster;.<newline>26 August
1995.</em>
Here is a config snippet from a machine with
a Digi International PC/8 with 16550. It has 8 modems connected
to these 8 lines, and they work just great. Do not
forget to add <tt>options "COM_MULTIPORT"</tt> or it
will not work very well!
<tscreen><verb>
device sio4 at isa? port 0x100 tty flags 0xb05
device sio5 at isa? port 0x108 tty flags 0xb05
device sio6 at isa? port 0x110 tty flags 0xb05
device sio7 at isa? port 0x118 tty flags 0xb05
device sio8 at isa? port 0x120 tty flags 0xb05
device sio9 at isa? port 0x128 tty flags 0xb05
device sio10 at isa? port 0x130 tty flags 0xb05
device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr
</verb></tscreen>
The trick in setting this up is that the MSB of the
flags represent the last SIO port, in this case 11 so
flags are 0xb05.
<sect3><heading>Boca 16</heading>
<p><em>Contributed by &a.whiteside;.<newline>26 August
1995.</em>
The procedures to make a Boca 16 pord board with
FreeBSD are pretty straightforward, but you will need
a couple things to make it work:
<enum>
<item>You either need the kernel sources installed
so you can recompile the necessary options or
you will need someone else to compile it for you.
The 2.0.5 default kernel does <bf>not</bf> come with
multiport support enabled and you will need to add
a device entry for each port anyways.
</item>
<item>Two, you will need to know the interrupt and IO
setting for your Boca Board so you can set these
options properly in the kernel.</item>
</enum>
One important note - the actual UART chips for the
Boca 16 are in the connector box, not on the internal
board itself. So if you have it unplugged, probes of
those ports will fail. I have never tested booting with
the box unplugged and plugging it back in, and I
suggest you do not either.
If you do not already have a custom kernel
configuration file set up, refer to <ref
id="kernelconfig" name="Kernel Configuration"> for
general procedures. The following are the specifics
for the Boca 16 board and assume you are using the
kernel name MYKERNEL and editing with vi.
<enum>
<item>Add the line
<tscreen><verb>
options "COM_MULTIPORT"
</verb></tscreen>
to the config file.
</item>
<item>Where the current <tt>device sio
<em>xxx</em></tt> lines are, you will need to add
16 more devices. <em>Only the last device
includes the interrupt vector for the
board</em>. (See the <tt>sio(4)</tt> manual page
for detail as to why.)
The following example is for a Boca Board with an
interrupt of 3, and a base IO address 100h. The
IO address for Each port is +8 hexadecimal from
the previous port, thus the 100h, 108h, 110h...
addresses.
<tscreen><verb>
device sio1 at isa? port 0x100 tty flags 0x1005
device sio2 at isa? port 0x108 tty flags 0x1005
device sio3 at isa? port 0x110 tty flags 0x1005
device sio4 at isa? port 0x118 tty flags 0x1005
[...]
device sio15 at isa? port 0x170 tty flags 0x1005
device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr
</verb></tscreen>
The flags entry <em>must</em> be changed from
this example unless you are using the exact same
sio assignments. Flags are set according to
0x<em>MYY</em> where <em>M</em> indicates the
minor number of the master port (the last port on
a Boca 16) and <em>YY</em> indicates if FIFO is
enabled or disabled(enabled), IRQ sharing is
used(yes) and if there is an AST/4 compatible IRQ
control register(no).
In this example,
<tscreen><verb>
flags 0x1005
</verb></tscreen>
indicates that the master port is sio16. If I
added another board and assigned sio17 through
sio28, the flags for all 16 ports on
<em>that</em> board would be 0x1C05, where 1C
indicates the minor number of the master port.
Do not change the 05 setting.</item>
<item>Save and complete the kernel configuration,
recompile, install and reboot.
Presuming you have successfully installed the
recompiled kernel and have it set to the correct
address and IRQ, your boot message should
indicate the successful probe of the Boca ports
as follows: (obviously the sio numbers, IO and
IRQ could be different)
<tscreen><verb>
sio1 at 0x100-0x107 flags 0x1005 on isa
sio1: type 16550A (multiport)
sio2 at 0x108-0x10f flags 0x1005 on isa
sio2: type 16550A (multiport)
sio3 at 0x110-0x117 flags 0x1005 on isa
sio3: type 16550A (multiport)
sio4 at 0x118-0x11f flags 0x1005 on isa
sio4: type 16550A (multiport)
sio5 at 0x120-0x127 flags 0x1005 on isa
sio5: type 16550A (multiport)
sio6 at 0x128-0x12f flags 0x1005 on isa
sio6: type 16550A (multiport)
sio7 at 0x130-0x137 flags 0x1005 on isa
sio7: type 16550A (multiport)
sio8 at 0x138-0x13f flags 0x1005 on isa
sio8: type 16550A (multiport)
sio9 at 0x140-0x147 flags 0x1005 on isa
sio9: type 16550A (multiport)
sio10 at 0x148-0x14f flags 0x1005 on isa
sio10: type 16550A (multiport)
sio11 at 0x150-0x157 flags 0x1005 on isa
sio11: type 16550A (multiport)
sio12 at 0x158-0x15f flags 0x1005 on isa
sio12: type 16550A (multiport)
sio13 at 0x160-0x167 flags 0x1005 on isa
sio13: type 16550A (multiport)
sio14 at 0x168-0x16f flags 0x1005 on isa
sio14: type 16550A (multiport)
sio15 at 0x170-0x177 flags 0x1005 on isa
sio15: type 16550A (multiport)
sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa
sio16: type 16550A (multiport master)
</verb></tscreen>
If the messages go by too fast to see, <tt>dmesg
&gt; more</tt> will show you the boot
messages.</item>
<item>Next, appropriate entries in <tt>/dev</tt> for the devices
must be made using the <tt>/dev/MAKEDEV</tt>
script. After becoming root:
<tscreen>
# cd /dev<newline>
# ./MAKEDEV tty1<newline>
# ./MAKEDEV cua1<newline>
<em>(everything in between)</em><newline>
# ./MAKEDEV ttyg<newline>
# ./MAKEDEV cuag
</tscreen>
If you do not want or need callout devices for some
reason, you can dispense with making the <tt>cua*</tt>
devices.</item>
<item>If you want a quick and sloppy way to make
sure the devices are working, you can simply plug
a modem into each port and (as root) <tt>echo at
&gt; ttyd*</tt> for each device you have
made. You <em>should</em> see the RX lights flash
for each working port.</item>
</enum>

108
handbook/stable.sgml Normal file
View file

@ -0,0 +1,108 @@
<!-- $Id: stable.sgml,v 1.2 1996-05-16 23:18:19 mpp Exp $ -->
<!-- The FreeBSD Documentation Project -->
<chapt><heading>Staying stable with FreeBSD<label id="stable"></heading>
<p><em>Contributed by &a.jkh;.</em>
<!--
THE FREEBSD STABLE POLICY
Last updated: $Date: 1996-05-16 23:18:19 $
This document attempts to explain the rationale behind
FreeBSD-stable, what you should expect should you decide to run it,
and states some prerequisites for making sure the process goes as
smoothly as possible.
-->
<sect><heading>What is FreeBSD-stable?</heading>
<p>FreeBSD-stable is our development branch for a more low-key and
conservative set of changes intended for our next mainstream release.
Changes of an experimental or untested nature do not go into this
branch (see <ref id="current" name="FreeBSD-current">).
<sect><heading>Who needs FreeBSD-stable?</heading>
<p>If you are a commercial user or someone who puts maximum stability of
their FreeBSD system before all other concerns, you should consider tracking
<em>stable</em>. This is especially true if you have installed the most
recent release (<htmlurl url="ftp://ftp.freebsd.org/pub/FreeBSD/2.1.0-RELEASE"
name="2.1.0-RELEASE"> at the time of this writing) since the <em>stable</em>
branch is effectively a bug-fix stream relative to the previous release.
<p>Please note that the <em>stable</em> tree endevors, above all, to
be fully compilable and stable at all times, but we do occasionally
make mistakes (these are still active sources with quickly-transmitted
updates, after all). We also do our best to thoroughly test fixes in
<em>current</em> before bringing them into <em>stable</em>, but sometimes
our tests fail to catch every case. If something breaks for you in
<em>stable</em>, please let us know <em>immediately!</em> (see
next section).
<sect><heading>Using FreeBSD-stable</heading>
<p><enum><item> Join the freebsd-stable mailing list. This will
keep you informed of build-dependencies that may appear in
<em>stable</em> or any other issues requring special attention.
Developers will also make announcements in this mailing list when
they are contemplating some contraversal fix or update, giving
the users a chance to respond if they have any issues to raise concerning
the proposed change.
To join this list, send mail to &a.majordomo and say:
<verb>
subscribe freebsd-stable
</verb>
In the body of your message. Optionally, you can also say `help'
and Majordomo will send you full help on how to subscribe and
unsubscribe to the various other mailing lists we support.
<item> Grab the sources from ftp.FreeBSD.ORG. You can do this in
three ways:
<enum>
<item> Using the CTM facility described below. Unless you
have a good TCP/IP connection at a flat rate, this is
the way to do it.
<item> Use the CMU `sup' program (Software Update
Protocol), also described below.
This is the second most recommended method, since it allows
you to grab the entire collection once and then only what has
changed from then on. Many people run sup from cron
and keep their sources up-to-date automatically.
<item> Use ftp. The source tree for FreeBSD-stable is always
"exported" on:
<htmlurl url="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-stable"
name="ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-stable">
<p>We also use `wu-ftpd' which allows compressed/tar'd grabbing
of whole trees. e.g. you see:
<verb>
usr.bin/lex
</verb>
You can do:
<verb>
ftp> cd usr.bin
ftp> get lex.tar.Z
</verb>
And it will get the whole directory for you as a compressed
tar file.
</enum>
<item> Essentially, if you need rapid on-demand access to the source and
communications bandwidth is not a consideration, use sup or ftp.
Otherwise, use CTM.
<item> Before compiling stable, read the Makefile in /usr/src
carefully. You should at least run a `make world' the first time
through as part of the upgrading process.
Reading freebsd-stable will keep you up-to-date on other bootstrapping
procedures that sometimes become necessary as we move towards the next
release.
</enum>

21
handbook/synching.sgml Normal file
View file

@ -0,0 +1,21 @@
<!-- $Id: synching.sgml,v 1.1 1996-02-11 00:16:20 jkh Exp $ -->
<!-- The FreeBSD Documentation Project -->
<chapt><heading>Synchronizing source trees over the Internet<label id="synching"></heading>
<p><em>Contributed by &a.jkh;.</em>
<!--
Last updated: $Date: 1996-02-11 00:16:20 $
This document tries to describe the various ways in which a user may
use the internet to keep development sources in synch.
-->
<p>There are various ways of using an Internet (or email) connection
to stay up-to-date with whatever collection of FreeBSD project sources
it is that interests you. The primary services we offer are:
&sup;
&ctm;

1108
handbook/uart.sgml Normal file
View file

File diff suppressed because it is too large Load diff