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
|
Compilation:
The first step in running this fine software (:) is to get it to
compile. Every effort on my part will be made to make this code
compile and run on any reasonable system. The information in this
file CURRENTLY pertains only to Unix users, as I don't have the
VMS experience required to create this code on those systems.
The first step is to run the configure script provided in this
directory. This will generate a good makefile and a file called
tweak.h in the include directory. These files are vital for the
compilation of the system.
You must also edit the files include/client_conf.h and
include server_conf.h as they contain parameters which must
still at this point be manually set by the person compiling
the code.
>> By default, the configure script will set up the Makefile
>> to install the code in /usr/local/bin and the man pages under
>> /usr/local/man. If you wish to change this, you MUST run
>> configure with the --prefix option. For instance, on my
>> machine, I install the files under /usr/jt/bin and /usr/jt/man.
>> To do this, I type configure --prefix=/usr/jt
At this point, you should just be able to type 'make' (or
'make merge' in you are compiling the merged clients) and
then 'make install' (or 'make install-merge'). This will
compile and (if you do an install) install the clients
in the directory specified by you in the Makefile. You
may also wish to type 'make install-man' if you wish to
install the manual pages.
If you get ANY errors or warnings while compiling this code
(excepting warnings about the function signal), please send
me email (at jtraub@cs.cmu.edu) with a complete copy of the
output of make as well as a copy of the tweak.h file and the
Makefile. These will be required for me to even attempt to
track down the bug, and if they aren't included, I most likely
won't be able to.
IMPORTANT NOTE: You do not need to run the fspd process if you only
wish to access existing fsp archives. FSPD is only needed if you
wish to set up and maintain a new archive for use.
Client utilities:
All inter-command states are kept in these three shell environment
variables.
FSP_PORT Port number of the fspd you wish to contact.
FSP_HOST Host name or number of the fspd.
FSP_DIR Your current working directory in the archive.
When multiple client utilities are run at the same time on the
same client machine, packet multiplexing mechanisms can be used
to enable concurrent access to the same fsp database. If none
of the mechanisms are selected at compile time, FSP_LOCALPORT
can be used to ensure that only once client utility can run at
any time. In this case, FSP_LOCALPORT can be set to any port
number not current used on the client machine.
FSP_TRACE can be set if you want status reports be printed while
files are being transferred.
FSP_DELAY variable can be used to set the retransmit interval for
client utilities (in thousandth of a second). The retransmit rate
is adjusted in an exponential manner, until the retry rate reaches
5 minutes per retry. This delay cannot be set below 250 usecs.
FSP_BUF_SIZE can be set to a positive number less than or equal
to 1024. When set, it determines the size of data to be send for
each request during file and directory information transfer. The
default is 1024. Some sites are connected via links that cannot
transmit buffers containing 1024 bytes of data in addition to the
header information. Setting FSP_BUF_SIZE to a lower value will
allow these sites to access fsp archives.
FSP_LOCAL_DIR can be set to a local working directory from/to which
all data will be transferred.
Server Administration:
The only things you need for setting up a FSP server is a work
directory for the service the FSP server itself (fspd) and
an fspd.conf file in the place you specified in include/server_conf.h.
To create an fspd.conf file, copy the example.conf file
provided to the correct place and edit to suit your tastes.
fspd can run independently or it can be run under inetd. When
running independently, fspd waits for messages through a UDP
socket whoes port number is defined in the fspd.conf file.
When runing under inetd, fspd is invoked as in.fspd. Inetd will
spawn fspd when a message arrives for the FSP socket. The fspd
process will take over and stick around to wait on additional
messages. After 2 minutes pass with no messages, fspd will exit
and return control to inted.
Sample setup for inetd operation:
In /etc/services file:
fsp 21/udp fspd
In /etc/inetd.conf file:
fsp dgram udp wait ftp /usr/etc/fspd in.fspd
In this sample, the same port number for ftp is used for the
fsp socket. There will not be a conflict because ftp uses
stream protocol, and fsp uses UDP protocol. The fspd program
in this example is ran under user 'ftp'.
Many other options controlling the behavior of fspd can be set in
the fspd.conf file. Please read the comments in the example.conf
file for details.
FSPD provides directory security through a series of . files created
in the directories serviced by fspd. These files are invisible to
the clients, and can (mostly) be changed via the fprocmd client
utility (or by the server administrator manually). The only file
that can not be changed in this manner is the ownership of a
directory. The files and their meanings are:
.OWN.XXXXXXXX specifies that the machine whose IP number is
encoded as XXXXXXXX owns the directory. The owner
of a directory automatically has all other rights to
a directory and is the only one that can change the
other protections. It is created when a directory
is initially created in the archive via fmkdir.
.FSP_OK_DEL Grants any client the permission to delete any file
from the current directory.
.FSP_OK_ADD Grants any client the permission to add new files to the current directory.
.FSP_OK_MKDIR Grants any client the permission to create new sub-
directories under the current directory owned by
the client creating the directory.
.FSP_PRIVATE If this file exists, only the owner of the directory
is allowed to read the contents of the files in the
directory. Subdirectories of this directory will
inherit the privacy protection.
Clients do not get to read the directory information directly.
Instead, fspd maintains a directory listing for each directory
in a cache file. If the directory is writable by fspd, or if a
writable file in it is prepared beforehand, fspd will store the
directory information in .FSP_CONTENT file in that directory.
Otherwise, it will store the information in a pair of files (with
hashed names) in a special directory specified in the fspd.conf
file. The latter allows read-only directories to be exported.
When a client requests information for a directory, the cache
file is created if it doesn't exist, and it is rebuilt if it is
out of date. The information is accessed by having the client
read the directory listing file. Care is taken so that the client
will not get corrupted entries when the directory is changed while
the listing is being read.
Files being uploaded are first written to a temporary file in the
work directory: .TXXXXXXXXYYYY where XXXXXXXX is the inet number
of the client, and YYYY is the port number of the client program.
When upload is compelete, the file is moved into the intended
location.
Sending it an 'alarm' signal will cause fspd to dump its current
client database into the file .HTAB_DUMP in the work directory.
This can be useful for debugging and for catching rogue clients.
|
