[3229] in SIPB-AFS-requests
Re: migrating rosebud to a Sun
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Sat Jan 16 19:44:37 1999
Date: Sat, 16 Jan 1999 19:44:31 -0500
From: mhpower@MIT.EDU
To: mwhitson@MIT.EDU
Cc: zacheiss@MIT.EDU, sipb-afsreq@MIT.EDU
In-Reply-To: "[3228] in SIPB-AFS-requests"
>You feel we should:
> - keep all of the servers' /os and /srvd local on the servers,
Yes. I think the needed (about) 1 Gb of disk space is a very small
expense compared to the benefit of having nearly everything available
locally in case there's a situation that needs it.
> based on a canonical tree in the sipb cell
No, I don't think it's necessary to have copies of /os and /srvd
stored somewhere under /afs/sipb.mit.edu. I'm not opposed to making
a copy there, but I think it's adequate to have a backup copy of /os
and /srvd either on a tape or a ufs disk in the machine room. (The
backup would have /os and /srvd with patches applied and thus would
not necessarily be the same as any copy in the athena or dev cells.)
>Recreating a server using the ASO instructions and scripts, in my
>opinion, takes equal or less time than recovering the system disk from
>tape backup would.
Well, certainly an option that would take less time is worth looking
at. But, I'm not sure what you mean by "my opinion" of how much time
it would take to recover a system disk. Do you mean "my estimate"? (To
me, "my opinion" suggest that maybe the current ASO instructions and
scripts haven't ever been used, but I definitely would expect they
have been used, and possibly someone even remembers the time needed.)
> * I will contend that the set of instructions and scripts ASO
>uses for creating an AFS server are clear enough ...
Do you know if the current set of instructions and scripts is
considered public, or if sipb could obtain a copy of them and
distribute them to whatever members and prospectives it wished? Or is
it possibly the case that ASO or another part of IS would prefer to
give persons access to the instructions and scripts at its discretion?
I'd like to look at these, if possible, or at least get some
clarification of what the ASO model is. You said it was:
> ... the ASO model (mostly remote system
>packs and mkserv)
whereas in Garry's mail on January 9 he wrote:
> ... The
>setup currently used in the athena, dev, ops, and zone cells calls for
>all the necessary/useful parts of the syspacks to be copied local with
>synctree, something that could be done easily with mkserv or a
>.private.sync file. RVDCLIENT is then set to false in rc.conf, and the
>machine does not attach packs.
I would think that either a machine uses remote system packs, or it
doesn't. Is Garry referring to an "athena, dev, ops, and zone cell
model" that's different from the "ASO model"?
Or possibly you mean that, on servers with this type of installation,
if I needed to run a program that didn't happen to be among those
designated necessary/useful, it'd be expected that I'd just figure out
a full afs path, e.g., /afs/athena/system/sun4x_56/srvd/usr/athena/bin?
Another specific aspect that I don't yet understand is whether both
the "ASO model" and the "dialup model" include applying Sun
recommended patches, or only the latter. I suppose one might make the
argument that, on an afs server, no account other than root is ever
used, and no network processes will ever run that depend on
Sun-supplied application software, so all (or nearly all) Sun
recommended patches are irrelevant. Is that what the patch situation
is, or does a non-dialup system-disk recovery involve applying some
Sun patches (I'd expect that we have no guarantee that Sun's procedure
for applying patches will remain the same in the future)?
> * To set up this system, we would need to go to a lot of
>trouble, including setting up backup software and scripts, possibly
>buying a tape drive, and developing instructions and procedures ...
I'd expect that the software and documentation would be the same for
any sipb server running SunOS 5, and similar for other servers. We
backup other servers with software that basically requires only perl
and Gnu tar, both of which work well on SunOS 5.6. In any case, I
don't think this is adding work that's specific to maintaining the
sipb afs cell. Having more people know how to restore sipb servers
from backups is generally useful, regardless of whether the final
outcome is to backup afs servers' system disks or not.
Also, I don't want to suggest that buying a new tape drive should
necessarily occur before deploying any new server machines. If we
think it would be worthwhile, it could be added later (with, up until
then, some potential inconvenience to the people who do backups using
the tape drive in the sipb office). Definitely the lack of a new tape
drive would not be a reason to delay deploying an afs server until
during the spring term.
Finally, one side issue:
>Subject: Re: migrating rosebud to a Sun
>To: sipb-afsreq@MIT.EDU
>Cc: zacheiss@MIT.EDU
>From: Mike Whitson <mwhitson@MIT.EDU>
>In-Reply-To: mhpower@MIT.EDU's message of Mon, 11 Jan 1999 14:46:27 -0500
>
>Matt: I just read and reread your mail three times, ...
When replying to a message, to me it seems customary to include the
sender of that message as one of the recipients of your reply. I
didn't include a "Reply-To: sipb-afsreq@MIT.EDU" header line...
Matt
