Hi there, I doubt very much that is a problem with the GT, more my trying to understand what I must have missed.
I have a client machine that's been installed with a number of VDT-packaged RPMs (GT 4.0.7) from here: http://vdt.cs.wisc.edu/vdt_rpms/1.10.1/release-1/x86_rhap_5/ The client has been successfully used to: 1) Interact with an iRODS server 2) Do GridFTP with a pacman/VDT-2 GT4 job submission gateway using UberFTP 3) Access a pacman/VDT-2 GT4 job submission gateway (JSG) using globusrun-ws in passive mode Note that I had to set $GLOBUS_TCP_PORT_RANGE to get "active" GridFTP to work for the UberFTP client. The working globusrun-ws command was: globusrun-ws -passive -submit -s -S -F jsg.dom.ain -Ft Fork -c /usr/bin/id Ok, here's where it starts to get slightly messy: if I remove the "-passive" then a "reverse" GridFTP connection made from the JSG tries to connect to a random port on the client and falls foul of the firewall. If set GLOBUS_TCP_PORT_RANGE to match the firewall, akin to what was needed for the UberFTP, I get an almost immediate seg. fault. If I unset GLOBUS_TCP_PORT_RANGE but open up all incoming ports on the client I get an almost immediate seg. fault. Setting GLOBUS_TCP_SOURCE_RANGE whilst :fully open" makes no difference either. If I then restrict the firewall back the original settings, I get back to having the attempted return GridFTP connection fail. I have tried turning on what debugging there is and looking in various log but no clues. Questions thus are: Why would the segfault only happen when the firewall was opened up and not when I specify port ranges in the environment ? What's likely to be causing the segfault ? Do GLOBUS_TCP_PORT_RANGE/GLOBUS_TCP_SOURCE_RANGE have any client-side influence on globusrun-ws submissions ? Is there a way to turn on even more debug/logging info ? I appreciate that this is an old VDT/GT but the fact that the passive submission works has me believing that this should be a simple way to get a test client operational without needing a full pacman/VDT2 install. Unless of course the issue is of the interation with the VDT1 client accessing the VDT2 "server". Open to suggestions, Kevin -- Kevin M. Buckley Room: CO327 School of Engineering and Phone: +64 4 463 5971 Computer Science Victoria University of Wellington New Zealand
