[3055] in SIPB-AFS-requests
Re: Proceeding with new-rosebud
daemon@ATHENA.MIT.EDU (John Hawkinson)
Mon Jul 13 17:42:42 1998
Date: Mon, 13 Jul 1998 17:42:31 -0400 (EDT)
To: mhpower@MIT.EDU
Cc: sipb-afsreq@MIT.EDU
In-Reply-To: "[3052] in SIPB-AFS-requests"
From: John Hawkinson <jhawk@MIT.EDU>
| >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.
I must admit that stating 'happiest and best' is an exaggeration.
Nevertheless, I do think it's happy and good. See below.
| 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).
With the notable exception of the operating system.
| 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.
To the best of my knowledge, we have access to the build area used
to produce the binaries run in the athena cell. I think that if we
can confirm that this is the case and verify that those binariesf
and builds won't be expected to change out from under us, then
that nullifies most concerns.
| 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 think that's true, but it's also advantageous to be able to demonstrate
that any bugs we encounter were not artifacts of a custom SIPB build
process. This is particularly useful if we encounter bugs and problems
and wich MIT to put pressure on Transarc to fix them.
It appears that /mit/afsdev/bld* are acl'd to builder:afs-read, which
few SIPB afs cell maintainers are on. I imagine that's easy to fix,
for those on source-access. Greg, would you concur?
On the other hand, it looks like /mit/afsdev/bld.34a changed
quite recently (today!), so perhaps my assertion that things change
infrequently and not without notice is incorrect.
I'd be curious to see what Jonathon has to say on this point. ... It
might be worth examining the SIPB zephyr logs for -c sipb -i ops
today. I am now much less certain of the correct stance to be in, and
would want to see some psuedoguarantees from {somebody}. I made a
copy of the backup volumes of ~afsdev/bld into the zone cell, since
I'm somewhat concerned about ops' afs build tree.
| > ..., 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.
Actually, I beg to differ. I think that if we were successful in
encapsulating the machine's configuration in an epic poem and passing that
down through generations of SIPB members via an oral tradition, it would
be commendable, valuable, and forth funding.
| 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.
Seriously, though, stating things in terms of functional requirements
is useful, I agree.
| 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?
It's reasonable, but I don't consider it quite sufficient.
| 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?
I would like to see something like that. Maybe it's too much work.
I'm not sure.
| Should we keep the modified file, the original file, and a pointer
| to the source code used to generate each of them?
If we have access to it, that'd be nice.
Greg observes:
/ I think mainly what we're missing is a way of figuring out what
/ software (stuff under /afs/sipb/service) and OS patches are installed
/ on a machine. It's probably sufficient to instate a file under
/ /afs/sipb/machine/servername which gives that information.
I think that's important too.
I'd basically like to have a procedure that lets us install a
machine (afs server, whatever), without going through days-drawn-out-agony.
and severe questioning.
If there was some confidence that all we had to do was:
Install the machine.
Apply vendor patches.
Do a recursive rcsdiff over /afs/sipb/machine/... and feed
it to (cd /; patch -p0) on the new machine
that would be cool. I'm not sure we're there yet.
Despite what I said earlier:
\ While this doesn't have to be (and probably cannot reasonbly be) as
\ self-contained as mkserv,
and Greg said:
/ I agree that SIPB doesn't want little configuration changes to involve
/ a lot of voodoo (like editing mkserv scripts), and I think the two
I'm seriously wondering whether mkserv isn't the best solution.
I realize I didn't completely define my requirements in a terribly
stellar or clear fashion, but hopefully they're clear enough.
--jhawk
