[gt-user] Problems with MyProxy and VOMS support

[Lanati, Matteo]

Hi all,

I compiled MyProxy with VOMS support from the latest source tarball available, linking it against voms version 2.0.10 and openssl 1.0.1h.
I think the result is fine:
- if I do a $GLOBUS_LOCATION/sbin/myproxy-server -V I see "myproxy-server version MYPROXYv2 (v6.1 Jun 2015 PAM VOMS OCSP)”, meaning that VOMS support is there
- if I look at the executable, I see the dependency from libvomsapi, "libvomsapi.so.1 => /opt/voms/lib/libvomsapi.so.1”.
Unfortunately, when I try to retrieve a proxy that I uploaded earlier and ask MyProxy to sign it for me, it fails. The proxy is issued, but without the VO signature.
On the client I do

myproxy-logon -m esr

and I see

Enter MyProxy pass phrase:
failed to run voms-proxy-init: No such file or directory
A credential has been received for user …

Of course I don’t have voms-proxy-init on my client, that’s the whole point of using MyProxy for this task.

On the server side I see

...
Passphrase matches credentials, and PAM config is "sufficient"; authentication succeeds without checking PAM.
Owner: matteo
Location: /var/myproxy_test/ ...
Max. delegation lifetime: 43200 seconds
Sending OK response to client /C=...
retrieving proxy
Stored Credential is Proxy. VOMS AC doesn't verify.
retrieving VOMS User Information.
Retrieve esr VO
Contact to VOMS Server: voms.grid.sara.nl
Delegating credentials for /C=... lifetime=43200
Sending OK response to client /C=...
Client /C=... disconnected

Is the message "Stored Credential is Proxy. VOMS AC doesn't verify” the symptom of a problem?
In the config file I defined

allow_voms_attribute_requests true
voms_userconf /etc/vomses

and it seems that my VO (esr) and the VOMS server have been identified.

The whole setup used to work with GT 5.2.4 (compiled from scratch).
Is there any suggestion?

Best,

Matteo




Matteo Lanati
Distributed Resources Group
Leibniz-Rechenzentrum (LRZ)
Boltzmannstrasse 1
85748 Garching b. München (Germany)
Phone: [phone]

[Basney, Jim]

Hi Matteo,

Sorry for the slow response. Unfortunately I don't have easy access to a
VOMS environment to try to reproduce the problem you've reported.

I think the "VOMS AC doesn't verify" message is not a symptom of the
problem. I think you should also see that message from your working GT
5.2.4 install. I think that debug message is always printed for proxies
stored in the MyProxy repository when adding VOMS attributes. Reviewing
the code, I'd expect to see some other error thrown by the myproxy-server
if it failed to insert the VOMS attributes.

There was some re-organization of the VOMS code in the MyProxy v6.1.6
release that may have introduced a bug, but that's just an unsubstantiated
suspicion on my part. I assume you're seeing this behavior with
globus_toolkit-6.0.1421093009.tar.gz from
http://toolkit.globus.org/ftppub/gt6/installers/src. It would be helpful
to know if the same problem occurs with the original GT 6.0 tarball
(globus_toolkit-6.0.tar.gz) from September 2014 before the MyProxy v6.1.6
updates.

I opened https://github.com/globus/globus-toolkit/issues/31 to track this
issue.

Regards,
Jim

