This is am-utils.info, produced by makeinfo version 4.1 from am-utils.texi. START-INFO-DIR-ENTRY * Am-utils: (am-utils). The Amd automounter suite of utilities END-INFO-DIR-ENTRY  File: am-utils.info, Node: Network Host Filesystem, Next: Network Filesystem Group, Prev: Network Filesystem, Up: Filesystem Types Network Host Filesystem (`host') ================================ The "host" (`type:=host') filesystem allows access to the entire export tree of an NFS server. The implementation is layered above the `nfs' implementation so keep-alives work in the same way. The only option which needs to be specified is `rhost' which is the name of the fileserver to mount. The `host' filesystem type works by querying the mount daemon on the given fileserver to obtain its export list. Amd then obtains filehandles for each of the exported filesystems. Any errors at this stage cause that particular filesystem to be ignored. Finally each filesystem is mounted. Again, errors are logged but ignored. One common reason for mounts to fail is that the mount point does not exist. Although Amd attempts to automatically create the mount point, it may be on a remote filesystem to which Amd does not have write permission. When an attempt to unmount a `host' filesystem mount fails, Amd remounts any filesystems which had successfully been unmounted. To do this Amd queries the mount daemon again and obtains a fresh copy of the export list. Amd then tries to mount any exported filesystems which are not currently mounted. Sun's automounter provides a special `-hosts' map. To achieve the same effect with Amd requires two steps. First a mount map must be created as follows: * type:=host;rhost:=${key};fs:=${autodir}/${rhost}/root and then start Amd with the following command amd /net net.map where `net.map' is the name of map described above. Note that the value of `${fs}' is overridden in the map. This is done to avoid a clash between the mount tree and any other filesystem already mounted from the same fileserver. If different mount options are needed for different hosts then additional entries can be added to the map, for example host2 opts:=ro,nosuid,soft would soft mount `host2' read-only.  File: am-utils.info, Node: Network Filesystem Group, Next: Unix Filesystem, Prev: Network Host Filesystem, Up: Filesystem Types Network Filesystem Group (`nfsx') ================================= The "nfsx" (`type:=nfsx') filesystem allows a group of filesystems to be mounted from a single NFS server. The implementation is layered above the `nfs' implementation so keep-alives work in the same way. The options are the same as for the `nfs' filesystem with one difference. The following options should be specified: `rhost' the remote fileserver. The default value is taken from the local host name (`${host}') if no other value is specified. `rfs' is a list of filesystems to mount, and must be specified. The list is in the form of a comma separated strings. For example: pub type:=nfsx;rhost:=gould;\ rfs:=/public,/,graphics,usenet;fs:=${autodir}/${rhost}/root The first string defines the root of the tree, and is applied as a prefix to the remaining members of the list which define the individual filesystems. The first string is _not_ used as a filesystem name. A parallel operation is used to determine the local mount points to ensure a consistent layout of a tree of mounts. Here, the _three_ filesystems, `/public', `/public/graphics' and `/public/usenet', would be mounted. A local mount point, `${fs}', _must_ be specified. The default local mount point will not work correctly in the general case. A suggestion is to use `fs:=${autodir}/${rhost}/root'.  File: am-utils.info, Node: Unix Filesystem, Next: Caching Filesystem, Prev: Network Filesystem Group, Up: Filesystem Types Unix Filesystem (`ufs', `xfs', or `efs') ======================================== The "ufs" (`type:=ufs') filesystem type provides access to the system's standard disk filesystem--usually a derivative of the Berkeley Fast Filesystem. The following option must be specified: `dev' the block special device to be mounted. A UFS entry might be: jsp host==charm;type:=ufs;dev:=/dev/sd0d;sublink:=jsp UFS is the default Unix disk-based file system, which Am-utils picks up during the autoconfiguration phase. Some systems have more than one type, such as IRIX, that comes with EFS (Extent File System) and XFS (Extended File System). In those cases, you may explicitly set the file system type, by using entries such: ez1 type:=efs;dev:=/dev/xd0a ez2 type:=xfs;dev:=/dev/sd3c  File: am-utils.info, Node: Caching Filesystem, Next: CD-ROM Filesystem, Prev: Unix Filesystem, Up: Filesystem Types Caching Filesystem (`cachefs') ============================== The "cachefs" (`type:=cachefs') filesystem caches files from one location onto another, presumably providing faster access. It is particularly useful to cache from a larger and remote (slower) NFS partition to a smaller and local (faster) UFS directory. The following options must be specified: `cachedir' the directory where the cache is stored. `rfs' the path name to the "back file system" to be cached from. `fs' the "front file system" mount point to the cached files, where Amd will set a symbolic link pointing to. A CacheFS entry for, say, the `/import' Amd mount point, might be: copt type:=cachefs;cachedir:=/cache;rfs:=/import/opt;fs:=/n/import/copt Access to the pathname `/import/copt' will follow a symbolic link to `/n/import/copt'. The latter is the mount point for a caching file system, that caches from `/import/opt' to `/cache'. Caveats: 1. This file system is currently only implemented for Solaris 2.x! 2. Before being used for the first time, the cache directory must be initialized with `cfsadmin -c CACHEDIR'. See the manual page for cfsadmin(1M) for more information. 3. The "back file system" mounted must be a complete file system, not a subdirectory thereof; otherwise you will get an error "Invalid Argument". 4. If Amd aborts abnormally, the state of the cache may be inconsistent, requiring running the command `fsck -F cachefs CACHEDIR'. Otherwise you will get the error "No Space Left on Device".  File: am-utils.info, Node: CD-ROM Filesystem, Next: Loopback Filesystem, Prev: Caching Filesystem, Up: Filesystem Types CD-ROM Filesystem (`cdfs') ========================== The "cdfs" (`type:=cdfs') filesystem mounts a CD-ROM with an ISO9660 format filesystem on it. The following option must be specified: `dev' the block special device to be mounted. Some operating systems will fail to mount read-only CDs unless the `ro' option is specified. A cdfs entry might be: cdfs os==sunos4;type:=cdfs;dev:=/dev/sr0 \ os==sunos5;addopts:=ro;type:=cdfs;dev:=/dev/dsk/c0t6d0s2  File: am-utils.info, Node: Loopback Filesystem, Next: Memory/RAM Filesystem, Prev: CD-ROM Filesystem, Up: Filesystem Types Loopback Filesystem (`lofs') ============================ The "lofs" (`type:=lofs') filesystem is also called the loopback filesystem. It mounts a local directory on another, thus providing mount-time binding to another location (unlike symbolic links). The loopback filesystem is particularly useful within the context of a chroot-ed directory (via chroot(2)), to provide access to directories otherwise inaccessible. The following option must be specified: `rfs' the pathname to be mounted on top of `${fs}'. Usually, the FTP server runs in a chroot-ed environment, for security reasons. In this example, lofs is used to provide a subdirectory within a user's home directory, also available for public ftp. lofs type:=lofs;rfs:=/home/ezk/myftpdir;fs:=/usr/ftp/pub/ezk  File: am-utils.info, Node: Memory/RAM Filesystem, Next: Null Filesystem, Prev: Loopback Filesystem, Up: Filesystem Types Memory/RAM Filesystem (`mfs') ============================= The "mfs" (`type:=mfs') filesystem is available in 4.4BSD, Linux, and other systems. It creates a filesystem in a portion of the system's memory, thus providing very fast file (volatile) access. XXX: THIS FILESYSTEM IS NOT IMPLEMENTED YET!  File: am-utils.info, Node: Null Filesystem, Next: Floppy Filesystem, Prev: Memory/RAM Filesystem, Up: Filesystem Types Null Filesystem (`nullfs') ========================== The "nullfs" (`type:=nullfs') filesystem is available from 4.4BSD, and is very similar to the loopback filesystem, "lofs". XXX: THIS FILESYSTEM IS NOT IMPLEMENTED YET!  File: am-utils.info, Node: Floppy Filesystem, Next: Translucent Filesystem, Prev: Null Filesystem, Up: Filesystem Types Floppy Filesystem (`pcfs') ========================== The "pcfs" (`type:=pcfs') filesystem mounts a floppy previously formatted for the MS-DOS format. The following option must be specified: `dev' the block special device to be mounted. A pcfs entry might be: pcfs os==sunos4;type:=pcfs;dev:=/dev/fd0 \ os==sunos5;type:=pcfs;dev:=/dev/diskette  File: am-utils.info, Node: Translucent Filesystem, Next: Shared Memory+Swap Filesystem, Prev: Floppy Filesystem, Up: Filesystem Types Translucent Filesystem (`tfs') ============================== The "tfs" (`type:=tfs') filesystem is an older version of the 4.4BSD "unionfs". XXX: THIS FILESYSTEM IS NOT IMPLEMENTED YET!  File: am-utils.info, Node: Shared Memory+Swap Filesystem, Next: User ID Mapping Filesystem, Prev: Translucent Filesystem, Up: Filesystem Types Shared Memory+Swap Filesystem (`tmpfs') ======================================= The "tmpfs" (`type:=tmpfs') filesystem shares memory between a the swap device and the rest of the system. It is generally used to provide a fast access `/tmp' directory, one that uses memory that is otherwise unused. This filesystem is available in SunOS 4.x and 5.x. XXX: THIS FILESYSTEM IS NOT IMPLEMENTED YET!  File: am-utils.info, Node: User ID Mapping Filesystem, Next: Program Filesystem, Prev: Shared Memory+Swap Filesystem, Up: Filesystem Types User ID Mapping Filesystem (`umapfs') ===================================== The "umapfs" (`type:=umapfs') filesystem maps User IDs of file ownership, and is available from 4.4BSD. XXX: THIS FILESYSTEM IS NOT IMPLEMENTED YET!  File: am-utils.info, Node: Program Filesystem, Next: Symbolic Link Filesystem, Prev: User ID Mapping Filesystem, Up: Filesystem Types Program Filesystem (`program') ============================== The "program" (`type:=program') filesystem type allows a program to be run whenever a mount or unmount is required. This allows easy addition of support for other filesystem types, such as MIT's Remote Virtual Disk (RVD) which has a programmatic interface via the commands `rvdmount' and `rvdunmount'. The following options must be specified: `mount' the program which will perform the mount. `unmount' the program which will perform the unmount. The exit code from these two programs is interpreted as a Unix error code. As usual, exit code zero indicates success. To execute the program Amd splits the string on whitespace to create an array of substrings. Single quotes `'' can be used to quote whitespace if that is required in an argument. There is no way to escape or change the quote character. To run the program `rvdmount' with a host name and filesystem as arguments would be specified by `fs:=${autodir}${path};mount:="/etc/rvdmount rvdmount fserver ${fs}"'. The first element in the array is taken as the pathname of the program to execute. The other members of the array form the argument vector to be passed to the program, "including argument zero". This means that the split string must have at least two elements. The program is directly executed by Amd, not via a shell. This means that scripts must begin with a `#!' interpreter specification. If a filesystem type is to be heavily used, it may be worthwhile adding a new filesystem type into Amd, but for most uses the program filesystem should suffice. When the program is run, standard input and standard error are inherited from the current values used by Amd. Standard output is a duplicate of standard error. The value specified with the `-l' command line option has no effect on standard error.  File: am-utils.info, Node: Symbolic Link Filesystem, Next: Symbolic Link Filesystem II, Prev: Program Filesystem, Up: Filesystem Types Symbolic Link Filesystem (`link') ================================= Each filesystem type creates a symbolic link to point from the volume name to the physical mount point. The `link' filesystem does the same without any other side effects. This allows any part of the machines name space to be accessed via Amd. One common use for the symlink filesystem is `/homes' which can be made to contain an entry for each user which points to their (auto-mounted) home directory. Although this may seem rather expensive, it provides a great deal of administrative flexibility. The following option must be defined: `fs' The value of FS option specifies the destination of the link, as modified by the SUBLINK option. If SUBLINK is non-null, it is appended to `${fs}'`/' and the resulting string is used as the target. The `link' filesystem can be thought of as identical to the `ufs' filesystem but without actually mounting anything. An example entry might be: jsp host==charm;type:=link;fs:=/home/charm;sublink:=jsp which would return a symbolic link pointing to `/home/charm/jsp'.  File: am-utils.info, Node: Symbolic Link Filesystem II, Next: NFS-Link Filesystem, Prev: Symbolic Link Filesystem, Up: Filesystem Types Symbolic Link Filesystem II (`linkx') ===================================== The "linkx" (`type:=linkx') filesystem type is identical to `link' with the exception that the target of the link must exist. Existence is checked with the lstat(2) system call. The `linkx' filesystem type is particularly useful for wildcard map entries. In this case, a list of possible targets can be given and Amd will choose the first one which exists on the local machine.  File: am-utils.info, Node: NFS-Link Filesystem, Next: Automount Filesystem, Prev: Symbolic Link Filesystem II, Up: Filesystem Types NFS-Link Filesystem (`nfsl') ============================ The "nfsl" (`type:=nfsl') filesystem type is a combination of two others: `link' and `nfs'. If the local host name is equal to the value of `${rhost}', or if the target pathname listed in `${fs}' exists, `nfsl' will behave exactly as `type:=link', and refer to the target as a symbolic link. If the local host name is not equal to the value of `${rhost}', or if the target of the link does not exist, Amd will treat it as `type:=nfs', and will mount a remote pathname for it. The `nfsl' filesystem type is particularly useful as a shorthand for the more cumbersome and yet one of the most popular Amd entries. For example, you can simplify all map entries that look like: zing -fs:=/n/shekel/u/zing \ host!=shekel;type:=nfs;rhost:=shekel;rfs:=${fs} \ host==shekel;type:=link or zing -fs:=/n/shekel/u/zing \ exists(${fs});type:=link \ !exists(${fs});type:=nfs;rhost:=shekel;rfs:=${fs} into a shorter form zing type:=nfsl;fs:=/n/shekel/u/zing;rhost:=shekel;rfs:=${fs} Not just does it make the maps smaller and simpler, but it avoids possible mistakes that often happen when forgetting to set up the two entries (one for `type:=nfs' and the other for `type:=link') necessary to perform transparent mounts of existing or remote mounts.  File: am-utils.info, Node: Automount Filesystem, Next: Direct Automount Filesystem, Prev: NFS-Link Filesystem, Up: Filesystem Types Automount Filesystem (`auto') ============================= The "auto" (`type:=auto') filesystem type creates a new automount point below an existing automount point. Top-level automount points appear as system mount points. An automount mount point can also appear as a sub-directory of an existing automount point. This allows some additional structure to be added, for example to mimic the mount tree of another machine. The following options may be specified: `cache' specifies whether the data in this mount-map should be cached. The default value is `none', in which case no caching is done in order to conserve memory. However, better performance and reliability can be obtained by caching some or all of a mount-map. If the cache option specifies `all', the entire map is enumerated when the mount point is created. If the cache option specifies `inc', caching is done incrementally as and when data is required. Some map types do not support cache mode `all', in which case `inc' is used whenever `all' is requested. Caching can be entirely disabled by using cache mode `none'. If the cache option specifies `regexp' then the entire map will be enumerated and each key will be treated as an egrep-style regular expression. The order in which a cached map is searched does not correspond to the ordering in the source map so the regular expressions should be mutually exclusive to avoid confusion. Each mount map type has a default cache type, usually `inc', which can be selected by specifying `mapdefault'. The cache mode for a mount map can only be selected on the command line. Starting Amd with the command: amd /homes hesiod.homes -cache:=inc will cause `/homes' to be automounted using the "Hesiod" name server with local incremental caching of all successfully resolved names. All cached data is forgotten whenever Amd receives a `SIGHUP' signal and, if cache `all' mode was selected, the cache will be reloaded. This can be used to inform Amd that a map has been updated. In addition, whenever a cache lookup fails and Amd needs to examine a map, the map's modify time is examined. If the cache is out of date with respect to the map then it is flushed as if a `SIGHUP' had been received. An additional option (`sync') may be specified to force Amd to check the map's modify time whenever a cached entry is being used. For example, an incremental, synchronized cache would be created by the following command: amd /homes hesiod.homes -cache:=inc,sync `fs' specifies the name of the mount map to use for the new mount point. Arguably this should have been specified with the `${rfs}' option but we are now stuck with it due to historical accident. `pref' alters the name that is looked up in the mount map. If `${pref}', the "prefix", is non-null then it is prepended to the name requested by the kernel "before" the map is searched. `opts' Normally, `auto' style maps are not browsable even if you turn on directory browsability (*note browsable_dirs Parameter::). To enable browsing entries in `auto' maps, specify `opts:=browsable' in the description of this map. The server `dylan.doc.ic.ac.uk' has two user disks: `/dev/dsk/2s0' and `/dev/dsk/5s0'. These are accessed as `/home/dylan/dk2' and `/home/dylan/dk5' respectively. Since `/home' is already an automount point, this naming is achieved with the following map entries: dylan type:=auto;fs:=${map};pref:=${key}/ dylan/dk2 type:=ufs;dev:=/dev/dsk/2s0 dylan/dk5 type:=ufs;dev:=/dev/dsk/5s0  File: am-utils.info, Node: Direct Automount Filesystem, Next: Union Filesystem, Prev: Automount Filesystem, Up: Filesystem Types Direct Automount Filesystem (`direct') ====================================== The "direct" (`type:=direct') filesystem is almost identical to the automount filesystem. Instead of appearing to be a directory of mount points, it appears as a symbolic link to a mounted filesystem. The mount is done at the time the link is accessed. *Note Automount Filesystem::, for a list of required options. Direct automount points are created by specifying the `direct' filesystem type on the command line: amd ... /usr/man auto.direct -type:=direct where `auto.direct' would contain an entry such as: usr/man -type:=nfs;rfs:=/usr/man \ rhost:=man-server1 rhost:=man-server2 In this example, `man-server1' and `man-server2' are file servers which export copies of the manual pages. Note that the key which is looked up is the name of the automount point without the leading `/'.  File: am-utils.info, Node: Union Filesystem, Next: Error Filesystem, Prev: Direct Automount Filesystem, Up: Filesystem Types Union Filesystem (`union') ========================== The "union" (`type:=union') filesystem type allows the contents of several directories to be merged and made visible in a single directory. This can be used to overcome one of the major limitations of the Unix mount mechanism which only allows complete directories to be mounted. For example, supposing `/tmp' and `/var/tmp' were to be merged into a new directory called `/mtmp', with files in `/var/tmp' taking precedence. The following command could be used to achieve this effect: amd ... /mtmp union:/tmp:/var/tmp -type:=union Currently, the unioned directories must _not_ be automounted. That would cause a deadlock. This seriously limits the current usefulness of this filesystem type and the problem will be addressed in a future release of Amd. Files created in the union directory are actually created in the last named directory. This is done by creating a wildcard entry which points to the correct directory. The wildcard entry is visible if the union directory is listed, so allowing you to see which directory has priority. The files visible in the union directory are computed at the time Amd is started, and are not kept up-to-date with respect to the underlying directories. Similarly, if a link is removed, for example with the `rm' command, it will be lost forever.  File: am-utils.info, Node: Error Filesystem, Next: Top-level Filesystem, Prev: Union Filesystem, Up: Filesystem Types Error Filesystem (`error') ========================== The "error" (`type:=error') filesystem type is used internally as a catch-all in the case where none of the other filesystems was selected, or some other error occurred. Lookups and mounts always fail with "No such file or directory". All other operations trivially succeed. The error filesystem is not directly accessible.  File: am-utils.info, Node: Top-level Filesystem, Next: Root Filesystem, Prev: Error Filesystem, Up: Filesystem Types Top-level Filesystem (`toplvl') =============================== The "toplvl" (`type:=toplvl') filesystems is derived from the `auto' filesystem and is used to mount the top-level automount nodes. Requests of this type are automatically generated from the command line arguments.  File: am-utils.info, Node: Root Filesystem, Next: Inheritance Filesystem, Prev: Top-level Filesystem, Up: Filesystem Types Root Filesystem (`root') ======================== The "root" (`type:=root') filesystem type acts as an internal placeholder onto which Amd can pin `toplvl' mounts. Only one node of this type need ever exist and one is created automatically during startup. The effect of having more than one root node is undefined. The root filesystem is not directly accessible.  File: am-utils.info, Node: Inheritance Filesystem, Prev: Root Filesystem, Up: Filesystem Types Inheritance Filesystem (`inherit') ================================== The "inheritance" (`type:=inherit') filesystem is not directly accessible. Instead, internal mount nodes of this type are automatically generated when Amd is started with the `-r' option. At this time the system mount table is scanned to locate any filesystems which are already mounted. If any reference to these filesystems is made through Amd then instead of attempting to mount it, Amd simulates the mount and "inherits" the filesystem. This allows a new version of Amd to be installed on a live system simply by killing the old daemon with `SIGTERM' and starting the new one. This filesystem type is not generally visible externally, but it is possible that the output from `amq -m' may list `inherit' as the filesystem type. This happens when an inherit operation cannot be completed for some reason, usually because a fileserver is down.  File: am-utils.info, Node: Amd Configuration File, Next: Run-time Administration, Prev: Filesystem Types, Up: Top Amd Configuration File ********************** The `amd.conf' file is the configuration file for Amd, as part of the am-utils suite. This file contains runtime configuration information for the Amd automounter program. * Menu: * File Format:: * The Global Section:: * Regular Map Sections:: * Common Parameters:: * Global Parameters:: * Regular Map Parameters:: * amd.conf Examples::  File: am-utils.info, Node: File Format, Next: The Global Section, Prev: Amd Configuration File, Up: Amd Configuration File File Format =========== The `amd.conf' file consists of sections and parameters. A section begins with the name of the section in square brackets `[]' and continues until the next section begins or the end of the file is reached. Sections contain parameters of the form `name = value'. The file is line-based -- that is, each newline-terminated line represents either a comment, a section name or a parameter. No line-continuation syntax is available. Section names, parameter names and their values are case sensitive. Only the first equals sign in a parameter is significant. Whitespace before or after the first equals sign is discarded. Leading, trailing and internal whitespace in section and parameter names is irrelevant. Leading and trailing whitespace in a parameter value is discarded. Internal whitespace within a parameter value is not allowed, unless the whole parameter value is quoted with double quotes as in `name = "some value"'. Any line beginning with a pound sign `#' is ignored, as are lines containing only whitespace. The values following the equals sign in parameters are all either a string (no quotes needed if string does not include spaces) or a boolean, which may be given as `yes'/`no'. Case is significant in all values. Some items such as cache timeouts are numeric.  File: am-utils.info, Node: The Global Section, Next: Regular Map Sections, Prev: File Format, Up: Amd Configuration File The Global Section ================== The global section must be specified as `[global]'. Parameters in this section either apply to Amd as a whole, or to all other regular map sections which follow. There should be only one global section defined in one configuration file. It is highly recommended that this section be specified first in the configuration file. If it is not, then regular map sections which precede it will not use global values defined later.  File: am-utils.info, Node: Regular Map Sections, Next: Common Parameters, Prev: The Global Section, Up: Amd Configuration File Regular Map Sections ==================== Parameters in regular (non-global) sections apply to a single map entry. For example, if the map section `[/homes]' is defined, then all parameters following it will be applied to the `/homes' Amd-managed mount point.  File: am-utils.info, Node: Common Parameters, Next: Global Parameters, Prev: Regular Map Sections, Up: Amd Configuration File Common Parameters ================= These parameters can be specified either in the global or a map-specific section. Entries specified in a map-specific section override the default value or one defined in the global section. If such a common parameter is specified only in the global section, it is applicable to all regular map sections that follow. * Menu: * browsable_dirs Parameter:: * map_options Parameter:: * map_type Parameter:: * mount_type Parameter:: * search_path Parameter::  File: am-utils.info, Node: browsable_dirs Parameter, Next: map_options Parameter, Prev: Common Parameters, Up: Common Parameters browsable_dirs Parameter ------------------------ (type=string, default=`no'). If `yes', then Amd's top-level mount points will be browsable to readdir(3) calls. This means you could run for example ls(1) and see what keys are available to mount in that directory. Not all entries are made visible to readdir(3): the `/defaults' entry, wildcard entries, and those with a `/' in them are not included. If you specify `full' to this option, all but the `/defaults' entry will be visible. Note that if you run a command which will attempt to stat(2) the entries, such as often done by `ls -l' or `ls -F', Amd will attempt to mount every entry in that map. This is often called a "mount storm".  File: am-utils.info, Node: map_options Parameter, Next: map_type Parameter, Prev: browsable_dirs Parameter, Up: Common Parameters map_options Parameter --------------------- (type=string, default no options). This option is the same as specifying map options on the command line to Amd, such as `cache:=all'.  File: am-utils.info, Node: map_type Parameter, Next: mount_type Parameter, Prev: map_options Parameter, Up: Common Parameters map_type Parameter ------------------ (type=string, default search all map types). If specified, Amd will initialize the map only for the type given. This is useful to avoid the default map search type used by Amd which takes longer and can have undesired side-effects such as initializing NIS even if not used. Possible values are `file' plain files `hesiod' Hesiod name service from MIT `ldap' Lightweight Directory Access Protocol `ndbm' (New) dbm style hash files `nis' Network Information Services (version 2) `nisplus' Network Information Services Plus (version 3) `passwd' local password files `union' union maps  File: am-utils.info, Node: mount_type Parameter, Next: search_path Parameter, Prev: map_type Parameter, Up: Common Parameters mount_type Parameter -------------------- (type=string, default=`nfs'). All Amd mount types must be NFS. That is, Amd is an NFS server on the map mount points, for the local host it is running on. If `autofs' is specified, Amd will log an error message and forcibly convert it to NFS.  File: am-utils.info, Node: search_path Parameter, Prev: mount_type Parameter, Up: Common Parameters search_path Parameter --------------------- (type=string, default no search path). This provides a (colon-delimited) search path for file maps. Using a search path, sites can allow for local map customizations and overrides, and can distributed maps in several locations as needed.  File: am-utils.info, Node: Global Parameters, Next: Regular Map Parameters, Prev: Common Parameters, Up: Amd Configuration File Global Parameters ================= The following parameters are applicable to the `[global]' section only. * Menu: * arch Parameter:: * auto_dir Parameter:: * cache_duration Parameter:: * cluster Parameter:: * debug_options Parameter:: * dismount_interval Parameter:: * full_os Parameter:: * fully_qualified_hosts Parameter:: * hesiod_base Parameter:: * karch Parameter:: * ldap_base Parameter:: * ldap_cache_maxmem Parameter:: * ldap_cache_seconds Parameter:: * ldap_hostports Parameter:: * local_domain Parameter:: * log_file Parameter:: * log_options Parameter:: * nfs_proto Parameter:: * nfs_retransmit_counter Parameter:: * nfs_retry_interval Parameter:: * nfs_vers Parameter:: * nis_domain Parameter:: * normalize_hostnames Parameter:: * os Parameter:: * osver Parameter:: * pid_file Parameter:: * plock Parameter:: * portmap_program Parameter:: * print_pid Parameter:: * print_version Parameter:: * restart_mounts Parameter:: * selectors_in_defaults Parameter:: * show_statfs_entries Parameter:: * unmount_on_exit Parameter:: * vendor Parameter::  File: am-utils.info, Node: arch Parameter, Next: auto_dir Parameter, Prev: Global Parameters, Up: Global Parameters arch Parameter -------------- (type=string, default to compiled in value). Allows you to override the value of the arch Amd variable.  File: am-utils.info, Node: auto_dir Parameter, Next: cache_duration Parameter, Prev: arch Parameter, Up: Global Parameters auto_dir Parameter ------------------ (type=string, default=`/a'). Same as the `-a' option to Amd. This sets the private directory where Amd will create sub-directories for its real mount points.  File: am-utils.info, Node: cache_duration Parameter, Next: cluster Parameter, Prev: auto_dir Parameter, Up: Global Parameters cache_duration Parameter ------------------------ (type=numeric, default=300). Same as the `-c' option to Amd. Sets the duration in seconds that looked up map entries remain in the cache.  File: am-utils.info, Node: cluster Parameter, Next: debug_options Parameter, Prev: cache_duration Parameter, Up: Global Parameters cluster Parameter ----------------- (type=string, default no cluster). Same as the `-C' option to Amd. Specifies the alternate HP-UX cluster to use.  File: am-utils.info, Node: debug_options Parameter, Next: dismount_interval Parameter, Prev: cluster Parameter, Up: Global Parameters debug_options Parameter ----------------------- (type=string, default no debug options). Same as the `-D' option to Amd. Specify any debugging options for Amd. Works only if am-utils was configured for debugging using the `--enable-debug' option. The `mem' option, as well as all other options, can be turned on via `--enable-debug=mem'. Otherwise debugging options are ignored. Options are comma delimited, and can be preceded by the string `no' to negate their meaning. You can get the list of supported debugging and logging options by running `amd -H'. Possible values are: `all' all options `amq' register for amq `daemon' enter daemon mode `fork' fork server `full' program trace `mem' trace memory allocations `mtab' use local `./mtab' file `str' debug string munging `test' full debug but no daemon `trace' trace RPC protocol and NFS mount arguments  File: am-utils.info, Node: dismount_interval Parameter, Next: full_os Parameter, Prev: debug_options Parameter, Up: Global Parameters dismount_interval Parameter --------------------------- (type=numeric, default=120). Same as the `-w' option to Amd. Specify in seconds, the time between attempts to dismount file systems that have exceeded their cached times.  File: am-utils.info, Node: full_os Parameter, Next: fully_qualified_hosts Parameter, Prev: dismount_interval Parameter, Up: Global Parameters full_os Parameter ----------------- (type=string, default to compiled in value). The full name of the operating system, along with its version. Allows you to override the compiled-in full name and version of the operating system. Useful when the compiled-in name is not desired. For example, the full operating system name on linux comes up as `linux', but you can override it to `linux-2.2.5'.  File: am-utils.info, Node: fully_qualified_hosts Parameter, Next: hesiod_base Parameter, Prev: full_os Parameter, Up: Global Parameters fully_qualified_hosts Parameter ------------------------------- (type=string, default=`no'). If `yes', Amd will perform RPC authentication using fully-qualified host names. This is necessary for some systems, and especially when performing cross-domain mounting. For this function to work, the Amd variable `${hostd}' is used, requiring that `${domain}' not be null.  File: am-utils.info, Node: hesiod_base Parameter, Next: karch Parameter, Prev: fully_qualified_hosts Parameter, Up: Global Parameters hesiod_base Parameter --------------------- (type=string, default=`automount'). Specify the base name for hesiod maps.  File: am-utils.info, Node: karch Parameter, Next: ldap_base Parameter, Prev: hesiod_base Parameter, Up: Global Parameters karch Parameter --------------- (type=string, default to karch of the system). Same as the `-k' option to Amd. Allows you to override the kernel-architecture of your system. Useful for example on Sun (Sparc) machines, where you can build one Amd binary, and run it on multiple machines, yet you want each one to get the correct karch variable set (for example, sun4c, sun4m, sun4u, etc.) Note that if not specified, Amd will use uname(2) to figure out the kernel architecture of the machine.  File: am-utils.info, Node: ldap_base Parameter, Next: ldap_cache_maxmem Parameter, Prev: karch Parameter, Up: Global Parameters ldap_base Parameter ------------------- (type=string, default not set). Specify the base name for LDAP. This often includes LDAP-specific values such as country and organization.  File: am-utils.info, Node: ldap_cache_maxmem Parameter, Next: ldap_cache_seconds Parameter, Prev: ldap_base Parameter, Up: Global Parameters ldap_cache_maxmem Parameter --------------------------- (type=numeric, default=131072). Specify the maximum memory Amd should use to cache LDAP entries.  File: am-utils.info, Node: ldap_cache_seconds Parameter, Next: ldap_hostports Parameter, Prev: ldap_cache_maxmem Parameter, Up: Global Parameters ldap_cache_seconds Parameter ---------------------------- (type=numeric, default=0). Specify the number of seconds to keep entries in the cache.  File: am-utils.info, Node: ldap_hostports Parameter, Next: local_domain Parameter, Prev: ldap_cache_seconds Parameter, Up: Global Parameters ldap_hostports Parameter ------------------------ (type=string, default not set). Specify the LDAP host and port values.  File: am-utils.info, Node: local_domain Parameter, Next: log_file Parameter, Prev: ldap_hostports Parameter, Up: Global Parameters local_domain Parameter ---------------------- (type=string, default no sub-domain). Same as the `-d' option to Amd. Specify the local domain name. If this option is not given the domain name is determined from the hostname, by removing the first component of the fully-qualified host name.  File: am-utils.info, Node: log_file Parameter, Next: log_options Parameter, Prev: local_domain Parameter, Up: Global Parameters log_file Parameter ------------------ (type=string, default=`stderr'). Same as the `-l' option to Amd. Specify a file name to log Amd events to. If the string `/dev/stderr' is specified, Amd will send its events to the standard error file descriptor. If the string `syslog' is given, Amd will record its events with the system logger syslogd(8). If your system supports syslog facilities, then the default facility used is `LOG_DAEMON'. When using syslog, if you wish to change the facility, append its name to the option name, delimited by a single colon. For example, if it is the string `syslog:local7' then Amd will log messages via syslog(3) using the `LOG_LOCAL7' facility. If the facility name specified is not recognized, Amd will default to `LOG_DAEMON'. Note: while you can use any syslog facility available on your system, it is generally a bad idea to use those reserved for other services such as `kern', `lpr', `cron', etc.  File: am-utils.info, Node: log_options Parameter, Next: nfs_proto Parameter, Prev: log_file Parameter, Up: Global Parameters log_options Parameter --------------------- (type=string, default no logging options). Same as the `-x' option to Amd. Specify any logging options for Amd. Options are comma delimited, and can be preceded by the string `no' to negate their meaning. The `debug' logging option is only available if am-utils was configured with `--enable-debug'. You can get the list of supported debugging options by running `amd -H'. Possible values are: `all' all messages `debug' debug messages `error' non-fatal system errors `fatal' fatal errors `info' information `map' map errors `stats' additional statistical information `user' non-fatal user errors `warn' warnings `warning' warnings  File: am-utils.info, Node: nfs_proto Parameter, Next: nfs_retransmit_counter Parameter, Prev: log_options Parameter, Up: Global Parameters nfs_proto Parameter ------------------- (type=string, default to trying version tcp then udp). By default, Amd tries `tcp' and then `udp'. This option forces the overall NFS protocol used to TCP or UDP. It overrides what is in the Amd maps, and is useful when Amd is compiled with NFSv3 support that may not be stable. With this option you can turn off the complete usage of NFSv3 dynamically (without having to recompile Amd) until such time as NFSv3 support is desired again.  File: am-utils.info, Node: nfs_retransmit_counter Parameter, Next: nfs_retry_interval Parameter, Prev: nfs_proto Parameter, Up: Global Parameters nfs_retransmit_counter Parameter -------------------------------- (type=numeric, default=11). Same as the retransmit part of the `-t' timeout.retransmit option to Amd. Specifies the number of NFS retransmissions that the kernel will use to communicate with Amd. *Note -t Option::.  File: am-utils.info, Node: nfs_retry_interval Parameter, Next: nfs_vers Parameter, Prev: nfs_retransmit_counter Parameter, Up: Global Parameters nfs_retry_interval Parameter ---------------------------- (type=numeric, default=8). Same as the timeout part of the `-t' timeout.retransmit option to Amd. Specifies the NFS timeout interval, in _tenths_ of seconds, between NFS/RPC retries (for UDP only). This is the value that the kernel will use to communicate with Amd. *Note -t Option::. Amd relies on the kernel RPC retransmit mechanism to trigger mount retries. The values of the nfs_retransmit_counter and the nfs_retry_interval parameters change the overall retry interval. Too long an interval gives poor interactive response; too short an interval causes excessive retries.  File: am-utils.info, Node: nfs_vers Parameter, Next: nis_domain Parameter, Prev: nfs_retry_interval Parameter, Up: Global Parameters nfs_vers Parameter ------------------ (type=numeric, default to trying version 3 then 2). By default, Amd tries version 3 and then version 2. This option forces the overall NFS protocol used to version 3 or 2. It overrides what is in the Amd maps, and is useful when Amd is compiled with NFSv3 support that may not be stable. With this option you can turn off the complete usage of NFSv3 dynamically (without having to recompile Amd) until such time as NFSv3 support is desired again.  File: am-utils.info, Node: nis_domain Parameter, Next: normalize_hostnames Parameter, Prev: nfs_vers Parameter, Up: Global Parameters nis_domain Parameter -------------------- (type=string, default to local NIS domain name). Same as the `-y' option to Amd. Specify an alternative NIS domain from which to fetch the NIS maps. The default is the system domain name. This option is ignored if NIS support is not available.  File: am-utils.info, Node: normalize_hostnames Parameter, Next: os Parameter, Prev: nis_domain Parameter, Up: Global Parameters normalize_hostnames Parameter ----------------------------- (type=boolean, default=`no'). Same as the `-n' option to Amd. If `yes', then the name referred to by `${rhost}' is normalized relative to the host database before being used. The effect is to translate aliases into "official" names.  File: am-utils.info, Node: os Parameter, Next: osver Parameter, Prev: normalize_hostnames Parameter, Up: Global Parameters os Parameter ------------ (type=string, default to compiled in value). Same as the `-O' option to Amd. Allows you to override the compiled-in name of the operating system. Useful when the built-in name is not desired for backward compatibility reasons. For example, if the built-in name is `sunos5', you can override it to `sos5', and use older maps which were written with the latter in mind.  File: am-utils.info, Node: osver Parameter, Next: pid_file Parameter, Prev: os Parameter, Up: Global Parameters osver Parameter --------------- (type=string, default to compiled in value). Same as the `-o' option to Amd. Allows you to override the compiled-in version number of the operating system. Useful when the built-in version is not desired for backward compatibility reasons. For example, if the build in version is `2.5.1', you can override it to `5.5.1', and use older maps that were written with the latter in mind.  File: am-utils.info, Node: pid_file Parameter, Next: plock Parameter, Prev: osver Parameter, Up: Global Parameters pid_file Parameter ------------------ (type=string, default=`/dev/stdout'). Specify a file to store the process ID of the running daemon into. If not specified, Amd will print its process id onto the standard output. Useful for killing Amd after it had run. Note that the PID of a running Amd can also be retrieved via Amq (*note Amq -p option::). This file is used only if the `print_pid' option is on (*note print_pid Parameter::).  File: am-utils.info, Node: plock Parameter, Next: portmap_program Parameter, Prev: pid_file Parameter, Up: Global Parameters plock Parameter --------------- (type=boolean, default=`yes'). Same as the `-S' option to Amd. If `yes', lock the running executable pages of Amd into memory. To improve Amd's performance, systems that support the plock(3) call can lock the Amd process into memory. This way there is less chance the operating system will schedule, page out, and swap the Amd process as needed. This improves Amd's performance, at the cost of reserving the memory used by the Amd process (making it unavailable for other processes).  File: am-utils.info, Node: portmap_program Parameter, Next: print_pid Parameter, Prev: plock Parameter, Up: Global Parameters portmap_program Parameter ------------------------- (type=numeric, default=300019). Specify an alternate Port-mapper RPC program number, other than the official number. This is useful when running multiple Amd processes. For example, you can run another Amd in "test" mode, without affecting the primary Amd process in any way. For safety reasons, the alternate program numbers that can be specified must be in the range 300019-300029, inclusive. Amq has an option `-P' which can be used to specify an alternate program number of an Amd to contact. In this way, amq can fully control any number of Amd processes running on the same host.  File: am-utils.info, Node: print_pid Parameter, Next: print_version Parameter, Prev: portmap_program Parameter, Up: Global Parameters print_pid Parameter ------------------- (type=boolean, default=`no'). Same as the `-p' option to Amd. If `yes', Amd will print its process ID upon starting.  File: am-utils.info, Node: print_version Parameter, Next: restart_mounts Parameter, Prev: print_pid Parameter, Up: Global Parameters print_version Parameter ----------------------- (type=boolean, default=`no'). Same as the `-v' option to Amd, but the version prints and Amd continues to run. If `yes', Amd will print its version information string, which includes some configuration and compilation values.  File: am-utils.info, Node: restart_mounts Parameter, Next: selectors_in_defaults Parameter, Prev: print_version Parameter, Up: Global Parameters restart_mounts Parameter ------------------------ (type=boolean, default=`no'). Same as the `-r' option to Amd. If `yes' Amd will scan the mount table to determine which file systems are currently mounted. Whenever one of these would have been auto-mounted, Amd inherits it.  File: am-utils.info, Node: selectors_in_defaults Parameter, Next: show_statfs_entries Parameter, Prev: restart_mounts Parameter, Up: Global Parameters selectors_in_defaults Parameter ------------------------------- (type=boolean, default=`no'). If `yes', then the `/defaults' entry of maps will search for and process any selectors before setting defaults for all other keys in that map. Useful when you want to set different options for a complete map based on some parameters. For example, you may want to better the NFS performance over slow slip-based networks as follows: /defaults \ wire==slip-net;opts:=intr,rsize=1024,wsize=1024 \ wire!=slip-net;opts:=intr,rsize=8192,wsize=8192 Deprecated form: selectors_on_default.  File: am-utils.info, Node: show_statfs_entries Parameter, Next: unmount_on_exit Parameter, Prev: selectors_in_defaults Parameter, Up: Global Parameters show_statfs_entries Parameter ----------------------------- (type=boolean), default=`no'). If `yes', then all maps which are browsable will also show the number of entries (keys) they have when df(1) runs. (This is accomplished by returning non-zero values to the statfs(2) system call).