This is the official version of am-utils.

See the file NEWS for news on this and previous releases.

*** General Notes to alpha/beta testers:

[A] as alpha/beta testers, I expect you to be able to find certain things on
your own (especially look at the sources to figure out how things work).

[B] if you intend to modify any files, first find out if the file you want
to modify gets autogenerated from some other place.  If so, modify it at the
source.

You can adjust some of the configuration of am-utils after it has been
auto-configured by putting whatever definitions you wish in a file called
localconfig.h, located in the top build directory (the same one where
config.h is created for you).

[C] there are several ways you can build am-utils:

(1) run the buildall script as follows:

	./buildall

This would build all the applications inside a special directory relative to
the root of the source tree, called A.<cpu-company-system>, where the <>
part is filled in by GNU's config.guess script.  This is the preferred
method, for it will separate the build from the sources, and allow you to
run buildall for multiple architectures concurrently.

You can run "buildall -h" to see what options it takes.

(2) run the configure script such as:

	./configure

and then run

	make

This would configure amd in the directory you've run the configure script,
and build it there.  Run "make install" to install all the necessary files.

Note that this is good for building only one version of amd on one
architecture!  Don't try this for multiple architectures.  If you must, then
after doing one such build, run "make distclean" and then reconfigure for
another architecture.

(3) run the configure script for build in a different location.  Let's say
that /src/am-utils-6.0 is where you unpacked the sources.  So you could

	mkdir /src/build/sunos5
	cd /src/build/sunos5
	/src/am-utils-6.0/configure --srcdir=/src/am-utils-6.0
	make

This is a manual method that will let you build in any directory outside the
am-utils source tree.  It requires that your "make" program understand
VPATH.  This can be used multiple times to build am-utils concurrently in
multiple (but different) directories.  In fact, the buildall script
described above does precisely that, using the A.* subdirectories.

(4) If you need to configure am-utils with extra libraries and/or headers,
for example to add hesiod support, do so as follows:

	configure --enable-libs="-lhesiod -lresolv" \
		--enable-ldflags="-L/usr/local/hesiod/lib" \
		--enable-cppflags="-I/usr/local/hesiod/include"

[D] If you modify any of the *.[chyl] sources in the directories amd, amq,
hlfsd, lib, etc, all you need to do to get a new version of am-utils is run
make.

If you modify any of the files in the m4/ or conf/ directories, or any *.in
or *.am file, then you must rebuild the configure script, Makefile.in files,
aclocal.m4, etc.  The best way to do so is to run

	./bootstrap
or
	./buildall -K

To be a developer and be able to run "bootstrap", you must have
autoconf-2.68, automake-1.11.1, and libtool 2.2.6b installed on your system (or
later versions thereof).  You no longer need to get my special version of
automake.  Contact me if you'd like to be a maintainer and get access to the
CVS server.

After you've remade the basic configuration files you must rerun the
buildall script to rerun configure and then remake the binaries.

Modifying M4 macros may not be very intuitive to anyone that has not done so
before.  Let me know if you are having any problems with them.  I fully
expect, at least initially, to have to be the sole developer of the M4
macros and let others concentrate on C sources.

[E] Report all bugs via Bugzilla or the am-utils list (see
www.am-utils.org).  Avoid reporting to my personal email address.  It is
important to involve the whole list in bug fixes etc.

Good luck.

Erez Zadok,
Maintainer, am-utils.

		 NFS Attribute Caching OS Problems and Amd
		      Last updated September 18, 2005

* Summary:

Some OSs don't seem to have a way to turn off the NFS attribute cache, which
breaks the Amd automounter so badly that it is not recommend using Amd on
such OS for heavy use, not until this is fixed.


* Details:

Amd is a user-level NFSv2 server that manages automounts of all other file
systems.  The kernel contacts Amd via RPCs, and Amd in turn performs the
actual mounts, and then responds back to the kernel's RPCs.  Every kernel
caches attributes of files, in a cache called the Directory Name Lookup
Cache (DNLC), or a Directory Cache (dcache).

