[3230] in SIPB-AFS-requests
Re: migrating rosebud to a Sun
daemon@ATHENA.MIT.EDU (Mike Whitson)
Sun Jan 17 03:48:41 1999
To: sipb-afsreq@MIT.EDU
Cc: zacheiss@MIT.EDU, mhpower@MIT.EDU
From: Mike Whitson <mwhitson@MIT.EDU>
Date: 17 Jan 1999 03:48:33 -0500
In-Reply-To: mhpower@MIT.EDU's message of Sat, 16 Jan 1999 19:44:31 -0500
mhpower@MIT.EDU writes:
> 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.
I believe the effective expense increases significantly when we take
into account the delays to this upgrade involved in acquiring the disk
and setting it up.
> >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.)
Creating an AFS server's system disk using ASO's procedures takes
approximately one hour (this can vary based on network traffic and
many other variables). I do not have information on how long it would
take to perform the same procedure using your suggested setup, so I
must make an educated guess when attempting to compare them. Hence
"in my opinion."
> 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 don't believe there's currently a clear policy concerning the
disposition of the documentation and scripts, but I don't believe
there will be any problem sharing them with SIPB. The basic
instructions are in
/mit/ops/doc/admin/afs/solaris.afs.install
(Currently, that directory is acl'd to system:source-access, though I
don't believe anything in there is considered terribly private. I'll
verify with ASO that there's no need for the acl to be so strict and
then hopefully make it more freely readable.) The instructions for
the SunOS 4 version of this procedure (which to the best of my
knowledge were used to set up ronald-ann and reynelda in their current
incarnations) are in the file sunos.afs.install in the same directory.
The primary script used is:
/mit/ops/services/afs/ss.afs
Also, the "afs", "ops", and "remote" mkserv services are used. These
are configured in
/mit/mkserv/services/8.[12]/{afs,ops,remote}.{add,sync,del,dep}
> I'd like to look at these, if possible...
You appear to be on source-access, so you should be able to read all
of the aforementioned files.
> ...or at least get some clarification of what the ASO model is.
> 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"?
No, Garry and I are talking about the same thing, but with different
vocabulary. I apologize for the confusion. Let me try to clarify.
ASO servers (with the primary exception of dialups) use the synctree
functionality of the mkserv utilty to bring *some portion* of the
system packs local. Exactly what portion is brought local is
determined by the service that server runs, and configured in
/mit/mkserv/services/8.[12]/*.sync. They do not attach system packs
by default (RVDCLIENT=false in /etc/athena/rc.conf), but they do run
AFS clients, and packs can be attached manually if needed. We do not
back up the system disks of our AFS servers, since all the information
on any one server's system disk can be easily recreated by
reinstalling it. We do back up the system disks of other servers,
which have unique information on their system disks.
Dialups, on the other hand, have full local system packs, which are
generated using a scripted procedure (see
/mit/ops/doc/admin/dialup/how-to-make-a-sun-dialup for details),
starting with the standard athena system packs, but potentially adding
local patches and modifications (including Sun patches). This process
is laborious, and can take many hours to complete. We find it
acceptable only because the dialups are a pool, and a multiple-hour
outage of a single dialup does not greatly affect the performance of
the pool as it is visible to end users.
> 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?
That, or simply manually attach the system packs from AFS. If we find
we commonly need a utility which is not synctree'd locally, we add
that program to the afs.sync mkserv config file such that it will be
brought local in future installs, and remedy it manually in the
interim.
> 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)?
For non-dialup servers (i.e., for servers which do not have end users
logging in to them), we do not generally apply Sun patches outside the
Athena release cycle unless there is a security or operational
emergency. In that case, we usually apply the patches manually as an
interim measure while working with Athena Release Engineering to
ensure that those patches are immediately incorporated into an Athena
patch release. As you suggest, we find that many security patches,
which fix local buffer overrun exploits and other holes involving an a
priori login to the machine, are not relevant enough to our dedicated
servers to warrant going to lots of trouble to install them outside
the Athena release cycle.
Thus, the install procedure for ASO servers (excluding the dialups)
does not involve applying patches.
> 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.
Ahh, that was unclear. Part of my reason for disagreeing with you
involves the fact that I would like this upgrade not to be delayed any
more. I think that looking into adding backup functionality (in
general) would be a fine thing, as long as it doesn't interfere with
the operation and upgrade of the server.
In the meantime, however, I believe that there already exists a system
that works, and while developing new ways of doing things is fine,
there's no need to delay this upgrade fixing something that isn't
broken. The other two sipb-cell AFS servers are set up in the ASO
fashion already; it's not like there's a lack of precedent for using
this procedure.
> Finally, one side issue:
> 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...
When replying to mailing list traffic, I trim individuals from the
recipient list if they are also on the mailing list in question. I
assumed that since you were obviously reading and replying to
sipb-afsreq, mail there would reach you by whatever your favorite
method was for reading said list.
-mike
