3) you agreed with me that moving my service ip to an alternate
network interface such as eth2 might help, but even so, it would
only help if that interface were the default route to the rest
of the world, wouldn't it?
[...]
If so, then it implies that for the moment, the globus container
must for consistency be run with a GLOBUS_HOSTNAME that matches the
default IP by which you talk to the rest of the world. Is this
correct?
Also don't know, it's been a while since I've done any real network work.
Your argument sounds reasonable, but if it were me, I'd just go
experimentally verify one way or the other.
Thanks to Dave Dykstra here at Fermilab, I was able to find a
piece of IP route-fu which forces the interface to answer
with the service IP as its default.
ip route change default via 131.225.167.200 dev eth0 src 131.225.166.2
ip route change 131.225.166.0/23 dev eth0 proto kernel scope link src
131.225.166.2
This forces 131.225.166.2 (my service IP) to be the default source IP that
is used when the system is using the eth0 default interface, which is
as you can see the interface we use to get pretty much anywhere from this
system. That allows me to globusrun-ws -submit from
a remote host without getting the authentication error I was getting
before, and without having to use the -subject option.
Now I just have to fix the RFT problem which I think
is traceable to not having the right host name
configured in the RFT mysqldb.
Steve Timm
--
------------------------------------------------------------------
Steven C. Timm, Ph.D (630) 840-8525
[EMAIL PROTECTED] http://home.fnal.gov/~timm/
Fermilab Computing Division, Scientific Computing Facilities,
Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.
