[17] in Kakapo Windows Team
Minutes of the June 26th, 2003 Kakapo Meeting
daemon@ATHENA.MIT.EDU (Kerem B Limon)
Mon Jun 30 20:10:14 2003
Message-Id: <5.2.0.9.2.20030630194254.073723c8@hesiod>
Date: Mon, 30 Jun 2003 20:10:01 -0400
To: Kakapos at MIT <kakapo@mit.edu>
From: Kerem B Limon <kerem.limon@MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Enclosed are my meeting minutes for the June 26, 2003 (second) Kakapo
meeting. Please send all corrections to me and I will issue an updated
version if necessary. My apologies for the delay in getting this out.
Regards,
Kerem
---Enclosure:---
Kakapo Meeting Minutes
Date & Time: Thu, June 26th, 2003 @ 1300 - 1430 (1:00 PM - 2:30 PM)
Location: W92-225
Attending: Chad Dupuis, Paul Hill, Jonathan Hunt, Kerem Limon, Brian
Murphy, Tom Thornton, Jonathon Weiss
Absent: Tom Coveney, Jean Foster, Phil Long, Oliver Thomas (other engagements)
1) Meeting Logistics (brief, open discussion)
There was some miscommunication as to the location of the meeting. At the
end of the last meeting, we had left it at agreeing to meet in W20 for the
time being. However, a change in the availability of the room in W20
required Brian to reschedule to W92-225. We were subsequently bumped to an
adjacent conference room due to a meeting running over there, and were
limited to meeting until 1400 (2:00 PM) to make room for the next booked
meeting there.
It was agreed that next time, any location changes should be announced ASAP
and noted in the Subject: field of the corresponding e-mails. Due to the
short notice, some people who missed the e-mail or the location change
showed up in W20 initially. Brian will look into booking the locations for
the foreseeable future to avoid this kind of disconnect.
2) Keyserver Discussion (Chad; continuing from last week)
Chad explained that he is moving forward with setting up a keyserving
system for Architecture/Urban Studies and Planning (DUSP), with which to
experiment.
Academic Computing has a large number of licenses available for use there
from another project that no longer needs them.
They are going to be treating it as a mini-Discovery project of sorts, and
are not going to be considering any other keyserving tools from other
vendors besides the one at hand.
They intend to loan out licenses on a per-term basis. This system allows
for concurrent licensing, that is, for example 20 total licenses that can
be served to a pool of 50 machines.
Chad noted that this is expensive software and is often pirated by the
students. He also noted that there was a need to give users read access to
MSIs, wherever they are stored, due to some particular needs some of this
software has, and this opens the door to piracy by simply acquiring the MSI
from its location. Kerem asked if the piracy was a result of students' need
to run the software remotely (e.g. outside the lab, from home), or for more
nefarious reasons (e.g., wanting to 'have own copy' to use elsewhere or
after MIT). Chad suspected the latter is more common. Chad added that our
current authentication/control method isn't there to combat the problem--we
mostly base things on IP filtering. Carnegie Mellon (CMU) and others have
some Kerberos plug-ins which may be able to help, but Chad/ACS have not
tested these.
Kerem mentioned that some type of VPN solution would be nice to work with
the IP-based control mechanism, but given the potential fallout and
complexity, noted we probably do not yet want to go down that path.
Chad added that there is a 'deputizing' tool for MSIs available to properly
key MSIs they can use to make them keyserver compatible.
Jonathon (Weiss) raised the question of what we envisioned 'success' in the
keyserver effort to be. Some of the roundtable ideas mentioned included:
o Some way of dealing with Macs with regard to keyserving.
o Concurrent possible use for Campus, with ideally, delegated keyserving.
o Being able to just give the software out to users and using the keys
solely for control.
Kerem asked the question of whether we check with the vendor and someone
like Paul Heffernan to verify license compliance, should someone want to
host their key licenses on our keyservers, and whether there is a process
in development for that. Paul commented that this could be part of Chad's
job, and Chad answered that Alex Prengel does similar work for the
(Linux/Unix)Athena space. He also mentioned that dealing with companies for
Windows software where we've had dealings before for Linux/Unix software
might be smoother.
Kerem asked for a list of who's using what keyed applications, and who's
responsible for assuring these systems work. He mentioned that his
motivation was to have a clear escalation reference, should it be necessary
as a support tool. Chad mentioned some of this information is available on
his MSI page at http://mit.edu/acs/windows/msisupport.html. Kerem then
asked if the escalation path of user going to local/container admin for
support, and than that admin going to Chad at this point (as he is running
most keyservers at this point) would be the correct one for the time being.
Chad agreed that was the case so far, and cited Architecture/DUSP as the
one group with local support in their labs.
3) Kakapo Process Discussion (open discussion)
Brian raised the question of whether this (Kakapo Team) is the proper venue
for receiving container requests and approving them. Paul countered by
noting that we do not send each mailing list request to Owls and that
containers are similar. Kerem disagreed that the implications of container
ownership surpass that of mailing lists, and the process for mailing lists
issuing and support for them have all been well determined. Jonathon
(Weiss) asked if the approval process for containers were currently broken,
after hearing in certain cases container requests from academic areas
forwarded to ac-proposals (they're not directly on the container-request
list) fell into a black hole. Paul verified that has been the case.
Jonathon (Weiss) then wondered that if we were taking on the container
approval role from ac-proposals. He also noted that a container request is
more like a cluster admin request in Athena.
Kerem noted that there are two issues at hand--(1) the question of who
needs to see all requests, and (2) the question of who has the authority to
sign-off on that. He added that while these two groups may overlap, they
may also be distinct. Brian suggested that a complicated process would
overburden IS if we were to try to process each request equally, even when
it is an additional container request from a group who already has a number
of them. Kerem then suggested the two pertinent questions for container
approvals are possibly, (1) whether the request makes sense (e.g. are they
requesting 100 containers to manage 100 different machines vs. a known
admin just requesting a new container for a new cluster of machines, etc.),
and (2) whether there is someone knowledgeable enough and/or willing to
gear up and learn to admin the container, and who they are. Paul suggested
that we can build shortcuts in order to deal with the issue of additional
container requests from existing container admins.
Brian wondered if there was a 'master' list of existing containers
anywhere, and whether it was maintained. Paul and Kerem noted that these
can be obtained in Moira and/or Active Directory using the standard
interfaces from any win.mit.edu machine by container admins. Kerem
suggested that what we desire to do (the two goals above) may be met by
simply adding the right people/groups to the appropriate mailing lists and
deciding on the tracking system. Jonathon (Weiss) and Paul also raised the
question of the tracking tool. Paul mentioned that CaseTracker has been
proposed as the tracking tool for container requests, but Jonathon (Weiss)
wanted to clarify the issues before committing, as Athena Server Ops (ASO)
doesn't routinely use CaseTracker. Kerem suggested putting together a
proposal for this and sending it to the Kakapo list before the next meeting.
4) Hardware/Software Recommendations (open discussion)
Brian asked the question of whether we needed to make any hardware/software
recommendations around Windows. Kerem noted that Windows is flexible enough
to gracefully deal with variant hardware and that there have been no major
problems in his experience or in the win.mit.edu space as far as he knows.
Kerem felt that we could deal with such issues by exception. He added that
as per a win.mit.edu description document he produced with Richard Edelson,
they were able to leverage existing hardware (and software) recommendations
for the academic and administrative spaces. He suggested that it is
generally safe to go with existing MIT recommendations, and we may need to
clue in to that effort should hardware concerns arise on our end. Paul
commented that in the past Theresa has also checked in with Paul in lieu of
win.mit.edu.
5) Mailing List and Discuss Archive
Brian had attempted to create a LISTSERV mailing list and had not yet
finished. After a brief discussion, it was agreed that an Athena mailing
list would be adequate. Jonathon (Weiss) agreed to create the LIST kakapo
and an associated Discuss archive and let everyone know when they were both
active (should be later in the day).
We adjourned at approximately 1405 (2:05 PM).
Kerem B. Limon
Project Team Leader
Delivery Process, MIT Information Systems
kerem.limon@mit.edu /e-mail
+1-617-253-1150 /voice
+1-617-258-8736 /fax
