search

google-code-export / nmrrestrntsgrid

Automatically exported from code.google.com/p/nmrrestrntsgrid
0 stars 0 forks source link

BMRB network or tang's settings trying to prevent a DoS attack are preventing repeated downloads #143

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Repeat a couple of times:
wget http://144.92.167.182/servlet_data/viavia/mr_mysql_backup/mrfile.txt
from work or home machine in the Netherlands. It works fine from tang to itself.

I've tried to vary the name tang to it's ip number but to no cause.

Dmitri, could this be caused by tang's apache settings?

I didn't see anything suspect in:
/var/log/httpd and
/etc/httpd/conf/httpd.conf  
I see a lot of access from search engines indexing the servlet_data dir but 
that should be ok.

Can you look into this? Note that is a very serious issue because it prevents 
all BMRB users from 
using data at restraintsgrid.wisc.edu. Fortunatley, the main BMRB site appears 
to be fine:

wget "http://www.bmrb.wisc.edu/cgi-bin/explore.cgi?format=raw\&bmrbId=4096"

works for me 10 times in a row.

Work around is to have this data on nmr.cmbi.ru.nl for now.

Original issue reported on code.google.com by jurge...@gmail.com on 3 Dec 2008 at 9:21

GoogleCodeExporter commented 9 years ago 
Looking good
Tomorrow I resync

Original comment by jurge...@gmail.com on 10 Mar 2009 at 6:43

GoogleCodeExporter commented 9 years ago 
Still fails after a dozen of files and I need almost a million. It prevents me 
from doing this project.

Can you debug this from your end? Just fiddle with 
/big/docr/workspace/nmrrestrntsgrid/scripts/rsyncPDB.csh
until you have all data in.

I am halting work on NRG until.

Original comment by jurge...@gmail.com on 11 Mar 2009 at 11:10

GoogleCodeExporter commented 9 years ago 
I continue development in Nijmegen.
I'll pick up Madison when Dmitri fixes this issue 143.

Original comment by jurge...@gmail.com on 12 Mar 2009 at 10:07

