Home | History | only in am-utils
Up to higher level directory
NameDateSize
acinclude.m405-Feb-2006359.4K
aclocal.m420-Sep-200541.1K
amd/09-Jun-2008
amd2netbsd30-Apr-20084.1K
amq/09-Jun-2008
AUTHORS05-Feb-200614.9K
aux_conf.h.in23-Apr-20052K
bootstrap27-Nov-20042.6K
BUGS20-Sep-200512.8K
buildall05-Feb-20068.6K
ChangeLog05-Feb-2006412.9K
commit27-Nov-20046K
conf/09-Jun-2008
config.guess05-Feb-200642.4K
config.guess.long05-Feb-20061.8K
config.h.in05-Feb-200655.9K
config.sub05-Feb-200631K
configure05-Feb-20061.9M
configure.in05-Feb-200636.6K
COPYING23-Apr-20052K
cvs-server.txt27-Nov-20041.3K
depcomp23-Apr-200514.8K
doc/09-Jun-2008
FAQ23-Apr-20052.9K
fixmount/09-Jun-2008
fsinfo/09-Jun-2008
hlfsd/09-Jun-2008
include/29-Aug-2008
INSTALL05-Feb-20065.1K
install-sh23-Apr-20059K
ldap-id.ms05-Feb-20069.3K
ldap-id.txt13-May-200110.6K
ldap.schema23-Apr-20051.5K
libamu/09-Jun-2008
LSM.am-utils29-Nov-2002715
ltmain.sh05-Feb-2006182.4K
m4/09-Jun-2008
Makefile.am05-Feb-20069.4K
Makefile.in05-Feb-200629.2K
MIRRORS.html27-Nov-20042.8K
MIRRORS.txt27-Nov-20041.8K
missing23-Apr-200510.3K
mk-amd-map/09-Jun-2008
mkinstalldirs23-Apr-20053.3K
NEWS05-Feb-200651.9K
README27-Nov-20043.8K
README.attrcache05-Feb-20066.4K
README.autofs05-Feb-20067.7K
README.ldap23-Apr-20051.5K
README.osx23-Apr-20051.6K
README.y2k27-Nov-20041.1K
scripts/09-Jun-2008
stamp-h.in19-Nov-200010
tasks23-Apr-20053.3K
vers.m405-Feb-200611
wire-test/09-Jun-2008

