amdref.texinfo

早期freebsd实现

* Key Lookup::
* Location Format::
@end menu

@node     Map Types, Key Lookup, Mount Maps, Mount Maps
@comment  node-name,  next,  previous,  up
@section Map Types
@cindex Mount map types
@cindex Map types
@cindex Configuration map types
@cindex Types of mount map
@cindex Types of configuration map
@cindex Determining the map type

A mount-map provides the run-time configuration information to @i{Amd}.
Maps can be implemented in many ways.  Some of the forms supported by
@i{Amd} are regular files, ndbm databases, NIS maps the @dfn{Hesiod}
name server and even the password file.

A mount-map @dfn{name} is a sequence of characters.  When an automount
point is created a handle on the mount-map is obtained.  For each map
type configured @i{Amd} attempts to reference the a map of the
appropriate type.  If a map is found, @i{Amd} notes the type for future
use and deletes the reference, for example closing any open file
descriptors.  The available maps are configure when @i{Amd} is built and
can be displayed by running the command @samp{amd -v}.

By default, @i{Amd} caches data in a mode dependent on the type of map.
This is the same as specifying @samp{cache:=mapdefault} and selects a
suitable default cache mode depending on the map type.  The individual
defaults are described below.  The @var{cache} option can be specified
on automount points to alter the caching behaviour (@pxref{Automount
Filesystem}).@refill

The following map types have been implemented, though some are not
available on all machines.  Run the command @samp{amd -v} to obtain a
list of map types configured on your machine.

@menu
* File maps::
* ndbm maps::
* NIS maps::
* Hesiod maps::
* Password maps::
* Union maps::
@end menu

@node     File maps, ndbm maps, Map Types, Map Types
@comment  node-name,  next,  previous,  up
@subsection File maps
@cindex File maps
@cindex Flat file maps
@cindex File map syntactic conventions

When @i{Amd} searches a file for a map entry it does a simple scan of
the file and supports both comments and continuation lines.

Continuation lines are indicated by a backslash character (@samp{\}) as
the last character of a line in the file.  The backslash, newline character
@emph{and any leading white space on the following line} are discarded.  A maximum
line length of 2047 characters is enforced after continuation lines are read
but before comments are stripped.  Each line must end with
a newline character; that is newlines are terminators, not separators.
The following examples illustrate this:

@example
key     valA   valB;   \
          valC
@end example

specifies @emph{three} locations, and is identical to

@example
key     valA   valB;   valC
@end example

However,

@example
key     valA   valB;\
          valC
@end example

specifies only @emph{two} locations, and is identical to

@example
key     valA   valB;valC
@end example

