+Installation Notes for Amd.
+
+NOTE: Please read all of this before starting.
+ It is not very long and may save you time in the long term.
+
+1. ``Getting started...''
+
+If you got this release in a shar file then run the shell script Configure in
+the top directory. If you got this release in a tar file then you are all
+set (though if you feel left out you can run Configure anyway).
+
+2. ``Find out what version of UN*X you are running...''
+
+To install Amd you need a port for your version of UN*X. In this directory
+are several files called os-*.h. One of these should correspond to your
+version of UN*X. Look at the comments at the top of each file to determine
+which one applies to you. If none of them do, then either no-one has yet
+done a port, or your version of UN*X is so braindead that a port is not
+possible (e.g. System V without reliable signals). Run the program
+"config/os-type" in the current directory to see whether you and Amd are in
+agreement about your operating system type. The current known operating
+systems (grouped by architecture) are:
+
+ acis43 (AOS) ACIS 4.3BSD on an IBM RT
+ aix3 AIX 3.1
+ aux Apple A/UX
+ bsd44 4.4 BSD on whatever
+ concentrix Concentrix on an Alliant
+ fpx4 Celerity FPX 4.1/2
+ hlh42 4.2 BSD on HLH Orion 1/05
+ hpux HP-UX 6.* and 7.* on a HP9000/300
+ riscix 4.3 BSD on an Acorn Archimedes
+ sos3, sos4 SunOS 3.* and 4.* on a Sun-3 and Sun-4
+ u2_2 Ultrix 2.2 (or 2.*?) on a VAX (broken)
+ u3_0 Ultrix 3.0/4.0 (or 3.*?) on a VAX
+ umax43 4.3 BSD on an Encore Multimax
+ utx32 UTX/32 Rel2.1a on a Gould (not yet complete)
+ xinu43 More/BSD (4.3 BSD) on a VAX or HP9000/300
+
+ + some others...
+
+If you do define a new operating system type foo, you may care to create a
+file called Makefile.foo which defines the special Makefile parameters.
+
+3. ``Hacking the Makefile...''
+
+Some UN*X programs come with a Makefile which has to be manually configured
+for your particular operating system and hardware. However, Amd tries very
+hard to determine what type of machine you are using and how best to compile
+itself. If this does not work then you will have to find some heuristic
+which can differentiate your configuration. You may need to edit
+"config/arch" and "config/os-type". If you do make sure your changes can
+cope if /etc/motd is missing and please send it to the address below.
+
+You may care to tailor some site specific preferences in "Makefile.com". The
+variables most likely to be changes are at the top. Any changes are best put
+in the file Makefile.local (if they are applicable to all operating systems
+at your site) or Makefile.local.foo (where foo is the OS type as determined
+in part 1).
+
+Additionally, some configuration options may be altered in
+"config/Makefile.config". This means that you should not need to edit any
+distributed files apart from "config/Makefile.config". As a minimum, you
+should check:
+
+* You are using the correct C compiler. Amd, as shipped, does not use GCC.
+ Note that using GCC version 1.34 or later (e.g. 1.36) gives structure
+ passing problems with some parts of Sun's RPC library at least on Sun-4's.
+ The current workaround is to use the system CC to compile the part of the
+ automounter that gets hit by this problem. [[This is not the same problem
+ that is fixed by -fpcc-struct-return.]] Amd contains no "register"
+ declarations, so using old PCC based code generators is probably bad news.
+
+* The installation directory (ETC) is set up correctly.
+
+* If you are running tests then it may be worth switching on the DEBUG flag
+ which will cause a running commentary to be printed to the log file.
+
+4. ``Build the executable...''
+
+Now you need to compile the automounter. To do this you type:
+
+ make
+
+If you are porting to a new machine you may want to do:
+
+ make OS=foo
+
+where foo is the name of your version of UN*X as determined in part 1, until
+you have made the changes to config/os-type and/or config/arch. When the
+compilation is complete you will end up with a program called "A.arch_foo/Amd".
+
+Try running:
+
+ A.arch_foo/amd -v
+
+and check the output. It should look something like:
+
+ amd 5.2 of 90/06/23 23:55:04 Rel5.2 #0: Sat Jun 23 16:24:42 PDT 1990
+ Built by pendry@okeeffe.Berkeley.EDU for a tahoe running bsd44 (big-endian)
+ Map support for: root, passwd, nis, file, error.
+
+Make sure the O/S and architecture types were correctly derived during the
+build.
+
+5. ``Installation...''
+
+If you are not just testing Amd, then you can install it by typing:
+
+ make install
+
+to install "A.arch_foo/Amd" in "/usr/local/etc/amd" (or as otherwise
+modified in part 2).
+
+6. ``Update /etc/rpc''
+
+Amq uses Sun RPC to talk to Amd using program number 300019 which has
+been registered with Sun. Add the following lines to /etc/rpc or your
+YP or Hesiod master:
+
+# Automount control protocol
+amd 300019 amq
+
+7. ``Hanging your machine...''
+
+WARNING: THIS MAY HANG YOUR MACHINE IF YOU GET IT WRONG.
+
+Running Amd with a carelessly thought out mount map can cause your Amd to
+enter a deadlock inside the kernel. For example, attempting to automount a
+directory which is automounted can cause the automounter to issue a mount
+request causing the kernel to send an NFS request back to the same automounter,
+which is currently stuck in a system call and unable to respond - even
+kill -KILL won't get you out of this one.
+
+There is nothing you can do to fix it without rebooting your machine, so...
+
+Find a diskless workstation and play with that first before trying this on
+your main 200 user service machine (unless you hate your users). Something
+like a diskless Sun-4 is best for development testing - you can compile on a
+Sun-4 server and run the binary on the diskless node. They reboot very fast
+as well between tests.
+
+Now you can try running Amd. Please read the documentation in doc/Amd.tex
+for more details. The configuration file "a_master" provides a sample for
+you to play with. Something like:
+
+ ./amd -c 40 -D test,nodaemon /tmp/amnt a_master &
+
+is good for testing. Note that Amd will clean up correctly if you send it a
+SIGINT or SIGTERM. Other signals are either ignored or will blow it away,
+leaving your machine in a potentially dangerous state - usually a reboot is
+all that is required to fix it though ;-)
+
+Remember that Amd needs to run as root in order to do mounts/unmounts though
+it does check this condition somewhere near line one of main(). It will also
+need write permission in the working directory if you have built it with
+DEBUG defined. Watch out for NFS stepping in and mapping root to nobody.
+
+8. ``Report what happened...''
+
+If anything interesting happened, eg it didn't work, please report it to me
+-- Jan-Simon Pendry <jsp@doc.ic.ac.uk> -- as detailed in the README file.
+
+KNOWN PROBLEMS - Contact me for more details
+
+* Amd does not work correctly on a DecStation 3100 system running Ultrix 3.1.
+ This is a bug in Ultrix. Quite how the Ultrix mount command works is a
+ total mystery, but in any case the mount system call does not behave as
+ documented. Possibly fixed in Ultrix 4.0?
+
+* It is reported that amd deadlocks the kernel on a Sequent Symmetry.
+ Obviously this is a kernel bug.
+
+$Id: INSTALL,v 5.2 90/06/23 22:21:31 jsp Rel $
projects / unix-history / commitdiff