Amd manages its namespace in the user level, but the kernel caches names
itself.  So the two must coordinate to ensure that both namespaces are in
sync.  If the kernel uses a cached entry from the DNLC, without consulting
Amd, users may see corruption of the automounter namespace (symlinks
pointing to the wrong places, ESTALE errors, and more).  For example,
suppose Amd timed out an entry and removed the entry from Amd's namespace.
Amd has to tell the kernel to purge its corresponding DNLC entry too.  The
way Amd often does that is by incrementing the last modification time
(mtime) of the parent directory.  This is the most common method for kernels
to check if their DNLC entries are stale: if the parent directory mtime is
newer, the kernel will discard all cached entries for that directory, and
will re-issue lookup methods.  Those lookups will result in
NFS_GETATTR/NFS_LOOKUP calls sent from the kernel down to Amd, and Amd can
then properly inform the kernel of the new state of automounted entries.

In order to ensure that Amd is "in charge" of its namespace without
interference from the kernel, Amd will try to turn off the NFS attribute
cache.  It does so by using the NFSMNT_NOAC flag, if it exists, or by
setting various "cache timeout" fields in struct nfs_args to 0 (acregmin,
acregmax, acdirmin, or acdirmax).

We have released a major new version of am-utils, version 6.1, in June 2005.
Since then, a lot of people have experimented with Amd, in anticipation of
migrating from the very old am-utils 6.0 to the new 6.1.  For a couple of
months since the release of 6.1, we have received reports of problems with
Amd, especially under heavy use.  Users reported getting ESTALE errors from
time to time, or seeing automounted entries whose symlinks don't point to
where it should be.  After much debugging, we traced it to a few places in
Amd where it wasn't updating the parent directory mtime as it should have;
in some places where Amd was indeed updating the mtime, it was using a
resolution of only 1 second, which was not fine enough under heavy load.  We
fixed this problem and switched to using a microsecond resolution mtime.

After fixing this in Amd, we went on to verify that things work for other
OSs.  When we got to test certain BSDs, we found out that they always cache
directory entries, and there is no way to turn it off completely.
Specifically, if we set the ac{reg,dir}{min,max} fields in struct nfs_args
all to zero, the kernel seems to cache the entries for a default number of
seconds (something like 5-30 seconds).  On some OSs, setting these four
fields to 0 turns off the attribute cache, but not on some BSDs.  We were
able to verify this using Amd and a script that exercises the interaction of
the kernel's attrcache and Amd.  (If you're interested, the script can be
made available.)

We then experimented by setting the ac{reg,dir}{min,max} fields in struct
nfs_args all to 1, the smallest non-zero value we could.  When we ran the
Amd exercising script, we found that the value of 1 reduced the race between
the DNLC and Amd, and the script took a little longer to run before it
detected an incoherency.  That makes sense: the smaller the DNLC cache
interval is, the shorter the window of vulnerability is.  (BTW, the man
pages on some OSs say that the ac{reg,dir}{min,max} fields use a 1 second
resolution, but experimentation indicated it was in 0.1 second units.)

Clearly, setting the ac{reg,dir}{min,max} fields to 0 is worse than setting
it to 1 on those OSs that don't have a way to turn off the attribute cache.
So the current workaround I've implemented in am-utils is to create a
configuration parameter called "broken_attrcache" which, if turned on, will
set these nfs_args fields to 1 instead of 0.  I wish I didn't have to create
such ugly workaround features in Amd, but I've got no choice.

The near term solution is for every OS to support a true 'noac' flag, which
can be added fairly easily.  This'd make Amd work reliably.

The long term solution is to implement Autofs support for all OSs and to
support it in Amd.  Currently, Amd supports autofs on Solaris and Linux;
FreeBSD is next.  Still, we found that even with autofs support, many
sysadmins still prefer to use the good 'ol non-autofs mode.


* Confirmed Status

This is the confirmed status of various OSs' vulnerability to this attribute
cache bug.  We are slowly checking the status of other OSs.  The status of
any OS not listed is unknown as of the date at the top of this file.

