[3052] in SIPB-AFS-requests
Re: Proceeding with new-rosebud
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Mon Jul 13 03:13:30 1998
From: mhpower@MIT.EDU
To: jhawk@MIT.EDU
Cc: sipb-afsreq@MIT.EDU
In-Reply-To: "[3050] in SIPB-AFS-requests"
Date: Mon, 13 Jul 1998 03:13:14 EDT
>Building our own is discouraged since I think everything is happiest and best
>if the SIPB cell runs the same binaries as the Athena cell.
I don't understand why you feel this would be happy or good. For
nearly all other sipb services, sipb has built the binaries of the
programs used to provide the service (I think there's one exception
but only on decstations). Having a complete build tree of afs-server
software of our own would seem to be valuable in many potential
circumstances, such as when we come up with patches for remotely
exploitable fileserver security holes.
I can see that we'd want to have server binaries that provide exactly
the same functionality except for clients that are trying to exploit
security holes or do denial of service. For example, I think that
people who administer multiple afs cells at MIT might generally prefer
that the same command not have different effects when run on different
cells. But I don't believe the afs-server software is quite delicate
enough that this can only be achieved by running the same binaries.
> ..., I would like to avoid the situation where in order to duplicate
>a machine's configuration, either a disk needs to be copied from
>another machine, or tens or scores of discuss transactions must be found
>and read through to track changes.
And I believe we also want to avoid the situation where the machine's
configuration is encapsulated in an epic poem that is passed down
through generations of sipb members via an oral tradition. Maybe
rather than stating what method you think should not be used for
recording the machine's configuration, you could suggest what method
you think should be used. For example, sometimes if /path/to/file is
changed on a machine's local disk, then the change is recorded in a
file named /afs/sipb/machine/server-name/path/to/file. Is this among
what you would consider "reasonable" or not? Should we instead store
both the modified file and also diffs between the modified file and
whatever file was in the original release used on the machine? Should
we instead store a script that has the effect of installing the
modified file? Should we keep the modified file, the original file,
and a pointer to the source code used to generate each of them?
Matt