Post by Lanati, Matteo
Hi all,
I compiled MyProxy with VOMS support from the latest source tarball
available, linking it against voms version 2.0.10 and openssl 1.0.1h.
- if I do a $GLOBUS_LOCATION/sbin/myproxy-server -V I see "myproxy-server
version MYPROXYv2 (v6.1 Jun 2015 PAM VOMS OCSP)², meaning that VOMS
support is there
- if I look at the executable, I see the dependency from libvomsapi,
"libvomsapi.so.1 => /opt/voms/lib/libvomsapi.so.1².
Unfortunately, when I try to retrieve a proxy that I uploaded earlier and
ask MyProxy to sign it for me, it fails. The proxy is issued, but without
the VO signature.
On the client I do
myproxy-logon -m esr
and I see
failed to run voms-proxy-init: No such file or directory
A credential has been received for user Š
Of course I don¹t have voms-proxy-init on my client, that¹s the whole
point of using MyProxy for this task.
On the server side I see
...
Passphrase matches credentials, and PAM config is "sufficient";
authentication succeeds without checking PAM.
Owner: matteo
Location: /var/myproxy_test/ ...
Max. delegation lifetime: 43200 seconds
Sending OK response to client /C=...
retrieving proxy
Stored Credential is Proxy. VOMS AC doesn't verify.
retrieving VOMS User Information.
Retrieve esr VO
Contact to VOMS Server: voms.grid.sara.nl
Delegating credentials for /C=... lifetime=43200
Sending OK response to client /C=...
Client /C=... disconnected
Is the message "Stored Credential is Proxy. VOMS AC doesn't verify² the
symptom of a problem?
In the config file I defined
allow_voms_attribute_requests true
voms_userconf /etc/vomses
and it seems that my VO (esr) and the VOMS server have been identified.
The whole setup used to work with GT 5.2.4 (compiled from scratch).
Is there any suggestion?
Best,
Matteo
Matteo Lanati
Distributed Resources Group
Leibniz-Rechenzentrum (LRZ)
Boltzmannstrasse 1
85748 Garching b. München (Germany)
Phone: [phone]

[Lanati, Matteo]

Hi Jim,

thanks for the answer, no pressure.
I'll try to increase the verbosity of 5.2.4 and check 6.0 (you're right, I'm testing the latest GT version).
I'll let you know in the next days.
Best,

Matteo



Matteo Lanati
Distributed Resources Group
Leibniz-Rechenzentrum (LRZ)
Boltzmannstrasse 1
85748 Garching b. München (Germany)
Phone: [phone]

________________________________________
From: Basney, Jim <***@illinois.edu>
Sent: 22 June 2015 19:36
To: Lanati, Matteo
Cc: gt-***@lists.globus.org
Subject: Re: [gt-user] Problems with MyProxy and VOMS support

Hi Matteo,

Sorry for the slow response. Unfortunately I don't have easy access to a
VOMS environment to try to reproduce the problem you've reported.

I think the "VOMS AC doesn't verify" message is not a symptom of the
problem. I think you should also see that message from your working GT
5.2.4 install. I think that debug message is always printed for proxies
stored in the MyProxy repository when adding VOMS attributes. Reviewing
the code, I'd expect to see some other error thrown by the myproxy-server
if it failed to insert the VOMS attributes.

There was some re-organization of the VOMS code in the MyProxy v6.1.6
release that may have introduced a bug, but that's just an unsubstantiated
suspicion on my part. I assume you're seeing this behavior with
globus_toolkit-6.0.1421093009.tar.gz from
http://toolkit.globus.org/ftppub/gt6/installers/src. It would be helpful
to know if the same problem occurs with the original GT 6.0 tarball
(globus_toolkit-6.0.tar.gz) from September 2014 before the MyProxy v6.1.6
updates.

I opened https://github.com/globus/globus-toolkit/issues/31 to track this
issue.

Regards,
Jim

