1 files changed, 0 insertions, 177 deletions
diff --git a/sbin/mount_umap/umap_manual b/sbin/mount_umap/umap_manual
deleted file mode 100644
index 4fcae246af2..00000000000
--- a/sbin/mount_umap/umap_manual
+++ /dev/null
@@ -1,177 +0,0 @@
-%	$OpenBSD: umap_manual,v 1.3 2002/06/09 08:13:08 todd Exp $
-%	$NetBSD: umap_manual,v 1.2 1995/03/18 14:58:19 cgd Exp $
-
-\appendix
-\section{The umap Layer} \label{sect:umap}
-
-\subsection{Introduction}
-
-Normally, the file system is expected to span a single administrative domain.
-An administrative domain, for these purposes, is a machine or set of
-machines that share common password file information, usually through
-the yellow pages mechanism.  File hierarchies that span more
-than one domain leads to certain problems, since the same numerical
-UID in one domain may correspond to a different user in another domain.
-If the system administrator is very careful to ensure that both domains
-contain identical user ID information, The umap layer can be used to
-run between those domains without changes
-
-The umap layer is a file system layer that sits on top of the normal
-file layer.  The umap layer maps Unix-style UIDs from
-one domain into the UIDs in the other domain.  By setting up the mappings
-properly, the same user with different UIDs in two domains can be seen
-as the same user, from the system point of view, or, conversely, two
-different users with the same UID in the two domains can be distinguished.
-
-First, we define some terms.  ``User'' refers to the human (or daemon) that
-has privileges to login, run programs, and access files.  ``UID''refers to
-the numerical identifier that uniquely identifies the user within a
-single domain.  ``Login name'' refers to the character string the user
-types to log into the system.  ``GID'' refers to the numerical group
-identifier used by Unix systems to identify groups of users.  ``Group
-name'' is the character string name attached to a particular GID in the
-local {\sf /etc/groups} file or the yellow pages groups file.
-
-In order for the umap layer to work properly, all users
-in either domain must have password file entries in both domains.
-They do not, however, have to have the same numerical UID, nor even the
-same character string login name (the latter is highly recommended,
-if possible, however).  Any user not having a UID in one domain will be
-treated as the special user NOBODY by the other domain, probably with
-undesirable consequences.  Any user not owning any files in the shared
-sub-trees need not be given a UID in the other domain.
-
-Groups work similarly.  The umap layer can translate group ID's between
-domains in the same manner as UID's.  Again, any group that wishes to
-participate must have a group ID in both domains,
-though it need not be the same GID in both.  If a group in one domain is not
-known in the other domain, that group will be treated as being NULLGROUP.
-The umap layer has no provisions for enrolling UID's from other domains
-as group members, but, since each user from each domain must have some
-UID in every domain, the UID in the local domain can be used to enroll
-the user in the local groups.
-
-NOBODY and NULLGROUP are special reserved UID's and GID's, respectively.
-NOBODY is user 32767.  NULLGROUP is group 65534.  If the system administrator
-wants to have an appropriate text string appear when these UID's are
-encountered by programs like {\sf ls -l}, he should add these values to
-the password and {\sf /etc/groups} file, or to the appropriate yellow pages.
-If these IDs are already in use in that domain, different values can be
-used for NOBODY and NULLGROUP, but that will require a recompilation of
-the umap layer code and, as a result, the entire kernel.  These
-values are defined in the {\sf umap\_info.h} file, kept with the rest of the
-umap source code.
-
-When the umap layer is in use, one of the participating domains is declared
-to be the master.  All UID and GID information stored for participating files
-will be stored in vnodes using its mappings, no matter what site the copies of
-the files are stored at.  The master domain therefore need not run a copy
-of the umap layer, as it already has all of the correct mappings.  All
-other domains must run a umap layer on top of any other layers they use.
-
-\subsection{Setting Up a umap Layer}
-
-The system administrator of a system needing to use the umap layer
-must take several actions.
-First, he must create files containing the necessary UID
-and GID mappings.  There is a separate file for user and group IDs.  The
-format of the files is the same.  The first line contains the total number
-of entries in the file.  Each subsequent line contains one mapping.  A
-mapping line consists of two numerical UIDs, separated by white space.
-The first is the UID of a user on the local machine.  The second is the
-UID for the same user on the master machine.  The maximum number of users
-that can be mapped for a single shared sub-tree is 64.  The maximum number of
-groups that can be mapped for a single sub-tree is 16.  These constants
-are set in the {\sf umap\_info.h} file, and can be changed, but changing them
-requires recompilation.  Separate mapping files can be used for each shared
-subtree, or the same mapping files can be shared by several sub-trees.
-
-Below is a sample UID mapping file.  There are four entries.  UID 5 is mapped
-to 5, 521 to 521, and 7000 to 7000.  UID 2002 is mapped to 604.  On this
-machine, the UID's for users 5, 521, and 7000 are the same as on the master,
-but UID 2002 is for a user whose UID on the master machine is 604.  All
-files in the sub-tree belonging to that user have UID 604 in their inodes,
-even on this machine, but the umap layer will ensure that anyone running
-under UID 2002 will have all files in this sub-tree owned by 604 treated as if
-they were owned by 2002.  An {\sf ls -l} on a file owned by 604 in this sub-tree
-will show the login name associated with UID 2002 as the owner.
-
-\noindent4\newline
-5 5\newline
-521 521\newline
-2002 604\newline
-7000 7000\newline
-
-The user and group mapping files should be owned by the root user, and
-should be writable only by that user.  If they are not owned by root, or
-are writable by some other user, the umap mounting command will abort.
-
-Normally, the sub-treeis grafted directly into the place in
-the file hierarchy where the it should appear to users.Using the umap
-layer requires that the sub-tree be grafted somewhere else, and
-the umap layer be mounted in the desired position in the file hierarchy.
-Depending on the situation, the underlying sub-tree can be wherever is
-convenient.
-
-\subsection{Troubleshooting umap Layer Problems}
-
-The umap layer code was not built with special convenience or
-robustness in mind, as it is expected to be superseded with a better
-user ID mapping strategy in the near future.  As a result, it is not
-very forgiving of errors in being set up.  Here are some possible
-problems, and what to do about them.
-
-\begin{itemize}
-
-
-\item{Problem: A file belongs to NOBODY, or group NULLGROUP.
-
-Fixes: The mapping files don't know about this file's real user or group.
-Either they are not in the mapping files, or the counts on the number of
-entries in the mapping files are too low, so entries at the end (including
-these) are being ignored.  Add the entries or fix the counts, and either
-unmount and remount the sub-tree, or reboot.}
-
-\item{Problem: A normal operation does not work.
-
-Fixes: Possibly, some mapping has not been set properly.  Check to
-see which files are used by the operation and who they appear to be
-owned by.  If they are owned by NOBODY or some other suspicious user,
-there may be a problem in the mapping files.  Be sure to check groups,
-too.  As above, if the counts of mappings in the mapping files are lower
-than the actual numbers of pairs, pairs at the end of the file will be
-ignored.  If any changes are made in the mapping files, you will need to
-either unmount and remount or reboot before they will take effect.
-
-Another possible problem can arise because not all Unix utilities
-rely exclusively on numeric UID for identification.  For instance,
-SCCS saves the login name in files.  If a user's login name on two machines
-isn't the same, SCCS may veto an operation even though Unix file permissions,
-as checked by the umap layer, may say it's OK.  There's not much to be
-done in such cases, unless the login name can be changed or one fiddles
-improperly with SCCS information.  There may be other, undiscovered cases
-where similar problems arise, some of which may be even harder to handle.}
-
-\item{Problem: Someone has access permissions he should not have.
-
-Fixes: This is probably caused by a mistake in the mapping files.  Check
-both user and group mapping files.  If any changes are made in the mapping
-files, you will need to unmount and remount the sub-tree or reboot before they
-will take effect.}
-
-\item{Problem: {\sf ls -l} (or a similar program) shows the wrong user for a file.
-
-Fixes: Probably a mistake in the mapping files.  In particular, if
-two local UIDs are mapped to a single master UID, stat calls will assign
-ownership to the first local UID occurring in the file, which may or may
-not be what was intended.  (Generally speaking, mapping two local UIDs to
-a single master UID is a bad idea, but the software will not prevent it.
-Similarly, mapping a single local UID to two master UIDs is a bad idea,
-but will not be prevented.  In this case, only the first mapping of the
-local UID will be done.  The second, and all subsequent ones, will be
-ignored.) If any changes are made in the mapping files, you will need to
-unmount and remount the sub-tree or reboot before they will take effect.}
-
-\end{itemize}
-
-\end{document}