[2585] in Release_7.7_team
Update on sshd for print server issues.
daemon@ATHENA.MIT.EDU (Bill Cattey)
Mon Feb 12 15:36:27 2001
Message-ID: <EuW4Z6Vz0001IvM2RH@mit.edu>
Date: Mon, 12 Feb 2001 20:36:22 +0000 ()
From: Bill Cattey <wdc@MIT.EDU>
To: jis@MIT.EDU
CC: release-team@MIT.EDU, karen@MIT.EDU
Here is what I know so far about the issue you raised about:
1. getting a patched sshd for 8.3 systems that run print servers.
2. status of 8.4 support for print servers
3. review of how people get information about things like 1 and 2 above.
1. It looks like the sshd you found on the nearby Athena print server
running 8.3 will DTRT. I will verify that explicitly with Garry
Zacheiss.
I am coming to believe it was ano oversight that the Athena Release
team, knowing that print servers needed to stay at 8.3 didn't think to
cook sshd
for 8.3 along with 8.4. (Isn't sshd the primary way of remote control
of a print server?) I think that when we have services that require old
Athena versions, for serious security fixes, we should have a policy in
place to offer
the appropriate retro-fix. I believe we have this policy in place. Perhaps
we spazzed.
2. I will be contacting Garry Zacheiss directly for an update on this.
He is the one doing the work.
3. I'm really sorry that you and Karen were inconvenienced by this
situation. Apparently Greg Hudson was relying on the following part
of the announcement he sent to release-announce:
If you have an Athena 8.3 or earlier machine which runs sshd, please
disable sshd for now (set SSHD=false in /etc/athena/rc.conf and "kill
`cat /var/athena/sshd.pid`") and contact us if you need further
support.
Please send questions or comments to release-team@mit.edu.
to trigger email to release-team@mit.edu if people felt the need for a
back-port of the sshd to 8.3, or for other additional work.
If Karen emailed bugs instead and didn't get timely satisfaction, that
may be due to insufficient attention being paid to the bugs list. I'll
poke at that.
According to Camilla Fox, there is a contact list for people running
print servers who would get notification when the support for Print
Servers in 8.4 was working. At this time, support is under test.
The current, short, simple answer to "Where do I go with these issues?" is:
release-team@mit.edu
I, people in ops, and people doing development work, as well as Oliver
Thomas in consulting will see the query, and AT LEAST one of us should
be able to deal with it in a timely manner.
I'm copying this note to release-team to ask the question:
Is it reasonable for us to expect our customers to be emailing
release-team when they have urgent issues with a release? Should we
be trying to have a more overarching list like bugs, or better
connection to the consultants, or the MIT Help Desk to make sure issues
get fast-tracked to us without us requiring customers to know
"release-team@mit.edu" is the right place to send to.
-wdc
