Virgin import of AMD (am-utils) v6.1.5

Sponsored by: Juniper Networks

1 files changed, 106 insertions, 9 deletions

diff --git a/contrib/amd/BUGS b/contrib/amd/BUGS
index fd52779..3a3ba6b 100644
--- a/contrib/amd/BUGS
+++ b/contrib/amd/BUGS
@@ -1,5 +1,8 @@
 	    LIST OF KNOWN BUGS IN AM-UTILS OR OPERATING SYSTEMS
 
+Note: report am-utils bugs via Bugzilla to https://bugzilla.am-utils.org/ or
+by email to the am-utils@am-utils.org mailing list.
+
 
 (1) mips-sgi-irix*
 
@@ -163,12 +166,15 @@ kernel will panic.
 
 The Linux kernels don't support Amd's direct mounts very well, leading to
 erratic behavior: shares that don't get remounted after the first timeout,
-inability to restart Amd because its mount points cannot be unmounted,
-etc. There are some kernel patches on the am-utils Web site, which solve
-these problems.  See http://www.am-utils.org/patches/.
+inability to restart Amd because its mount points cannot be unmounted, etc.
+There are some kernel patches on the am-utils Web site, which solve these
+problems.  See http://www.am-utils.org/patches/.
+
+Later 2.4.x kernels completely disallow the hack amd was using for direct
+mounts, so another solution will have to be found.
 
-UPDATE: kernels 2.4.10 and later completely disallow the direct mount hack,
-so direct mounts are simply not possible on those Linux kernels.
+Note: the above is for the old-style amd mount_type = nfs. The autofs mounts
+don't support direct mounts at all (due to lack of kernel support).
 
 (12) *-aix5.1.0.0 and *-hpux9*
 
@@ -177,14 +183,24 @@ to use /bin/ksh instead. The buildall script will do it for you; if for some
 reason you need to run configure directly, run it using 'ksh configure'
 instead of just 'configure'.
 
-[12A] *-aix5.1.*
+[12A] *-aix5.2.*
 
 Apparently there is an NFS client side bug in vmount() which causes amd to
 hang when it starts (and tries to NFS-mount itself).  According to IBM
 engineers, this has to do with partial support code for IPv6: the NFS kernel
 code doesn't appear to recognize the sin_family of the amd vmount(),
-although amd does the right thing.  The bug appears to have been fixed in
-AIX 5.2.  No known fix/patch is available for AIX 5.1 as of now (1/25/2003).
+although amd does the right thing.  The bug doesn't appear to be in 5.1 or
+4.3.3.  A fix from IBM is available, APAR number IY41417.
+
+A binary built on 4.3.3 will not work on 5.2, because the kernel ABIs have
+changed.
+
+[12C] *-aix*
+
+It is important that you install bos.net.nfs.adt before configuring and
+building am-utils.  If you don't, you will get compile-time or
+configure-time errors, especially when configure tries to find AIX's
+definition of struct nfs_args.
 
 (13) *-linux and *-darwin6.0
 
@@ -201,6 +217,87 @@ default).  Nonetheless, if a TCP connection breaks, under certain unclear
 circumstances the kernel might "forget" about that flag and start using
 unprivileged ports, causing the same EPERM error above.
 
+(14) Solaris
+
+The line "%option" in *.l files may cause Solaris /usr/ccs/bin/lex to abort
+with the error "missing translation value."  This is a bug in Solaris lex.
+
+Moreover, both Solaris yacc and lex produce code that does not pass strict
+compilation such as "gcc -Wall -Werror".
+
+Use GNU Flex and Bison instead.  You can download ready-made binaries from
+www.sunfreeware.com.  Note, however, that sometimes the binaries on
+sunfreeware.com don't seem to work, often because they are built against an
+older revision of Solaris or build tools.  In that case, build a fresh
+version of GNU flex and/or bison from the latest stable sources.  See
+http://www.gnu.org/software/flex/ and http://www.gnu.org/software/bison/.
+
+(15) Solaris 8 + patch 10899[34]-xx (18 <= xx < 25) or patch 11260[56]-xx
+
+With this patch, Sun updated the autofs kernel module and automountd
+userspace daemon from version 3 to version 4.  They also updated the
+/usr/include/rpcsvc/autofs_prot.x file, but forgot to regenerate the
+autofs_prot.h file.  Thus, when amd is compiled, it uses the old header and
+thinks it should use autofs version 3, when in fact the kernel now supports
+(and expects) only version 4.
+
+The workaround is to run 'rpcgen -C -h /usr/include/rpcsvc/autofs_prot.x >
+/usr/include/rpcsvc/autofs_prot.h' and completely reconfigure and rebuild
+am-utils (removing config.cache before running configure).
+
+The problem is fixed in patch revisions 10899[34]-25 and up.
+
+
+(16) Linux kernel 2.4+ and lofs mounts
+
+Lofs mounts are not supported by the linux kernel, at all, but since 2.4.0
+the kernel supports a similar type of mount called a bind mount.  Its
+semantics are closer to those of a hardlink than to those of lofs, and one
+of the results is that bind mounts ignore any mount options paseed to them.
+
+Amd uses bind mounts internally to emulate lofs mounts, which means that
+lofs mounts on linux will effectively ignore their mount parameters and
+inherit whatever options the original filesystem mounted upon had.
+
+
+(17) autoconf 2.57
+
+If you see configure warnings of the following kind:
+
+configure: WARNING: sys/proc.h: present but cannot be compiled
+configure: WARNING: sys/proc.h: check for missing prerequisite headers?
+configure: WARNING: sys/proc.h: proceeding with the preprocessor's result
+configure: WARNING:     ## ------------------------------------ ##
+configure: WARNING:     ## Report this to bug-autoconf@gnu.org. ##
+configure: WARNING:     ## ------------------------------------ ##
+
+please ignore them.  They are not real errors, and neither
+bug-autoconf@gnu.org nor the am-utils maintainers are interested in hearing
+about them.  Autoconf simply tries to do more than we need and attempts to
+compile each header in isolation, which fails for many system headers.
+That's ok, because we only need to know if a header file exists -- we know
+how to use it properly ourselves.
+
+While autoconf does offer a way to specify other files to be included with
+the tested header, in order to avoid these warnings, using it would enlarge
+the resulting configure script by an order of magnitude, and for no real
+gain.  Configure is big enough as it is, we don't need any more useless
+baggage in it.
+
+(18) NetBSD 2.0.2, FreeBSD 5.4, OpenBSD 3.7, and quite possibly most other
+     BSDs and other OSs (as of September 2005)
 
-Erez & Ion.
+Some BSD kernels don't have a way to turn off the NFS attribute cache.  They
+don't have a 'noac' mount flag, and setting various cache timeout fields in
+struct nfs_args doesn't turn off the attribute cache; instead, it sets the
+attribute cache timeout to some internal hard-coded default (usually
+anywhere from 5-30 seconds).  If Amd cannot turn off the NFS attribute
+cache, under heavy Amd usage, users could get ESTALE errors from automounted
+symlinks, or find that those symlinks point to the wrong place.  One
+workaround which would minimize this effect is to set auto_attrcache=1 in
+your amd.conf, but it doesn't eliminate the problem!  The best solutions are
+(1) to use Amd in Autofs mode, if it's supported in your OS, and (2) talk to
+your OS vendor to support a true "noac" flag.  See README.attrcache for more
+details.
 
+Erez & the am-utils team.