[comp.protocols.kerberos] NFS uid-map modifications available via archive server

jtkohl@ATHENA.MIT.EDU (John T Kohl) (04/14/89)

Sun Microsystems has graciously allowed MIT Project Athena to distribute
NFS modifications in 'diff' form.

These modifications create a 'mapping table' in an NFS server's kernel,
which is used to map the {ip addr, uid} of an NFS request into a
{uid, gidset} tuple to be used to determine access permission to files
on the NFS server.

Kerberos is used to mediate manipulation of this mapping table from the
network.  A tool is also provided to manipulate this mapping table
from a login session on the server.

This set of diffs and original code is available only by electronic mail.

To retrieve it, send a message to archive-server@ATHENA-DIST.MIT.EDU.
The message should contain a line like this:
	send krb-nfs uidmap.pt1.shar uidmap.pt2.shar

For information on what other things are available from the archive
server, send it messages containing lines like:
	help		(for info on how the archive server works)
	index		(for an index of what is available)

If you have trouble receiving replies from the archive server (it should
send an acknowledgement of your request within 1/2 hour of receipt), try
including a return path from ATHENA-DIST.MIT.EDU, by including a line
such as
	path garp!youruucphost!yourname

MX record handling is known to be flaky on the mailer on ATHENA-DIST.

The archive server contains many safeguards to ensure that it is not
monopolized by people asking for large amounts of data. The mailer is set up
so that it will send no more than a fixed amount of data each day. If the
work queue contains more requests than the day's quota, then the unsent files
will not be processed until the next day. Whenever the mailer is run to send
its day's quota, it sends the requests out shortest-first.

If you have a request waiting in the work queue and you send in another
request, the new request is added to the old one (thereby increasing its
size) rather than being filed anew. This prevents you from being able to
send in a large number of small requests as a way of beating the system.

jtkohl@ATHENA.MIT.EDU (John T Kohl) (04/15/89)

It turns out that the archive server doesn't like sending multiple shar
archives in a single request (to avoid possible problems with nested
shar's), so if you want the NFS code, you should send two separate
requests (it is best to wait for delivery of the first before asking for
the second):
	send krb-nfs uidmap.pt1.shar
then
	send krb-nfs uidmap.pt2.shar

Also, I didn't point this out explicitly, but this distribution will
probably be of little use if you don't have NFS source.

John

clyde@ut-emx.UUCP (Clyde W. Hoover) (04/17/89)

But why can't I just anonymous FTP this stuff?

Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas  
	clyde@emx.utexas.edu; ...!cs.utexas.edu!ut-emx!clyde

Tip #268: Don't feel insecure or inferior! Remember, you're ORGANIC!!
	  You could win an argument with almost any rock!