GoogleCodeExporter commented 9 years ago 
Syncing to RCSB from Nijmegen is very fast and keeps going:
...
data/biounit/coordinates/divided/gc/1gc3.pdb3.gz
      128999 100%  364.09kB/s    0:00:00 (xfer#25129, to-check=720514/819702)
data/biounit/coordinates/divided/gc/1gc3.pdb4.gz
      129201 100%  191.75kB/s    0:00:00 (xfer#25130, to-check=720513/819702)
data/biounit/coordinates/divided/gc/1gc4.pdb1.gz
      124955 100%  138.35kB/s    0:00:00 (xfer#25131, to-check=720512/819702)
data/biounit/coordinates/divided/gc/1gc4.pdb2.gz
      125647 100%  111.85kB/s    0:00:01 (xfer#25132, to-check=720511/819702)
data/biounit/coordinates/divided/gc/1gc4.pdb3.gz
      245328 100%  550.75kB/s    0:00:00 (xfer#25133, to-check=720510/819702)
data/biounit/coordinates/divided/gc/1gc5.pdb1.gz
       81703 100%  122.94kB/s    0:00:00 (xfer#25134, to-check=720509/819702)
...

Original comment by jurge...@gmail.com on 12 Mar 2009 at 12:04

GoogleCodeExporter commented 9 years ago 
It is not clear where the problems in the network are coming from and even if 
they
are under our control. I have reports from others (in other states) that the 
RCSB can
be very slow and intermitten at times. Large file transfers and the transfer of 
large
numbers of smaller files is not a problem unique to the UW-Madison or BMRB. 

Eldon

Original comment by Eldon.Ul...@gmail.com on 12 Mar 2009 at 3:14

GoogleCodeExporter commented 9 years ago 
It must be me but I can't get it under control from here. I hope Dmitri is able 
to sync the data and I will wait until 
he does. It's syncing fine to Nijmegen at the moment.

Original comment by jurge...@gmail.com on 12 Mar 2009 at 3:24

GoogleCodeExporter commented 9 years ago

Original comment by jurge...@gmail.com on 12 Mar 2009 at 3:24

GoogleCodeExporter commented 9 years ago 
The sync to Nijmegen completed fine a couple of days ago.

Chris had an interesting suggestion. The target for the sync is on squid which 
is nfs mounted on tang. He 
suggested the problem might be related to this situation. Dmitri, please figure 
this out if you can.

Original comment by jurge...@gmail.com on 20 Mar 2009 at 2:24

GoogleCodeExporter commented 9 years ago 
rsync of remediated PDB archive is now going full-speed on squid (where 
/dumpzone is).
Not sure why tang has a problem -- its network stats show no errors and link & 
duplex
settings are ok...

Anyway, Jurgen, we tried moving the sync out of your crontab and on to squid, 
but then
you requested I roll it back because it "broke something". What was it that 
broke and
why?

Original comment by dmitri.m...@gmail.com on 20 Mar 2009 at 6:32

GoogleCodeExporter commented 9 years ago 
This issue seemed to have been resolved by moving the partition off nfs dep.

Original comment by jurge...@gmail.com on 27 Mar 2009 at 11:16

GoogleCodeExporter commented 9 years ago 
It's still an issue with larger files.

Original comment by jurge...@gmail.com on 19 Jul 2009 at 5:13

GoogleCodeExporter commented 9 years ago

Original comment by jurge...@gmail.com on 3 Aug 2009 at 4:15

GoogleCodeExporter commented 9 years ago

Original comment by jurge...@gmail.com on 3 Aug 2009 at 4:39

GoogleCodeExporter commented 9 years ago 
This is still and issue. In response to Steve's suggestions:

I've noticed the same small benefits with limiting the bandwidth as D. 
suggested before I think.
Using that now with lionfish it still fails 3 times in a row, see below.

It indeed looks like more than tang is affected by the network problems.

Original comment by jurge...@gmail.com on 10 Nov 2009 at 6:19

GoogleCodeExporter commented 9 years ago 
Strangely the transfer from grunt via tang is working fine to my machine at 
home.
As per below, just in an hour it already downloaded the majority.
Perhaps my home machine isn't on a blacklist?

I'm reopening this issue to ask if BMRB could look into this.
It would be silly to download via my home machine again but that's my only 
access now.

...
2jxm/2jxm.tgz
     1808344 100%  992.11kB/s    0:00:01 (xfer#3529, to-check=1000/10672)
2jxn/2jxn.tgz
     1404136 100%  949.60kB/s    0:00:01 (xfer#3530, to-check=1000/10673)
2jxo/2jxo.tgz
      995076 100% 1011.19kB/s    0:00:00 (xfer#3531, to-check=1000/10674)
2jxp/2jxp.tgz
     1846419 100%  941.10kB/s    0:00:01 (xfer#3532, to-check=1000/10675)
2jxt/2jxt.tgz
     1426461 100%  768.36kB/s    0:00:01 (xfer#3533, to-check=1000/10676)
2jxu/2jxu.tgz
     1900559 100%  952.78kB/s    0:00:01 (xfer#3534, to-check=1000/10677)
...

Original comment by jurge...@gmail.com on 11 Nov 2009 at 10:20

GoogleCodeExporter commented 9 years ago 
Hi,

If the transfer is working for your home computer, but not for you at work, is 
the
problem at your Univ. and not here at BMRB?

Eldon

Original comment by Eldon.Ul...@gmail.com on 11 Nov 2009 at 2:57

GoogleCodeExporter commented 9 years ago 
Yep, I was thinking that too. I'll be able to talk to our sys admin tomorrow.
I don't think so but at least I have a way around now.

Original comment by jurge...@gmail.com on 11 Nov 2009 at 3:20

GoogleCodeExporter commented 9 years ago 
> Perhaps my home machine isn't on a blacklist?

There is no blacklist. SSH on tang was configured by you, I haven't touched it 
(or 
any other configs on tang) since.

On our "campus firewall" bandwidth is shared between all users (up to 100 
"virtual 
firewall contexts"). It seems when a few of them hit it with large file 
transfer, it 
starts acting up. If you happen to do the transfer when there is no other load 
on 
it, it'll work fine.

The other possibility is a similar bottleneck on your end of the connection.

Can you get database dumps from www, pull the list of blocks out of csv, and 
run 
curl to fetch the blocks from the servlet on www? That will bypass our firewall 
(www 
is not behind it), and throtle the transfer -- hopefully enough to get around 
whatever may be choking it on your side. It will also give you only data from 
released PDB entries.

Original comment by dmitri.m...@gmail.com on 11 Nov 2009 at 3:23

GoogleCodeExporter commented 9 years ago 
Testing again today shows the same behaviour as yesterday.

Downloads to my home mac work fine but to my work mac fails per below. Relaying 
this to our sys admin.

jd:stella/~/ $CINGROOT/scripts/cing/getNRG_ccpn.csh
wsetup: Command not found.
receiving incremental file list
./
1brv/
1brv/1brv.tgz
Read from remote host lionfish.bmrb.wisc.edu: Connection reset by peer

rsync: connection unexpectedly closed (426327 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) 
[receiver=3.0.6]
rsync: connection unexpectedly closed (69909 bytes received so far) [generator]
rsync error: unexplained error (code 255) at io.c(600) [generator=3.0.6]
Finished
jd:stella/~/ 
jd:stella/~/ 
jd:stella/~/ $CINGROOT/scripts/cing/getNRG_ccpn.csh
wsetup: Command not found.
receiving incremental file list

...HANGING...

Original comment by jurge...@gmail.com on 12 Nov 2009 at 12:18

GoogleCodeExporter commented 9 years ago 
Closing this issue again as it seems to be somewhat reliable to do -FROM- BMRB 
-TO- CMBI now.

Original comment by jurge...@gmail.com on 19 Nov 2009 at 9:04