Re: [gt-user] hostname in job contact string
Jim that completely resolved my problem. Thank you saludos, José Luis Gordillo Ruiz Coordinación de Supercómputo UNAM El 30/07/2014, a las 20:21, Basney, Jim jbas...@illinois.edu escribió: Hi José, My guess is that you want to set the GLOBUS_HOSTNAME environment variable [1] to the desired hostname when starting up the globus-gatekeeper, i.e., add export GLOBUS_HOSTNAME=hostname in your /etc/init.d/globus-gatekeeper script or env = GLOBUS_HOSTNAME=hostname in your /etc/xinetd.d/globus-gatekeeper file. According to [2] the globus-gatekeeper has honored the GLOBUS_HOSTNAME environment variable for a few years now. -Jim [1] http://toolkit.globus.org/toolkit/docs/latest-stable/ccommonlib/pi/ [2] https://globus.atlassian.net/browse/GRAM-134 On 7/30/14, 7:26 PM, j...@super.unam.mx wrote: Hi, I'm pretty sure this question has been answered in the past, but I couldn't find the answer I have a GRAM service running on a login-node in a cluster. As usually happens, this node has two network interfaces. I can successfully submit jobs to the node, however, the contact string returned is built using the hostname of the internal network interface. Is there a way to change that? thank you in advance, saludos, José Luis Gordillo Ruiz Coordinación de Supercómputo UNAM
[gt-user] myproxy-logon behavior
Hi all, I’ve already had a set of servers running different globus services. I also have a myproxy server running fine. My tests run well from Linux clients. However, they fail from MacOs X 10.10 clients with this error: globus_gsi_callback_module: Error in OLD GAA code: The subject of the certificate "/O=Grid/OU=GlobusTest/OU=simpleCA-nodoa.super.unam.mx/OU=Globus <http://simpleca-nodoa.super.unam.mx/OU=Globus> Simple CA/CN=nodob.super.unam.mx <http://nodob.super.unam.mx/>" does not match the signing policies defined in /Users/jlgr/.globus/certificates/70ff2959.signing_policy (error code 7) So, in order to have a clean environment, I deleted all certs in $HOME/.globus/certificates and rerun myproxy-logon -b …. both from Linux and Mac OSX, and I got different certificates!: FROM MACOSX $ myproxy-logon -T -b -s nodoa -l jlgr Bootstrapping MyProxy server root of trust. New trusted MyProxy server: /O=Grid/OU=GlobusTest/OU=simpleCA-nodoa.super.unam.mx/CN=nodoa.super.unam.mx <http://simpleca-nodoa.super.unam.mx/CN=nodoa.super.unam.mx> New trusted CA (70ff2959.0): /O=Grid/OU=GlobusTest/OU=simpleCA-nodoa.super.unam.mx/CN=Globus <http://simpleca-nodoa.super.unam.mx/CN=Globus> Simple CA FROM LINUX $ myproxy-logon -T -b -s nodoa -l jlgr Bootstrapping MyProxy server root of trust. New trusted MyProxy server: /O=Grid/OU=GlobusTest/OU=simpleCA-nodoa.super.unam.mx/CN=nodoa.super.unam.mx <http://simpleca-nodoa.super.unam.mx/CN=nodoa.super.unam.mx> New trusted CA (d3b04078.0): /O=Grid/OU=GlobusTest/OU=simpleCA-nodoa.super.unam.mx/CN=Globus <http://simpleca-nodoa.super.unam.mx/CN=Globus> Simple CA I’ve tryed in several clients and the result is the same Any ideas? thank you in advance saludos, José Luis Gordillo Ruiz Coordinación de Supercómputo DGTIC - UNAM
Re: [gt-user] trust roots in Mac OS
Jim, Mike, thank you for your help. Effectively, using globes-update-certificate-dir with -subject_hash_old solve the hashes issue, and also I’m now able to use clients from Mac OS El Capitan. saludos, José Luis Gordillo Ruiz Coordinación de Supercómputo - DGTIC On mar, ene 26, 2016 at 7:59 p.m., Michael Link <ml...@mcs.anl.gov> wrote: Jim's guess was right, though it isn't readily apparent. We build the Mac GT binaries to the 10.6 SDK, which includes openssl 0.9.8. (You can see in the error that it's not using El Capitan's standard version: /BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s3_clnt.c:998). You can find the correct hashes with the commands: openssl x509 -in -noout -hash openssl x509 -in -noout -subject_hash_old The Mac GT tools will need the -subject_hash_old names. There is a tool in the package, globus-update-certificate-dir, that will add symlinks of your certs with the correct hash name. In this case you'll want to edit it and modify the openssl command to use -subject_hash_old instead of -hash. Mike On 1/26/2016 6:40 PM, Basney, Jim wrote: > OK sorry my guess didn't help. Maybe someone else on the list has > another idea... > > -Jim > > On 1/26/16, 6:32 PM, José Luis Gordillo Ruiz wrote: > > version 1.x on both of them: > > Linux: $ openssl version > OpenSSL 1.0.1e-fips 11 Feb 2013 > > MacOS: $ openssl version > OpenSSL 1.0.1i 6 Aug 2014 > > > saludos, > > José Luis Gordillo Ruiz > Coordinación de Supercómputo - DGTIC > > > On mar, ene 26, 2016 at 6:28 p.m., Basney, Jim <jbas...@illinois.edu > <mailto:jbas...@illinois.edu>> wrote: > > Does one system have OpenSSL version 1.x and the other have > OpenSSL version 0.x? The hashes are different for the different > OpenSSL versions. Some details at: > http://www.cilogon.org/openssl1 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cilogon.org_openssl1=BQMFaQ=8hUWFZcy2Z-Za5rBPlktOQ=X-ngvEywj1r-yPTxcarA51KnpKNQOkBmvkP2StSnkJY=v0wghE3ea74IhF5BKwwOUAMTpTP41pMTw8r7chc7FWQ=8QYdbx2q3tg36922xVt3NeqYMPPCWgBzX0F9WoXlnXE=> > > On 1/26/16, 6:21 PM, José Luis Gordillo Ruiz wrote: > > Hi, > > I’m trying to setup some globus clients on a Mac OS (el > capitan). > > Initially, I’ve nothing on /etc/grid-security/certificates > nor .globus/certificates > > $ myproxy-get-trustroots -s condor -v > MyProxy v6.1 Jan 2016 PAM OCSP > Attempting to connect to 132.248.83.81:7512 > Successfully connected to condor:7512 > Expecting non-standard server DN > "/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx" > using trusted certificates directory > /Users/jlgr/.globus/certificates > no valid credentials found -- performing anonymous > authentication > Error authenticating: GSS Major Status: Authentication Failed > GSS Minor Status Error Chain: > globus_gss_assist: Error during context initialization > OpenSSL Error: > /BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s3_clnt.c:998: > in library: SSL routines, function > SSL3_GET_SERVER_CERTIFICATE: certificate verify failed > globus_gsi_callback_module: Could not verify credential > globus_gsi_callback_module: Can't get the local trusted CA > certificate: Untrusted self-signed certificate in chain with > hash 63167cb > > The CA that signed the myproxy-server's certificate is > untrusted. > If you want to trust the CA, re-run with the -b option. > ——— > > so, I know I have to run it con ‘-b’ option. However, my > concern is that when I run the same command on a Linux box > (under the same circumstances, with the same user > certificate) I got: > > $ myproxy-get-trustroots -s condor -v > MyProxy v6.1 Dec 2015 PAM SASL KRB5 LDAP VOMS OCSP > Attempting to connect to 132.248.83.81:7512 > Successfully connected to condor:7512 > Expecting non-standard server DN > "/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx" > using trusted certificates directory > /home/staff/jlgr/.globus/certificates > no valid credentials found -- performing anonymous > authentication > Error authenticating: GSS Major Status: Authentication Failed > GSS Minor Status Error Chain: > globus_gss_assist: Error during context initialization > OpenSSL Error: s3_clnt.c:1172: in library: SSL routines, > function SSL3_GET_SERVER_CERTIFICATE: certificate verify failed > globus_gsi_callback_module: Could not verify credential > globus_gsi_callback_module: Can't get the local trusted CA > certificate: Untrusted self-signed certificate in chain with > hash a6589a6c > > The CA that signed the myproxy-server's certificate is > untrusted. > If you want to trust the CA, re-run with the -b option. >
[gt-user] trust roots in Mac OS
Hi, I’m trying to setup some globus clients on a Mac OS (el capitan). Initially, I’ve nothing on /etc/grid-security/certificates nor .globus/certificates $ myproxy-get-trustroots -s condor -v MyProxy v6.1 Jan 2016 PAM OCSP Attempting to connect to 132.248.83.81:7512 Successfully connected to condor:7512 Expecting non-standard server DN "/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx" using trusted certificates directory /Users/jlgr/.globus/certificates no valid credentials found -- performing anonymous authentication Error authenticating: GSS Major Status: Authentication Failed GSS Minor Status Error Chain: globus_gss_assist: Error during context initialization OpenSSL Error: /BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s3_clnt.c:998: in library: SSL routines, function SSL3_GET_SERVER_CERTIFICATE: certificate verify failed globus_gsi_callback_module: Could not verify credential globus_gsi_callback_module: Can't get the local trusted CA certificate: Untrusted self-signed certificate in chain with hash 63167cb The CA that signed the myproxy-server's certificate is untrusted. If you want to trust the CA, re-run with the -b option. ——— so, I know I have to run it con ‘-b’ option. However, my concern is that when I run the same command on a Linux box (under the same circumstances, with the same user certificate) I got: $ myproxy-get-trustroots -s condor -v MyProxy v6.1 Dec 2015 PAM SASL KRB5 LDAP VOMS OCSP Attempting to connect to 132.248.83.81:7512 Successfully connected to condor:7512 Expecting non-standard server DN "/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx" using trusted certificates directory /home/staff/jlgr/.globus/certificates no valid credentials found -- performing anonymous authentication Error authenticating: GSS Major Status: Authentication Failed GSS Minor Status Error Chain: globus_gss_assist: Error during context initialization OpenSSL Error: s3_clnt.c:1172: in library: SSL routines, function SSL3_GET_SERVER_CERTIFICATE: certificate verify failed globus_gsi_callback_module: Could not verify credential globus_gsi_callback_module: Can't get the local trusted CA certificate: Untrusted self-signed certificate in chain with hash a6589a6c The CA that signed the myproxy-server's certificate is untrusted. If you want to trust the CA, re-run with the -b option. ——— So, you can se that the ‘untrusted self-signed’ certificates have different hashes, but the request was made to the same my-proxy server Why could be that? My real concern is that I can’t run globus clientes (globus-ftp, globusrun, etc) from MacOS but I can from Linux (with same user certificate, same servers, etc). I’ve been tracking down differences bt the clients and I found this difference in setting trust roots. saludos, José Luis Gordillo Ruiz Coordinación de Supercómputo - DGTIC
Re: [gt-user] globus-url-copy hangs
Hi all, I recently got into a similar problem. It’s a hostname resolution issue. see the thread for https://lists.globus.org/mailman/htdig/gt-user/2007-May/003429.html <https://lists.globus.org/mailman/htdig/gt-user/2007-May/003429.html> saludos, José Luis Gordillo Ruiz Coordinación de Supercómputo DGTIC - UNAM > El 14/03/2016, a las 9:57 a.m., Raj Kettimuthu <ketti...@anl.gov> escribió: > > Looks like a firewall issue to me. Do you have a set of ports open on the > server for data channel connections? If you have done that already, you have > to set that port range either in the server command line using ‘-port-range > startport,endport’ or set set the environment variable GLOBUS_TCP_PORT_RANGE > (GLOBUS_TCP_PORT_RANGE=startport,endport). > > On Mar 14, 2016, at 10:46 AM, Irena Johnson <ijohn...@pppl.gov > <mailto:ijohn...@pppl.gov>> wrote: > >> Dear Globus User Support, >> >> Our collaborator is having problem copying a file via command >> "globus-url-copy". >> Please see below. >> >> >> >> >> It hangs up after this: >> >> [nthoward@cmodws87 ~]$ globus-url-copy -v -dbg -nodcau >> file:///home/nthoward/281948_CMOD.REQUEST >> >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST> >> Source: file:///home/nthoward/ >> Dest: gsiftp://transpgrid.pppl.gov/~/incoming/ >> <http://transpgrid.pppl.gov/~/incoming/> >> 281948_CMOD.REQUEST >> debug: starting to put >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST> >> debug: connecting to >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST> >> debug: response from >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST>: >> 220 transpgrid2.pppl.gov <http://transpgrid2.pppl.gov/> GridFTP Server 7.20 >> (gcc64, 1420641370-85) >> [Globus Toolkit 6.0] ready. >> >> debug: authenticating with >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST> >> debug: response from >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST>: >> 230 User tr_nhoward logged in. >> >> debug: sending command to >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST>: >> SITE HELP >> >> debug: response from >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST>: >> 214-The following commands are recognized: >> ALLOAPPERESTCWD CDUPDCAUEPSVFEAT >> ERETMDTMSTATESTOHELPLISTMODENLST >> MLSCMLSDPASVRNFRMLSRMLSTNOOPOPTS >> STORPASSPBSZPORTPROTSITEEPRTRETR >> SPORMFMTSCKSTREVPWD QUITSBUFSIZE >> SPASSTRUSYSTRNTOTYPEUSERLANGMKD >> RMD DELECKSMDCSC >> 214 End >> >> debug: sending command to >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST>: >> FEAT >> >> debug: response from >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST>: >> 211-Extensions supported >> HTTP >> DCSC P,D >> MFMT >> AUTHZ_ASSERT >> MLSR >> MLSC >> UTF8 >> LANG EN >> DCAU >> PARALLEL >> SIZE >> MLST >> Type*;Size*;Modify*;Perm*;Charset;UNIX.mode*;UNIX.owner*;UNIX.uid*;UNIX.group*;UNIX.gid*;Unique*;UNIX.slink*;X.count; >> ERET >> ESTO >> SPAS >> SPOR >> REST STREAM >> MDTM >> PASV AllowDelayed; >> 211 End. >> >> debug: sending command to >> gsiftp://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST >> <http://transpgrid.pppl.gov/~/incoming/281948_CMOD.REQUEST>: >> SITE CLIENTINFO scheme=gsiftp;appname="globus-url-copy";appver="9.18 >> (gcc64, 1448068506-85) [unknown]"; >> debug: response from >> gsiftp://transpgrid.pppl.go
