|
|
1.1 root 1: Installation Notes for Amd.
2:
3: NOTE: Please read all of this before starting.
4: It is not very long and may save you time in the long term.
5:
6: 1. ``Getting started...''
7:
8: If you got this release in a shar file then run the shell script Configure in
9: the top directory. If you got this release in a tar file then you are all
10: set (though if you feel left out you can run Configure anyway).
11:
12: 2. ``Find out what version of UN*X you are running...''
13:
14: To install Amd you need a port for your version of UN*X. In this directory
15: are several files called os-*.h. One of these should correspond to your
16: version of UN*X. Look at the comments at the top of each file to determine
17: which one applies to you. If none of them do, then either no-one has yet
18: done a port, or your version of UN*X is so braindead that a port is not
19: possible (e.g. System V without reliable signals). Run the program
20: "config/os-type" in the current directory to see whether you and Amd are in
21: agreement about your operating system type. The current known operating
22: systems (grouped by architecture) are:
23:
24: acis43 (AOS) ACIS 4.3BSD on an IBM RT
25: aix3 AIX 3.1
26: aux Apple A/UX
27: bsd44 4.4 BSD on whatever
28: concentrix Concentrix on an Alliant
29: fpx4 Celerity FPX 4.1/2
30: hlh42 4.2 BSD on HLH Orion 1/05
31: hpux HP-UX 6.* and 7.* on a HP9000/300
32: riscix 4.3 BSD on an Acorn Archimedes
33: sos3, sos4 SunOS 3.* and 4.* on a Sun-3 and Sun-4
34: u2_2 Ultrix 2.2 (or 2.*?) on a VAX (broken)
35: u3_0 Ultrix 3.0/4.0 (or 3.*?) on a VAX
36: umax43 4.3 BSD on an Encore Multimax
37: utx32 UTX/32 Rel2.1a on a Gould (not yet complete)
38: xinu43 More/BSD (4.3 BSD) on a VAX or HP9000/300
39:
40: + some others...
41:
42: If you do define a new operating system type foo, you may care to create a
43: file called Makefile.foo which defines the special Makefile parameters.
44:
45: 3. ``Hacking the Makefile...''
46:
47: Some UN*X programs come with a Makefile which has to be manually configured
48: for your particular operating system and hardware. However, Amd tries very
49: hard to determine what type of machine you are using and how best to compile
50: itself. If this does not work then you will have to find some heuristic
51: which can differentiate your configuration. You may need to edit
52: "config/arch" and "config/os-type". If you do make sure your changes can
53: cope if /etc/motd is missing and please send it to the address below.
54:
55: You may care to tailor some site specific preferences in "Makefile.com". The
56: variables most likely to be changes are at the top. Any changes are best put
57: in the file Makefile.local (if they are applicable to all operating systems
58: at your site) or Makefile.local.foo (where foo is the OS type as determined
59: in part 1).
60:
61: Additionally, some configuration options may be altered in
62: "config/Makefile.config". This means that you should not need to edit any
63: distributed files apart from "config/Makefile.config". As a minimum, you
64: should check:
65:
66: * You are using the correct C compiler. Amd, as shipped, does not use GCC.
67: Note that using GCC version 1.34 or later (e.g. 1.36) gives structure
68: passing problems with some parts of Sun's RPC library at least on Sun-4's.
69: The current workaround is to use the system CC to compile the part of the
70: automounter that gets hit by this problem. [[This is not the same problem
71: that is fixed by -fpcc-struct-return.]] Amd contains no "register"
72: declarations, so using old PCC based code generators is probably bad news.
73:
74: * The installation directory (ETC) is set up correctly.
75:
76: * If you are running tests then it may be worth switching on the DEBUG flag
77: which will cause a running commentary to be printed to the log file.
78:
79: 4. ``Build the executable...''
80:
81: Now you need to compile the automounter. To do this you type:
82:
83: make
84:
85: If you are porting to a new machine you may want to do:
86:
87: make OS=foo
88:
89: where foo is the name of your version of UN*X as determined in part 1, until
90: you have made the changes to config/os-type and/or config/arch. When the
91: compilation is complete you will end up with a program called "A.arch_foo/Amd".
92:
93: Try running:
94:
95: A.arch_foo/amd -v
96:
97: and check the output. It should look something like:
98:
99: amd 5.2 of 90/06/23 23:55:04 Rel5.2 #0: Sat Jun 23 16:24:42 PDT 1990
100: Built by [email protected] for a tahoe running bsd44 (big-endian)
101: Map support for: root, passwd, nis, file, error.
102:
103: Make sure the O/S and architecture types were correctly derived during the
104: build.
105:
106: 5. ``Installation...''
107:
108: If you are not just testing Amd, then you can install it by typing:
109:
110: make install
111:
112: to install "A.arch_foo/Amd" in "/usr/local/etc/amd" (or as otherwise
113: modified in part 2).
114:
115: 6. ``Update /etc/rpc''
116:
117: Amq uses Sun RPC to talk to Amd using program number 300019 which has
118: been registered with Sun. Add the following lines to /etc/rpc or your
119: YP or Hesiod master:
120:
121: # Automount control protocol
122: amd 300019 amq
123:
124: 7. ``Hanging your machine...''
125:
126: WARNING: THIS MAY HANG YOUR MACHINE IF YOU GET IT WRONG.
127:
128: Running Amd with a carelessly thought out mount map can cause your Amd to
129: enter a deadlock inside the kernel. For example, attempting to automount a
130: directory which is automounted can cause the automounter to issue a mount
131: request causing the kernel to send an NFS request back to the same automounter,
132: which is currently stuck in a system call and unable to respond - even
133: kill -KILL won't get you out of this one.
134:
135: There is nothing you can do to fix it without rebooting your machine, so...
136:
137: Find a diskless workstation and play with that first before trying this on
138: your main 200 user service machine (unless you hate your users). Something
139: like a diskless Sun-4 is best for development testing - you can compile on a
140: Sun-4 server and run the binary on the diskless node. They reboot very fast
141: as well between tests.
142:
143: Now you can try running Amd. Please read the documentation in doc/Amd.tex
144: for more details. The configuration file "a_master" provides a sample for
145: you to play with. Something like:
146:
147: ./amd -c 40 -D test,nodaemon /tmp/amnt a_master &
148:
149: is good for testing. Note that Amd will clean up correctly if you send it a
150: SIGINT or SIGTERM. Other signals are either ignored or will blow it away,
151: leaving your machine in a potentially dangerous state - usually a reboot is
152: all that is required to fix it though ;-)
153:
154: Remember that Amd needs to run as root in order to do mounts/unmounts though
155: it does check this condition somewhere near line one of main(). It will also
156: need write permission in the working directory if you have built it with
157: DEBUG defined. Watch out for NFS stepping in and mapping root to nobody.
158:
159: 8. ``Report what happened...''
160:
161: If anything interesting happened, eg it didn't work, please report it to me
162: -- Jan-Simon Pendry <[email protected]> -- as detailed in the README file.
163:
164: KNOWN PROBLEMS - Contact me for more details
165:
166: * Amd does not work correctly on a DecStation 3100 system running Ultrix 3.1.
167: This is a bug in Ultrix. Quite how the Ultrix mount command works is a
168: total mystery, but in any case the mount system call does not behave as
169: documented. Possibly fixed in Ultrix 4.0?
170:
171: * It is reported that amd deadlocks the kernel on a Sequent Symmetry.
172: Obviously this is a kernel bug.
173:
174: $Id: INSTALL,v 5.2 90/06/23 22:21:31 jsp Rel $
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.