-
Notifications
You must be signed in to change notification settings - Fork 6
/
NOTES
231 lines (182 loc) · 8.44 KB
/
NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
CAP Installation notes
The Columbia University Appletalk Package is actually a rather broad
collection of libraries and programs. Following are some guidelines
in building the various programs and libraries.
Following are notes about the various components of CAP that require
special attention during installation or porting. Hopefully, we've
caught most of the major points, but there may be things missing.
Index:
CONFIGURATION
INSTALLATION
MACHINE SPECIFIC
LIBRARIES
SAMPLE PROGRAMS
CONTRIB
APPLICATIONS
*************
CONFIGURATION
*************
Configuration is somewhat automated. The configuration parameters are
divided into features and major and minor parameters. The major parameters
must be set to compile properly. The minor parameters are for
configuration of programs, etc.
To start off, you can run the "Configure" shell script to configure
the main parameters. One of the options in Configure allows you to edit
a file called 'm4.features'. This file is used to specify which of a set
of alternate features are included. For more details about the features,
see the README files in the patches subdirectories. Configure creates a
file called m4.setup. If necessary, you should then modify the secondary
(minor) parameters in this file.
Makefiles are generated from templates. m4.setup and m4.features define
variables used in the template. The command gen.makes builds the Makefiles.
Makefiles are included in all directories (Makefile) configured for
a standard BSD system. (Major configuration: bsd, no fastether,
needgetopt, no quotas). gen.makes creates "makefile" which should
be used in preference to "Makefile" on most machines.
Make sure you read "MACHINE SPECIFIC"! It points out os/machine
dependencies that are not handled by Configure.
************
DESTINATIONS
************
Or where do the files go? Generally, the defaults are:
/usr/local/cap - general programs
/usr/local/lib/cap - programs not for general use, data files
/usr/local/lib - libraries
/etc - some configuration files
Certainly machines do not search /usr/local/lib by default.
In these cases, the libraries are place in /usr/lib.
You should be modifying these in m4.setup.
************
INSTALLATION
************
A detailed procedure with testing mechanisms is defined in
doc/install.ms (a formatted copy is doc/install.doc).
However, you should peruse this document first.
****************
MACHINE SPECIFIC
****************
The current CAP distribution should work on:
BSD 4.2
BSD 4.3
Ultrix 1.0, 1.1, 1.2, 2.0 and hopefully 2.2
Sun OS 3.2 or higher
Pyramid's Unix under the BSD universe
ACIS 4.2 or 4.3 for the IBM RT PC
A/UX (using native AppleTalk with 2.0)
HP-UX for the series 9000 (release 6.0)
Encore (Multimax) (version unknown)
IRIS/IRIX for Silicon Graphics
AIX for the IBM 6000
and the majority should work under:
Convex Unix V6.1
and most should work with some manual work under:
HP-UX - release before 6.0
However, it should be noted that the baseline development system is
Ultrix 2.0 and things are tuned for that environment.
If your machine isn't listed, take a close look at the document
"PORTING" for things to watch out for.
On the pyramid, everything is compiled with the "-q" option to be
safe. "-q" tells it to pack the structures, possibly at the expense
of speed. SEE LOCKF below.
On the Encore Multimax, there are reports that the optimizer may be
overzealous. It may be wise to compile without optimization (or try
recompiling without optimization if there are problems).
On HP-UX, if you have an old release, you will have to define
"NEEDMSGHDR" in caposdefs in m4.setup as output by Configure. (You
can do it lib/cap/makefile, but that is not recommended).
On MORE/BSD, getgroups may return an array of gid_t instead of type
int. If this happens to be the case, you should edit aufsosdefs in
m4.setup and add:
-DGGTYPE="gid_t"
ALSO SEE LOCKF BELOW.
LOCKF - You should be careful here. Lockf is known to work properly
under Ultrix and A/UX. It should work okay under SunOS. There have
been reports of problems with lockf under Pyramid OSx and MORE/BSD.
If it is truly broken then you should comment out the "lockf in
system" in m4.setup. In other words, find the line:
define([X_LOCKF],1)
and put a "#" in front of it. If you do this and have already
compiled, then you should regenerate your makefiles with gen.makes,
regenerate libafp (lib/afp) making sure you recompile afposlock and
relink any programs that use libafp (currently samples/ash and
applications/aufs). Note that some systems may require a special
daemon for lockf to function (e.g. locking down outside the kernel).
Another problem may simply be the number of allowable locks in the
system.
Paul Campbell reports that AUX 1.0 goes to the disk for every call to
gettimeofday to validate the TZ information. In absched, a larger
number of gettimeofday calls are done that do not require TZ
information (even if they did require this information there are
better ways of doing things than going to disk on every call). To get
around this, the cap library LOCALTIME_GTOD says to call the function
_gettimeofday to grab the time only. This is noted here because
future versions of aux will probably require slightly different
handling.
On HP/Apollo Domain OS, CAP builds under the BSD 4.3 environment,
for Domain OS version 10.4. The main applications (aufs and
papif tested, lwsrv not tested) work on both 68K and 88K/PRISM
machines. The Domain OS syntax //node/path must be avoided in the
afpvol file. Note that this may result from the expansion of ~ if
home directories are defined using the full network syntax. The
problem is purely one of syntax, directories on other nodes may be
mounted using soft links or alternative syntax such as /../node/path.
You may want to modify the aufs man page to communicate this.
[Note: it is better for aufs (and other Unix software) if home
directories are defined without reference to //node and soft links
used between different nodes, so that ~ will never expand to the
unusual Apollo syntax.] Both flock, lockf and (if either the
APPLICATION_MANAGER or DENYREADWRITE options are chosen, see
netat/fcntldomv.h) undocumented fcntl range locking is used. Since
the underlying Domain file system handles locking, one hopes this
may all work -- but, from restrictions in the Domain file sytem,
perhaps not as well on files on remote nodes. If you primarily use
the System V environment but installed the BSD 4.3 environment, you
could probably build aufs, at least, under the BSD environment and
use it under System V.
*********
LIBRARIES
*********
There are three sets of libraries. The first is the core Appletalk
libraries. The second is the generic AFP libraries. The third is the
AFP client libraries. In the following we discuss some of the points
you should be aware of when building these.
CAP LIBRARIES
-------------
The core of CAP is the Appletalk libraries.
The major configuration parameter is for atalkdbm.c and tells it where
to find the atalk.local file. By default, it assumes
/etc/atalk.local, but can be reconfigured in m4.setup.
cap_conf.h contains a set of configuration parameters that defined
standard timeouts, etc, for protocols. At present, it only contains
parameters for PAP. You shouldn't need to touch this file.
AFP Libraries
-------------
o locking
The two defines for locking are "NOLOCKF" and "NOFLOCK" that should be
set appropriately for your machine. Most BSD systems should have
flock available. The only program that uses these calls is Aufs. For
the implications of what happens when you do or don't have these, see
the documentation on the various client and server (Aufs) programs.
In particular, see applications/aufs/INSTALLATION.
AFP Client Libraries
--------------------
You should be able to build afpc without any configuration changes.
***************
SAMPLE PROGRAMS
***************
You should be able to get away without modifying the default
compilation parameters. See samples/README for futher information.
***********
CONTRIBUTED
***********
See contrib/README for further information.
************
APPLICATIONS
************
See the README files in the various directories for further
information about configuration of these programs.
It is highly recommended that you look at the default configuration
for Aufs. This holds in particular if you are not running a virgin
BSD4.3 or BSD 4.2 system (have NFS added, etc): there is a good chance
you can configure parameters in that will result in better performance
and/or more functionality.