Re: [gt-user] Renewing /tmp/x509up_u$UID
It is possible to use myproxy-get-delegation a.k.a myproxy-retrieve to get a proxy from inside your job. If you use the -d (dn_as_username) option both to store and to retrieve the proxy then you don't need a passphase, the myproxy server will see the short lived proxy you already have and give you another one based on that. It can be tricky to figure out the right combination of options to store and retrieve but it can be done. At Fermilab what we do is set up a cron job behind the scenes to do this on behalf of the user.. the job submit does a myproxy-logon under the covers to store a proxy, and then there is a cron that runs to do myproxy-retrieve on a daily basis to put the actual short-lived proxy that the job will use. Steve From: gt-user on behalf of Koschmieder, Lukas Sent: Wednesday, May 30, 2018 5:56:15 AM To: gt-user@lists.globus.org Subject: [gt-user] Renewing /tmp/x509up_u$UID Hi, In http://toolkit.globus.org/toolkit/docs/3.2/gsi/key/#delegation the GSI delegation process is briefly described where an existing proxy_n can be used to sign an subsequent proxy_n+1. Assuming that I've used myproxy-logon to created a local proxy_n /tmp/x509up_u$UID. How would I create a proxy_n+1? Am I supposed to use openssl? Or is there a globus command for that? My goal is to renew /tmp/x509up_u$UID without reentering the passphrase. Best regards, Lukas -- Lukas Koschmieder Steel Institute IEHK RWTH Aachen University Intzestraße 1 52072 Aachen Germany
Re: [gt-user] Globus ³strict mode² coming March 2016 - Action Required
What has not been clear to me is the following: Stuart Martin's E-mail says that new clients will be released but it does not say what Globus version that those new clients correspond to. How do we tell via the client versions which ones are enforcing strict mode and which ones are not? Furthermore those of us who get the globus clients through other distributions, how do we tell when our distribution is starting to use them? Steve Timm From: gt-user-boun...@lists.globus.org on behalf of Basney, Jim Sent: Wednesday, May 4, 2016 9:00:54 AM To: GT User Subject: Re: [gt-user] Globus ³strict mode² coming March 2016 - Action Required Hi, Did this change happen as planned? Is the transition going OK for everyone? In my role as CA operator, I know we've been issuing a lot of host certs with multiple subjectAltNames in preparation for this transition, so hopefully everyone has the certs they need. -Jim On 2/4/16, 5:21 PM, Stuart Martin wrote: >Hi All, > >Here is a reminder about this deadline and upcoming change. > >Admins should check their host certificates and update them if necessary. > Replace any incompatible certificates by Mar 1, 2016. > >To allow a bit of a buffer between the service-side certificate update >deadline and clients beginning to use strict mode, updates will be made >to the Globus Toolkit to default the client-side algorithm to strict mode >on Tuesday, April 5, 2016. > >- The Globus Team > >> On Dec 1, 2015, at 2:50 PM, Stuart Martin wrote: >> >> Dear All, >> >> Globus is planning to change the default client-side algorithm for >>checking the server¹s identity used by GridFTP, MyProxy, GSI-OpenSSH, >>and GRAM. The new algorithm performs identity matching as described in >>section 3.1 of RFC 2818 >>(https://tools.ietf.org/html/rfc2818#section-3.1), the standard >>describing TLS use with HTTP. This involves a change in the >>globus-gssapi-gsi library, and will apply to any application that uses >>the updated library. >> >> The new ³strict mode² algorithm will be more strict in its enforcement, >>checking that the server¹s certificate identity matches the hostname >>that the client uses to contact the service. Once clients are >>configured for strict mode, client authentication (of any Globus >>service) would fail if the service is using a certificate that does not >>match the hostname that the client used to contact the service. >> >> This change will bring our identity checking algorithm in line with RFC >>2818, and will also close the door to reverse DNS lookup related attack >>vectors. As an example of why relying on reverse DNS for making security >>related decisions is not recommended, see this link: >>https://cwe.mitre.org/data/definitions/350.html. >> >> The Globus team has checked the host certificates used for a number of >>GridFTP endpoints and found that many are _not_ RFC 2818 compatible. >>These incompatible certificates will need to be replaced prior to >>clients defaulting to the new strict mode algorithm. >> >> We are reaching out to request that Globus service admins check their >>host certificates and update them if necessary. We are asking admins to >>replace any incompatible certificates by Mar 1, 2016. After March 1, we >>will release updated Globus Toolkit components that will change the >>default client authorization algorithm to strict mode. At that time, >>the Globus.org transfer service will also update its identity checking >>algorithm. This should ensure no service disruptions for the Globus >>community. >> >> Note: Globus Connect Server installations that use the Globus provided >>certificate are not affected and do not have to make any changes to >>their Globus Connect Server endpoint(s). >> >> We have created a page where additional details about this change will >>be communicated: >> https://docs.globus.org/security-bulletins/2015-12-strict-mode/ >> The above page includes common reasons for incompatibilities and how to >>check for compatibility. >> >> If you have any questions or concerns regarding this planned change, >>please contact us at supp...@globus.org. >> >> - The Globus team
Re: [gt-user] How to distribute problems to multiple resources (computers)?
The GT4 globus toolkit did include an implementation of the Monitoring and Discovery Service, which can be used by a number of sites to advertise to some central service which could then tell the user where to globus-job-submit (or globusrun-ws –submit as GT4 did.) In practice most production grids have some other non-globus method of telling the user which sites are available and now many free Slots that they have. Most common one is the BDII. The Open Science Grid in the US uses that, but also uses software known As the GlideinWMS to present the whole grid as a single unified resource to users. Steve Timm From: gt-user-boun...@lists.globus.org [mailto:gt-user-boun...@lists.globus.org] On Behalf Of john...@hushmail.com Sent: Sunday, November 18, 2012 5:52 PM To: gt-user Subject: [gt-user] How to distribute problems to multiple resources (computers)? Greetings GT community, Suppose that a pool of computers are able to donate their idle CPU time, how can a problem (i.e. an piece of code) get executed in them in a distributed manner? For example, when I use the command globus-job-submit, or globus-job-run, how will my local machine know where should these jobs to be submitted? I'm expecting that every resource should register itself to a discovery data base (service) that is hosted on a server(s). And that grid users (e.g. programmers/researchers) submit problems, they submit it somewhere that will dispatch them to multiple resources (CPU donators) according to a scheduler and an execution management plan that decies what to do in case of a failure. However, I fail to see how the above thoughts map to GT5 after following my reading of the quick start guide in http://www.globus.org/toolkit/docs/5.2/5.2.2/admin/quickstart/ -- what is in the guide is pretty controlled by the user/programmer (e.g. he specifies which computer to execute which commands on). Rgrds, J
Re: [gt-user] Condor-G sumission does not work while globus submit works
It appears that you are trying to mix two different versions of globus toolkit here. Globus-job-submit is a pre-ws GRAM (gt2) service. The URL you have in the condor submit file before is Trying to use GT4 (Web services) and worse, trying to use it on port 2119. Try the following GridResource in your condor-G submit file: GridResource= gt2 head.beng02.com/jobmanager-pbs I think if you use a pure gt2 service you will be fine. What you have below is a GT4 url on a GT2 port and that for sure will not work. Also, gt4 (web services) client is mostly broken in condor 7.6.6 and will be totally deprecated in the next major release of condor. Steve Timm From: gt-user-boun...@lists.globus.org [mailto:gt-user-boun...@lists.globus.org] On Behalf Of Hameed Alzahrani Sent: Sunday, April 29, 2012 8:19 PM To: gt-user@lists.globus.org Subject: [gt-user] Condor-G sumission does not work while globus submit works Hi, When I submit the following submission file through condor it does not work and the job remains idle while submitting the same job using globus-job-submit works without any errors. The log on the remote host shows authentication failure in the condor-G case but it does not shows any failure when submitting the job by globus. Does any one come across this problem or know how to solve it? any help will be appreciated. I use condor 7.6.6 and VDT 2 Submission file and process: [zhrani@CM Grid]$ cat hostname_submit.jcl grid_resource = gt4 https://head.beng02.com:2119/wsrf/services/ManagedJobFactoryService PBS Universe = grid when_to_transfer_output = ON_EXIT Executable = /bin/hostname Arguments = -f Output = cout.$(Cluster).$(Process) Log =clog.$(Cluster).$(Process) Queue [zhrani@CM Grid]$ condor_submit hostname_submit.jcl Submitting job(s). Logging submit event(s). 1 job(s) submitted to cluster 1106. [zhrani@CM Grid]$ condor_q -globus -- Submitter: CM.CHPC.hud.ac.uk : <192.168.0.10:21871> : CM.CHPC.hud.ac.uk ID OWNER STATUS MANAGER HOSTEXECUTABLE 1106.0 zhraniUNSUBMITTED PBS head.beng02.com /bin/hostname [zhrani@CM Grid]$ condor_rm zhrani User zhrani's job(s) have been marked for removal. [zhrani@CM Grid]$ globus-job-submit head.beng02.com /bin/hostname -f https://head.beng02.com:37308/6261/1335746926/ [zhrani@CM Grid]$ globus-job-status https://head.beng02.com:37308/6261/1335746926/ DONE [zhrani@CM Grid]$ globus-job-get-output https://head.beng02.com:37308/6261/1335746926/ head.beng02.com Gridmanager LOG: 04/30/12 01:46:29 [25065] resource https://head.beng02.com:2119/wsrf/services/ManagedJobFactoryService is now up 04/30/12 01:46:29 [25065] *** checkDelegation() 04/30/12 01:46:29 [25065] (1106.0) doEvaluateState called: gmState GM_UNSUBMITTED, globusState 04/30/12 01:47:19 [25065] Received CHECK_LEASES signal 04/30/12 01:47:19 [25065] in doContactSchedd() 04/30/12 01:47:19 [25065] querying for renewed leases 04/30/12 01:47:19 [25065] querying for removed/held jobs 04/30/12 01:47:19 [25065] Using constraint ((Owner=?="zhrani"&&JobUniverse==9)) && ((Managed =!= "ScheddDone")) && (JobStatus == 3 || JobStatus == 4 || (JobStatus == 5 && Managed =?= "External")) 04/30/12 01:47:19 [25065] Fetched 0 job ads from schedd 04/30/12 01:47:19 [25065] leaving doContactSchedd() 04/30/12 01:47:22 [25065] GridftpServer: Submitting job for proxy '/O=Grid/OU=GlobusTest/OU=simpleCA-head.beng02.com/OU=beng02.com/CN=zahrani' 04/30/12 01:47:22 [25065] entering FileTransfer::SimpleInit 04/30/12 01:47:22 [25065] Input files: /tmp/condor_g_scratch.0x19360fd0.25029/grid-mapfile 04/30/12 01:47:22 [25065] entering FileTransfer::UploadFiles (final_transfer=0) 04/30/12 01:47:22 [25065] entering FileTransfer::Upload 04/30/12 01:47:22 [25065] entering FileTransfer::DoUpload 04/30/12 01:47:22 [25065] DoUpload: sending file /tmp/condor_g_scratch.0x19360fd0.25029/master_proxy.2 04/30/12 01:47:22 [25065] FILETRANSFER: outgoing file_command is 4 for /tmp/condor_g_scratch.0x19360fd0.25029/master_proxy.2 04/30/12 01:47:22 [25065] Received GoAhead from peer to send /tmp/condor_g_scratch.0x19360fd0.25029/master_proxy.2 and all further files. 04/30/12 01:47:22 [25065] Sending GoAhead for 192.168.0.10 to receive /tmp/condor_g_scratch.0x19360fd0.25029/master_proxy.2 and all further files. 04/30/12 01:47:22 [25065] DoUpload: put_x509_delegation() returned 0 04/30/12 01:47:22 [25065] DoUpload: sending file /tmp/condor_g_scratch.0x19360fd0.25029/grid-mapfile 04/30/12 01:47:22 [25065] FILETRANSFER: outgoing file_command is 1 for /tmp/condor_g_scratch.0x19360fd0.25029/grid-mapfile 04/30/12 01:47:22 [25065] ReliSock::put_file_with_permissions(): going to send permissions 100644 04/30/12 01:47:22 [25065] put_file: going to send from filename /tmp/condor_g_scratch.0x19360fd0.25029/grid-mapfile 04/30/12 01:47:22 [25065] put_file: Found file size 84 04/30/12 01:47:22 [25065] put_file: sending 84 bytes 04/30/12 01:47:22 [25065] ReliSock: put_file: sent 84 bytes 04/30/12
