Folks, I need your help.
I can't tell if this is a DOS attack or someone with a REALLY slow net
connection. Whoever this is has been cloning the linux 2.6 (aka 2.5)
tree on bkbits so slowly that the tree is locked for days and can't
be updated. About once a day I go kill the clone because stracing it
shows it doing nothing.
Linus and Andrew M are annoyed enough that the tree isn't getting updates
that they complained to me. Makes me feel bad when they do that so that's
why I'm looking for help.
In case people want the details, we have a long standing arrangement
wherein Linus updates linus.bkbits.net and we update from that and then
update the linux.bkbits.net tree, i.e., the official tree. That's because
Linus got frustrated with waiting for locked trees so he got one that
can't be locked, pulls/clones from it are disallowed unless you are me
or him. So we go through a little hop skip and a jump where he pushes
to his tree, we pull from that, and then we push to linux.bkbits.net.
That way he never waits on a push. It's good to be Linus :-)
Anyway, we've suffered more than enough bad press so before I
assume that this host is a rogue and filter them, does anyone know who
merlin.fit.vutbr.cz is? If they really have that slow of a connection
we'll burn a CD and Fedex it to them, nobody should suffer that much.
But if this is just a DOS, we'll nuke 'em.
Thanks,
--lm
On Monday 29 March 2004 03:08, Larry McVoy wrote:
> Folks, I need your help.
>
> I can't tell if this is a DOS attack or someone with a REALLY slow net
> connection. Whoever this is has been cloning the linux 2.6 (aka 2.5)
> tree on bkbits so slowly that the tree is locked for days and can't
> be updated. About once a day I go kill the clone because stracing it
> shows it doing nothing.
>
> Linus and Andrew M are annoyed enough that the tree isn't getting updates
> that they complained to me. Makes me feel bad when they do that so that's
> why I'm looking for help.
>
> In case people want the details, we have a long standing arrangement
> wherein Linus updates linus.bkbits.net and we update from that and then
> update the linux.bkbits.net tree, i.e., the official tree. That's because
> Linus got frustrated with waiting for locked trees so he got one that
> can't be locked, pulls/clones from it are disallowed unless you are me
> or him. So we go through a little hop skip and a jump where he pushes
> to his tree, we pull from that, and then we push to linux.bkbits.net.
> That way he never waits on a push. It's good to be Linus :-)
>
> Anyway, we've suffered more than enough bad press so before I
> assume that this host is a rogue and filter them, does anyone know who
> merlin.fit.vutbr.cz is? If they really have that slow of a connection
> we'll burn a CD and Fedex it to them, nobody should suffer that much.
> But if this is just a DOS, we'll nuke 'em.
What will prevent someone else to do the same?
--
vda
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 28 Mar 2004, Larry McVoy wrote:
> Folks, I need your help.
>
> I can't tell if this is a DOS attack or someone with a REALLY slow net
> connection. Whoever this is has been cloning the linux 2.6 (aka 2.5)
> tree on bkbits so slowly that the tree is locked for days and can't
> be updated. About once a day I go kill the clone because stracing it
> shows it doing nothing.
>
> Linus and Andrew M are annoyed enough that the tree isn't getting updates
> that they complained to me. Makes me feel bad when they do that so that's
> why I'm looking for help.
[...]
> Anyway, we've suffered more than enough bad press so before I
> assume that this host is a rogue and filter them, does anyone know who
> merlin.fit.vutbr.cz is? If they really have that slow of a connection
> we'll burn a CD and Fedex it to them, nobody should suffer that much.
> But if this is just a DOS, we'll nuke 'em.
I don't know details of bk, so please forgive me if I am writing about
something already existing, but isn't it possible to implement a timeout
and some kind of intelligent retry in a similar manner to nowadays
http/ftp ? A server could then check if someone has made something with
his connection during last, say, minute and then drop the connection if
nothing was pulled during that time. Next, if someone has really slow
connection, give him the ability to start transfer from specified offset
so that he could retry from the place he had been dropped.
To prevent instant locking, maybe some kind of queuing? FIFO and if you
don't pull what you locked, you get kicked out. If you return, wait for
your turn until Linus ;) (or someone else) does his updates.
BTW, if I understand correctly, to read something from the tree one
doesn't really need to lock it. Only writes should be locked.
bye
T.
- --
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:[email protected] **
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBQGglixETUsyL9vbiEQJ3mwCg0XFzTQG9rhugOerAnQBzu8ObszMAni9i
9ggm8ENBVL/TDJ+N2UtvBWo7
=lLpf
-----END PGP SIGNATURE-----
At 3/29/2004 03:32 PM +0200, Tomasz Rola wrote:
>BTW, if I understand correctly, to read something from the tree one
>doesn't really need to lock it. Only writes should be locked.
Locking on reads prevents getting a copy of the tree with half of someone
else's changes that were written during your read. That gets more likely
as the time it takes to read the entire tree increases.
--
Jeff Woods <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 29 Mar 2004, Jeff Woods wrote:
> At 3/29/2004 03:32 PM +0200, Tomasz Rola wrote:
> >BTW, if I understand correctly, to read something from the tree one
> >doesn't really need to lock it. Only writes should be locked.
>
> Locking on reads prevents getting a copy of the tree with half of someone
> else's changes that were written during your read. That gets more likely
> as the time it takes to read the entire tree increases.
>
> --
> Jeff Woods <[email protected]>
Ok, I got it. However, maybe this can be better solved by introducing a
feature, that enables to create snapshots in the form of pairs:
(name, version). After one has such snapshot info retrieved, one can
unlock the tree and read the rest without locks, only by specifying the
version of the resource (i.e., file in this case) in addition to its name.
Or, without such snapshot feature, after reading the entire tree unlocked,
check the versions of retrieved files and search for new/newer files, and
repeat pulling only for them. And so on.
But I think snapshot-info is more elegant and less error prone solution.
The second way is more resource demanding, imho.
bye
T.
- --
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:[email protected] **
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBQGhKlBETUsyL9vbiEQKP2wCg5nW/AFswFYIW2CgadL90Jvp3uxkAoNkO
GZRUQlPN9PnOW7ji2hrOimYO
=pBFo
-----END PGP SIGNATURE-----
Hi!
> I can't tell if this is a DOS attack or someone with a REALLY slow net
> connection. Whoever this is has been cloning the linux 2.6 (aka 2.5)
> tree on bkbits so slowly that the tree is locked for days and can't
> be updated. About once a day I go kill the clone because stracing it
> shows it doing nothing.
Never explain with malice what can be explained by incompetence
as well :-).
> Anyway, we've suffered more than enough bad press so before I
> assume that this host is a rogue and filter them, does anyone know who
> merlin.fit.vutbr.cz is? If they really have that slow of a connection
> we'll burn a CD and Fedex it to them, nobody should suffer that much.
> But if this is just a DOS, we'll nuke 'em.
vutbr.cz is university in czech republic; duno what merlin.fit means,
perhaps its room at dormatory or something like that.
What kind of bandwidth do they use? You could also try to ping it and maybe finger/
telnet there to see what it is.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Hi,
I guess it is the student server (whatever that means) from the Faculty
of Information Technology of the Brno University of Technology in the
Czech Republic.
They give this information on the machine:
merlin
Asus P4P800-VM, Pentium 4 HT/2,6GHz, 512 MB RAM, 80 GB HDD
RedHat Linux
studentsk? server Linux
Also note that they list the following email-address for any problems:
[email protected]
or for information: [email protected]
As to which person is behind the process on the machine, I got no clue.
Kind regards,
Martijn Kuipers
On Sun, Mar 28, 2004 at 05:08:29PM -0800, Larry McVoy wrote:
> connection. Whoever this is has been cloning the linux 2.6 (aka 2.5)
> tree on bkbits so slowly that the tree is locked for days and can't
> be updated. About once a day I go kill the clone because stracing it
RCU for BitKeeper trees? :-)
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
bert hubert wrote:
> > connection. Whoever this is has been cloning the linux 2.6 (aka 2.5)
> > tree on bkbits so slowly that the tree is locked for days and can't
> > be updated. About once a day I go kill the clone because stracing it
>
> RCU for BitKeeper trees? :-)
Last I heard, RCU is patented by IBM, with permission to use it in GPL
programs (maybe limited to version 2 of the GPL?), so that Linux can use it.
So BitKeeper might not be able to use the technique, if the claims of the
patent are sufficiently broad (I haven't read it and don't intend to).
-- Jamie
On Wed, Mar 31, 2004 at 10:31:43PM +0100, Jamie Lokier wrote:
> > RCU for BitKeeper trees? :-)
>
> Last I heard, RCU is patented by IBM, with permission to use it in GPL
> programs (maybe limited to version 2 of the GPL?), so that Linux can use it.
This is really astonishing. It is not possible to say one thing about
bitkeeper without descending into a discussion on patents and licenses!
Amazing.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
On Sun, Mar 28, 2004 at 05:08:29PM -0800, Larry McVoy wrote:
> Folks, I need your help.
>
> I can't tell if this is a DOS attack or someone with a REALLY slow net
> connection. Whoever this is has been cloning the linux 2.6 (aka 2.5)
> tree on bkbits so slowly that the tree is locked for days and can't
> be updated. About once a day I go kill the clone because stracing it
> shows it doing nothing.
[snip]
> Anyway, we've suffered more than enough bad press so before I
> assume that this host is a rogue and filter them, does anyone know who
> merlin.fit.vutbr.cz is? If they really have that slow of a connection
> we'll burn a CD and Fedex it to them, nobody should suffer that much.
> But if this is just a DOS, we'll nuke 'em.
.cz: Czech Republic
.vutbr: Technical University of Brno
.fit: Faculty of Information Technology
merlin: a Linux server serving home directories and login accounts to
students
So it's likely a student doing the 'bk clone'.
What's surprising is that merlin shouldn't have a slow network
connection - quite the opposite - it's near the academic backbone of the
Czech Republic (a 2.5 gbit/sec pipe).
But maybe something doesn't work correctly - some NAT or MTU problem
stopping the communication ...
Or it's indeed an evil student.
The administrative contact for that machine is [email protected].
I hope this helps.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
bert hubert wrote:
> On Wed, Mar 31, 2004 at 10:31:43PM +0100, Jamie Lokier wrote:
> > > RCU for BitKeeper trees? :-)
> >
> > Last I heard, RCU is patented by IBM, with permission to use it in GPL
> > programs (maybe limited to version 2 of the GPL?), so that Linux can use it.
>
> This is really astonishing. It is not possible to say one thing about
> bitkeeper without descending into a discussion on patents and licenses!
No. It's an unfortunate coincidence that you mentioned RCU on a
BitKeeper(tm) thread. A suggestion to use RCU in, say, Mozilla or
FreeBSD would have elicited a similar response.
RCU patents were mentioned numerous times in the news when RCU was
added to the kernel. One presumes, then, that IBM was keen for it to
be known the technique is patented, and one would be wise to tread
carefully if intending to copy the technique as it is used in Linux,
as you jokingly suggested.
In case you misunderstood, the grandparent post was not an attack on
BitMover. Fwiw, I'm on BitMover's side if the RCU patent is relevant,
which it probably is not. I doubt if the patent extends beyond task
scheduling done in a certain way, although as I said I have not read it.
-- Jamie
On Thu, Apr 01, 2004 at 02:39:12PM +0100, Jamie Lokier wrote:
> bert hubert wrote:
> > On Wed, Mar 31, 2004 at 10:31:43PM +0100, Jamie Lokier wrote:
> > > > RCU for BitKeeper trees? :-)
> > >
> > > Last I heard, RCU is patented by IBM, with permission to use it in GPL
> > > programs (maybe limited to version 2 of the GPL?), so that Linux can use it.
> >
> > This is really astonishing. It is not possible to say one thing about
> > bitkeeper without descending into a discussion on patents and licenses!
>
> No. It's an unfortunate coincidence that you mentioned RCU on a
> BitKeeper(tm) thread. A suggestion to use RCU in, say, Mozilla or
> FreeBSD would have elicited a similar response.
>
> RCU patents were mentioned numerous times in the news when RCU was
> added to the kernel. One presumes, then, that IBM was keen for it to
> be known the technique is patented, and one would be wise to tread
> carefully if intending to copy the technique as it is used in Linux,
> as you jokingly suggested.
>
> In case you misunderstood, the grandparent post was not an attack on
> BitMover. Fwiw, I'm on BitMover's side if the RCU patent is relevant,
> which it probably is not. I doubt if the patent extends beyond task
> scheduling done in a certain way, although as I said I have not read it.
BitMover could care less about RCU, please leave us out of this discussion.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com