** Not Vulnerable (support a proper "noac" flag):

Sun Solaris 8 and 9 (10 probably works fine)
Linux: 2.6.11 kernel (2.4.latest probably works fine)
FreeBSD 5.4 and 6.0-SNAP001 (older versions probably work fine)
OpenBSD 3.7 (older versions probably work fine)

** Vulnerable (don't support a proper "noac" flag natively):

NetBSD 2.0.2 (older versions are also probably affected)

Note: NetBSD has promised to support a noac flag hopefully after 2.1.0 is
released (maybe in 3.0 or 2.2).  In the mean time, you can apply one of
these two kernel patchs to support a 'noac' flag in NetBSD 2.x or 3.x:
	ftp://ftp.netbsd.org/pub/NetBSD/misc/christos/2x.nfs.noac.diff
	ftp://ftp.netbsd.org/pub/NetBSD/misc/christos/3x.nfs.noac.diff
After applying this patch and rebuilding your kernel, reboot with the new
kernel.  Then copy the new nfs.h and nfsmount.h from /sys/nfs/ to
/usr/include/nfs/, and finally rebuild am-utils from scratch.

** Testing

When you build am-utils, a script named scripts/test-attrcache is built,
which can be used to test the NFS attribute cache behavior of the current
OS.  You can run this script as root as follows:

# make install
# cd scripts
# sh test-attrcache

If you run this script on an OS whose status is known (and not listed
above), please report it to us via Bugzilla or the am-utils mailing list
(see www.am-utils.org), so we can record it in this file.

Sincerely,
Erez.

# This file is README.autofs
# am-utils-6.1
# Erez Zadok <ezk AT cs.columbia.edu> a.k.a. "Darth Autoconf"
#
# modified by
# Ion Badulescu <ib42 At cs.columbia.edu> a.k.a. "The Autofs Master"

** General notes about the autofs support in am-utils

- The autofs code in am-utils is gamma quality for Linux, beta quality for
  Solaris 2.5+ and non-working for all the other systems.

- Link, lofs, ufs, nfs, nfsl, and auto mounts were tested and work properly;
  the others should work, but were not tested.

* Caveats:

- [this applies to Solaris/IRIX 6/HP-UX/AIX] Amd acts as *both* automountd and
automount.  There's no way to distinguish between the two.  When amd starts,
it first registers itself as an autofs server (automountd's job), then
parses its own maps, and decides which autofs-type mounts to make
(automount's job).  After the autofs mounts are made, amd listens for
requests from the kernel-based autofs, and acts upon them. Since there can
be only one autofs listener on a system, this means that automountd and amd
cannot run at the same time; nor can two amd's run at the same time if they
are both using autofs mounts.

- Linux support is available and fairly stable. Solaris 2.5+ support is
newer and less tested, but seems pretty stable as well. IRIX 6 and HP-UX
autofs support will probably be very easy once we get Solaris 2.5 to work,
as they use the same protocol and almost identical data structures. AIX
seems to be using the Solaris 2.5 protocol as well, but they don't provide
any headers or documentation so getting autofs to work will be tricky at best.

- Killing amd can become a problem if there are active mounts. Since mounts
are done "in place", we can't just unmount our mount points and go away. For
now, amd simply tells the kernel that it is dying; we need to think this
further.  It would be nice to "take over" the old mountpoints, there is
support for this in Solaris (due to is RPC nature) and is easy to add to
the Linux kernel (an ioctl on the mountpoint).

- The Solaris 2.5 implementation of the autofs v1 protocol is NON-REENTRANT,
and ignoring this limitation results in a DEADLOCK between the kernel and
the daemon. This is a serious problem, although only for the lofs and link
mount types. In other words, suppose the daemon is trying a lofs/link mount
whose destination crosses another autofs mountpoint. If that mountpoint is
not yet mounted, it will trigger another autofs lookup which will deadlock
inside the kernel -- because the kernel is waiting for the previous request
to return. This is not even something specific to amd, Sun's own automountd
has the exact same problem. Ctrl-C breaks the deadlock, so it's not fatal,
but the lofs/link entry is in effect unusable.

- Solaris 2.8 (at least) doesn't like getting to get out-of-order replies to
mount requests, and ignores the late ones. It's only a minor annoyance (read
delay), because the RPC is retried by the kernel and it succeeds the second
time around.

* Solaris:

- Amd w/ autofs mounts will fight over the listener port with Sun's
  automountd, so running both simultaneously is a really bad idea.

- Browsable_dirs is possible and implemented for Solaris 2.6+.

- Direct mounts are implemented and work correctly.

- Host maps are implemented and work correctly.

- On Solaris 2.6+, symlinks over autofs are inefficient. The kernel seems to
  time them out immediately after receiving them, so each access to a
  symlink causes a call to userspace. Needless to say, this negates the
  whole point of using autofs. Automountd seems to always use lofs mounts
  instead of symlinks, we do the same unless the admin requests
  "autofs_use_lofs = no" in amd.conf.

- Solaris 2.5/2.5.1 do not support symlinks over autofs, so links are always
  mounted as lofs mounts, subject to the limitation described in the caveats
  section above.

- Restarting autofs mounts is possible, but not yet implemented.

* Linux:

- Amd should work fine even when the Linux automounter is running, the
  mechanism being used prevents any kind of (evil) interaction between them.

- Browsing is not available if autofs support is used, due to limitations in
  the kernel<->daemon protocol used by Linux 2.2 and 2.4. Only already-mounted
  nodes will appear in the autofs directory, and this is implemented entirely
  in the kernel.

- Host maps are supported with all autofs versions.

- Direct maps cannot be supported since there is no kernel support for them;
  we might be able to get something eventually, but don't hold your breath.
  If anything, we may do it using a regular NFS mountpoint and bind-mount on
  top of it.

- Inherit doesn't make much sense because we can't restart a hung autofs
  mount point, due to kernel limitations. This needs to be fixed in the
  Linux kernel; it's not particularly difficult, and we might provide a
  patch at some point.

- Link (and lofs) mounts will use the new bind-mount support in Linux
  2.4+. No more symlinks! And /bin/pwd works great too.

- Auto maps are actually mounted as a separate autofs filesystem. Since each
  autofs filesystem consumes 2 file descriptors, and amd has at most 1024
  file descriptors available, there can be at most 512 of them mounted at
  the same time. Because of this, extensive use of auto maps is discouraged
  when using autofs on Linux.

* amd.conf requirements:

To tell amd to use an autofs-style mount point and mounts for a map, add

	mount_type = autofs

either to the global section, or to the sections of the individual maps you
selected. Mixing autofs and normal amd mount points in the same amd.conf
file *does* work.

* Map changes:

No changes are necessary. If a map is marked as autofs in amd.conf, mounts
are done "in place" and the "fs" parameter is ignored most of the time.

* Todo:

We are looking for volunteers to improve the autofs code!

(1) These fixes are needed:

- sublinks are broken

- when the mount type is 'link', transparently translate it into a loopback
file system mount (lofs), that would mount in place, rather than supply a
symlink, at least on systems whose autofs doesn't support symlinks. Linux
does support symlinks, Solaris 2.6+ does too, but Solaris 2.5/2.5.1 doesn't
and neither does IRIX 6. Moreover, Sun's automountd always uses lofs for
link mounts, even on 2.6+, because symlinks are not cached in the kernel and
thus are not particularly efficient. [done]

- complain if certain incompatible options (autofs and ...) are used. Direct
maps on Linux is one such case of incompatible options. Browsable_dirs on
Linux is another such case.

- if amd is killed or dies, the autofs mounts will remain intact as required
(your system is _not_ hung, yay!).  However, if you restart amd, it will not
correctly 'restart' the autofs mounts as the Sun automounter does.  Rather,
it might cause another mount to happen, which leaves your /etc/mnttab
cluttered with older mounts entries which cannot be unmounted. It might also
just pretend everything is ok, when in fact it isn't.

(2) Code expansion:

- [Solaris only] implement the sockets version of amu_get_autofs_address()
and create_autofs_service(), in conf/transp/transp_sockets.c. Not sure if
it's necessary, Solaris it still biased towards TLI/STREAMS in
userspace. [mostly done, untested, might be used on AIX 5.x+ and IRIX 6]

- Implement the restarting of autofs mount points. This is already doable on
Solaris; on Linux, the kernel needs to be patched to allow it.

(3) Testing and porting to other systems:

- nothing has been tested on IRIX 6, which reportedly has a similarly
functioning autofs to Solaris 2.5.  The code compiles, but has not been run
yet and is most likely broken.

- support for Linux autofs is stable, we need testers!

- support for Solaris 2.6+ is pretty stable, so we need testers for it, too!

- we did not test any version of Solaris on x86. It will probably work, but
you have been warned. Testers are welcome.

LDAP support for am-utils was originally done by Leif Johansson
<leifj AT it.su.se>.  He no longer maintains it.

The current LDAP support for am-utils is for LDAPv2 only.  Reportedly,
LDAPv3 mostly works.  Volunteers and patches are welcome.

The IANA has assigned the following Private Enterprise Number to:

	10180  Am-utils Organization   Erez Zadok	ezk AT am-utils.org

There are three files in this directory that relate to LDAP:

ldap.schema:

	This is the most current schema.

ldap-id.txt:

	This is an experimental schema for amd mount maps in LDAP.  Since
	LDAP isn't maintained now, this code may not match with either the
	current ldap_info.c code or with Amd mount maps in general.

	The schema is written in the form of an internet-draft but it has
	not been published as such.  We need volunteers who know and use
	LDAP to clean it up and further its process of submission.

ldap-id.ms:

	This is the NROFF source of the draft.  To generate the text from
	it, run "nroff -ms ldap-id.ms > ldap-id.txt"

Erez.

------- Forwarded Message

From: "IANA Private Enterprise Number" <iana-pen AT icann.org>
To: "Erez Zadok" <ezk AT cs.columbia.edu>
Subject: RE: Application for Enterprise-number (10180)
Date: Sun, 15 Jul 2001 14:43:45 -0700

Dear Erez,

The IANA has assigned the following Private Enterprise
Number to:

10180  Am-utils Organization   Erez Zadok                 ezk AT am-utils.org

Please notify the IANA if there is a change in your contact
or company information.

Thank you,

Bill Huang
IANA - Private Enterprise Numbers

------- End of Forwarded Message

Here some unconfirmed instructions for how to setup Amd on a MAC OS-X
machine.  Please direct all comments about this information, as well fixes,
updates, and corrections to the am-utils mailing list (see
www.am-utils.org).

Thanks,
Erez.

--cut--here----cut--here----cut--here----cut--here----cut--here----cut--here--


Date: Fri, 28 Jan 2005 06:53:50 -0800
From: Kevin Layer

The stock amd didn't work for us in Mac OS X 10.3.
Here's how we installed am-utils-6.1-20031025:

./configure --prefix=/usr
make
make install

Create /System/Library/StartupItems/AMD with the files:

AMD
Resources/	-- copy from other directories in ..
StartupParameters.plist

Then, make sure that AMDSERVER=-YES- is added to /etc/hostconfig.

******************* the file AMD:

#!/bin/sh

##
# Start AMD
##

. /etc/rc.common

if [ "${AMDSERVER:=-NO-}" = "-YES-" ]; then
    ConsoleMessage "Starting AMD server"

    if [ ! -f /etc/amd.conf -a -r /etc/amd.conf.template ]; then
        cp /etc/amd.conf.template /etc/amd.conf
    fi
    if [ ! -f /etc/amd.map -a -r /etc/amd.map.template ]; then
        cp /etc/amd.map.template /etc/amd.map
    fi
    /usr/sbin/amd
fi

******************* the file StartupParameters.plist:

{
  Description     = "AMD server";
  Provides        = ("AMD");
  Requires        = ("Resolver");
  OrderPreference = "None";
  Messages =
  {
    start = "Starting AMD server";
    stop  = "Stopping AMD server";
  };
}

*******************

With the beta's of 10.4 (64-bit) we're having issues with realpath()
and amd mounted directories, but hopefully this is just a bug that
they'll fix.

--
Kevin Layer                     http://www.franz.com/

- update vers.m4 to the new version you want to release: then rerun ./bootstrap
- update NEWS w/ appropriate items
- ./bootstrap && ./buildall && cd A.$ARCH.$VENDOR.$OSVERSION. && make check
- cd A.$ARCH.$VENDOR.$OSVERSION make distcheck
  That generates a tar.gz w/ version number to drop into the ftp/http server
- Make sure that all your files are committed at this point
- Now tag the current trunk:
	git tag -a am-utils-X_Y[abc]Z
  or
	git tag -a am-utils-X_Y_rcZ
  If you want to move the tag, use --force
- Push all commits and tags to the master repository
	git push --all
- email announcement to am-utils-announce@am-utils.org.  See
  README.release-announce as sample.

To: am-utils-announce@am-utils.org
Cc: am-utils@am-utils.org
Subject: am-utils-6.2-rc1 released

We've released am-utils-6.2-rc1, first and only release candidate in the
6.2 series (with nfsv4 support, autofs supports, and quite a few more
features).  This will be the first official release since 2006, so expect a
lot of bug fixes and improvements.

You can download am-utils-6.2-rc1 as well as other releases from:

	http://www.am-utils.org/

*** Notes specific to am-utils version 6.2-rc1

Filesystem Support:
    - Add support for NFSv4
    - Add support for Lustre
    - Add support for ext{2,3,4}
    - Add support for linux autofs version 5
    - Add support for TMPFS and UDF
New features:
    - Add amq -i (prints information about maps)
    - Add synchronous unmount code for amq -uu
    - Allow a comma-separated list of LDAP servers for failover
Changes in behavior:
    - Empty variable assignments, now unset the variable value.
    - Share LDAP connections between different maps to save resources
Portability fixes:
    - Changes to work with Linux-2.6.x, Linux-3.x and NetBSD-5.x, NetBSD-6.x,
      FreeBSD 7.x, Solaris
Bug fixes:
    - Many bug fixes, see ChangeLog

- minor new ports:
	* Please send us the 'config.guess' and 'amd -v' outputs
	  so we can complete this list.

- Bugs fixed:
	* many race conditions found and fixed by Krisztian Kovacs.

Cheers,
The am-utils team.

PS. Many thanks for Christos Zoulas for a huge amount of work he put in
towards this long-awaited release.

		Sun-style Automounter Syntax Support in Amd
		       Last updated: October 10, 2005


* Summary

The goal of this effort is to provide a drop in replacement for the Sun
automounter.  This is implemented in two ways.  (1) A new parser built into
Amd.  (2) a standalone sun2amd Unix filter tool that can convert Sun-style
maps to Amd maps.

Support for Sun-style maps in Amd (including this document) is a
work-in-progress.  This feature as a whole has not been throughly tested and
is "alpha" quality as of the date posted at the top of this document.

* Status

Currently sun2amd supports most of the basic syntax features of Sun maps.
However, support for Sun auto.master maps does not yet exists at any level.
Below is a list of supported and not-yet supported features.

1. Supported Sun map features:

- Simple map entry format: <key> [mount_options] location ...
	locations take the form of host:pathname

- Map Key Substitution: <key> <hostname>:/tmp/&
	the & expands to <key>

- Wildcard Key: * <hostname>:/tmp
	This is is a catch-all entry.

- Variable Substitution:
	$ARCH, $CPU, $HOST, $OSNAME, $OSREL, $OSVERS, $NATISA

- Multiple Mount format:
	<key> [mount_options] [mountpoint] [mount-options locations...]...

	ex.
		pluto -ro /tmp1 host1:/tmp1 /tmp2 host2:/tmp2

- HSFS file-system (cdrom): <key> -fstype=hsfs,ro :/dev/cdrom


2. Not-yet supported Sun map features:

- Replicated File Systems: <hostname>,<hostname>...:<pathname>
	This is a feature of Solaris that allows a user to specify a
	set of hosts to appear as one in a map entry.  When a host
	does not respond the kernel will switch to an alternate
	server.  Amd will supports the syntax for replicated file
	systems by creating multiple hosts, however, Amd will not
	perform any kind of fail over.

- CacheFS (although Amd supports type:=cachefs, sun2amd doesn't yet parse
  it).

- AutoFS (although Amd supports Autofs mounts and type:=auto, sun2amd
  may not parse it fully).

- Included maps: +<map_name>
	This will include the contents of a map into another map.

- Sun master maps: auto.master
	Amd still relies and amd.conf.  Any feature in auto.master
        must be duplicated using Amd equivalent features in amd.conf.

- /net mount point:
	The automounter is suppose to dynamically create map entries
        under this mount point corresponding to NFS server(s) exported
        file systems.  While this isn't parser by sun2amd, Amd does support
	host maps (type:=host).

- Federated Naming Service (FNS) (-xfn):
	A naming server that wraps a number of other naming service
        under one interface.

- "-null" map option: A way to cancel maps in the auto.master file.

- nsswitch.conf:
	This file provides a way to specify what lookup service to use
        for a number of systems including Sun's automounter.  In amd
        lookup services for map files are define in the amd.conf file.


* Setup

To enable Sun-style maps in Amd, set "sun_map_syntax = yes" in your amd.conf
file.  When this flag is set in [global], all maps read by Amd are assumed
to be Sun style maps.  You can set this on a per map basis, thus mixing
Sun-style and Amd-style maps.  For more information about amd.conf please
see the Amd documentation.

Example:

# file: amd.conf
################
[ global ]
sun_map_syntax = yes

[ /home ]
map_name = /etc/amd.sun_map
map_type = file


* sun2amd command line utility

In addition to build-in Amd support there also exists the sun2amd command
line utility that converts Sun maps to Amd maps.  This can be useful in
migrating one or more Sun maps to the Amd syntax in one step.

Example usage:

$ sun2amd -i sun_map -o amd_map

This line tells sun2amd to read the file sun_map and redirect its output to
a file called amd_map.  By default sun2amd reads from stdin and writes to
stdout (i.e., traditional Unix filter).


* FAQ

Q1: I know "/net" is not supported, but how can I achieve the same
    functionality with Amd?

A1: In short, you must create the '/net' entry as a Amd entry of type host
    by hand.  Below is an example of how to do this.  See the Amd
    documentation on type autofs for more information.

Example:

# file: amd.conf
################
[ /net ]
map_name = /etc/amd.net

# file: /etc/amd.net
###############
/defaults  fs:=${autodir}/${rhost}/root/${rfs}
*          rhost:=${key};type:=host;rfs:=/

(more FAQ entries to come...)

		       AM-UTILS YEAR-2000 COMPLIANCE

Most likely am-utils is y2k compliant.

I do not know for sure because I have not certified am-utils myself, nor do
I have the time for it.  I do not think that amd will be affected by y2k at
all, because it does not do anything with dates other than print the date on
the log file, in whatever format is provided by your os/libc --- especially
the ctime(3) call.

However, on Friday, September 18th 1998, Matthew Crosby <mcrosby AT ms.com>
reported that they evaluated 6.0a16 and found it to be compliant.

On March 26, 1999, Paul Balyoz <pbalyoz AT sedona.ch.intel.com> submitted a
patch to lostaltmail which makes it print Y2K compliant dates.  He used a
code scanner and manually "eyeballed" the code and could not find any more
problems.  Paul's patch is included in am-utils-6.0.1s7 and newer versions.
Paul also said that other 2-digit years used in am-utils are "harmless."

NOTE: NONE OF THE PERSONS MENTIONED HERE, AUTHOR INCLUDED, ARE WILLING TO
CERTIFY AM-UTILS AS Y2K COMPLIANT.  USE AT YOUR OWN RISK.

---
Erez Zadok.
Maintainer, am-utils package and am-utils list.
WWW:   http://www.am-utils.org