[workspace-user] Propagation with gsiftp failing - library loading error

[Tim Freeman]

On Thu, 22 Mar 2007 17:00:18 -0700
Duncan Penfold-Brown <dpb at uvic.ca> wrote:

> Hi,
> 
> I am running into a problem in trying to use gsiftp propagation with my 
> Workspaces system. To test propagation, I have images on my services 
> head-node that are to be pulled down to the hypervisor node for booting. 
> After properly setting all config files, I get an error in the 
> workspace-control create log for the workspace I try to propagate and 
> create.
> 
> Upon executing the workspace command from the services node, output 
> looks normal. The deployment stages and workspace information are 
> printed out as expected, and finish with the deployment message 
> "Changing state: Unpropagated --> Running." This appears normal, and is 
> consistent with previous working tests. All output to the container.log 
> file is also normal and expected, with the ssh call to the hypervisor 
> node returning successfully.
> 
> However, the workspace is not created on the hypervisor node.

If that is true and you got a 'Running' notification that means the transfer
error notification did not get sent properly or get to the service and that is
a bug -- which we'll investigate.

> Looking in 
> the workspace create log, I get this error message from globus-url-copy:
> 
> 2007-03-22 15:01:53,343 - DEBUG - workspace.xen_v2 (541) - image is 
> 'gsiftp://xxxx.yyyy/share/workspaces/rootfs'
> 2007-03-22 15:01:53,344 - DEBUG - workspace.xen_v2 (548) - image not 
> local calling propagate
> 2007-03-22 15:01:53,344 - DEBUG - workspace.xen_v2 (829) - entering 
> daemonized mode
> 2007-03-22 15:01:53,449 - DEBUG - workspace.xen_v2 (155) - destination 
> file is 'file:///opt/workspace/secureimages/workspace-2/rootfs'
> 2007-03-22 15:01:53,452 - INFO - workspace.xen_v2 (159) - running 
> transfer command '/usr/local/globus-4/bin/globus-url-copy 
> gsiftp://xxxx.yyyy/share/workspaces/rootfs 
> file:///opt/workspace/secureimages/workspace-2/rootfs'
> 2007-03-22 15:01:53,457 - INFO - workspace.xen_v2 (323) - error code = 32512
> 2007-03-22 15:01:53,458 - ERROR - workspace.xen_v2 (325) - error output:
> /usr/local/globus-4/bin/globus-url-copy: error while loading shared 
> libraries: libglobus_gass_copy_gcc32.so.0: cannot open shared object 
> file: No such file or directory
> 
> 
> This is a familiar error, and has occurred before due to unset 
> environment variables that globus-url-copy requires to find files. 
> However, all globus env. variables are set correctly (under all 
> applicable accounts, namely globus, and root for good measure). 
> Furthermore, when I copied that exact command from the log and executed 
> it from the globus account, it worked perfectly.

But how are you setting these environment variables?  It sounds like the
variables being set for a login are different than for an SSH command (which is
how workspace-control is being invoked).  If you get it working over ssh (and
not logged in to a shell) then it should work via workspace-control.  

For starters, try "ssh blah at xxx echo $GLOBUS_LOCATION"

What to do varies across distributions.  You can try just editing the default
profile.  You should also be able to add ~/.ssh/environment to fix (though you
may need to check on sshd config's PermitUserEnvironment setting). 

Tim 


> 
> So, in short: I don't know why globus-url-copy is having problems 
> finding the above library when called by workspace-control, as otherwise 
> globus-url-copy works fine. Any help is appreciated.
> 
> 
> PS: I do have valid certificates and proxies on both the services and 
> hypervisor nodes. Also, the globus directory on the hypervisor node is 
> NFS'ed, if that somehow could make a difference. Also, I have 
> successfully tested propagation with scp, and found it to work without 
> issues.
> 
> 
> thanks,
> 
> Duncan PB
>