On Fri, Mar 01, 2002 at 01:00:14PM -0600, Adam Heath wrote:
> It's perfectly fine. You don't announce to the world when some
> incident has occured, esp. when that incident may be nothing at all.
If the incident, or your response to it, results in the unavailability
of some services, I'd say an announcement to those affected *is*
warranted.
I agree with you that it's not the job of a sponsor like Brainfood to
make such an announcement to the developers in general. Instead, you
pass it along to those whose job it is.
> > If I were DPL, I'd have been on the phone to brainfood within minutes of
> > hearing that there was a possible incident.
>
> Well, that's all well and good, but we wouldn't have to respond to
> you. You don't maintain the machines. You have no idea of their
> history. The provider/sponsor, and DSA, do.
5.1. Powers
The Project Leader may:
1. Appoint Delegates or delegate decisions to the Technical Committee.
The Leader may define an area of ongoing responsibility or a specific
decision and hand it over to another Developer or to the Technical
Committee.
Once a particular decision has been delegated and made the Project Leader
may not withdraw that delegation; however, they may withdraw an ongoing
delegation of particular area of responsibility.
I conceive of the administration of Project Resources, including machines, as
being an area of ongoing responsibility. Do you disagree?
> Local admins should never talk to the debian populace, ever. They
> should only talk to DSA(thru -admin), and DSA should filter than on to
> everyone else.
I agree. However, I missed the part in this most recent situation where
DSA filtered what Brainfood had to say on to everyone else.
> > But the DPL -- at the very least -- should be in the loop. Sponsoring
> > sites provide resources of tremendous value to Debian, but it is
> > unacceptable for a vendor to unilaterally terminate services for an
> > indefinite period without adequate explanation. Hopefully, Ben is in
> > the loop on this issue and it's being handled in a way that I'd be
> > comfortable with were I in his shoes.
>
> No, this shows a severe lack of how things work in the real world.
> We have not terminated services. We have blocked ssh access.
I conceive of "ssh" as a service; don't you? According to the best
information available, posted as the channel topic in #debian-devel on
OPN, all inbound connections to Debian machines at Brainfood were
blocked except for ports 25, 80, and 443 (smtp, http, and https for
those readers who don't have /etc/services memorized).
> Mail, web, and dns are still working. Has the BTS gone down? Has
> list mail stopped flowing? Stop spreading FUD.
I didn't make any specific accusations. How could I have? All I knew
was that we had a communication problem. It was made a topic of
discussion on debian-vote and pitched to the DPL candidates. When
replying, I decided to CC everybody who I guessed would be in the
"chain" of knowledge from Brainfood down to the average developer. So,
that meant Brainfood (Ean), the DPL, and DSA.
> Why don't you say what you really mean here, instead of burying it in legal
> gobledy(sp) gook.
I get the feeling that what I meant, and what you think I meant, are
very different things. I was not trying to insinuate anything.
> > Perhaps the DMUP could be revised to establish acceptable standards of
> > behavior and incident response procedures that are binding upon the
> > sponsors and DSA team as well as our developers. After all, problems
> > can originate from anywhere, not just from plebe developers who get a
> > spanking from DSA every now and then.
>
> What does the DMUP have to do with this?
Nothing; hence my proposal that it be expanded.
> In fact, how can you know anything about this situation? No
> information has been given.
Bingo! That's the problem I've seized upon. There was, however, a very
small amount of information disseminated to the #debian-devel IRC
channel, which I frequent. And, of course, the requisite rampant
speculation. Developers who don't IRC, as far as I can tell, had
absolutely no way of finding out why some services were unavailable.
(No passive way, anyway -- I guess we could encourage people to mail
debian-admin everytime they have a problem, but that wouldn't really be
fair to the DSA team. Better, I think, would be for outages to be
announced when they're known about -- that way you can just tell people
where to look if they suspect a problem and you spare the debian-admin
list a bunch of repititious questions: "Is it broken?" "When will it be
fixed?")
> Any type of inference you try to make is pure conjecture on your part,
> with no basis in fact whatsoever. So back off.
Please let me know what I can do to help ensure that the lines of
communication don't fail in the future.
> > A status report containing as much information as possible should be
> > posted to debian-private by the DPL or DPL delegate within 24 hours of
> > any incident like the one that has happened to us this week.
>
> I informed -admin. That's all you need to know.
Is there a reason this information doesn't seem to have propagated any
farther?
--
G. Branden Robinson | Communism is just one step on the
Debian GNU/Linux | long road from capitalism to
branden@debian.org | capitalism.
http://people.debian.org/~branden/ | -- Russian saying
Attachment:
pgpW0ucEeClBg.pgp
Description: PGP signature