README

      1 This is the official version of am-utils.
      2 
      3 See the file NEWS for news on this and previous releases.
      4 
      5 *** General Notes to alpha/beta testers:
      6 
      7 [A] as alpha/beta testers, I expect you to be able to find certain things on
      8 your own (especially look at the sources to figure out how things work).
      9 
     10 [B] if you intend to modify any files, first find out if the file you want
     11 to modify gets autogenerated from some other place.  If so, modify it at the
     12 source.
     13 
     14 You can adjust some of the configuration of am-utils after it has been
     15 auto-configured by putting whatever definitions you wish in a file called
     16 localconfig.h, located in the top build directory (the same one where
     17 config.h is created for you).
     18 
     19 [C] there are several ways you can build am-utils:
     20 
     21 (1) run the buildall script as follows:
     22 
     23 	./buildall
     24 
     25 This would build all the applications inside a special directory relative to
     26 the root of the source tree, called A.<cpu-company-system>, where the <>
     27 part is filled in by GNU's config.guess script.  This is the preferred
     28 method, for it will separate the build from the sources, and allow you to
     29 run buildall for multiple architectures concurrently.
     30 
     31 You can run "buildall -h" to see what options it takes.
     32 
     33 (2) run the configure script such as:
     34 
     35 	./configure
     36 
     37 and then run
     38 
     39 	make
     40 
     41 This would configure amd in the directory you've run the configure script
     42 in, and the built it there.  Run "make install" to install all the necessary
     43 files.
     44 
     45 Note that this is good for building only one version of amd on one
     46 architecture!  Don't try this for multiple architectures.  If you must, then
     47 after doing one such build, run "make distclean" and then reconfigure for
     48 another architecture.
     49 
     50 (3) run the configure script for build in a different location.  Let's say
     51 that /src/am-utils-6.0 is where you unpacked the sources.  So you could
     52 
     53 	mkdir /src/build/sunos5
     54 	cd /src/build/sunos5
     55 	/src/am-utils-6.0/configure --srcdir=/src/am-utils-6.0
     56 	make
     57 
     58 This is a manual method that will let you build in any directory outside the
     59 am-utils source tree.  It requires that your "make" program understand
     60 VPATH.  This can be used multiple times to build am-utils concurrently in
     61 multiple (but different) directories.  In fact, the buildall script
     62 described above does precisely that, using the A.* subdirectories.
     63 
     64 (4) If you need to configure am-utils with extra libraries and/or headers,
     65 for example to add hesiod support, do so as follows:
     66 
     67 	configure --enable-libs="-lhesiod -lresolv" \
     68 		--enable-ldflags="-L/usr/local/hesiod/lib" \
     69 		--enable-cppflags="-I/usr/local/hesiod/include"
     70 
     71 [D] If you modify any of the *.[chyl] sources in the directories amd, amq,
     72 hlfsd, lib, etc, all you need to do to get a new version of am-utils is run
     73 make.
     74 
     75 If you modify any of the files in the m4/ or conf/ directories, or any *.in
     76 or *.am file, then you must rebuild the configure script, Makefile.in files,
     77 aclocal.m4, etc.  The best way to do so is to run
     78 
     79 	./bootstrap
     80 or
     81 	./buildall -K
     82 
     83 To be a developer and be able to run "bootstrap", you must have
     84 autoconf-2.50, automake-1.5, and libtool 1.4 installed on your system (or
     85 later versions thereof).  You no longer need to get my special version of
     86 automake.  Contact me if you'd like to be a maintainer and get access to the
     87 CVS server.
     88 
     89 After you've remade the basic configuration files you must rerun the
     90 buildall script to rerun configure and then remake the binaries.
     91 
     92 Modifying M4 macros may not be very intuitive to anyone that has not done so
     93 before.  Let me know if you are having any problems with them.  I fully
     94 expect, at least initially, to have to be the sole developers of the M4
     95 macros and let others concentrate on C sources.
     96 
     97 [E] Report all bugs to am-utils (a] am-utils.org.  Avoid reporting to my
     98 personal email address.  It is important to involve the whole list in bug
     99 fixes etc.
    100 
    101 Good luck.
    102 
    103 Erez Zadok,
    104 Maintainer, am-utils.
    105

