[691] in Kerberos

home help back first fref pref prev next nref lref last post

NFS uid-map modifications available via archive server

daemon@TELECOM.MIT.EDU (John T Kohl)
Fri Apr 14 11:10:06 1989

From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU

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.

home help back first fref pref prev next nref lref last post