Post by Lanati, Matteo
Hi all,
I compiled MyProxy with VOMS support from the latest source tarball
available, linking it against voms version 2.0.10 and openssl 1.0.1h.
- if I do a $GLOBUS_LOCATION/sbin/myproxy-server -V I see "myproxy-server
version MYPROXYv2 (v6.1 Jun 2015 PAM VOMS OCSP)², meaning that VOMS
support is there
- if I look at the executable, I see the dependency from libvomsapi,
"libvomsapi.so.1 => /opt/voms/lib/libvomsapi.so.1².
Unfortunately, when I try to retrieve a proxy that I uploaded earlier and
ask MyProxy to sign it for me, it fails. The proxy is issued, but without
the VO signature.
On the client I do
myproxy-logon -m esr
and I see
failed to run voms-proxy-init: No such file or directory
A credential has been received for user Š
Of course I don¹t have voms-proxy-init on my client, that¹s the whole
point of using MyProxy for this task.
On the server side I see
...
Passphrase matches credentials, and PAM config is "sufficient";
authentication succeeds without checking PAM.
Owner: matteo
Location: /var/myproxy_test/ ...
Max. delegation lifetime: 43200 seconds
Sending OK response to client /C=...
retrieving proxy
Stored Credential is Proxy. VOMS AC doesn't verify.
retrieving VOMS User Information.
Retrieve esr VO
Contact to VOMS Server: voms.grid.sara.nl
Delegating credentials for /C=... lifetime=43200
Sending OK response to client /C=...
Client /C=... disconnected
Is the message "Stored Credential is Proxy. VOMS AC doesn't verify² the
symptom of a problem?
In the config file I defined
allow_voms_attribute_requests true
voms_userconf /etc/vomses
and it seems that my VO (esr) and the VOMS server have been identified.
The whole setup used to work with GT 5.2.4 (compiled from scratch).
Is there any suggestion?
Best,
Matteo
Matteo Lanati
Distributed Resources Group
Leibniz-Rechenzentrum (LRZ)
Boltzmannstrasse 1
85748 Garching b. München (Germany)
Phone: [phone]

[Lanati, Matteo]

Hi again Jim,

unfortunately I have the same problem with GT 6.0 (from Sep. 2014).
Versions 5.2.4 and 5.2.5 are fine.
If someone from the GT team is willing to look into that, we can give you access to
a test machine with the same libraries/setup we used to do our tests.
All the best,

Matteo



Matteo Lanati
Distributed Resources Group
Leibniz-Rechenzentrum (LRZ)
Boltzmannstrasse 1
85748 Garching b. München (Germany)
Phone: [phone]

[Jan Just Keijser]

Hi,

the error is on the client side:

Enter MyProxy pass phrase:
failed to run voms-proxy-init: No such file or directory
A credential has been received for user Š


when you run
myproxy-logon -m esr
the myproxy-logon command tries to launch 'voms-proxy-init -voms esr .....' and it fails to find voms-proxy-init.

FWIW:
I've download globus_toolkit-6.0.1433516164, built myproxy with voms support and launched a MyProxy server. It listed VOMS supported, and indeed, when I upload a vomsified proxy to it the proxy is stored. Delegated proxies
(e.g. run 'myproxy-get-delegation' without listing a voms server) included the VOMS info from the original upload.


cheers,

JJK / Jan Just Keijser
Nikhef
Amsterdam

Post by Basney, Jim
Hi Matteo,
Sorry for the slow response. Unfortunately I don't have easy access to a
VOMS environment to try to reproduce the problem you've reported.
I think the "VOMS AC doesn't verify" message is not a symptom of the
problem. I think you should also see that message from your working GT
5.2.4 install. I think that debug message is always printed for proxies
stored in the MyProxy repository when adding VOMS attributes. Reviewing
the code, I'd expect to see some other error thrown by the myproxy-server
if it failed to insert the VOMS attributes.
There was some re-organization of the VOMS code in the MyProxy v6.1.6
release that may have introduced a bug, but that's just an unsubstantiated
suspicion on my part. I assume you're seeing this behavior with
globus_toolkit-6.0.1421093009.tar.gz from
http://toolkit.globus.org/ftppub/gt6/installers/src. It would be helpful
to know if the same problem occurs with the original GT 6.0 tarball
(globus_toolkit-6.0.tar.gz) from September 2014 before the MyProxy v6.1.6
updates.
I opened https://github.com/globus/globus-toolkit/issues/31 to track this
issue.
Regards,
Jim