After a complete line has been read from the file, including
continuations, @i{Amd} determines whether there is a comment on the
line.  A comment begins with a hash (``@samp{#}'') character and
continues to the end of the line.  There is no way to escape or change
the comment lead-in character.

Note that continuation lines and comment support @dfn{only} apply to
file maps, or ndbm maps built with the @code{mk-amd-map} program.

When caching is enabled, file maps have a default cache mode of
@code{all} (@pxref{Automount Filesystem}).

@node     ndbm maps, NIS maps, File maps, Map Types
@comment  node-name,  next,  previous,  up
@subsection ndbm maps
@cindex ndbm maps

An ndbm map may be used as a fast access form of a file map.  The program,
@code{mk-amd-map}, converts a normal map file into an ndbm database.
This program supports the same continuation and comment conventions that
are provided for file maps.  Note that ndbm format files may @emph{not}
be sharable across machine architectures.  The notion of speed generally
only applies to large maps; a small map, less than a single disk block,
is almost certainly better implemented as a file map.

ndbm maps do not support cache mode @samp{all} and, when caching is
enabled, have a default cache mode of @samp{inc} (@pxref{Automount Filesystem}).

@node     NIS maps, Hesiod maps, ndbm maps, Map Types
@comment  node-name,  next,  previous,  up
@subsection NIS maps
@cindex NIS (YP) maps

When using NIS (formerly YP), an @i{Amd} map is implemented directly
by the underlying NIS map.  Comments and continuation lines are
@emph{not} supported in the automounter and must be stripped when
constructing the NIS server's database.

NIS maps do not support cache mode @code{all} and, when caching is
enabled, have a default cache mode of @code{inc} (@pxref{Automount Filesystem}).

The following rule illustrates what could be added to your NIS @file{Makefile},
in this case causing the @file{amd.home} map to be rebuilt:
@example
$(YPTSDIR)/amd.home.time: $(ETCDIR)/amd.home
        -@@sed -e "s/#.*$$//" -e "/^$$/d" $(ETCDIR)/amd.home | \
          awk '@{  \
                 for (i = 1; i <= NF; i++) \
                     if (i == NF) @{ \
                         if (substr($$i, length($$i), 1) == "\\") \
                             printf("%s", substr($$i, 1, length($$i) - 1)); \
                         else \
                             printf("%s\n", $$i); \
                     @} \
                     else \
                         printf("%s ", $$i); \
             @}' | \
        $(MAKEDBM) - $(YPDBDIR)/amd.home; \
        touch $(YPTSDIR)/amd.home.time; \
        echo "updated amd.home"; \
        if [ ! $(NOPUSH) ]; then \
                $(YPPUSH) amd.home; \
                echo "pushed amd.home"; \
        else \
                : ; \
        fi
@end example

Here @code{$(YPTSDIR)} contains the time stamp files, and @code{$(YPDBDIR)} contains
the dbm format NIS files.

@node     Hesiod maps, Password maps, NIS maps, Map Types
@comment  node-name,  next,  previous,  up
@subsection Hesiod maps
@cindex Hesiod maps

When the map name begins with the string @samp{hesiod.} lookups are made
using the @dfn{Hesiod} name server.  The string following the dot is
used as a name qualifier and is prepended with the key being located.
The entire string is then resolved in the @code{automount} context.  For
example, if the the key is @samp{jsp} and map name is
@samp{hesiod.homes} then @dfn{Hesiod} is asked to resolve
@samp{jsp.homes.automount}.

Hesiod maps do not support cache mode @samp{all} and, when caching is
enabled, have a default cache mode of @samp{inc} (@pxref{Automount Filesystem}).

The following is an example of a @dfn{Hesiod} map entry:

@example
jsp.homes.automount HS TXT "rfs:=/home/charm;rhost:=charm;sublink:=jsp"
njw.homes.automount HS TXT "rfs:=/home/dylan/dk2;rhost:=dylan;sublink:=njw"
@end example

@node     Password maps, Union maps, Hesiod maps, Map Types
@comment  node-name,  next,  previous,  up
@subsection Password maps
@cindex Password file maps
@cindex /etc/passwd maps
@cindex User maps, automatic generation
@cindex Automatic generation of user maps
@cindex Using the password file as a map

The password map support is unlike the four previous map types.  When
the map name is the string @file{/etc/passwd} @i{Amd} can lookup a user
name in the password file and re-arrange the home directory field to
produce a usable map entry.

@i{Amd} assumes the home directory has the format
`@t{/}@i{anydir}@t{/}@i{dom1}@t{/../}@i{domN}@t{/}@i{login}'.
@c @footnote{This interpretation is not necessarily exactly what you want.}
It breaks this string into a map entry where @code{$@{rfs@}} has the
value `@t{/}@i{anydir}@t{/}@i{domN}', @code{$@{rhost@}} has the value
`@i{domN}@t{.}@i{...}@t{.}@i{dom1}', and @code{$@{sublink@}} has the
value @samp{login}.@refill

Thus if the password file entry was

@example
/home/achilles/jsp
@end example

the map entry used by @i{Amd} would be

@example
rfs:=/home/achilles;rhost:=achilles;sublink:=jsp
@end example

Similarly, if the password file entry was

@example
/home/cc/sugar/mjh
@end example

the map entry used by @i{Amd} would be 

@example
rfs:=/home/sugar;rhost:=sugar.cc;sublink:=jsp
@end example

@node     Union maps, , Password maps, Map Types
@comment  node-name,  next,  previous,  up
@subsection Union maps
@cindex Union file maps

The union map support is provided specifically for use with the union
filesystem, @pxref{Union Filesystem}.

It is identified by the string @samp{union:} which is followed by a
colon separated list of directories.  The directories are read in order,
and the names of all entries are recorded in the map cache.  Later
directories take precedence over earlier ones.  The union filesystem
type then uses the map cache to determine the union of the names in all
the directories.

@c subsection Gdbm

@node     Key Lookup, Location Format, Map Types, Mount Maps
@comment  node-name,  next,  previous,  up
@section How keys are looked up
@cindex Key lookup
@cindex Map lookup
@cindex Looking up keys
@cindex How keys are looked up
@cindex Wildcards in maps

The key is located in the map whose type was determined when the
automount point was first created.  In general the key is a pathname
component.  In some circumstances this may be modified by variable
expansion (@pxref{Variable Expansion}) and prefixing.  If the automount
point has a prefix, specified by the @var{pref} option, then that is
prepended to the search key before the map is searched.

If the map cache is a @samp{regexp} cache then the key is treated as an
egrep-style regular expression, otherwise a normal string comparison is
made.

If the key cannot be found then a @dfn{wildcard} match is attempted.
@i{Amd} repeatedly strips the basename from the key, appends @samp{/*} and
attempts a lookup.  Finally, @i{Amd} attempts to locate the special key @samp{*}.

@group
For example, the following sequence would be checked if @file{home/dylan/dk2} was
being located:

@example
   home/dylan/dk2
   home/dylan/*
   home/*
   *
@end example
@end group

At any point when a wildcard is found, @i{Amd} proceeds as if an exact
match had been found and the value field is then used to resolve the
mount request, otherwise an error code is propagated back to the kernel.
(@pxref{Filesystem Types}).@refill

@node     Location Format, , Key Lookup, Mount Maps
@comment  node-name,  next,  previous,  up
@section Location Format
@cindex Location format
@cindex Map entry format
@cindex How locations are parsed

The value field from the lookup provides the information required to
mount a filesystem.  The information is parsed according to the syntax
shown below.

@display
@i{location-list}:
                  @i{location-selection}
                  @i{location-list} @i{white-space} @t{||} @i{white-space} @i{location-selection}
@i{location-selection}:
                  @i{location}
                  @i{location-selection} @i{white-space} @i{location}
@i{location}:
                  @i{location-info}
                  @t{-}@i{location-info}
                  @t{-}
@i{location-info}:
                  @i{sel-or-opt}
                  @i{location-info}@t{;}@i{sel-or-opt}
                  @t{;}
@i{sel-or-opt}:
                  @i{selection}
                  @i{opt-ass}
@i{selection}:
                  selector@t{==}@i{value}
                  selector@t{!=}@i{value}
@i{opt-ass}:
                  option@t{:=}@i{value}
@i{white-space}:
                  space
                  tab
@end display

Note that unquoted whitespace is not allowed in a location description.
White space is only allowed, and is mandatory, where shown with non-terminal
@samp{white-space}.