README.attrcache

      1 		 NFS Attribute Caching OS Problems and Amd
      2 		      Last updated September 18, 2005
      3 
      4 * Summary:
      5 
      6 Some OSs don't seem to have a way to turn off the NFS attribute cache, which
      7 breaks the Amd automounter so badly that it is not recommend using Amd on
      8 such OS for heavy use, not until this is fixed.
      9 
     10 
     11 * Details:
     12 
     13 Amd is a user-level NFSv2 server that manages automounts of all other file
     14 systems.  The kernel contacts Amd via RPCs, and Amd in turn performs the
     15 actual mounts, and then responds back to the kernel's RPCs.  Every kernel
     16 caches attributes of files, in a cache called the Directory Name Lookup
     17 Cache (DNLC), or a Directory Cache (dcache).
     18 
     19 Amd manages its namespace in the user level, but the kernel caches names
     20 itself.  So the two must coordinate to ensure that both namespaces are in
     21 sync.  If the kernel uses a cached entry from the DNLC, without consulting
     22 Amd, users may see corruption of the automounter namespace (symlinks
     23 pointing to the wrong places, ESTALE errors, and more).  For example,
     24 suppose Amd timed out an entry and removed the entry from Amd's namespace.
     25 Amd has to tell the kernel to purge its corresponding DNLC entry too.  The
     26 way Amd often does that is by incrementing the last modification time
     27 (mtime) of the parent directory.  This is the most common method for kernels
     28 to check if their DNLC entries are stale: if the parent directory mtime is
     29 newer, the kernel will discard all cached entries for that directory, and
     30 will re-issue lookup methods.  Those lookups will result in
     31 NFS_GETATTR/NFS_LOOKUP calls sent from the kernel down to Amd, and Amd can
     32 then properly inform the kernel of the new state of automounted entries.
     33 
     34 In order to ensure that Amd is "in charge" of its namespace without
     35 interference from the kernel, Amd will try to turn off the NFS attribute
     36 cache.  It does so by using the NFSMNT_NOAC flag, if it exists, or by
     37 setting various "cache timeout" fields in struct nfs_args to 0 (acregmin,
     38 acregmax, acdirmin, or acdirmax).
     39 
     40 We have released a major new version of am-utils, version 6.1, in June 2005.
     41 Since then, a lot of people have experimented with Amd, in anticipation of
     42 migrating from the very old am-utils 6.0 to the new 6.1.  For a couple of
     43 months since the release of 6.1, we have received reports of problems with
     44 Amd, especially under heavy use.  Users reported getting ESTALE errors from
     45 time to time, or seeing automounted entries whose symlinks don't point to
     46 where it should be.  After much debugging, we traced it to a few places in
     47 Amd where it wasn't updating the parent directory mtime as it should have;
     48 in some places where Amd was indeed updating the mtime, it was using a
     49 resolution of only 1 second, which was not fine enough under heavy load.  We
     50 fixed this problem and switched to using a microsecond resolution mtime.
     51 
     52 After fixing this in Amd, we went on to verify that things work for other
     53 OSs.  When we got to test certain BSDs, we found out that they always cache
     54 directory entries, and there is no way to turn it off completely.
     55 Specifically, if we set the ac{reg,dir}{min,max} fields in struct nfs_args
     56 all to zero, the kernel seems to cache the entries for a default number of
     57 seconds (something like 5-30 seconds).  On some OSs, setting these four
     58 fields to 0 turns off the attribute cache, but not on some BSDs.  We were
     59 able to verify this using Amd and a script that exercises the interaction of
     60 the kernel's attrcache and Amd.  (If you're interested, the script can be
     61 made available.)
     62 
     63 We then experimented by setting the ac{reg,dir}{min,max} fields in struct
     64 nfs_args all to 1, the smallest non-zero value we could.  When we ran the
     65 Amd exercising script, we found that the value of 1 reduced the race between
     66 the DNLC and Amd, and the script took a little longer to run before it
     67 detected an incoherency.  That makes sense: the smaller the DNLC cache
     68 interval is, the shorter the window of vulnerability is.  (BTW, the man
     69 pages on some OSs say that the ac{reg,dir}{min,max} fields use a 1 second
     70 resolution, but experimentation indicated it was in 0.1 second units.)
     71 
     72 Clearly, setting the ac{reg,dir}{min,max} fields to 0 is worse than setting
     73 it to 1 on those OSs that don't have a way to turn off the attribute cache.
     74 So the current workaround I've implemented in am-utils is to create a
     75 configuration parameter called "broken_attrcache" which, if turned on, will
     76 set these nfs_args fields to 1 instead of 0.  I wish I didn't have to create
     77 such ugly workaround features in Amd, but I've got no choice.
     78 
     79 The near term solution is for every OS to support a true 'noac' flag, which
     80 can be added fairly easily.  This'd make Amd work reliably.
     81 
     82 The long term solution is to implement Autofs support for all OSs and to
     83 support it in Amd.  Currently, Amd supports autofs on Solaris and Linux;
     84 FreeBSD is next.  Still, we found that even with autofs support, many
     85 sysadmins still prefer to use the good 'ol non-autofs mode.
     86 
     87 
     88 * Confirmed Status
     89 
     90 This is the confirmed status of various OSs' vulnerability to this attribute
     91 cache bug.  We are slowly checking the status of other OSs.  The status of
     92 any OS not listed is unknown as of the date at the top of this file.
     93 
     94 ** Not Vulnerable (support a proper "noac" flag):
     95 
     96 Sun Solaris 8 and 9 (10 probably works fine)
     97 Linux: 2.6.11 kernel (2.4.latest probably works fine)
     98 FreeBSD 5.4 and 6.0-SNAP001 (older versions probably work fine)
     99 OpenBSD 3.7 (older versions probably work fine)
    100 
    101 ** Vulnerable (don't support a proper "noac" flag natively):
    102 
    103 NetBSD 2.0.2 (older versions are also probably affected)
    104 
    105 Note: NetBSD has promised to support a noac flag hopefully after 2.1.0 is
    106 released (maybe in 3.0 or 2.2).  In the mean time, you can apply one of
    107 these two kernel patchs to support a 'noac' flag in NetBSD 2.x or 3.x:
    108 	ftp://ftp.netbsd.org/pub/NetBSD/misc/christos/2x.nfs.noac.diff
    109 	ftp://ftp.netbsd.org/pub/NetBSD/misc/christos/3x.nfs.noac.diff
    110 After applying this patch and rebuilding your kernel, reboot with the new
    111 kernel.  Then copy the new nfs.h and nfsmount.h from /sys/nfs/ to
    112 /usr/include/nfs/, and finally rebuild am-utils from scratch.
    113 
    114 ** Testing
    115 
    116 When you build am-utils, a script named scripts/test-attrcache is built,
    117 which can be used to test the NFS attribute cache behavior of the current
    118 OS.  You can run this script as root as follows:
    119 
    120 # make install
    121 # cd scripts
    122 # sh test-attrcache
    123 
    124 If you run this script on an OS whose status is known (and not listed
    125 above), please report it to am-utils (a] am-utils.org, so we can record it in
    126 this file.
    127 
    128 Sincerely,
    129 Erez.
    130

README.autofs

      1 # This file is README.autofs
      2 # am-utils-6.1
      3 # Erez Zadok <ezk (a] cs.columbia.edu> a.k.a. "The Lord of Darkness"
      4 #
      5 # modified by
      6 # Ion Badulescu <ib42 (a] cs.columbia.edu> a.k.a. "The Autofs Master"
      7 
      8 ** General notes about the autofs support in am-utils
      9 
     10 - The autofs code in am-utils is gamma quality for Linux, beta quality for
     11   Solaris 2.5+ and non-working for all the other systems.
     12 
     13 - Link, lofs, ufs, nfs, nfsl, and auto mounts were tested and work properly;
     14   the others should work, but were not tested.
     15 
     16 * Caveats:
     17 
     18 - [this applies to Solaris/IRIX 6/HP-UX/AIX] Amd acts as *both* automountd and
     19 automount.  There's no way to distinguish between the two.  When amd starts,
     20 it first registers itself as an autofs server (automountd's job), then
     21 parses its own maps, and decides which autofs-type mounts to make
     22 (automount's job).  After the autofs mounts are made, amd listens for
     23 requests from the kernel-based autofs, and acts upon them. Since there can
     24 be only one autofs listener on a system, this means that automountd and amd
     25 cannot run at the same time; nor can two amd's run at the same time if they
     26 are both using autofs mounts.
     27 
     28 - Linux support is available and fairly stable. Solaris 2.5+ support is
     29 newer and less tested, but seems pretty stable as well. IRIX 6 and HP-UX
     30 autofs support will probably be very easy once we get Solaris 2.5 to work,
     31 as they use the same protocol and almost identical data structures. AIX
     32 seems to be using the Solaris 2.5 protocol as well, but they don't provide
     33 any headers or documentation so getting autofs to work will be tricky at best.
     34 
     35 - Killing amd can become a problem if there are active mounts. Since mounts
     36 are done "in place", we can't just unmount our mount points and go away. For
     37 now, amd simply tells the kernel that it is dying; we need to think this
     38 further.  It would be nice to "take over" the old mountpoints, there is
     39 support for this in Solaris (due to is RPC nature) and is easy to add to
     40 the Linux kernel (an ioctl on the mountpoint).
     41 
     42 - The Solaris 2.5 implementation of the autofs v1 protocol is NON-REENTRANT,
     43 and ignoring this limitation results in a DEADLOCK between the kernel and
     44 the daemon. This is a serious problem, although only for the lofs and link
     45 mount types. In other words, suppose the daemon is trying a lofs/link mount
     46 whose destination crosses another autofs mountpoint. If that mountpoint is
     47 not yet mounted, it will trigger another autofs lookup which will deadlock
     48 inside the kernel -- because the kernel is waiting for the previous request
     49 to return. This is not even something specific to amd, Sun's own automountd
     50 has the exact same problem. Ctrl-C breaks the deadlock, so it's not fatal,
     51 but the lofs/link entry is in effect unusable.
     52 
     53 - Solaris 2.8 (at least) doesn't like getting to get out-of-order replies to
     54 mount requests, and ignores the late ones. It's only a minor annoyance (read
     55 delay), because the RPC is retried by the kernel and it succeeds the second
     56 time around.
     57 
     58 * Solaris:
     59 
     60 - Amd w/ autofs mounts will fight over the listener port with Sun's
     61   automountd, so running both simultaneously is a really bad idea.
     62 
     63 - Browsable_dirs is possible and implemented for Solaris 2.6+.
     64 
     65 - Direct mounts are implemented and work correctly.
     66 
     67 - Host maps are implemented and work correctly.
     68 
     69 - On Solaris 2.6+, symlinks over autofs are inefficient. The kernel seems to
     70   time them out immediately after receiving them, so each access to a
     71   symlink causes a call to userspace. Needless to say, this negates the
     72   whole point of using autofs. Automountd seems to always use lofs mounts
     73   instead of symlinks, we do the same unless the admin requests
     74   "autofs_use_lofs = no" in amd.conf.
     75 
     76 - Solaris 2.5/2.5.1 do not support symlinks over autofs, so links are always
     77   mounted as lofs mounts, subject to the limitation described in the caveats
     78   section above.
     79 
     80 - Restarting autofs mounts is possible, but not yet implemented.
     81 
     82 * Linux:
     83 
     84 - Amd should work fine even when the Linux automounter is running, the
     85   mechanism being used prevents any kind of (evil) interaction between them.
     86 
     87 - Browsing is not available if autofs support is used, due to limitations in
     88   the kernel<->daemon protocol used by Linux 2.2 and 2.4. Only already-mounted
     89   nodes will appear in the autofs directory, and this is implemented entirely
     90   in the kernel.
     91 
     92 - Host maps are supported with all autofs versions.
     93 
     94 - Direct maps cannot be supported since there is no kernel support for them;
     95   we might be able to get something eventually, but don't hold your breath.
     96   If anything, we may do it using a regular NFS mountpoint and bind-mount on
     97   top of it.
     98 
     99 - Inherit doesn't make much sense because we can't restart a hung autofs
    100   mount point, due to kernel limitations. This needs to be fixed in the
    101   Linux kernel; it's not particularly difficult, and we might provide a
    102   patch at some point.
    103 
    104 - Link (and lofs) mounts will use the new bind-mount support in Linux
    105   2.4+. No more symlinks! And /bin/pwd works great too.
    106 
    107 - Auto maps are actually mounted as a separate autofs filesystem. Since each
    108   autofs filesystem consumes 2 file descriptors, and amd has at most 1024
    109   file descriptors available, there can be at most 512 of them mounted at
    110   the same time. Because of this, extensive use of auto maps is discouraged
    111   when using autofs on Linux.
    112 
    113 * amd.conf requirements:
    114 
    115 To tell amd to use an autofs-style mount point and mounts for a map, add
    116 
    117 	mount_type = autofs
    118 
    119 either to the global section, or to the sections of the individual maps you
    120 selected. Mixing autofs and normal amd mount points in the same amd.conf
    121 file *does* work.
    122 
    123 * Map changes:
    124 
    125 No changes are necessary. If a map is marked as autofs in amd.conf, mounts
    126 are done "in place" and the "fs" parameter is ignored most of the time.
    127 
    128 * Todo:
    129 
    130 We are looking for volunteers to improve the autofs code!
    131 
    132 (1) These fixes are needed:
    133 
    134 - sublinks are broken
    135 
    136 - when the mount type is 'link', transparently translate it into a loopback
    137 file system mount (lofs), that would mount in place, rather than supply a
    138 symlink, at least on systems whose autofs doesn't support symlinks. Linux
    139 does support symlinks, Solaris 2.6+ does too, but Solaris 2.5/2.5.1 doesn't
    140 and neither does IRIX 6. Moreover, Sun's automountd always uses lofs for
    141 link mounts, even on 2.6+, because symlinks are not cached in the kernel and
    142 thus are not particularly efficient. [done]
    143 
    144 - complain if certain incompatible options (autofs and ...) are used. Direct
    145 maps on Linux is one such case of incompatible options. Browsable_dirs on
    146 Linux is another such case.
    147 
    148 - if amd is killed or dies, the autofs mounts will remain intact as required
    149 (your system is _not_ hung, yay!).  However, if you restart amd, it will not
    150 correctly 'restart' the autofs mounts as the Sun automounter does.  Rather,
    151 it might cause another mount to happen, which leaves your /etc/mnttab
    152 cluttered with older mounts entries which cannot be unmounted. It might also
    153 just pretend everything is ok, when in fact it isn't.
    154 
    155 (2) Code expansion:
    156 
    157 - [Solaris only] implement the sockets version of amu_get_autofs_address()
    158 and create_autofs_service(), in conf/transp/transp_sockets.c. Not sure if
    159 it's necessary, Solaris it still biased towards TLI/STREAMS in
    160 userspace. [mostly done, untested, might be used on AIX 5.x+ and IRIX 6]
    161 
    162 - Implement the restarting of autofs mount points. This is already doable on
    163 Solaris; on Linux, the kernel needs to be patched to allow it.
    164 
    165 (3) Testing and porting to other systems:
    166 
    167 - nothing has been tested on IRIX 6, which reportedly has a similarly
    168 functioning autofs to Solaris 2.5.  The code compiles, but has not been run
    169 yet and is most likely broken.
    170 
    171 - support for Linux autofs is stable, we need testers!
    172 
    173 - support for Solaris 2.6+ is pretty stable, so we need testers for it, too!
    174 
    175 - we did not test any version of Solaris on x86. It will probably work, but
    176 you have been warned. Testers are welcome.
    177

README.ldap

      1 LDAP support for am-utils was originally done by Leif Johansson
      2 <leifj (a] it.su.se>.  He no longer maintains it.
      3 
      4 The current LDAP support for am-utils is for LDAPv2 only.  Reportedly,
      5 LDAPv3 mostly works.  Volunteers and patches are welcome.
      6 
      7 The IANA has assigned the following Private Enterprise Number to:
      8 
      9 	10180  Am-utils Organization   Erez Zadok	ezk (a] am-utils.org
     10 
     11 There are three files in this directory that relate to LDAP:
     12 
     13 ldap.schema:
     14 
     15 	This is the most current schema.
     16 
     17 ldap-id.txt:
     18 
     19 	This is an experimental schema for amd mount maps in LDAP.  Since
     20 	LDAP isn't maintained now, this code may not match with either the
     21 	current ldap_info.c code or with Amd mount maps in general.
     22 
     23 	The schema is written in the form of an internet-draft but it has
     24 	not been published as such.  We need volunteers who know and use
     25 	LDAP to clean it up and further its process of submission.
     26 
     27 ldap-id.ms:
     28 
     29 	This is the NROFF source of the draft.  To generate the text from
     30 	it, run "nroff -ms ldap-id.ms > ldap-id.txt"
     31 
     32 Erez.
     33 
     34 ------- Forwarded Message
     35 
     36 From: "IANA Private Enterprise Number" <iana-pen (a] icann.org>
     37 To: "Erez Zadok" <ezk (a] cs.columbia.edu>
     38 Subject: RE: Application for Enterprise-number (10180)
     39 Date: Sun, 15 Jul 2001 14:43:45 -0700
     40 
     41 Dear Erez,
     42 
     43 The IANA has assigned the following Private Enterprise
     44 Number to:
     45 
     46 10180  Am-utils Organization   Erez Zadok                 ezk (a] am-utils.org
     47 
     48 Please notify the IANA if there is a change in your contact
     49 or company information.
     50 
     51 Thank you,
     52 
     53 Bill Huang
     54 IANA - Private Enterprise Numbers
     55 
     56 ------- End of Forwarded Message
     57 
     58

README.osx

      1 Here some unconfirmed instructions for how to setup Amd on a MAC OS-X
      2 machine.  Please direct all comments about this information, as well fixes,
      3 updates, and corrections to the am-utils mailing list (see
      4 www.am-utils.org).
      5 
      6 Thanks,
      7 Erez.
      8 
      9 --cut--here----cut--here----cut--here----cut--here----cut--here----cut--here--
     10 
     11 
     12 Date: Fri, 28 Jan 2005 06:53:50 -0800
     13 From: Kevin Layer
     14 
     15 The stock amd didn't work for us in Mac OS X 10.3.
     16 Here's how we installed am-utils-6.1-20031025:
     17 
     18 ./configure --prefix=/usr
     19 make
     20 make install
     21 
     22 Create /System/Library/StartupItems/AMD with the files:
     23 
     24 AMD
     25 Resources/	-- copy from other directories in ..
     26 StartupParameters.plist
     27 
     28 Then, make sure that AMDSERVER=-YES- is added to /etc/hostconfig.
     29 
     30 ******************* the file AMD:
     31 
     32 #!/bin/sh
     33 
     34 ##
     35 # Start AMD
     36 ##
     37 
     38 . /etc/rc.common
     39 
     40 if [ "${AMDSERVER:=-NO-}" = "-YES-" ]; then
     41     ConsoleMessage "Starting AMD server"
     42 
     43     if [ ! -f /etc/amd.conf -a -r /etc/amd.conf.template ]; then
     44         cp /etc/amd.conf.template /etc/amd.conf
     45     fi
     46     if [ ! -f /etc/amd.map -a -r /etc/amd.map.template ]; then
     47         cp /etc/amd.map.template /etc/amd.map
     48     fi
     49     /usr/sbin/amd
     50 fi
     51 
     52 ******************* the file StartupParameters.plist:
     53 
     54 {
     55   Description     = "AMD server";
     56   Provides        = ("AMD");
     57   Requires        = ("Resolver");
     58   OrderPreference = "None";
     59   Messages =
     60   {
     61     start = "Starting AMD server";
     62     stop  = "Stopping AMD server";
     63   };
     64 }
     65 
     66 *******************
     67 
     68 With the beta's of 10.4 (64-bit) we're having issues with realpath()
     69 and amd mounted directories, but hopefully this is just a bug that
     70 they'll fix.
     71 
     72 --
     73 Kevin Layer                     http://www.franz.com/
     74 
     75

README.y2k

      1 		       AM-UTILS YEAR-2000 COMPLIANCE
      2 
      3 Most likely am-utils is y2k compliant.
      4 
      5 I do not know for sure because I have not certified am-utils myself, nor do
      6 I have the time for it.  I do not think that amd will be affected by y2k at
      7 all, because it does not do anything with dates other than print the date on
      8 the log file, in whatever format is provided by your os/libc --- especially
      9 the ctime(3) call.
     10 
     11 However, on Friday, September 18th 1998, Matthew Crosby <mcrosby (a] ms.com>
     12 reported that they evaluated 6.0a16 and found it to be compliant.
     13 
     14 On March 26, 1999, Paul Balyoz <pbalyoz (a] sedona.ch.intel.com> submitted a
     15 patch to lostaltmail which makes it print Y2K compliant dates.  He used a
     16 code scanner and manually "eyeballed" the code and could not find any more
     17 problems.  Paul's patch is included in am-utils-6.0.1s7 and newer versions.
     18 Paul also said that other 2-digit years used in am-utils are "harmless."
     19 
     20 NOTE: NONE OF THE PERSONS MENTIONED HERE, AUTHOR INCLUDED, ARE WILLING TO
     21 CERTIFY AM-UTILS AS Y2K COMPLIANT.  USE AT YOUR OWN RISK.
     22 
     23 ---
     24 Erez Zadok.
     25 Maintainer, am-utils package and am-utils list.
     26 Email: am-utils (a] am-utils.org
     27 WWW:   http://www.am-utils.org
     28