More on alpha9.crl.dec.com

[Jason Molenda]

We've got only one log file from when alpha9.crl.dec.com started
up, so I looked it over by hand.  The silliness started on 6/15.
Before that they behave like a real person doing real cvs stuff.
On 6/15 at 9pm PST (6/16 midnight east-coast time where they're
probably located) they start making repeated connections to sourceware:

alpha9.crl.dec.com 2002-06-15T21:25:07 thru 2002-06-15T21:26:03 15155
alpha9.crl.dec.com 2002-06-15T21:26:03 thru 2002-06-15T21:26:09 13776
alpha9.crl.dec.com 2002-06-15T21:26:09 thru 2002-06-15T21:26:18 13776
alpha9.crl.dec.com 2002-06-15T21:26:19 thru 2002-06-15T21:26:25 13776
alpha9.crl.dec.com 2002-06-15T21:26:25 thru 2002-06-15T21:26:31 13776
alpha9.crl.dec.com 2002-06-15T21:26:32 thru 2002-06-15T21:26:39 13776
alpha9.crl.dec.com 2002-06-15T21:26:39 thru 2002-06-15T21:26:45 13776
alpha9.crl.dec.com 2002-06-15T21:26:45 thru 2002-06-15T21:26:52 13776

This continues unabated for the rest of the log file -- I couldn't
find any times (by hand inspection) where alpha9.crl.dec.com wasn't
making continuous cvs connections, with the same exact number of
bytes transfered nearly every time:

alpha9.crl.dec.com 2002-06-16T11:59:58 thru 2002-06-16T12:00:18 13776
alpha9.crl.dec.com 2002-06-16T12:00:19 thru 2002-06-16T12:00:36 13776
alpha9.crl.dec.com 2002-06-16T12:00:37 thru 2002-06-16T12:00:59 13776
alpha9.crl.dec.com 2002-06-16T12:00:59 thru 2002-06-16T12:01:21 13776
alpha9.crl.dec.com 2002-06-16T12:01:21 thru 2002-06-16T12:01:36 13776
alpha9.crl.dec.com 2002-06-16T12:01:37 thru 2002-06-16T12:01:50 13776
alpha9.crl.dec.com 2002-06-16T12:01:50 thru 2002-06-16T12:02:03 13776
alpha9.crl.dec.com 2002-06-16T12:02:03 thru 2002-06-16T12:02:18 13776
alpha9.crl.dec.com 2002-06-16T12:02:19 thru 2002-06-16T12:02:37 13776
alpha9.crl.dec.com 2002-06-16T12:02:37 thru 2002-06-16T12:02:48 13776
alpha9.crl.dec.com 2002-06-16T12:02:48 thru 2002-06-16T12:02:57 13776
alpha9.crl.dec.com 2002-06-16T12:02:57 thru 2002-06-16T12:03:06 13776
alpha9.crl.dec.com 2002-06-16T12:03:06 thru 2002-06-16T12:03:14 13776
alpha9.crl.dec.com 2002-06-16T12:03:14 thru 2002-06-16T12:03:22 13776
alpha9.crl.dec.com 2002-06-16T12:03:23 thru 2002-06-16T12:03:30 13776
alpha9.crl.dec.com 2002-06-16T12:03:31 thru 2002-06-16T12:03:40 13776
alpha9.crl.dec.com 2002-06-16T12:03:41 thru 2002-06-16T12:03:50 13776
alpha9.crl.dec.com 2002-06-16T12:03:50 thru 2002-06-16T12:03:58 13776
alpha9.crl.dec.com 2002-06-16T12:03:59 thru 2002-06-16T12:04:09 13776
alpha9.crl.dec.com 2002-06-16T12:04:09 thru 2002-06-16T12:04:18 13776
alpha9.crl.dec.com 2002-06-16T12:04:18 thru 2002-06-16T12:04:26 13776
alpha9.crl.dec.com 2002-06-16T12:04:26 thru 2002-06-16T12:04:35 13776
alpha9.crl.dec.com 2002-06-16T12:04:35 thru 2002-06-16T12:04:43 13776
alpha9.crl.dec.com 2002-06-16T12:04:43 thru 2002-06-16T12:04:50 13776
alpha9.crl.dec.com 2002-06-16T12:04:50 thru 2002-06-16T12:04:57 13776
alpha9.crl.dec.com 2002-06-16T12:04:57 thru 2002-06-16T12:05:07 13776

Occasionally the byte count goes up a bit for a given connection.
Sometimes it was 64 bytes instead of 13k.  Remember how I said the
# of alpha9 connections for that week in June was 30,000 -- that's
a huge underestimate; most of the log files were missing 8-12 hours
of their log because alpha9 was causing the log files to scroll
faster than the nightly crontab could filter them.  I'd guess the
actual # of connections was more in the 50,000-60,000 range for
that week.

I can't begin to imagine what someone is doing over there -- if I
didn't know better I'd say it is some malicious person who is trying
to sneakily slow down sourceware.  But I'm sure it's really just
someone doing something remarkably stupid.  Maybe repeated cvs
status commands?  Or a "cvs update -l" in some directory of great
interest to that person?  They were behaving like a real user until
6/15, so maybe they got frustrated by an unresponsive server and
decided to do

while true
do
  cd gcc/gcc   # don't mean to accuse the gcc developers in particular
  cvs update
done


In any event, I don't feel even a little bad about blocking this
machine.  Both Chris and I have noticed a lot of inexplicable load
on sourceware for a couple weeks -- part of it has been all the
troubles H-P has been going through to get indexing working, but
I suspect no small part of it is this person at alpha9.crl.  With
luck the person will realize his or her mistake, or will pipe up
and ask for help and someone will kindly explain that there are
better ways to accomplish whatever they're doing.


Jason

PS-  Chris, a cvs transaction looks like this:

@400000003d2aa9611d1aa924 tcpserver: pid 27607 from 64.161.12.226
@400000003d2aa9611d1ac864 tcpserver: ok 27607 sources.redhat.com:209.249.29.67:2401 :64.161.12.226::64704
@400000003d2aa96139239dec tcpserver: end 27607 status 0
@400000003d2aa9613923d0b4 tcpserver: status: 6/10
@400000003d2aa9613923dc6c bytestats: pid 27607 in 535 out 1631

/www/bin/anoncvs-aggregator.sh needs this:

@400000003d2aa9611d1aa924 tcpserver: pid 27607 from 64.161.12.226
@400000003d2aa9613923dc6c bytestats: pid 27607 in 535 out 1631

The "tcpserver end" and "tcpserver ok" entries aren't needed.
"tcpserver status" and "tcpserver deny" should be retained as I
can see them being useful to humans looking at the log.

The byte savings aren't great; I think we should increase the size
of the logs from 3MB to 30MB and keep an eye out for alpha9's
activities shifting to another machine.