Post by Lanati, Matteo
Hi all,
I compiled MyProxy with VOMS support from the latest source tarball
available, linking it against voms version 2.0.10 and openssl 1.0.1h.
- if I do a $GLOBUS_LOCATION/sbin/myproxy-server -V I see "myproxy-server
version MYPROXYv2 (v6.1 Jun 2015 PAM VOMS OCSP)², meaning that VOMS
support is there
- if I look at the executable, I see the dependency from libvomsapi,
"libvomsapi.so.1 => /opt/voms/lib/libvomsapi.so.1².
Unfortunately, when I try to retrieve a proxy that I uploaded earlier and
ask MyProxy to sign it for me, it fails. The proxy is issued, but without
the VO signature.
On the client I do
myproxy-logon -m esr
and I see
failed to run voms-proxy-init: No such file or directory
A credential has been received for user Š
Of course I don¹t have voms-proxy-init on my client, that¹s the whole
point of using MyProxy for this task.
On the server side I see
...
Passphrase matches credentials, and PAM config is "sufficient";
authentication succeeds without checking PAM.
Owner: matteo
Location: /var/myproxy_test/ ...
Max. delegation lifetime: 43200 seconds
Sending OK response to client /C=...
retrieving proxy
Stored Credential is Proxy. VOMS AC doesn't verify.
retrieving VOMS User Information.
Retrieve esr VO
Contact to VOMS Server: voms.grid.sara.nl
Delegating credentials for /C=... lifetime=43200
Sending OK response to client /C=...
Client /C=... disconnected
Is the message "Stored Credential is Proxy. VOMS AC doesn't verify² the
symptom of a problem?
In the config file I defined
allow_voms_attribute_requests true
voms_userconf /etc/vomses
and it seems that my VO (esr) and the VOMS server have been identified.
The whole setup used to work with GT 5.2.4 (compiled from scratch).
Is there any suggestion?

[Lanati, Matteo]

Hi Jan,

I see your point (upload a VOMS enabled proxy, generated locally), but I want to store on MyProxy a plain proxy (without signature) and retrieve a credential with a VO extension. It’s MyProxy that should contact the VOMS server to get the signature. The goal is to avoid to install (and configure) the VOMS utils on the client, since it is a tedious task.

I think that when I do a “myproxy-logon -m esr”, myproxy-logon realises that it received a proxy without the signature, then it tries to add it looking for voms-proxy-init, as a fallback. I want MyProxy to do the dirty work for me and for my users ;-) . It used to work on GT 5.2.4/5.2.5. As explained by Jim in the previous mail, something changed in the meanwhile.

All the best,

Matteo

Post by Lanati, Matteo
Hi,
failed to run voms-proxy-init: No such file or directory
A credential has been received for user Š
when you run
myproxy-logon -m esr
the myproxy-logon command tries to launch 'voms-proxy-init -voms esr .....' and it fails to find voms-proxy-init.
I've download globus_toolkit-6.0.1433516164, built myproxy with voms support and launched a MyProxy server. It listed VOMS supported, and indeed, when I upload a vomsified proxy to it the proxy is stored. Delegated proxies (e.g. run 'myproxy-get-delegation' without listing a voms server) included the VOMS info from the original upload.
cheers,
JJK / Jan Just Keijser
Nikhef
Amsterdam

Matteo Lanati
Distributed Resources Group
Leibniz-Rechenzentrum (LRZ)
Boltzmannstrasse 1
85748 Garching b. München (Germany)
Phone: [phone]

[Basney, Jim]

I agree. MyProxy offers 3 options for adding VOMS attributes to the
credential:

1. adding the VOMS attributes via myproxy-init by calling voms-proxy-init
2. adding the VOMS attributes via myproxy-server using the VOMS APIs
(as requested by myproxy-logon -m)
3. adding the VOMS attributes via myproxy-logon by calling voms-proxy-init

If I understand correctly, the problem is that option #2 is not working in
GT 6.0, so myproxy-logon is trying option #3 as a fall-back, but we want
to get option #2 working again. Of the 3 options, only option #2 requires
linking with the VOMS libraries, because options #1 and #3 just call
voms-proxy-init. As Matteo explains, the nice thing about option #2 is it
doesn't require a client-side VOMS install.

I'm working on re-establishing my VOMS test environment so I can help
further with the diagnosis. Thanks Matteo for confirming that the problem
is with all GT 6.0 versions but not with GT 5.2.4 and GT 5.2.5. That
should help in finding the cause.

Regards,
Jim

Post by Lanati, Matteo
Hi Jan,
I see your point (upload a VOMS enabled proxy, generated locally), but I
want to store on MyProxy a plain proxy (without signature) and retrieve a
credential with a VO extension. It's MyProxy that should contact the VOMS
server to get the signature. The goal is to avoid to install (and
configure) the VOMS utils on the client, since it is a tedious task.
I think that when I do a "myproxy-logon -m esr", myproxy-logon realises
that it received a proxy without the signature, then it tries to add it
looking for voms-proxy-init, as a fallback. I want MyProxy to do the
dirty work for me and for my users ;-) . It used to work on GT
5.2.4/5.2.5. As explained by Jim in the previous mail, something changed
in the meanwhile.
All the best,
Matteo

Post by Lanati, Matteo
Hi,
failed to run voms-proxy-init: No such file or directory
A credential has been received for user Š
when you run
myproxy-logon -m esr
the myproxy-logon command tries to launch 'voms-proxy-init -voms esr
.....' and it fails to find voms-proxy-init.
I've download globus_toolkit-6.0.1433516164, built myproxy with voms
support and launched a MyProxy server. It listed VOMS supported, and
indeed, when I upload a vomsified proxy to it the proxy is stored.
Delegated proxies (e.g. run 'myproxy-get-delegation' without listing a
voms server) included the VOMS info from the original upload.
cheers,
JJK / Jan Just Keijser
Nikhef
Amsterdam

Matteo Lanati
Distributed Resources Group
Leibniz-Rechenzentrum (LRZ)
Boltzmannstrasse 1
85748 Garching b. München (Germany)
Phone: [phone]

[Jan Just Keijser]

Hi all,

Post by Basney, Jim
I agree. MyProxy offers 3 options for adding VOMS attributes to the
1. adding the VOMS attributes via myproxy-init by calling voms-proxy-init
2. adding the VOMS attributes via myproxy-server using the VOMS APIs
(as requested by myproxy-logon -m)
3. adding the VOMS attributes via myproxy-logon by calling voms-proxy-init
If I understand correctly, the problem is that option #2 is not working in
GT 6.0, so myproxy-logon is trying option #3 as a fall-back, but we want
to get option #2 working again. Of the 3 options, only option #2 requires
linking with the VOMS libraries, because options #1 and #3 just call
voms-proxy-init. As Matteo explains, the nice thing about option #2 is it
doesn't require a client-side VOMS install.
I'm working on re-establishing my VOMS test environment so I can help
further with the diagnosis. Thanks Matteo for confirming that the problem
is with all GT 6.0 versions but not with GT 5.2.4 and GT 5.2.5. That
should help in finding the cause.

ah, I didn't know about feature #2 : quite nice&interesting!
And yes, I can reproduce it with GT 6 as well; after some digging I
found that the problem is caused by the 'configure' script for the
myproxy code: when checking for 'globus_gsi_proxy_handle_set_extensions'
it cannot find the library libglobus_gsi_proxy_core and thus disables
support for this (#undef HAVE_GLOBUS_GSI_PROXY_HANDLE_SET_EXTENSIONS)
This causes myproxy to not add *any* extensions to delegated proxies
(see ssl_utils.c, lines 1708-1720) , including the voms extensions.
If you rerun the myproxy 'configure' script
LDFLAGS="-L/usr/local/globus-6/lib" ./configure ....
then it picks up 'globus_gsi_proxy_handle_set_extensions' just fine and
the problem is resolved.

HTH,

JJK / Jan Just Keijser
Nikhef
Amsterdam

Post by Basney, Jim

Post by Lanati, Matteo
Hi Jan,
I see your point (upload a VOMS enabled proxy, generated locally), but I
want to store on MyProxy a plain proxy (without signature) and retrieve a
credential with a VO extension. It's MyProxy that should contact the VOMS
server to get the signature. The goal is to avoid to install (and
configure) the VOMS utils on the client, since it is a tedious task.
I think that when I do a "myproxy-logon -m esr", myproxy-logon realises
that it received a proxy without the signature, then it tries to add it
looking for voms-proxy-init, as a fallback. I want MyProxy to do the
dirty work for me and for my users ;-) . It used to work on GT
5.2.4/5.2.5. As explained by Jim in the previous mail, something changed
in the meanwhile.
All the best,
Matteo

Post by Lanati, Matteo
Hi,
failed to run voms-proxy-init: No such file or directory
A credential has been received for user Š
when you run
myproxy-logon -m esr
the myproxy-logon command tries to launch 'voms-proxy-init -voms esr
.....' and it fails to find voms-proxy-init.
I've download globus_toolkit-6.0.1433516164, built myproxy with voms
support and launched a MyProxy server. It listed VOMS supported, and
indeed, when I upload a vomsified proxy to it the proxy is stored.
Delegated proxies (e.g. run 'myproxy-get-delegation' without listing a
voms server) included the VOMS info from the original upload.

[Lanati, Matteo]

Hi again Jan,

thanks for looking into this.
I confirm that it works for me too.
All the best.

Matteo

Post by Lanati, Matteo
Hi all,

Post by Basney, Jim
I agree. MyProxy offers 3 options for adding VOMS attributes to the
1. adding the VOMS attributes via myproxy-init by calling voms-proxy-init
2. adding the VOMS attributes via myproxy-server using the VOMS APIs
(as requested by myproxy-logon -m)
3. adding the VOMS attributes via myproxy-logon by calling voms-proxy-init
If I understand correctly, the problem is that option #2 is not working in
GT 6.0, so myproxy-logon is trying option #3 as a fall-back, but we want
to get option #2 working again. Of the 3 options, only option #2 requires
linking with the VOMS libraries, because options #1 and #3 just call
voms-proxy-init. As Matteo explains, the nice thing about option #2 is it
doesn't require a client-side VOMS install.
I'm working on re-establishing my VOMS test environment so I can help
further with the diagnosis. Thanks Matteo for confirming that the problem
is with all GT 6.0 versions but not with GT 5.2.4 and GT 5.2.5. That
should help in finding the cause.

ah, I didn't know about feature #2 : quite nice&interesting!
And yes, I can reproduce it with GT 6 as well; after some digging I found that the problem is caused by the 'configure' script for the myproxy code: when checking for 'globus_gsi_proxy_handle_set_extensions' it cannot find the library libglobus_gsi_proxy_core and thus disables support for this (#undef HAVE_GLOBUS_GSI_PROXY_HANDLE_SET_EXTENSIONS)
This causes myproxy to not add *any* extensions to delegated proxies (see ssl_utils.c, lines 1708-1720) , including the voms extensions.
If you rerun the myproxy 'configure' script
LDFLAGS="-L/usr/local/globus-6/lib" ./configure ....
then it picks up 'globus_gsi_proxy_handle_set_extensions' just fine and the problem is resolved.
HTH,
JJK / Jan Just Keijser
Nikhef
Amsterdam

Post by Basney, Jim

Post by Lanati, Matteo
Hi Jan,
I see your point (upload a VOMS enabled proxy, generated locally), but I
want to store on MyProxy a plain proxy (without signature) and retrieve a
credential with a VO extension. It's MyProxy that should contact the VOMS
server to get the signature. The goal is to avoid to install (and
configure) the VOMS utils on the client, since it is a tedious task.
I think that when I do a "myproxy-logon -m esr", myproxy-logon realises
that it received a proxy without the signature, then it tries to add it
looking for voms-proxy-init, as a fallback. I want MyProxy to do the
dirty work for me and for my users ;-) . It used to work on GT
5.2.4/5.2.5. As explained by Jim in the previous mail, something changed
in the meanwhile.
All the best,
Matteo

Post by Lanati, Matteo
Hi,
failed to run voms-proxy-init: No such file or directory
A credential has been received for user Š
when you run
myproxy-logon -m esr
the myproxy-logon command tries to launch 'voms-proxy-init -voms esr
.....' and it fails to find voms-proxy-init.
I've download globus_toolkit-6.0.1433516164, built myproxy with voms
support and launched a MyProxy server. It listed VOMS supported, and
indeed, when I upload a vomsified proxy to it the proxy is stored.
Delegated proxies (e.g. run 'myproxy-get-delegation' without listing a
voms server) included the VOMS info from the original upload.

Matteo Lanati
Distributed Resources Group
Leibniz-Rechenzentrum (LRZ)
Boltzmannstrasse 1
85748 Garchi

[Steven M Clark]

I downloaded the latest source version of gt6 = globus_toolkit-6.0.1433516164.

Doing a straight forward configure and make produces errors in gsi_openssh build.

./configure --prefix=${GLOBUS_HOME} \
--enable-myproxy \
--disable-gram5 \
--disable-gram5-server \
--disable-gram5-lsf \
--disable-gram5-sge \
--disable-gram5-slurm \
--disable-gram5-condor \
--disable-gram5-pbs \
--disable-gram5-auditing
make

...
make[1]: Entering directory `/var/condor/Globus/build/globus_toolkit-6.0.1433516164'
make[2]: Entering directory `/var/condor/Globus/build/globus_toolkit-6.0.1433516164/gsi_openssh/source'
(cd openbsd-compat && make)
make[3]: Entering directory `/var/condor/Globus/build/globus_toolkit-6.0.1433516164/gsi_openssh/source/openbsd-compat'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/var/condor/Globus/build/globus_toolkit-6.0.1433516164/gsi_openssh/source/openbsd-compat'
/bin/sh ./libtool --mode=link gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -fstack-protector-all -lssh -lopenbsd-compat -lcrypto -lrt -ldl -lutil -lz -lnsl -lcrypt -lresolv -lpthread /var/condor/Globus/build/globus_toolkit-6.0.1433516164/common/source/library/libglobus_common.la /var/condor/Globus/build/globus_toolkit-6.0.1433516164/gsi/gssapi/source/library/libglobus_gssapi_gsi.la /var/condor/Globus/build/globus_toolkit-6.0.1433516164/gsi/gss_assist/source/libglobus_gss_assist.la /var/condor/Globus/build/globus_toolkit-6.0.1433516164/usage/c/sender/source/libglobus_usage.la
./libtool: 5639: ./libtool: libtool_args+= -o: not found
./libtool: 6417: ./libtool: compile_command+= -o: not found
./libtool: 6418: ./libtool: finalize_command+= -o: not found
./libtool: 5639: ./libtool: libtool_args+= ssh: not found
./libtool: 5645: ./libtool: compile_command+= @OUTPUT@: not found
...

My solution was to force the gsi_openssh/source/Makefile to be run with SHELL=/bin/bash by changing

#SHELL = /bin/sh

to

SHELL = /bin/bash

I am doing the build on a Debian7 system.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.8 (wheezy)
Release: 7.8
Codename: wheezy

---
Steven Clark
Application Engineer for Scientific Computing

----- Original Message -----
From: "Jim Basney" <***@illinois.edu>
To: "Matteo Lanati" <***@lrz.de>, "Jan Just Keijser" <***@nikhef.nl>
Cc: gt-***@lists.globus.org
Sent: Wednesday, June 24, 2015 12:02:06 PM
Subject: Re: [gt-user] Problems with MyProxy and VOMS support

I agree. MyProxy offers 3 options for adding VOMS attributes to the
credential:

1. adding the VOMS attributes via myproxy-init by calling voms-proxy-init
2. adding the VOMS attributes via myproxy-server using the VOMS APIs
(as requested by myproxy-logon -m)
3. adding the VOMS attributes via myproxy-logon by calling voms-proxy-init

If I understand correctly, the problem is that option #2 is not working in
GT 6.0, so myproxy-logon is trying option #3 as a fall-back, but we want
to get option #2 working again. Of the 3 options, only option #2 requires
linking with the VOMS libraries, because options #1 and #3 just call
voms-proxy-init. As Matteo explains, the nice thing about option #2 is it
doesn't require a client-side VOMS install.

I'm working on re-establishing my VOMS test environment so I can help
further with the diagnosis. Thanks Matteo for confirming that the problem
is with all GT 6.0 versions but not with GT 5.2.4 and GT 5.2.5. That
should help in finding the cause.

Regards,
Jim

Post by Lanati, Matteo
Hi Jan,
I see your point (upload a VOMS enabled proxy, generated locally), but I
want to store on MyProxy a plain proxy (without signature) and retrieve a
credential with a VO extension. It's MyProxy that should contact the VOMS
server to get the signature. The goal is to avoid to install (and
configure) the VOMS utils on the client, since it is a tedious task.
I think that when I do a "myproxy-logon -m esr", myproxy-logon realises
that it received a proxy without the signature, then it tries to add it
looking for voms-proxy-init, as a fallback. I want MyProxy to do the
dirty work for me and for my users ;-) . It used to work on GT
5.2.4/5.2.5. As explained by Jim in the previous mail, something changed
in the meanwhile.
All the best,
Matteo

Post by Lanati, Matteo
Hi,
failed to run voms-proxy-init: No such file or directory
A credential has been received for user Š
when you run
myproxy-logon -m esr
the myproxy-logon command tries to launch 'voms-proxy-init -voms esr
.....' and it fails to find voms-proxy-init.
I've download globus_toolkit-6.0.1433516164, built myproxy with voms
support and launched a MyProxy server. It listed VOMS supported, and
indeed, when I upload a vomsified proxy to it the proxy is stored.
Delegated proxies (e.g. run 'myproxy-get-delegation' without listing a
voms server) included the VOMS info from the original upload.
cheers,
JJK / Jan Just Keijser
Nikhef
Amsterdam

Matteo Lanati
Distributed Resources Group
Leibniz-Rechenzentrum (LRZ)
Boltzmannstrasse 1
85748 Garching b. München (Germany)
Phone: [phone]

[Steven M Clark]

Sorry - the previous email about VOMS should have been axed.

---
Steven Clark
Application Engineer for Scientific Computing

----- Original Message -----
From: "Steven M Clark" <***@purdue.edu>
To: "globus toolkit" <gt-***@lists.globus.org>
Sent: Thursday, June 25, 2015 7:10:38 PM
Subject: [gt-user] Problem building gt6 from source

I downloaded the latest source version of gt6 = globus_toolkit-6.0.1433516164.

Doing a straight forward configure and make produces errors in gsi_openssh build.

./configure --prefix=${GLOBUS_HOME} \
--enable-myproxy \
--disable-gram5 \
--disable-gram5-server \
--disable-gram5-lsf \
--disable-gram5-sge \
--disable-gram5-slurm \
--disable-gram5-condor \
--disable-gram5-pbs \
--disable-gram5-auditing
make

...
make[1]: Entering directory `/var/condor/Globus/build/globus_toolkit-6.0.1433516164'
make[2]: Entering directory `/var/condor/Globus/build/globus_toolkit-6.0.1433516164/gsi_openssh/source'
(cd openbsd-compat && make)
make[3]: Entering directory `/var/condor/Globus/build/globus_toolkit-6.0.1433516164/gsi_openssh/source/openbsd-compat'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/var/condor/Globus/build/globus_toolkit-6.0.1433516164/gsi_openssh/source/openbsd-compat'
/bin/sh ./libtool --mode=link gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -fstack-protector-all -lssh -lopenbsd-compat -lcrypto -lrt -ldl -lutil -lz -lnsl -lcrypt -lresolv -lpthread /var/condor/Globus/build/globus_toolkit-6.0.1433516164/common/source/library/libglobus_common.la /var/condor/Globus/build/globus_toolkit-6.0.1433516164/gsi/gssapi/source/library/libglobus_gssapi_gsi.la /var/condor/Globus/build/globus_toolkit-6.0.1433516164/gsi/gss_assist/source/libglobus_gss_assist.la /var/condor/Globus/build/globus_toolkit-6.0.1433516164/usage/c/sender/source/libglobus_usage.la
./libtool: 5639: ./libtool: libtool_args+= -o: not found
./libtool: 6417: ./libtool: compile_command+= -o: not found
./libtool: 6418: ./libtool: finalize_command+= -o: not found
./libtool: 5639: ./libtool: libtool_args+= ssh: not found
./libtool: 5645: ./libtool: compile_command+= @OUTPUT@: not found
...

My solution was to force the gsi_openssh/source/Makefile to be run with SHELL=/bin/bash by changing

#SHELL = /bin/sh

to

SHELL = /bin/bash

I am doing the build on a Debian7 system.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.8 (wheezy)
Release: 7.8
Codename: wheezy

---
Steven Clark
Application Engineer for Scientific Computing