🚀 go-pugleaf

	I suppose I should ask if the folks in comp.unix.large would like us
to move this discussion out of here? While we are certainly talking about large
unix systems, it may not be of interest to more than me and the Michigan folks,
and I expect I could talk the UM folks out of a Unix guest account and carry 
on from there.

rees@pisa.citi.umich.edu (Jim Rees) writes:

>In article <vanepp.721411740@sfu.ca>, vanepp@fraser.sfu.ca (Peter Van Epp) writes:

>  ...
>  UM is a lot bigger than SFU, and some of the issues that we managed to slid
>  through (a common uid space for the whole campus for instance) will be 
>  more difficult at UM...

>Actually, that's one of the only parts that has been done here.  We've got a
>pretty nifty distributed system for assigning uids called uniqname.  I think
>there's a paper on it somewhere (Usenix?).  Some large fraction of the
>University community now has a unique Unix uid.

If I had thought of it, I knew that :-), I was expecting that you might be 
big enough to run out of 65000+ uids. It seems to me that the IFS project
is a fair good step along the path to MTS migration too (although I haven't
heard how it is going lately). We are small enough that we could make do with
a single NFS fileserver to give us central file services (like backup and
restore, although the restore side is a lot less convienient than the MTS
version). There are a number of people (smart ones in my opinion!) that 
want nothing to do with their own Unix box if it means (as it currently
does at SFU) that they have to do their own system administration and 
system backup. They figure that it is better for the university to pay us to 
look after all of that for them. There are also people that are choosing to
do it all for themselves using such central services as they like such
as mail delivery, NetNews services and PD software for the machine types
that we support that we export to the world (readonly) from the file server.
	The major advantage of the setup as it stands now, is that both
services are availible for those that want them (unlike MTS where it was 
all central). The next challange is going to be whether we can provide some
kind of a "consulting" system administration service to make it easier for
people to run machines on their desks. I expect that for that to happen
we will need either AFS or DFS for both security and local caching of files
from a central file server (like IFS) so that dataless machines on peoples
desktops can be supported. If we can't work that out, then there is going
to be a constant war for funding between the people that want central
support (and the departments that are too small to be able to do it for
themselves) and the people that want the money from the computing center
budget to do it themselves (I expect you folks at UM are familiar with this
argument!).
	I suspect that most of the rest of the MTS community will follow us
down the road, after all, many of the ideas that we used where generated
within the MTS community at the various MTS workshops over the last 7 or 8
years while we thought and talked about what should replace MTS. We just got 
the conversion speeded up quite a bit by the computing center being moved 
under a new Vice President (from the VP Research and Development to the 
Associate VP Academic).  The new VP thought that it could be done (and by 
implication, that the people working for him could do it!), and succeeded 
in getting the academic community to buy in by giving the control of the 
project to the academic committees.
	These committees consulted with their peers about what the community
requrements were and then balanced that against the amount of money that they 
had to work with (i.e. the maintance budget for the mainframe). 
	Meanwhile the computing center staff identified what and 
how much was currently being done on the mainframe, and then presented that
data to the committee to decide what should be done about it (where possible
we identified what could be done about it and how much it would cost as well). 
Which in some cases turned out to be that the service would no longer be
offered, either because there was no Unix alternative, or it was too expensive.
	The fact that it was a committee of their peers making these decisions
rather than the computing center was probably the single thing that smoothed
this transition the most. If the computing center had done this, we would of
course been wrong, but as the committees decided it and the faculty had input
into the committee, it is harder to complain (not impossible of course, but
harder)
	I will admit that when this plan was proposed (dump MTS within the 
next nine months, under the direction of a series of academic committees),
I thought it was probably resume time, time to once again watch the fireworks
from afar ... Luckily I held off doing anything much about it (other than
updating my resume of course), since while it was a tremendous amount of
work, it is also very satisfiying to see the results of that work. The
committees were good enough to consult with the computing center for advise
about what to buy (although the final decsions were of course theirs), and
how we thought things should be done. I hope and believe that they are 
reasonably happy (as is the community) with what resulted. The conversion 
went far more smoothly than we had any right to expect.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada