[361] in Release_7.7_team
Finally closing the loop on the MAE AppleTalk streams module
daemon@ATHENA.MIT.EDU (Reid M. Pinchback)
Mon Oct 2 15:38:57 1995
To: release-team@MIT.EDU, cfields@MIT.EDU, wdc@MIT.EDU, miki@MIT.EDU
Date: Mon, 02 Oct 1995 15:38:35 EDT
From: "Reid M. Pinchback" <reidmp@MIT.EDU>
It looks like we're finally going to be able to resolve (positively)
the issue of being able to get legal permission to incorporate the
AppleTalk streams module into our Solaris release and/or machine
installation process in whatever way we wish. Just to make sure
everybody is on the same wavelength, here is where things stand.
PROBLEM
1. The MAE AppleTalk streams module must be installed before MAE
AppleTalk functionality is available, which is a critical feature
of the package. At present, the module is only installed on the
machines in 2-032 via a mkserv script that the CSR's must run
every time they re-install one of the Sparc 5's in that room,
and this renders the machines non-public. Because reinstalls take
a long time, mkserv mae doesn't get run until the next time the CSR's
do a pass by the room. This creates a window where people can use MAE
but AppleTalk isn't available. This isn't just a theoretical window...
it actually happens at least a couple of times a week that somebody
reports a problem where they've started MAE but AppleTalk isn't working
on that machine. This isn't a huge problem, more like an ongoing
annoyance that can frustrate users and waste some of the CSR's time.
2. From a long-term perspective, someday we may want to make MAE available
in other locations, and then the notion of running mkserv to put the
machines in a non-public configuration starts to break down. To use
the magic words, it don't scale.
POSSIBLE SOLUTIONS
1. On a short-term basis, Miki and I have been talking about the possibility
of integrating invocation of the mkserv mae into the installation process.
For this to work properly mkserv mae couldn't render the machines
non-public anymore. Also, some tweaking of the track configuration
would likely be needed. The implementation and testing of this should
be relatively simple; presence of the AppleTalk stack in the machines
in 2-032 hasn't caused any problems that we know of. The results should
not be user visible. This would eliminate the need for the CSR's to
deal with the 2-032 Sparc 5's as some kind of "special case" maintenance
problem.
2. On a long-term basis of course we could look at completely integrating the
results of installing the AppleTalk streams module with the contents of
/srvd, but that would have to wait until the next (patch?) release,
probably around IAP.
NEXT STEPS
Okay, now that I've outlined the issues and the possible steps we could take
(along with the "do nothing for now step", which is always an option),
its time for those in the know to react to the proposal. Please send
responses/suggestions/reactions to me and cc miki on them.
===============================================================
= Reid M. Pinchback =
= Senior Faculty Liaison =
= Academic Computing Services, MIT =
= =
= Email: reidmp@mit.edu =
= URL: http://web.mit.edu/reidmp/www/home.html =
===============================================================
