Root4Star CFEngine Instructions

Part1: Steps for installing CFEngine 3 and running the installstar policy manually

Step 1-1. Get CFEngine installer file.
     wget http://www.star.bnl.gov/irmo/cfengine/cfengine-community-3.3.9-1.x86_64.rpm

(file was taken from CFEngine website just held locally)

 
Step 1-2. Install Cfengine
     /bin/rpm -ivh cfengine-community-3.3.9-1.x86_64.rpm

 
Step 1-3. Get local ip address
     /sbin/ifconfig

Step 1-4. Bootstrap cfengine to itself (no quotes for ip address)
     /var/cfengine/bin/cf-agent --bootstrap --policy-server ‘ip address’

Note: While we are not using an actual policy server in these instructions, cfengine needs some policy server in order to run. Since any Cfengine client can also be a policy hub, we bootstrap it to itself.

Step 1-5. Get the policy and place it in /var/cfengine/masterfiles.
     cd /var/cfengine/masterfiles
     wget http://www.star.bnl.gov/irmo/cfengine/installstar.cf

Step 1-6. Manually instigate the policy with output to the screen.
     /var/cfengine/bin/cf-agent -KI -f installstar.cf

(At this time the policy will need to make a few passes because of certain conditions (classes) in the policy that are not met until the first run is finished. You can continue to instigate the policy using the command /var/cfengine/bin/cf-agent –KI –f installstar.cf until the output Reports the 4 lines below.

     R: All of the required packges have been installed! :-)
      R: The installstar script has been installed! :-)
      R: The user staruser has been created and already exists! :-)
      R: The rhstar group has been created and already exists! :-)

Step 1-7. Once the policy has full completed you should su to the staruser.
     su - staruser
 You should then be able to run
      root4star

More info: Cfengine policies are designed to reach its desired state by “repairing” the machine to your specification by running the policies multiple times (This is typical with large policies like installstar.cf, this is not usually necessary with smaller policies). Once we have a dedicated policy hub we can tell Cfengine to run every 5 or 10 minutes (or any at time we like). We set this in the promises.cf file; this file is the main CFEngine file that runs all other policies.

Part 2: How to setup CFEngine Policy hub & allow CFEngine to automate the installstar policy.

Log onto the machine that you want to be the policy hub to be and complete Steps 1-1 to 1-4 as seen above.

Step 2-5. Get the policy and place it in /var/cfengine/masterfiles
     cd /var/cfengine/masterfiles
     wget http://www.star.bnl.gov/irmo/cfengine/installstar_auto.cf

Step 2-6. Get the modified promises.cf file and place it in /var/cfengine/masterfiles

Note: This file must be named promises.cf. It may be wise to backup your default promises file if you need to go back (the changes are minimal from default)
     mv /var/cfengine/masterfiles/promises.cf promises.cf.old
     cd /var/cfengine/masterfiles
     wget http://www.star.bnl.gov/irmo/cfengine/promises.cf

At this point you should be able to just wait and let CFEngine work its magic. You can look in the /var/cfengine/outputs directory and you will see logs generated every 5 minutes. You will see the same logs as you saw in the first part of this tutorial when you ran /var/cfengine/bin/cf-agent –KI –f installstar.

Note: You will not be able to run /var/cfengine/cf-agent –KI –f installstar_auto.cf against that policy as it relies on the promises.cf file for its bundlesequence (See commented lines at the top of installstar_auto.cf)

Although, if you keep the original installstar.cf file you can still instigate that policy manually.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 3: Allowing other machines to bootstrap (connect) to your policy-hub

For this tutorial you will need to complete all of the steps in “Part 2: How to setup CFEngine Policy hub & allow CFEngine to automate installstar.cf”

 
ON THE POLICY HUB

Step 3-1. You will need to add a firewall rule to /etc/sysconfig/iptables to allow machines to bootstrap to the hub.
     Any where under :OUTPUT ACCEPT[0: 0]
     Add the lines -A INPUT -p tcp -m state --state NEW -m tcp --dport 5308 -j ACCEPT

Then restart iptables
     service iptables restart

 
ON THE CLIENT MACHINE(s)

Step 3-2. Get CFEngine installer file.
     wget http://www.star.bnl.gov/irmo/cfengine/cfengine-community-3.3.9-1.x86_64.rpm

Step 3-3. Install Cfengine.
     rpm –Ivh  cfengine-community-3.3.9-1.x86_64.rpm

 
Step 3-4. Bootstrap to the policy-hub (no quotes)
     /var/cfengine/bin/cf-agent --bootstrap--policy-server ‘ip address of Policy Hub’

CFEngine will log to the screen that the bootstrap was successful. Now you can wait and watch the policies/policy populate in the directory /var/cfengine/inputs.
You can look in /var/cfengine/outputs to see the generated logs. By using the promises.cf file from www.star.bnl.gov, logs will be generated every 5 minutes.

SRM/DRM Testing June/July 2007

SRM/DRM Testing June/July 2007

Site Bandwidth Testing

The above is a bandwidth test done using the tool iperf (version iperf_2.0.2-4_i386) between the site KISTI (ui03.sdfarm.kr) and BNL (stargrid03) around the beginning of the year 2014. The connection was noted to collapse (drop to zero) a few times during testing before a full plot could be prepared.

The above histogram shows the number of simultaneous copies in one minute bins, extracted from a few week segment of the actual production at KISTI. Solitary copies are suppressed because they overwhelm the plot. Copies represent less than 1% of the jobs total run time.

The above is a bandwidth test done using the tool iperf (version iperf_2.0.2-4_i386) between the site Dubna (lxpub01.jinr.ru) and BNL (stargrid01) on 8/14/2015. After exactly 97 parallel connections the connection was noted to collapse with many parallel processes timing out, this behavior was consistent across three attempts but was not present at any lower number of parallel connections. It is suspected that a soft limit is placed on the number of parallel processes somewhere.The raw data is attached at the bottom.

The 2006 STAR analysis scenario

This page will describe in detail the STAR analysis scenario as it was in ~2006.  This scenario involves SUMS grid job submission at RCF through condor-g to PDSF using SRM's at both ends to transfer input and output files in a managed fashion.

Transfer BNL/PDSF, summer 2009

This page will document the data transfers from/to PDSF to/from BNL in the summer/autumn of 2009.

October 17, 2009

I repeated earlier tests I had run with Dan Gunter (see below "Previous results"). It takes onlt 3 streams to saturate the 1GigE network interface of stargrid04.

[stargrid04] ~/> globus-url-copy -vb file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null
   2389704704 bytes        23.59 MB/sec avg        37.00 MB/sec inst

[stargrid04] ~/> globus-url-copy -vb -tcp-bs 8388608 file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null
   1569718272 bytes        35.39 MB/sec avg        39.00 MB/sec inst

[stargrid04] ~/> globus-url-copy -vb -tcp-bs 4388608 file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null
   1607467008 bytes        35.44 MB/sec avg        38.00 MB/sec inst

[stargrid04] ~/> globus-url-copy -p 2 -vb -tcp-bs 4388608 file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null
   3414425600 bytes        72.36 MB/sec avg        63.95 MB/sec inst

[stargrid04] ~/> globus-url-copy -p 4 -vb -tcp-bs 4388608 file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null
   8569487360 bytes       108.97 MB/sec avg       111.80 MB/sec inst

[stargrid04] ~/> globus-url-copy -p 3 -vb -tcp-bs 4388608 file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null
   5576065024 bytes       106.36 MB/sec avg       109.70 MB/sec inst



[stargrid04] ~/> globus-url-copy -vb gsiftp://pdsfgrid2.nersc.gov/dev/zero file:///dev/null
    625999872 bytes         9.95 MB/sec avg        19.01 MB/sec inst

[stargrid04] ~/> globus-url-copy -vb -tcp-bs 4388608 gsiftp://pdsfgrid2.nersc.gov/dev/zero file:///dev/null
   1523580928 bytes        30.27 MB/sec avg        38.00 MB/sec inst

[stargrid04] ~/> globus-url-copy -vb -p 2 -tcp-bs 4388608 gsiftp://pdsfgrid2.nersc.gov/dev/zero file:///dev/null
   8712617984 bytes        71.63 MB/sec avg        75.87 MB/sec inst

[stargrid04] ~/> globus-url-copy -vb -p 3 -tcp-bs 4388608 gsiftp://pdsfgrid2.nersc.gov/dev/zero file:///dev/null
   7064518656 bytes       102.08 MB/sec avg       111.88 MB/sec inst

October 15, 2009 - evening

After replacing network card to 10GigE so that we could plug directly into the core switch quicktest gives:

[stargrid04] ~/> iperf -c pdsfsrm.nersc.gov -m -w 8388608 -t 120 -p 60005
------------------------------------------------------------
Client connecting to pdsfsrm.nersc.gov, TCP port 60005
TCP window size: 8.00 MByte
------------------------------------------------------------
[  3] local 130.199.6.109 port 50291 connected with 128.55.36.74 port 60005
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-120.0 sec  4.39 GBytes    314 Mbits/sec
[  3] MSS size 1368 bytes (MTU 1408 bytes, unknown interface)

More work tomorrow.

October 15, 2009

Comparison between the signal from an optical tap at the NERSC  border with the tcpdump on the node showed most of the loss happening between the border and pdsfsrm.nersc.gov.

More work was done to optimize single-stream throughput.

• pdsfsrm was moved from a switch that serves the rack where it resides to a switch that is one level up and closer to the border
• a configuration of the forcedeth driver was changed (options forcedeth optimization_mode=1 poll_interval=100 set in /etc/modprobe.conf).

Changes resulted in an improved throughput but it is stillfar from what should be (see details below). We are going to insert a 10 GigE card into the node and move it even closer to the border.

Here are the results with those buffer memory settings as of the morning 10/15/2009. There is a header from the first
measurement and then results from a few tests run minutes apart.

-------------------------------------------------------------------------
[stargrid04] ~/> iperf -c pdsfsrm.nersc.gov -m -w 8388608 -t 120 -p 60005 
------------------------------------------------------------------------- 
Client connecting to pdsfsrm.nersc.gov, TCP port 60005 TCP window size: 8.00 MByte 
------------------------------------------------------------------------- 
[ 3] local 130.199.6.109 port 44070 connected with 128.55.36.74 port 60005 
[ ID] Interval Transfer Bandwidth [ 3] 0.0-120.0 sec 1.81 GBytes 129 Mbits/sec 
[ 3] 0.0-120.0 sec 3.30 GBytes 236 Mbits/sec 
[ 3] 0.0-120.0 sec 1.86 GBytes 133 Mbits/sec 
[ 3] 0.0-120.0 sec 2.04 GBytes 146 Mbits/sec 
[ 3] 0.0-120.0 sec 3.61 GBytes 258 Mbits/sec 
[ 3] 0.0-120.0 sec 1.88 GBytes 135 Mbits/sec 
[ 3] 0.0-120.0 sec 3.35 GBytes 240 Mbits/sec 


Then I restored the "dtn" buffer memory settings - again morning 10/15/2009 and I got similar if not worse results: 


-------------------------------------------------------------------------
[stargrid04] ~/> iperf -c pdsfsrm.nersc.gov -m -w 8388608 -t 120 -p 60005 
-------------------------------------------------------------------------
Client connecting to pdsfsrm.nersc.gov, TCP port 60005 TCP window size: 8.00 MByte 
------------------------------------------------------------------------- 
[ 3] local 130.199.6.109 port 44361 connected with 128.55.36.74 port 60005 
[ ID] Interval Transfer Bandwidth [ 3] 0.0-120.0 sec 2.34 GBytes 168 Mbits/sec 
[ 3] 0.0-120.0 sec 1.42 GBytes 101 Mbits/sec 
[ 3] 0.0-120.0 sec 2.08 GBytes 149 Mbits/sec 
[ 3] 0.0-120.0 sec 2.13 GBytes 152 Mbits/sec 
[ 3] 0.0-120.0 sec 1.76 GBytes 126 Mbits/sec 
[ 3] 0.0-120.0 sec 1.42 GBytes 102 Mbits/sec 
[ 3] 0.0-120.0 sec 2.07 GBytes 148 Mbits/sec 
[ 3] 0.0-120.0 sec 2.07 GBytes 148 Mbits/sec 


And here if for comparison and to show how things vary with more or less same load on pdsfgrid2 results for the "dtn" settings 
just like above from 10/14/2009 afternoon.


 --------------------------------------------------------------------------------------
[stargrid04] ~/> iperf -c pdsfsrm.nersc.gov -m -w 8388608 -t 120 -p 60005 
--------------------------------------------------------------------------------------
Client connecting to pdsfsrm.nersc.gov, TCP port 60005 TCP window size: 8.00 MByte 
--------------------------------------------------------------------------------------
[ 3] local 130.199.6.109 port 34366 connected with 128.55.36.74 port 60005 
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-120.0 sec 1.31 GBytes 93.5 Mbits/sec   
[ 3] 0.0-120.0 sec 1.58 GBytes 113 Mbits/sec     
[ 3] 0.0-120.0 sec 1.75 GBytes 126 Mbits/sec     
[ 3] 0.0-120.0 sec 1.88 GBytes 134 Mbits/sec     
[ 3] 0.0-120.0 sec 2.56 GBytes 183 Mbits/sec     
[ 3] 0.0-120.0 sec 2.53 GBytes 181 Mbits/sec     
[ 3] 0.0-120.0 sec 3.25 GBytes 232 Mbits/sec 

Since the "80Mb/s or worse" persisted for a long time and was measured on various occasions the new numbers are due to the forceth param or the switch change. Most probably it was the switch. It is also true that the "dtn" settings were able to cope slightly better with the location on the Dell switch but seem to be not doing much when pdsfgrid2 is plugged directly into the "old pdsfcore" switch.

October 2, 2009

Notes on third party srm-copy to PDSF:

1) on PDSF interactive node, you need to set up your environment:

source /usr/local/pkg/OSG-1.2/setup.csh

2) srm-copy (recursive) has the following form:

srm-copy gsiftp://stargrid04.rcf.bnl.gov//star/institutions/lbl_prod/andrewar/transfer/reco/production_dAu/ReversedFullField/P08ie/2008/023b/  srm://pdsfsrm.nersc.gov:62443/srm/v2/server\?SFN=/eliza9/starprod/reco/production_dAu/ReversedFullField/P08ie/2008/023/  -recursive -td /eliza9/starprod/reco/production_dAu/ReversedFullField/P08ie/2008/023/

October 1, 2009

We conducted srm-copy tests between RCF and PDSF this week. Initially, the rates we saw for a third party srm-copy between RCF (stargrid04) and PDSF (pdsfsrm) are detailed in plots from Dan:

September 24, 2009 

We updated the transfer proceedure to make use of the OSG automated monitoring tools. Perviously, the transfers ran between stargrid04 and one of the NERSC data transfer nodes. To take advantage of Dan's automated log harvesting, we're switiching the target to pdsfsrm.nersc.gov.

Transfers between stargrid04 and pdsfsrm are fairly stable at ~20MBytes/sec (as reported by the "-vb" option in the globus-url-copy). The command used is of the form:

globus-url-copy -r -p 15 gsiftp://stargrid04.rcf.bnl.gov/[dir]/ gisftp://pdsfsrm.nersc.gov/[target dir]/

Plots from the first set using the pdsfsrm node:

The most recent rates seen are given in Dan's plots from Sept. 23rd:

So, the data transfer is progressing at ~100-200 Mb/s. We will next compare to rates using the new BeStMan installation at PDSF.

Previous results

Tests have been repeated as a new node (stargrid10) became available. We ran from the SRM end host at PDSF pdsfgrid2.nersc.gov to the new stargrid10.rhic.bnl.gov endpoint at BNL . Because of firewalls we could only run from PDSF to BNL, not the other way. A 60-second test got about 75Mb/s. This number is consistent with earlier iperf tests between stargrid02 and pdsfgrid2.

globus-url-copy with 8 streams would go up 400Mb/s and 16 streams 550MB/s. Also with stargrid10, the transfer rates would be the same to and from BNL.

Details below.

pdsfgrid2 59% iperf -s -f m -m -p 60005 -w 8388608 -t 60 -i 2
------------------------------------------------------------
Server listening on TCP port 60005
TCP window size: 16.0 MByte (WARNING: requested 8.00 MByte)
------------------------------------------------------------
[  4] local 128.55.36.74 port 60005 connected with 130.199.6.208 port 36698
[  4]  0.0- 2.0 sec  13.8 MBytes  57.9 Mbits/sec
[  4]  2.0- 4.0 sec  19.1 MBytes  80.2 Mbits/sec
[  4]  4.0- 6.0 sec  4.22 MBytes  17.7 Mbits/sec
[  4]  6.0- 8.0 sec  0.17 MBytes  0.71 Mbits/sec
[  4]  8.0-10.0 sec  2.52 MBytes  10.6 Mbits/sec
[  4] 10.0-12.0 sec  16.7 MBytes  70.1 Mbits/sec
[  4] 12.0-14.0 sec  17.4 MBytes  73.1 Mbits/sec
[  4] 14.0-16.0 sec  16.1 MBytes  67.7 Mbits/sec
[  4] 16.0-18.0 sec  15.8 MBytes  66.4 Mbits/sec
[  4] 18.0-20.0 sec  17.5 MBytes  73.6 Mbits/sec
[  4] 20.0-22.0 sec  17.6 MBytes  73.7 Mbits/sec
[  4] 22.0-24.0 sec  18.1 MBytes  75.8 Mbits/sec
[  4] 24.0-26.0 sec  19.5 MBytes  81.7 Mbits/sec
[  4] 26.0-28.0 sec  19.3 MBytes  80.9 Mbits/sec
[  4] 28.0-30.0 sec  13.8 MBytes  58.1 Mbits/sec
[  4] 30.0-32.0 sec  14.5 MBytes  60.7 Mbits/sec
[  4] 32.0-34.0 sec  14.7 MBytes  61.8 Mbits/sec
[  4] 34.0-36.0 sec  14.6 MBytes  61.2 Mbits/sec
[  4] 36.0-38.0 sec  17.2 MBytes  72.2 Mbits/sec
[  4] 38.0-40.0 sec  19.5 MBytes  81.6 Mbits/sec
[  4] 40.0-42.0 sec  19.5 MBytes  81.6 Mbits/sec
[  4] 42.0-44.0 sec  19.5 MBytes  81.6 Mbits/sec
[  4] 44.0-46.0 sec  19.5 MBytes  81.7 Mbits/sec
[  4] 46.0-48.0 sec  19.5 MBytes  81.6 Mbits/sec
[  4] 48.0-50.0 sec  19.1 MBytes  79.9 Mbits/sec
[  4] 50.0-52.0 sec  19.3 MBytes  80.9 Mbits/sec
[  4] 52.0-54.0 sec  19.4 MBytes  81.3 Mbits/sec
[  4] 54.0-56.0 sec  19.4 MBytes  81.5 Mbits/sec
[  4] 56.0-58.0 sec  19.5 MBytes  81.6 Mbits/sec
[  4] 58.0-60.0 sec  19.5 MBytes  81.7 Mbits/sec
[  4]  0.0-60.4 sec    489 MBytes  68.0 Mbits/sec
[  4] MSS size 1368 bytes (MTU 1408 bytes, unknown interface)

The client was on stargrid10.

on stargrid10

from stargrid10 to pdsfgrid2:

[stargrid10] ~/> globus-url-copy -vb file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null Source: file:///dev/ Dest: gsiftp://pdsfgrid2.nersc.gov/dev/

zero  ->  null
  513802240 bytes         7.57 MB/sec avg         9.09 MB/sec inst

Cancelling copy...

[stargrid10] ~/> globus-url-copy -vb -p 4 file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null Source: file:///dev/ Dest: gsiftp://pdsfgrid2.nersc.gov/dev/

zero  ->  null
 1863843840 bytes        25.39 MB/sec avg        36.25 MB/sec inst

Cancelling copy...

[stargrid10] ~/> globus-url-copy -vb -p 6 file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null Source: file:///dev/ Dest: gsiftp://pdsfgrid2.nersc.gov/dev/

zero  ->  null
 3354394624 bytes        37.64 MB/sec avg        44.90 MB/sec inst

Cancelling copy...

[stargrid10] ~/> globus-url-copy -vb -p 8 file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null Source: file:///dev/ Dest: gsiftp://pdsfgrid2.nersc.gov/dev/

zero  ->  null
 5016649728 bytes        47.84 MB/sec avg        57.35 MB/sec inst

Cancelling copy...

[stargrid10] ~/> globus-url-copy -vb -p 12 file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null Source: file:///dev/ Dest: gsiftp://pdsfgrid2.nersc.gov/dev/

zero  ->  null
 5588647936 bytes        62.70 MB/sec avg        57.95 MB/sec inst

Cancelling copy...

[stargrid10] ~/> globus-url-copy -vb -p 16 file:///dev/zero gsiftp://pdsfgrid2.nersc.gov/dev/null Source: file:///dev/ Dest: gsiftp://pdsfgrid2.nersc.gov/dev/

zero  ->  null
15292432384 bytes        74.79 MB/sec avg        65.65 MB/sec inst

Cancelling copy...

and on stargrid10 the other way, from pdsfgrid2 to stargrid10 (similar although slightly better)

[stargrid10] ~/> globus-url-copy -vb gsiftp://pdsfgrid2.nersc.gov/dev/zero file:///dev/null Source: gsiftp://pdsfgrid2.nersc.gov/dev/ Dest: file:///dev/

zero  ->  null
 1693450240 bytes        11.54 MB/sec avg        18.99 MB/sec inst

Cancelling copy...

[stargrid10] ~/> globus-url-copy -vb -p 4 gsiftp://pdsfgrid2.nersc.gov/dev/zero file:///dev/null Source: gsiftp://pdsfgrid2.nersc.gov/dev/ Dest: file:///dev/

zero  ->  null
12835618816 bytes        45.00 MB/sec avg        73.50 MB/sec inst

Cancelling copy...

[stargrid10] ~/> globus-url-copy -vb -p 8 gsiftp://pdsfgrid2.nersc.gov/dev/zero file:///dev/null Source: gsiftp://pdsfgrid2.nersc.gov/dev/ Dest: file:///dev/

zero  ->  null
14368112640 bytes        69.20 MB/sec avg       100.50 MB/sec inst

And now on pdsfgrid2 from pfsfgrid2 to stargrid10 (similar to the result for 4 stream in same direction above)

pdsfgrid2 70% globus-url-copy -vb -p 4 file:///dev/zero gsiftp://stargrid10.rcf.bnl.gov/dev/null Source: file:///dev/ Dest: gsiftp://stargrid10.rcf.bnl.gov/dev/

zero  ->  null
20869021696 bytes        50.39 MB/sec avg        73.05 MB/sec inst

Cancelling copy...

and to stargrid02, really, really bad. but since the node is going away we won't be investigating the mistery.

pdsfgrid2 71% globus-url-copy -vb -p 4 file:///dev/zero gsiftp://stargrid02.rcf.bnl.gov/dev/null Source: file:///dev/ Dest: gsiftp://stargrid02.rcf.bnl.gov/dev/

zero  ->  null
  275513344 bytes         2.39 MB/sec avg         2.40 MB/sec inst

Cancelling copy...

12 Mar 2009

Baseline from bwctl from SRM end host at PDSF -- pdsfgrid2.nersc.gov -- to a perfsonar endpoint at BNL -- lhcmon.bnl.gov. Because of firewalls, could only run from PDSF to BNL, not the other way around. Last I checked, this direction was getting about 5Mb/s from SRM. A 60-second test to the perfsonar host got about 275Mb/s.

Summary: Current baseline from perfSONAR is more than 50X what we're seeing.

RECEIVER START
bwctl: exec_line: /usr/local/bin/iperf -B 192.12.15.23 -s -f m -m -p 5008 -w 8388608 -t 60 -i 2
bwctl: start_tool: 3445880257.865809
------------------------------------------------------------
Server listening on TCP port 5008
Binding to local address 192.12.15.23
TCP window size: 16.0 MByte (WARNING: requested 8.00 MByte)
------------------------------------------------------------
[ 14] local 192.12.15.23 port 5008 connected with 128.55.36.74 port 5008
[ 14]  0.0- 2.0 sec  7.84 MBytes  32.9 Mbits/sec
[ 14]  2.0- 4.0 sec  38.2 MBytes    160 Mbits/sec
[ 14]  4.0- 6.0 sec    110 MBytes    461 Mbits/sec
[ 14]  6.0- 8.0 sec  18.3 MBytes  76.9 Mbits/sec
[ 14]  8.0-10.0 sec  59.1 MBytes    248 Mbits/sec
[ 14] 10.0-12.0 sec    102 MBytes    428 Mbits/sec
[ 14] 12.0-14.0 sec    139 MBytes    582 Mbits/sec
[ 14] 14.0-16.0 sec    142 MBytes    597 Mbits/sec
[ 14] 16.0-18.0 sec  49.7 MBytes    208 Mbits/sec
[ 14] 18.0-20.0 sec    117 MBytes    490 Mbits/sec
[ 14] 20.0-22.0 sec  46.7 MBytes    196 Mbits/sec
[ 14] 22.0-24.0 sec  47.0 MBytes    197 Mbits/sec
[ 14] 24.0-26.0 sec  81.5 MBytes    342 Mbits/sec
[ 14] 26.0-28.0 sec  75.9 MBytes    318 Mbits/sec
[ 14] 28.0-30.0 sec  45.5 MBytes    191 Mbits/sec
[ 14] 30.0-32.0 sec  56.2 MBytes    236 Mbits/sec
[ 14] 32.0-34.0 sec  55.5 MBytes    233 Mbits/sec
[ 14] 34.0-36.0 sec  58.0 MBytes    243 Mbits/sec
[ 14] 36.0-38.0 sec  61.0 MBytes    256 Mbits/sec
[ 14] 38.0-40.0 sec  61.6 MBytes    258 Mbits/sec
[ 14] 40.0-42.0 sec  72.0 MBytes    302 Mbits/sec
[ 14] 42.0-44.0 sec  62.6 MBytes    262 Mbits/sec
[ 14] 44.0-46.0 sec  64.3 MBytes    270 Mbits/sec
[ 14] 46.0-48.0 sec  66.1 MBytes    277 Mbits/sec
[ 14] 48.0-50.0 sec  33.6 MBytes    141 Mbits/sec
[ 14] 50.0-52.0 sec  63.0 MBytes    264 Mbits/sec
[ 14] 52.0-54.0 sec  55.7 MBytes    234 Mbits/sec
[ 14] 54.0-56.0 sec  56.9 MBytes    239 Mbits/sec
[ 14] 56.0-58.0 sec  59.5 MBytes    250 Mbits/sec
[ 14] 58.0-60.0 sec  50.7 MBytes    213 Mbits/sec
[ 14]  0.0-60.3 sec  1965 MBytes    273 Mbits/sec
[ 14] MSS size 1448 bytes (MTU 1500 bytes, ethernet)
bwctl: stop_exec: 3445880322.405938

RECEIVER END

11 Feb 2009

By: Dan Gunter and Iwona Sakrejda

Measured between the STAR SRM hosts at NERSC/PDSF and Brookhaven:

• pdsfgrid2.nersc.gov (henceforth, "PDSF")
• stargrid02.rcf.bnl.gov (henceforth, "BNL")

Current data flow is from PDSF to BNL, but plans are to have data flow both ways.

All numbers are in megabits per second (Mb/s). Layer 4 (transport) protocol was TCP. Tests were at least 60 sec. long, 120 sec. for the higher numbers (to give it time to ramp up). All numbers are approximate, of course.

Both sides had recent Linux kernels with auto-tuning. The max buffer sizes were at Brian Tierney's recommended sizes.

From BNL to PDSF

Tool: iperf

• 1 stream: 50-60 Mb/s (but some dips around 5Mb/s)
• 8 or 16 streams: 250-300Mb/s aggregate

Tool: globus-url-copy (see PDSF to BNL for details). This was to confirm that globus-url-copy and iperf were roughly equivalent.

• 1 stream: ~70 Mb/s
• 8 streams: 250-300 Mb/s aggregate. Note: got same number with PDSF iptables turned off.

From PDSF to BNL

Tool: globus-url-copy (gridftp) -- iperf could not connect, which we proved was due to BNL restrictions by temporarily disabling IPtables at PDSF. To avoid any possible I/O effects, ran globus-url-copy from /dev/zero to /dev/null.

• 1 stream: 5 Mb/s
• 8 streams: 40 Mb/s
• 64 streams: 250-300 Mb/s aggregate. Note: got same number with PDSF iptables turned off.

18 Aug 2008 - BNL (stargrid02) - LBLnet (dlolson)

Below are results from iperf tests bnl to lbl.
650 Mbps with very little loss is quite good.
For the uninformed (like me), we ran iperf server on dlolson.lbl.gov
listening on port 40050, then ran client on stargrid02.rcf.bnl.gov
sending udp packets with max rate of 1000 Mbps

[olson@dlolson star]$ iperf -s -p 40050 -t 60 -i 1 -u
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 40.0-41.0 sec  78.3 MBytes    657 Mbits/sec  0.012 ms    0/55826 (0%)
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 41.0-42.0 sec  78.4 MBytes    658 Mbits/sec  0.020 ms    0/55946 (0%)
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 42.0-43.0 sec  78.4 MBytes    658 Mbits/sec  0.020 ms    0/55911 (0%)
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 43.0-44.0 sec  76.8 MBytes    644 Mbits/sec  0.023 ms    0/54779 (0%)
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 44.0-45.0 sec  78.4 MBytes    657 Mbits/sec  0.016 ms    7/55912 (0.013%)
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 45.0-46.0 sec  78.4 MBytes    658 Mbits/sec  0.016 ms    0/55924 (0%)
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 46.0-47.0 sec  78.3 MBytes    656 Mbits/sec  0.024 ms    0/55820 (0%)
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 47.0-48.0 sec  78.3 MBytes    657 Mbits/sec  0.016 ms    0/55870 (0%)



[stargrid02] ~/> iperf -c dlolson.lbl.gov -t 60 -i 1 -p 40050 -u -b 1000M
[ ID] Interval       Transfer     Bandwidth
[  3] 40.0-41.0 sec  78.3 MBytes    657 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 41.0-42.0 sec  78.4 MBytes    658 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 42.0-43.0 sec  78.4 MBytes    657 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 43.0-44.0 sec  76.8 MBytes    644 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 44.0-45.0 sec  78.4 MBytes    657 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 45.0-46.0 sec  78.4 MBytes    658 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 46.0-47.0 sec  78.2 MBytes    656 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 47.0-48.0 sec  78.3 MBytes    657 Mbits/sec

Additional notes:
iperf server at bnl would not answer tho we used port 29000 with
GLOBUS_TCP_PORT_RANGE=20000,30000

iperf server at pdsf (pc2608) would not answer either.

25 August 2008 BNL - PDSF iperf results, after moving pdsf grid nodes to 1 GigE net

(pdsfgrid5) iperf % build/bin/iperf -s -p 40050 -t 20 -i 1 -u
------------------------------------------------------------
Server listening on UDP port 40050
Receiving 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
------------------------------------------------------------
[  3] local 128.55.36.73 port 40050 connected with 130.199.6.168 port 56027
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec  78.5 MBytes    659 Mbits/sec  0.017 ms   14/56030 (0.025%)
[  3]  0.0- 1.0 sec  44 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  1.0- 2.0 sec  74.1 MBytes    621 Mbits/sec  0.024 ms    8/52834 (0.015%)
[  3]  1.0- 2.0 sec  8 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  2.0- 3.0 sec  40.4 MBytes    339 Mbits/sec  0.023 ms   63/28800 (0.22%)
[  3]  2.0- 3.0 sec  63 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  3.0- 4.0 sec  73.0 MBytes    613 Mbits/sec  0.016 ms  121/52095 (0.23%)
[  3]  3.0- 4.0 sec  121 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  4.0- 5.0 sec  76.6 MBytes    643 Mbits/sec  0.020 ms   18/54661 (0.033%)
[  3]  4.0- 5.0 sec  18 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  5.0- 6.0 sec  76.8 MBytes    644 Mbits/sec  0.015 ms   51/54757 (0.093%)
[  3]  5.0- 6.0 sec  51 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  6.0- 7.0 sec  77.1 MBytes    647 Mbits/sec  0.016 ms   40/55012 (0.073%)
[  3]  6.0- 7.0 sec  40 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  7.0- 8.0 sec  74.9 MBytes    628 Mbits/sec  0.040 ms   64/53414 (0.12%)
[  3]  7.0- 8.0 sec  64 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  8.0- 9.0 sec  76.0 MBytes    637 Mbits/sec  0.021 ms   36/54189 (0.066%)
[  3]  8.0- 9.0 sec  36 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  9.0-10.0 sec  75.6 MBytes    634 Mbits/sec  0.018 ms   21/53931 (0.039%)
[  3]  9.0-10.0 sec  21 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 10.0-11.0 sec  54.7 MBytes    459 Mbits/sec  0.038 ms   20/38994 (0.051%)
[  3] 10.0-11.0 sec  20 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 11.0-12.0 sec  75.6 MBytes    634 Mbits/sec  0.019 ms   37/53939 (0.069%)
[  3] 11.0-12.0 sec  37 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 12.0-13.0 sec  74.1 MBytes    622 Mbits/sec  0.056 ms    4/52888 (0.0076%)
[  3] 12.0-13.0 sec  24 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 13.0-14.0 sec  75.4 MBytes    633 Mbits/sec  0.026 ms  115/53803 (0.21%)
[  3] 13.0-14.0 sec  115 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 14.0-15.0 sec  77.1 MBytes    647 Mbits/sec  0.038 ms   50/54997 (0.091%)
[  3] 14.0-15.0 sec  50 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 15.0-16.0 sec  75.2 MBytes    631 Mbits/sec  0.016 ms   26/53654 (0.048%)
[  3] 15.0-16.0 sec  26 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 16.0-17.0 sec  78.2 MBytes    656 Mbits/sec  0.039 ms   39/55793 (0.07%)
[  3] 16.0-17.0 sec  39 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 17.0-18.0 sec  76.6 MBytes    643 Mbits/sec  0.017 ms   35/54635 (0.064%)
[  3] 17.0-18.0 sec  35 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 18.0-19.0 sec  76.5 MBytes    641 Mbits/sec  0.039 ms   23/54544 (0.042%)
[  3] 18.0-19.0 sec  23 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3] 19.0-20.0 sec  78.0 MBytes    654 Mbits/sec  0.017 ms    1/55624 (0.0018%)
[  3] 19.0-20.0 sec  29 datagrams received out-of-order
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-20.0 sec  1.43 GBytes    614 Mbits/sec  0.018 ms   19/1044598 (0.0018%)
[  3]  0.0-20.0 sec  864 datagrams received out-of-order


[stargrid02] ~/> iperf -c pdsfgrid5.nersc.gov -t 20 -i 1 -p 40050 -u -b 1000M
------------------------------------------------------------
Client connecting to pdsfgrid5.nersc.gov, UDP port 40050
Sending 1470 byte datagrams
UDP buffer size:   128 KByte (default)
------------------------------------------------------------
[  3] local 130.199.6.168 port 56027 connected with 128.55.36.73 port 40050
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  78.5 MBytes    659 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  1.0- 2.0 sec  74.1 MBytes    621 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  2.0- 3.0 sec  40.4 MBytes    339 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  3.0- 4.0 sec  73.0 MBytes    613 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  4.0- 5.0 sec  76.6 MBytes    643 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  5.0- 6.0 sec  76.8 MBytes    644 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  6.0- 7.0 sec  77.1 MBytes    647 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  7.0- 8.0 sec  74.8 MBytes    628 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  8.0- 9.0 sec  76.0 MBytes    637 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  9.0-10.0 sec  75.6 MBytes    634 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 10.0-11.0 sec  54.6 MBytes    458 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 11.0-12.0 sec  75.7 MBytes    635 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 12.0-13.0 sec  74.1 MBytes    622 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 13.0-14.0 sec  75.4 MBytes    633 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 14.0-15.0 sec  77.1 MBytes    647 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 15.0-16.0 sec  75.2 MBytes    631 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 16.0-17.0 sec  78.2 MBytes    656 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 17.0-18.0 sec  76.6 MBytes    643 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 18.0-19.0 sec  76.4 MBytes    641 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-20.0 sec  1.43 GBytes    614 Mbits/sec
[  3] Sent 1044598 datagrams
[  3] Server Report:
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[  3]  0.0-20.0 sec  1.43 GBytes    614 Mbits/sec  0.017 ms   19/1044598 (0.0018%)
[  3]  0.0-20.0 sec  864 datagrams received out-of-order

Transfers to/from Birmingham

Getting site information from VORS

238,Purdue-Physics,grid.physics.purdue.edu:2119,compute,OSG,PASS,2006-08-21 19:16:25
237,Rice,osg-gate.rice.edu:2119,compute,OSG,FAIL,2006-08-21 19:17:07
13,SDSS_TAM,tam01.fnal.gov:2119,compute,OSG,PASS,2006-08-21 19:17:10
38,SPRACE,spgrid.if.usp.br:2119,compute,OSG,PASS,2006-08-21 19:17:51
262,STAR-Bham,rhilxs.ph.bham.ac.uk:2119,compute,OSG,PASS,2006-08-21 19:23:12
217,STAR-BNL,stargrid02.rcf.bnl.gov:2119,compute,OSG,PASS,2006-08-21 19:24:11
16,STAR-SAO_PAULO,stars.if.usp.br:2119,compute,OSG,PASS,2006-08-21 19:26:55
44,STAR-WSU,rhic23.physics.wayne.edu:2119,compute,OSG,PASS,2006-08-21 19:29:10
34,TACC,osg-login.lonestar.tacc.utexas.edu:2119,compute,OSG,FAIL,2006-08-21 19:30:23
19,TTU-ANTAEUS,antaeus.hpcc.ttu.edu:2119,compute,OSG,PASS,2006-08-21 19:30:54

#VORS text interface (grid = All, VO = all, res = 217)
shortname=STAR-BNL
gatekeeper=stargrid02.rcf.bnl.gov
gk_port=2119
globus_loc=/opt/OSG-0.4.0/globus
host_cert_exp=Feb 24 17:32:06 2007 GMT
gk_config_loc=/opt/OSG-0.4.0/globus/etc/globus-gatekeeper.conf
gsiftp_port=2811
grid_services=
schedulers=jobmanager is of type fork
jobmanager-condor is of type condor
jobmanager-fork is of type fork
jobmanager-mis is of type mis
condor_bin_loc=/home/condor/bin
mis_bin_loc=/opt/OSG-0.4.0/MIS-CI/bin
mds_port=2135
vdt_version=1.3.9c
vdt_loc=/opt/OSG-0.4.0
app_loc=/star/data08/OSG/APP
data_loc=/star/data08/OSG/DATA
tmp_loc=/star/data08/OSG/DATA
wntmp_loc=: /tmp
app_space=6098.816 GB
data_space=6098.816 GB
tmp_space=6098.816 GB
extra_variables=MountPoints
SAMPLE_LOCATION default /SAMPLE-path
SAMPLE_SCRATCH devel /SAMPLE-path
exec_jm=stargrid02.rcf.bnl.gov/jobmanager-condor
util_jm=stargrid02.rcf.bnl.gov/jobmanager
sponsor_vo=star
policy=http://www.star.bnl.gov/STAR/comp/Grid

Globus 1.1.x

QuickStart.pdf is for Globus version 1.1.3 / 1.1.4 .

Globus Toolkit Error FAQ

Globus Toolkit Error FAQ

For GRAM error codes, follow this link.

The purpose of this document is to outline common errors encountered after the installation and setup of the Globus Toolkit.

1. GRAM Job Submission failed because the connection to the server failed (check host and port) (error code 12)
2. error in loading shared libraries
3. ERROR: no valid proxy, or lifetime to small (one hour)
4. GRAM Job submission failed because authentication with the remote server failed (error code 7)
5. GRAM Job submission failed bacause authentication failed: remote certificate not yet valid (error code 7)
6. GRAM Job submission failed bacause authentication failed: remote certificate has expired (error code 7)
7. GRAM Job submission failed because data transfer to the server failed (error code 10)
8. GRAM Job submission failed because authentication failed: Expected target subject name="/CN=host/hostname"
   Target returned subject name="/O=Grid/O=Globus/CN=hostname.domain.edu" (error code 7)
9. Problem with local credentials no proxy credentials: run grid-proxy-init or wgpi first
10. GRAM Job submission failed because authentication failed: remote side did not like my creds for unknown reason
11. GRAM Job submission failed because the job manager failed to open stdout (error code 73)
    or
    GRAM Job submission failed because the job manager failed to open stderr (error code 74)
12. GRAM Job submission failed because the provided RSL string includes variables that could not be identified (error code 39)
13. 530 Login incorrect / FTP LOGIN REFUSED (shell not in /etc/shells)
14. globus_i_gsi_gss_utils.c:866: globus_i_gsi_gss_handshake: Unable to verify remote side's credentials: Couldn't verify the remote certificate
    OpenSSL Error: s3_pkt.c:1031: in library: SSL routines, function SSL3_READ_BYTES: sslv3 alert bad certificate (error code 7)
15. globus_gsi_callback.c:438: globus_i_gsi_callback_cred_verify: Could not verify credential: self signed certificate in certificate chain (error code 7)
    or
    globus_gsi_callback.c:424: globus_i_gsi_callback_cred_verify: Can't get the local trusted CA certificate: Cannot find issuer certificate for local credential (error code 7)
16. SSL3_GET_CLIENT_CERTIFICATE: no certificate returned
17. undefined symbol: lutil_sasl_interact
    followed by a failure to load a module
    /usr/local/globus-2.4.2/etc/grid-info-slapd.conf: line 23: failed to load or initialize module libback_giis.la

1. GRAM Job Submission failed because the connection to the server failed (check host and port) (error code 12)

   Diagnosis

   Your client is unable to contact the gatekeeper specified. Possible causes include:
   • The gatekeeper is not running
   • The host is not reachable.

   • The gatekeeper is on a non-standard port

   Solution

   Make sure the gatekeeper is being launched by inetd or xinetd. Review the Install Guide if you do not know how to do this. Check to make sure that ordinary TCP/IP connections are possible; can you ssh to the host, or ping it? If you cannot, then you probably can't submit jobs either. Check for typos in the hostname.

   Try telnetting to port 2119. If you see a "Unable to load shared library", the gatekeeper was not built statically, and does not have an appropriate LD_LIBRARY_PATH set. If that is the case, either rebuild it statically, or set the environment variable for the gatekeeper. In inetd, use /usr/bin/env to wrap the launch of the gatekeeper, or in xinetd, use the "env=" option.

   Check the $GLOBUS_LOCATION/var/globus-gatekeeper.log if it exists. It may tell you that the private key is insecure, so it refuses to start. In that case, fix the permissions of the key to be read only by the owner.

   If the gatekeeper is on a non-standard port, be sure to use a contact string of host:port.
   Back to top

   ---

2. error in loading shared libraries

   Diagnosis

   LD_LIBRARY_PATH is not set.

   Solution

   If you receive this as a client, make sure to read in either $GLOBUS_LOCATION/etc/globus-user-env.sh (if you are using a Bourne-like shell) or $GLOBUS_LOCATION/etc/globus-user-env.csh (if you are using a C-like shell)
   Back to top

   ---

3. ERROR: no valid proxy, or lifetime to small (one hour)

   Diagnosis

   You are running globus-personal-gatekeeper as root, or did not run grid-proxy-init.

   Solution

   Don't run globus-personal-gatekeeper as root. globus-personal-gatekeeper is designed to allow an ordinary user to establish a gatekeeper using a proxy from their personal certificate. If you are root, you should setup a gatekeeper using inetd or xinetd, and using your host certificates. If you are not root, make sure to run grid-proxy-init before starting the personal gatekeeper.
   Back to top

   ---

4. GRAM Job submission failed because authentication with the remote server failed (error code 7)

   Diagnosis

   Check the $GLOBUS_LOCATION/var/globus-gatekeeper.log on the remote server. You will probably see something like:

   Authenticated globus user: /O=Grid/O=Globus/OU=your.domain/OU=Your Name
   Failure: globus_gss_assist_gridmap() failed authorization. rc =1

   Solution

   This indicates that your account is not in the grid-mapfile. Create the grid-mapfile in /etc/grid-security (or wherever the -gridmap flag in $GLOBUS_LOCATION/etc/globus-gatekeeper.conf points to) with an entry pairing your subject name to your user name. Review the Install Guide if you do not know how to do this.  If you see "rc = 7", you may have bad permissions on the /etc/grid-security/.  It needs to be readable so that users can see the certificates/ subdirectory.
   Back to top

   ---

5. GRAM Job submission failed bacause authentication failed: remote certificate not yet valid (error code 7)

   Diagnosis

   This indicates that the remote host has a date set greater than five minutes in the future relative to the remote host.

   Try typing "date -u" on both systems at the same time to verify this. (The "-u" specifies that the time should be displayed in universal time, also known as UTC or GMT.)

   Solution

   Ultimately, synchronize the hosts using NTP. Otherwise, unless you are willing to set the client host date back, you will have to wait until your system believes that the remote certificate is valid. Also, be sure to check your shell environment to see if you have any time zone variables set.
   Back to top

   ---

6. GRAM Job submission failed because authentication failed: remote certificate has expired (error code 7)

   Diagnosis

   This indicates that the remote host has an expired certificate.

   To double-check, you can use grid-cert-info or grid-proxy-info. Use grid-cert-info on /etc/grid-security/hostcert.pem if you are dealing with a system level gatekeeper. Use grid-proxy-info if you are dealing with a personal gatekeeper.

   Solution

   If the host certificate has expired, use grid-cert-renew to get a renewal. If your proxy has expired, create a new one with grid-proxy-init.
   Back to top

   ---

7. GRAM Job submission failed because data transfer to the server failed (error code 10)

   Diagnosis

   Check the $GLOBUS_LOCATION/var/globus-gatekeeper.log on the remote server. You will probably see something like:

   Authenticated globus user: /O=Grid/O=Globus/OU=your.domain/OU=Your Name
   Failure: globus_gss_assist_gridmap() failed authorization. rc =1

   Solution

   This indicates that your account is not in the grid-mapfile. Create the grid-mapfile in /etc/grid-security (or wherever the -gridmap flag in $GLOBUS_LOCATION/etc/globus-gatekeeper.conf points to) with an entry pairing your subject name to your user name. Review the Install Guide if you do not know how to do this.
   Back to top

   ---

8. GRAM Job submission failed because authentication failed: Expected target subject name="/CN=host/hostname"
   Target returned subject name="/O=Grid/O=Globus/CN=hostname.domain.edu" (error code 7)

   Diagnosis

   New installations will often see errors like the above where the expected target subject name has just the unqualified hostname but the target returned subject name has the fully qualified domain name (e.g. expected is "hostname" but returned is "hostname.domain.edu").

   This is usually becuase the client looks up the target host's IP address in /etc/hosts and only gets the simple hostname back.

   Solution

   The solution is to edit the /etc/hosts file so that it returns the fully qualified domain name. To do this find the line in /etc/hosts that has the target host listed and make sure it looks like:

   xx.xx.xx.xx hostname.domain.edu hostname

   Where "xx.xx.xx.xx" should be the numeric IP address of the host and hostname.domain.edu should be replaced with the actual hostname in question. The trick is to make sure the full name (hostname.domain.edu) is listed before the nickname (hostname).

   If this only happens with your own host, see the explanation of the failed to open stdout error, specifically about how to set the GLOBUS_HOSTNAME for your host.
   Back to top

   ---

9. Problem with local credentials no proxy credentials: run grid-proxy-init or wgpi first

   Diagnosis

   You do not have a valid proxy.

   Solution

   Run grid-proxy-init
   Back to top

   ---

10. GRAM Job submission failed because authentication failed: remote side did not like my creds for unknown reason

    Diagnosis

    Check the $GLOBUS_LOCATION/var/globus-gatekeeper.log on the remote host. It probably says "remote certificate not yet valid". This indicates that the client host has a date set greater than five minutes in the future relative to the remote host.

    Try typing "date -u" on both systems at the same time to verify this. (The "-u" specifies that the time should be displayed in universal time, also known as UTC or GMT.)

    Solution

    Ultimately, synchronize the hosts using NTP. Otherwise, unless you are willing to set the client host date back, you will have to wait until the remote server believes that your proxy is valid. Also, be sure to check your shell environment to see if you have any time zone variables set.
    Back to top

    ---

11. GRAM Job submission failed because the job manager failed to open stdout (error code 73)

    Or GRAM Job submission failed because the job manager failed to open stderr (error code 74)

    Diagnosis

    The remote job manager is unable to open a connection back to your client host. Possible causes include:
    • Bad results from globus-hostname. Try running globus-hostname on your client. It should output the fully qualified domain name of your host. This is the information which the GRAM client tools use to let the jobmanager on the remote server know who to open a connection to. If it does not give a fully qualified domain name, the remote host may be unable to open a connection back to your host.
    • A firewall. If a firewall blocks the jobmanager's attempted connection back to your host, this error will result.
    • Troubles in the ~/.globus/.gass_cache on the remote host. This is the least frequent cause of this error. It could relate to NFS or AFS issues on the remote host.

    • It is also possible that the CA that issued your Globus certificate is not trusted by your local host. Running 'grid-proxy-init -verify' should detect this situation.

    Solution

    Depending on the cause from above, try the following solutions:
    • Fix the result of 'hostname' itself. You can accomplish this by editing /etc/hosts and adding the fully qualified domain name of your host to this file. See how to do this in the explanation of the expected target subject error. If you cannot do this, or do not want to do this, you can set the GLOBUS_HOSTNAME environment variable to override the result of globus-hostname. Set GLOBUS_HOSTNAME to the fully qualified domain name of your host.
    • To cope with a firewall, use the GLOBUS_TCP_PORT_RANGE environment variable. If your host is behind a firewall, set GLOBUS_TCP_PORT_RANGE to the allowable incoming connections on your firewall. If the firewall is in front of the remote server, you will need the remote site to set GLOBUS_TCP_PORT_RANGE in the gatekeeper's environment to the allowable incoming range of the firewall in front of the remote server. If there are firewalls on both sides, perform both of the above steps. Note that the allowable ranges do not need to coincide on the two firewalls; it is, however, necessary that the GLOBUS_TCP_PORT_RANGE be valid for both incoming and outgoing connections of the firewall it is set for.
    • If you are working with AFS, you will want the .gass_cache directory to be a link to a local filesystem. If you are having NFS trouble, you will need to fix it, which is beyond the scope of this document.

    • Install the trusted CA for your certificate on the local system.

    
    Back to top

    ---

12. GRAM Job submission failed because the provided RSL string includes variables that could not be identified (error code 39)

    Diagnosis

    You submitted a job which specifies an RSL substitution which the remote jobmanager does not recognize. The most common case is using a 2.0 version of globus-job-get-output with a 1.1.x gatekeeper/jobmanager.

    Solution

    Currently, globus-job-get-output will not work between a 2.0 client and a 1.1.x gatekeeper. Work is in progress to ensure interoperability by the final release. In the meantime, you should be able to modify the globus-job-get-output script to use $(GLOBUS_INSTALL_PATH) instead of $(GLOBUS_LOCATION).
    Back to top

    ---

13. 530 Login incorrect / FTP LOGIN REFUSED (shell not in /etc/shells)

    Diagnosis

    The 530 Login incorrect usually indicates that your account is not in the grid-mapfile, or that your shell is not in /etc/shells.

    Solution

    If your account is not in the grid-mapfile, make sure to get it added. If it is in the grid-mapfile, check the syslog on the machine, and you may see the /etc/shells message. If that is the case, make sure that your shell (as listed in finger or chsh) is in the list of approved shells in /etc/shells.
    Back to top

    ---

14. globus_i_gsi_gss_utils.c:866: globus_i_gsi_gss_handshake: Unable to verify remote side's credentials: Couldn't verify the remote certificate
    OpenSSL Error: s3_pkt.c:1031: in library: SSL routines, function SSL3_READ_BYTES: sslv3 alert bad certificate (error code 7)

    Diagnosis

    This error message usually indicates that the server you are connecting to doesn't trust the Certificate Authority (CA) that issued your Globus certificate.

    Solution

    Either use a certificate from a different CA or contact the administer of the resource you are connecting to and request that they install the CA certificate in their trusted certificates directory.
    Back to top

    ---

15. globus_gsi_callback.c:438: globus_i_gsi_callback_cred_verify: Could not verify credential: self signed certificate in certificate chain (error code 7)

    Or globus_gsi_callback.c:424: globus_i_gsi_callback_cred_verify: Can't get the local trusted CA certificate: Cannot find issuer certificate for local credential (error code 7)

    Diagnosis

    This error message indicates that your local system doesn't trust the certificate authority (CA) that issued the certificate on the resource you are connecting to.

    Solution

    You need to ask the resource administrator which CA issued their certificate and install the CA certificate in the local trusted certificates directory.
    Back to top  

    ---

16. SSL3_GET_CLIENT_CERTIFICATE: no certificate returned

    Diagnosis

    This error message indicates that the name in the certificate for the remote party is not legal according local signing_policy file for that CA.

    Solution

    You need to verify you have the correct signing policy file installed for the CA by comparing it with the one distributed by the CA.
    Back to top

    ---

17. undefined symbol: lutil_sasl_interact

    Diagnosis

    Globus replica catalog was installed along with MDS/Information Services.

    Solution

    Do not install the replica bundle into a GLOBUS_LOCATION containing other Information Services. The Replica Catalog is also deprecated - use RLS instead.
    Back to top

Intro to FermiGrid site for STAR users

The FNAL_FERMIGRID site policy and some documentation can be found here:

http://fermigrid.fnal.gov/policy.html

You must use VOMS proxies (rather than grid certificate proxies) to run at this site.  A brief intro to voms proxies is here:  Introduction to voms proxies for grid cert users

All users with STAR VOMS proxies are mapped to a single user account ("star").

Technical note: (Quoting from an email that Steve Timm sent to Levente) "Fermigrid1.fnal.gov is not a simple jobmanager-condor. It is emulating the jobmanager-condor protocol and then forwarding the jobs on to whichever clusters have got free slots, 4 condor clusters and actually one pbs cluster behind it too." For instance, I noticed jobs submitted to this gatekeeper winding up at the USCMS-FNAL-WC1-CE site in MonAlisa. (What are the other sites?)

You can use SUMS to submit jobs to this site (though this feature is still in beta testing) following this example:
star-submit-beta -p dynopol/FNAL_FERMIGRID jobDesription.xml

where jobDescription.xml is the filename of your job's xml file.

Site gatekeeper info:

Hostname:  fermigrid1.fnal.gov

condor queue is available (fermigrid1.fnal.gov/jobmanager-condor)

If no jobmanager is specified, the job runs on the gatekeeper itself (jobmanager-fork, I’d assume)

[stargrid02] ~/> globus-job-run fermigrid1.fnal.gov /bin/cat /etc/redhat-release

Scientific Linux Fermi LTS release 4.2 (Wilson)

Fermi worker node info:

[stargrid02] ~/> globus-job-run fermigrid1.fnal.gov/jobmanager-condor /bin/cat /etc/redhat-release

Scientific Linux SL release 4.2 (Beryllium)

[stargrid02] ~/> globus-job-run fermigrid1.fnal.gov/jobmanager-condor /usr/bin/gcc -v

Using built-in specs.

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux

Thread model: posix

gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)

Introduction to voms proxies for grid cert users

Here is an example to illustrate the difference between grid proxies and voms proxies (note that the WARNING and Error lines at the top don’t seem to preclude the use of the voms proxy – the fact is that I don’t know why those appear or what practical implications there are from the underlying cause – I hope to update this info as I learn more):

In order to obtain the proxy, the VOMS server for the requested VO must be contacted (with the potential drawback that it introduces a dependency on a working VOMS server that doesn’t exist with a simple grid cert. It is worth further noting that either a VOMS or GUMS server (I should investigate this) will also be contacted by VOMS-aware gatekeepers to authenticate the users at job submission time, behind the scenes. One goal (or consequence at least) of this sort of usage is to eliminate static grid-map-files.)

Something else to note (and investigate): the voms-proxy doesn’t necessarily last as long as the basic grid cert proxy – the voms part can apparently expire independent of the grid-proxy. Consider this example, in which the two expiration times are different:

(Question: What determines the duration of the voms-proxy extension - the VOMS server or the user/client?)

Technical note 1: on stargrid02, the “vomses” file, which lists the URL for VOMS servers, was not in a default location used by voms-proxy-init, and thus it was not actually working (basically, it worked just like grid-proxy-init). I have put an existing vomses file in /opt/OSG-0.4.1/voms/etc and it seems content to use it.

Technical note 2: neither stargrid03’s VDT installation nor the WNC stack on the rcas nodes has VOMS tools. I’m guessing that the VDT stack is too old on stargrid03 and that voms-proxy tools are missing on the worker nodes because that functionality isn't really needed on a worker node.

Job Managers

Modifying Virtual Machine Images and Deploying Them

Modifying Virtual Machine Images and Deploying Them

The steps:

1. login to stargrid01

    

2. Check that your ssh public key is in $home/.ssh/id_rsa.pub, if not put it there.

    

3. Select the base image you wish to modify. You will find the name of the image you are currently using for your cluster by looking inside:

   /star/u/lbhajdu/ec2/workspace-cloud-client-010/samples/[cluster discretions].xml
   

   Open up this file you will find a structure that looks something like the one below. There are two <workspace> blocks one for the gatekeeper and one for the worker nodes. The name of the image for the worker node is in the second block in-between the <image> tags. So for the example below the name would be osgworker-012.

<workspace>
  <name>head-node</name>
    <image>osgheadnode-012</image>
    <quantity>1</quantity>
	.
	.
	.
</workspace>
<workspace>
    <name>compute-nodes</name>
    <image>osgworker-012</image>
    <quantity>3</quantity>
    <nic interface=”eth1”>private</nic>
	.
	.
	.  
</workspace>

 

3. To make a modification to the image we have to mount/deploy that image. Once we know the name, simply type:

   ./bin/cloud-client.sh --run --name [image name] --hours 50
   

   Where [image name] is the name we found in step 3. This image will be up for 50 hours. You will have to save the image before you run out of time, else all of your changes will be lost.

   The output of this command will look something like:

   [stargrid01] ~/ec2/workspace-cloud-client-010/> ./bin/cloud-client.sh --run --name osgworker-012 --hours 50
   (Overriding old GLOBUS_LOCATION '/opt/OSG-0.8.0-client/globus')
   (New GLOBUS_LOCATION: '/star/u/lbhajdu/ec2/workspace-cloud-client-010/lib/globus')
   SSH public keyfile contained tilde:
   - '~/.ssh/id_rsa.pub' --> '/star/u/lbhajdu/.ssh/id_rsa.pub'
   Launching workspace.
   Workspace Factory Service:
   https://tp-vm1.ci.uchicago.edu:8445/wsrf/services/WorkspaceFactoryService
   Creating workspace "vm-003"... done.
   IP address: 128.135.125.29
   Hostname: tp-x009.ci.uchicago.edu
   Start time: Tue Jan 13 13:59:04 EST 2009
   Shutdown time: Thu Jan 15 15:59:04 EST 2009
   Termination time: Thu Jan 15 16:09:04 EST 2009
   Waiting for updates.
   "vm-003" reached target state: Running
   Running: 'vm-003'
   

   It will take some time for the command to finish, usually a few minutes. Make sure you do not loose the output for this command. Inside the output there are two pieces of information you must note. They are the hostname and the handle. In this example the hostname is tp-x009.ci.uchicago.edu and the handle is vm-003.

    

4. Next log on to the host using the host name from step 4. Note that your ssh public key will be copied to the /root/.ssh/id_rsa.pub. To log on type:

   ssh root@[hostname]

   Example:

   ssh root@tp-x009.ci.uchicago.edu
   

5. Next make the change(s) to the image, you wish to make (this step is up to you).

    

6. To save the changes you will need the handle from step 2. And you will need to pick a name for the new image. Run this command:

   ./bin/cloud-client.sh --save 	--handle [handle name] --newname [new image name]

   Where [handle name] is replaced with the name of the handle and [new image name] is replaced with the new image’s name. If you do not use the name option you will overwrite your image. Here is an example with the values from above.

   ./bin/cloud-client.sh --save --handle vm-003 --newname starworker-sl08f
   The output will look something like this:
   [stargrid01] ~/ec2/workspace-cloud-client-010/> ./bin/cloud-client.sh --save --handle vm-004 --newname starworker-sl08e
   (Overriding old GLOBUS_LOCATION '/opt/OSG-0.8.0-client/globus')
   (New GLOBUS_LOCATION: '/star/u/lbhajdu/ec2/workspace-cloud-client-010/lib/globus')
   Saving workspace.
   - Workspace handle (EPR): '/star/u/lbhajdu/ec2/workspace-cloud-client-010/history/vm-004/vw-epr.xml'
   - New name: 'starworker-sl08e'
   Waiting for updates.
   "Workspace #919": TransportReady, calling destroy for you.
   "Workspace #919" was terminated.
   

7. This is an optional step, because the images can be several GB big you may want to delete the old image with this command:

   ./bin/cloud-client.sh --delete --name [old image name] 
   

   This is what it would look like:

   (Overriding old GLOBUS_LOCATION '/opt/OSG-0.8.0-client/globus')
   (New GLOBUS_LOCATION: '/star/u/lbhajdu/ec2/workspace-cloud-client-010/lib/globus')
   Deleting: gsiftp://tp-vm1.ci.uchicago.edu:2811//cloud/56441986/starworker-sl08f
   Deleted.
   

    

8. To start up a cluster with the new image you will need to modify one of the:

   /star/u/lbhajdu/ec2/workspace-cloud-client-010/samples/[cluster discretion].xml

   file inside the <workspace> block of the worker node replace <image> with the name of your own image from step 7. You can also set the number of worker node images you wish to bring up by setting the number in the <quantity> tag.

    

   Note: Be careful remember there are usually at least two <workspace> blocks in each xml fie.

    

9. Next just bring up the cluster like any other VM cluster. (See my Drupal documentation)

Rudiments of grid map files on gatekeepers

Running Magellan Cloud at NERSC, Run 11

Running Magellan Cloud at NERSC

Fig 1. General scheme of allocation of resources and connections between machines

Fig 2. Specific implementation of the propagation of STAR DB snapshots, external DB monitoring is abandoned

SRM instructions for bulk file transfer to PDSF

These links describe how to do bulk file transfers from RCF to PDSF.

Scalability Issue Troubleshooting at EC

Scalability Issue Troubleshooting at EC2

Running jobs at EC2 show some scalability issues with grater then 20-50 jobs submitted at once. The pathology can only be seen once the jobs have completed there run cycle, that is to say, after the jobs copy back the files they have produced and the local batch system reports the job as having finished. The symptoms are as follows:

1. No stdout from the job as defined in the .condorg file as “output=” comes back. No stderror from the job as defined in the .condorg file as “error=” comes back.

It should be noted that the std output/error can be recovered from the gate keeper at EC2 by scp'ing it back. The std output/error resides in:

/home/torqueuser/.globus/job/[gk name]/*/stdout

/home/torqueuser/.globus/job/[gk name]/*/stderr

The command would be:

scp -r root@[gk name]:/home/torqueuser/.globus/job /star/data08/users/lbhajdu/vmtest/io/

2. Jobs are still reported as running under condor_q on the submitting end long after they have finished, and the batch system on the other end reports them is finished.

Below is a standard sample condor_g file from a job:

[stargrid01] /<1>data08/users/lbhajdu/vmtest/> cat globusscheduler= ec2-75-101-199-159.compute-1.amazonaws.com/jobmanager-pbs
output =/star/data08/users/starreco/prodlog/P08ie/log/C3A7967022377B3E5F2DCCE2C60CB79D_998.log
error =/star/data08/users/starreco/prodlog/P08ie/log/C3A7967022377B3E5F2DCCE2C60CB79D_998.err
log =schedC3A7967022377B3E5F2DCCE2C60CB79D_998.condorg.log
transfer_executable= true
notification =never
universe =globus
stream_output =false
stream_error =false
queue

The job parameters:

Work flow:

1. Copy in event generator configuration

2. Run raw event generator

3. Copy back raw event file (*.fzd)

4. Run reconstruction on raw events

5. Copy back reconstructed files(*.root)

6. Clean Up

Work flow processes : globus-url-copy -> pythia -> globus-url-copy -> root4star -> globus-url-copy

Note: Some low runtime processes not shown

Run time:

23 hours@1000 eventes

1 hour@10-100 events

Output:

15M rcf1504_*_1000evts.fzd

18M rcf1504_*_1000evts.geant.root

400K rcf1504_*_1000evts.hist.root

1.3M rcf1504_*_1000evts.minimc.root

3.7M rcf1504_*_1000evts.MuDst.root

60K rcf1504_*_1000evts.tags.root

14MB stdoutput log, later changed to 5KB by piping output to file and copying back via globus-url-copy.

Paths:

Jobs submitted form:

/star/data08/users/lbhajdu/vmtest/

Output copied back to:

/star/data08/users/lbhajdu/vmtest/data

STD redirect copied back to:

/star/data08/users/starreco/prodlog/P08ie/log

The tests:

1. We first tested 100nodes. Whit 14MB of text going to stdoutput. Failed with symptoms above.

2. Next test was with 10nodes. With 14MB of text going to stdoutput. This worked without any problems.

3. Next test was 20 nodes. With 14MB of text going to stdoutput. This worked without any problems.

4. Next test was 40 nodes. With 14MB of text going to stdoutput. Failed with symptoms above.

5. Next we redirected “>” the output of the event generator and the reconstruction to a file and copied this file back directly with globus-url-copy after the job was finished. We tested again with 40 nodes. The std out now is only 15K. This time it worked without any problems. (Was this just coincidence?)

    

6. Next we tried with 75 nodes and the redirected output trick. This failed with symptoms above.

7. Next we tried with 50 nodes. This failed with symptoms above.

8. We have consulted Alain Roy who has advised an upgrade of globus and condor-g. He says the upgrade of condor-g is most likely to help. Tim has upgraded the image with the latest version of globus and I will be submitting from stargrid05 which has a newer condor-g version. The software versions are listed here:

• Stargrid01

  • Condor/Condor-G 6.8.8

  • Globus Toolkit, pre web-services, client 4.0.5

  • Globus Toolkit, web-services, client 4.0.5

   

• Stargrid05

  • $CondorVersion: 7.0.5 Sep 20 2008 BuildID: 105846

  • Globus Toolkit, pre web-services, client 4.0.7

  • Globus Toolkit, pre web-services, server 4.0.7

     

9. We have tested on a five node cluster (1 head node, 4 works) and discovered a problem with stargrid05. Jobs do not get transfered over to the submitting side. The RCF has been contacted we know this is on our side. It was decided we should not submit until we can try from stargrid05.

Specification for a Grid efficiency framework

The following is an independently developed grid efficiency framework that will be consolidated with Lidia’s framework.  

The point of this work is to be able to add wrappers around the job that will report back key parameters about the job such as the time it started and the time it stopped the type of node it ran on, if it was successful and so on. These commands execute and return back strings in the jobs output stream. These can be parsed by an executable (I call it the job scanner) that extracts the parameters and writes them into a database. Later other programs use this data to produce web pages, and plots out of any parameter we have recorded.  

The image attached shows the relation between elements in my database and commands in my CSH. The commands in my CSH script will be integrated into SUMS soon. This will make it possible for any framework to parse out these parameters.   

Starting up a Globus Virtual Workspace with STAR’s image.

The steps:

1) login to stargrid01

2) Check that your ssh public key is at $home/.ssh/id_rsa.pub. This will be the key the client package copies to the gatekeeper and client nodes under the root account allowing local password free login as root, which you will need to install grid host certs.

a. Note the file name location must be as defined exactly as above or you must modify the path and name in the client configuration at ./workspace-cloud-client-009/conf/cloud.properties (more on this later).

b. If your using a Putty generated ssh public key it will not work directly. You can simply edit it with a text editor to get it in to this format. Below is an example of the right format A and the wrong format B. If it has multiple lines then it is the wrong format.

Right format A:

Wrong format B:

3) Get the grid client. By copying the folder /star/u/lbhajdu/ec2/workspace-cloud-client-009 to your area. It is recommended you execute your commands from inside the workspace-cloud-client-009. The manual describes all commands and paths relative to this directory, I will do the same.

a. This grid client is almost the same as the one you download from globus except it has the ./samples/star1.xml, which is configured to load STAR’s custom image.

4) cp to the workspace-cloud-client-009 and type:

The output should look like this:

Normal
0

false
false
false

MicrosoftInternetExplorer4

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-ansi-language:#0400;
mso-fareast-language:#0400;
mso-bidi-language:#0400;}

5.) To start the cluster type:

Two very important things you will want to make a note of from this output are the cluster handle (usually looks something like “cluster-025”) and the gatekeeper name. It will take about 10minutes to lunch this cluster. The cluster will have one gatekeeper and one worker node. The max life time of the cluster is set in the command line arguments, more parameters are in the xml file (you will want to check with Tim before changing these).
If the command hangs up really quickly (about a minute) and says something like “terminating cluster”, this usually means that you do not have a sufficient number of slots to run.

It should look something like this:

5) But hold on you can’t submit yet even thought the grid map file has our DNs in it, the gatekeeper is not trusted. We will need to install an OSG host cert on the other side. Not just anybody can do this. Doug and Leve can do this at least (and I am assuming Wayne). Open up another terminal and logon into the newly instantiated gatekeeper as root. Example here:

6) Create a .globus directory:

7) Go back to the stargrid node and copy over your grid cert and key:

8) Move over to /etc/grid-security/ on the gate keeper:

9) Create a host cert here:

10) Change right on the credentialed:

11) Delete the old host credentialed:

12) Rename the credentials:

13) Check grid functionality back on stargrid01

14) Do your grid work

15) When its time for the cluster to go down (if there is unused time remaining) run the below command. Note that you will need the cluster handle from the command used to bring up the cluster.

If there are problems:

If there are problems try this web page:
http://workspace.globus.org/clouds/cloudquickstart.html
If there are still problems try this mailing list:
workspace-user@globus.org
If there are still problems contact Tim Freeman (tfreeman at mcs.anl.gov).

Troubleshooting gsiftp at STAR-BNL

Updates on March 30:

Updates on April 2:

Updates on April 16:

>Thanks for the -dbg+TCP logs!  I posted them in a new ticket at http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=5190
>The response from the GridFTP team, posted there, is:
>"""
>What this report shows me is that the client (globus-url-copy) successfully forms a TCP control channel connection with the server.  It then successfully reads the 220 Banner message from the server.  The client then attempts to authenicate with the server.  It sends the AUTH GSSAPI command and posts a read for a response.  It is this second read that times out.

>From what i see here the both sides believe the TCP connection is formed successfully, enough so that at least 1 message is sent from the server to the client (220 banner) and possibly 1 from the client to the server (AUTH GSSAPI, since we dont have server logs we cannot confirm the server actually received it).

>I think the next step should be looking at the gssapi authentication logs on the gridftp server side to see what commands were actually received and what replies sent.  I think debugging at the TCP layer may be premature and may be introducing some red herrings.

>To get the desired logs sent the env
>export GLOBUS_XIO_GSSAPI_FTP_DEBUG=255,filename
>"""
>So, is it possible to get this set in the env of the server you're using, trigger the problem, then send the resulting gridftp.log?

I have done that and a sample log file (including log_level ALL) is attached as "gridftp-auth.xio_gssapi_ftp_debug.log"  This log file covers a sample test of 11 transfers in which 1 failed.

Updates on April 20:

Updates on April 23:

Updates on May 10:

[Long ago,] Eric Hjort did some testing with 1 second delays between successive connections and found no failures.  In recent limited testing with shorter delays, it appears that there is a threshhold at about 0.1 sec.  With delays longer than 0.1 sec, I've not seen any failures of this sort.

I installed the OSG-0.6.0 client package on presley.star.bnl.gov, which is between the RACF and BNL firewalls.  It also experiences failures when connecting to stargrid02 (inside the RACF firewall).

We've made additional tests with different server and client systems and collected additional firewall logs and tcpdumps.  For instance, using the g-u-c client on stargrid01.rcf.bnl.gov (inside both the RACF and BNL perimeter firewalls) and a gsiftp server on netmon.usatlas.bnl.gov (outside both firewalls) we see failures that appear to be the same.  I have attached firewall logs from both the RACF firewall ("RACF_fw_logs.txt") and the BNL firewall ("BNL_perimeter_fw_logs.txt") for a test with 4 failures out of 50 transfers (using a small 2.5 KB file).  Neither log shows anything out of the ordinary, with each expected connection showing up as permitted.  Tcpdumps from the client and server are also attached ("stargrid01-client.pcap" and "netmon-server.pcap" respectively).  They show a similar behaviour as in the previous dumps from NERSC and stargrid02, in which the failed connections appear to break immediately, with the client's first ACK packet somehow not quite being "understood" by the server.

RACF and ITD networking personnel have looked into this a bit.  To make a long story short, their best guess is "kernel bug, probably a race condition".  This is a highly speculative guess, with no hard evidence.  The fact that the problem has only been noticed when crossing firewalls at BNL casts doubt on this.  For instance, using a client on a NERSC host connecting to netmon, I've seen no failures, and I need to make this clear to them.  Based on tests with other clients (eg. presley.star.bnl.gov) and servers (eg. rftpexp01.rhic.bnl.gov), there is additional evidence that the problem only occurs when crossing firewalls at BNL, but I would like to quantify this, rather than relying on ad hoc testing by hand, with the hope of removing any significant possibility of statistical flukes in the test results so far.

Updates on May 25:

In testing this week, I have focused on eliminating a couple of suspects.  First, I replaced gsiftpd with a telnetd on stargrid03.rcf.bnl.gov.  The telnetd was setup to run under xinetd using port 2811 -- thus very similar to a stock gsiftp service (and conveniently punched through the various firewalls).  Testing this with connections from PDSF quickly turned up the same sort of broken connections as with gsiftp.  This seems to exonerate the globus/VDT/OSG software stack, though it doesn't rule out the possiblity of a bug in a shared library that is used by the gsiftp server.

Updates on May 30:

SOLUTION(?)

By building xinetd from the latest source (v 2.3.14, released Oct. 24, 2005) and replacing the executable from the stock Red Hat RPM on stargrid02 (with prior testing on stargrid03), the connection problems disappeared.  (minor note:  I built it with the libwrap and loadavg options compiled in, as I think Red Hat does.)

For the record, here is some version information for the servers used in various testing to date:

stargrid02 and stargrid03 are identical as far as relevant software versions:
Linux stargrid02.rcf.bnl.gov 2.4.21-47.ELsmp #1 SMP Wed Jul 5 20:38:41 EDT 2006 i686 i686 i386 GNU/Linux
Red Hat Enterprise Linux WS release 3 (Taroon Update 8)
xinetd-2.3.12-6.3E.2 (the most recent update from Red Hat for this package for RHEL 3.  Confusingly enough, the CHANGELOG for this package indicates it is version 2:2.3.***13***-6.3E.2 (not 2.3.***12***))
Replacing this with xinetd-2.3.14 built from source has apparently fixed the problem on this node.

rftpexp01.rhic.bnl.gov (between the RACF and BNL firewalls):
Linux rftpexp01.rhic.bnl.gov 2.4.21-47.0.1.ELsmp #1 SMP Fri Oct 13 17:56:20 EDT 2006 i686 i686 i386 GNU/Linux
Red Hat Enterprise Linux WS release 3 (Taroon Update 8)
xinetd-2.3.12-6.3E.2 

netmon.usatlas.bnl.gov (outside the firewalls at BNL):
Linux netmon.usatlas.bnl.gov 2.6.9-42.0.8.ELsmp #1 SMP Tue Jan 23 13:01:26 EST 2007 i686 i686 i386 GNU/Linux
Red Hat Enterprise Linux WS release 4 (Nahant Update 4)
xinetd-2.3.13-4.4E.1 (the most recent update from Red Hat for this package in RHEL 4.)

Miscellaneous wrap-up:

Open questions and remaining tests:

Using the GridCat Python client at BNL

If you want to run the GridCat Python client, there is a problem on some nodes at BNL related to BNL's proxy settings. Here are some notes that may help.

First, you'll need to get the gcatc.py Python script itself and put it somewhere that you can access. Here is the URL I used to get it, though apparently others exist:

http://gdsuf.phys.ufl.edu:8080/releases/gridcat/gridcat-client/bin/gcatc.py

(I used wget on the node on which I planned to run it, you may get it any way that works.)

Now, the trick at BNL is to get the proxy set correctly. Even though nodes like stargrid02.rcf.bnl.gov have a default "http_proxy" environment variable, it seems that Python's httplib doesn't parse it correctly and thus it fails. But it is easy enough to override as needed.

For example, here is one way in a bash shell:

[root@stargrid02 root]# http_proxy=192.168.1.4:3128; python gcatc.py --directories STAR-WSU

griddir /data/r23b/grid

appdir /data/r20g/apps

datadir /data/r20g/data

tmpdir /data/r20g/tmp

wntmpdir /tmp

Similarly in a tcsh shell:

[stargrid02] ~/> env http_proxy=192.168.1.4:3128 python /tmp/gcatc.py --gsiftpstatus STAR-BNL

gsiftp_in Pass

gsiftp_out Pass

Doug's email of November 3, 2005 contained a more detailed shell script (that requires gcatc.py) to query lots of information: http://lists.bnl.gov/mailman/private/stargrid-l/2005-November/002426.html.
You could add the proxy modification into that script, presumably as a local variable.

CERTS & VOMS/VOMRS

CERTS

If you do NOT have a grid certificate yet or need to renew your certificate, you need to either request a certificate or request a renewal. Instructions are available as:

• Obtaining a Grid CERT
• Renewing a CERT
• Convert and export a CERT
• Installing your CERT (browser install)
• Join the STAR VO
• FAQ

• Your Sponsor and point of contact should be "Jerome Lauret"  the STAR/VO representative (and not your supervisor name or otherwise)
  
• Note that as a request for a CERT, being added to the STAR VO requires approval from the STAR/RA and the STAR/VO representative (the RA are aware of this - best chance for your request to be promptly approved is to have the proper "Sponsor")
• It does not hurt to specify that you belong to STAR when the ticket is created
• Please, indicate on the request for a CERTificate what is your expected use of Grid services (data transfer? rnning jobs? anything else?)
• Requesting a using a CERT and using it binds you to the OSG Policy Agreement you have to accept during the request. Failure to comply or violations will lead to a revocation of your CERT validity (in STAR, you have to expect that your VO representative will make sure of the polity IS respected in full)
   
• The big advantage of renewing a CERT rather than requesting a new one is that the CN will be preserved (so no need for gridmap change)
• The STAR/VO does NOT acept CERT-ificates other than STAR related CERT-ificates that is, OSG DigiCert-Grid CERT obtained for STAR related work and purposes. A user owning a CERT from a different VO will not be granted membership in VOMS - request a new CERT uniquely associated to STAR related work.
• STAR rule of thumb / convention - Additional user certificates mapped to generic accounts: the CN would indicate the CERT owner's name. The generic account would appear in parenthesis. An example: /CN=Lidia Didenko (starreco)
• STAR rule of thumb / convention - Service certificates: The CN field shows the requestor of the certificate

VOMS and VOMRS

Having a CERT is the first step. You now need to be part of a Virtual Organization (VO).

STAR used VOMRS during PPDG time and switched to VOMS at OSG time to maintained its VO user's certificates.
Only VOMS is currentely maintained. A VO is used as a centralized repository of user based information so all sites on the grid could be updated on addition (or removal) of identifications. VOMS service and Web interface are maintained by the RACF.
 

OSG Issues

This page will anchor various OSG-related collaborative efforts.

STAR VO Privilege Configuration

<!--- 9 STAR ---!>
<groupMapping name='star' accountingVo='star' accountingDesc='STAR'>
    <userGroup className='gov.bnl.gums.VOMSGroup'
       url='https://vo.racf.bnl.gov:8443/edg-voms-admin/star/services/VOMSAdmin'
       persistenceFactory='mysql'
       name='osg-star'
       voGroup="/star"
       sslCertfile='/etc/grid-security/hostcert.pem'
       sslKey='/etc/grid-security/hostkey.pem' ignoreFQAN="true"/>
    <accountMapping className='gov.bnl.gums.GroupAccountMapper'
      groupName='osg-star' />
</groupMapping>

Site information

This page will provide information specific to the STAR Grid sites.

pacman -get http://www.cs.wisc.edu/vdt/vdt_136_cache:Globus-SGE-Setup

$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 2119 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 2119 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 2135 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 2135 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 2136 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 2136 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 2811 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 2811 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 2812 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 2812 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 2912 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 2912 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 7512 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 7512 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 8443 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 8443 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 19000 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 19000 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 19001 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 19001 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p udp -d $GLOBALIP --dport 20000:65000 -j DNAT --to $STAR1
$filter -t nat -A PREROUTING -p tcp -d $GLOBALIP --dport 20000:65000 -j DNAT --to $STAR1

setenv GLOBUS_TCP_PORT_RANGE "60000 65000"
setenv GLOBUS_HOSTNAME="stars.if.usp.br"

export GLOBUS_TCP_PORT_RANGE="60000 65000"
export GLOBUS_HOSTNAME="stars.if.usp.br"

"/DC=org/DC=doegrids/OU=People/CN=Leigh Grundhoefer (GridCat) 693100" XXXX
"/DC=org/DC=doegrids/OU=People/CN=Bockjoo Kim 740786" XXXX

  globus-gatekeeper       2119/tcp        # Added by the VDT
  gsiftp                  2811/tcp        # Added by the VDT
  gsiftp2                 2812/tcp        # Added by the VDT
  gsiftp                  2811/udp        # Added by the VDT
  gsiftp2                 2812/udp        # Added by the VDT

globus-url-copy -dbg file:///star/u/suaide/gram_job_mgr_13594.log gsiftp://stars.if.usp.br/home/star/c

Specification for the storage and cataloging of STAR virtual machine images

Specification for the storage and cataloging of STAR virtual machine images

About this document:

This documentation describes where and how STAR virtual hard disk images are stored. Through standardization we can allow images to be:

• reusable by others
• cataloged, so the total available inventory if images is known
• locatable quickly
• somewhat self describing

What is a virtual machine image:

An image is a virtual hard disk, basically a large file on your "real" hard disk, whose contents are presented to the virtual machines (VM) as if it were a complete hard disk. STAR has a repository of virtual machine images which have operating systems and the STAR software stack pre-installed. Businesses now provide large computing facilities with many nodes running virtual machines that can be rented by the hour. One can upload a virtual machine image and essentially rubber stamp as many nodes of a particular configuration as desired. So they are not exactly identical, for example you will be wanting different names for each node (rcas1,rcas2,rcas3,...), a special step called contextualization is used to slightly customize each image.

A common type of image format many people are familiar with is the .ISO file. For example one can dump a block device like a hard disk or optical drive to one of these files. (could be a little irrelevant)

Example:

dd if=/dev/cdrom of=/home/bobfox/myCDimage.iso 

One can then mount the file as if it where any other hard disk. In most newer desktop Linux distributions in the default Gnome desktop one can just click on an iso file and the mounted drive icon will appear on your desktop. Most virtual machines (VMware, VirtualBox) support mounting of ISO files as if they where CD-ROMS attached to a real system.

What does STAR want to do with this technology:

The STAR software stack is not yet as easy to install as “just keep clicking next”. We can make most of these complexities go away by providing virtual machine images to tier-2(+) STAR sites with the software stack pre-installed and ready to run out of the box.

STAR's dreams of running on the grid have languished for a long time because of the non-homogeneous nature of GRID host sites. STAR can not recompile and certify a customized version of its software stack for each site even if the resources are free and available. However most of the differences between sites offering computing resource can be leveled out if they all run virtual machines. This means STAR can guaranty that its software will run on different sites and that the output file produced are as valid as if they had been run on the local BNL Tear 1 site via the usual stringent quality assurance processes STAR employs.

It all sounds too good to be true. That is because it is. There are many different virtual machine softwares all with different formats of virtual machine images.

Some common virtual machine softwares are:

• VirtualBox
• VMware
• KVM
• XEN

Virtual machine images:

These different virtual machine softwares require different image formats. Some can be easily converted, however most can not. For example Xen images don't contain any files in it /boot partition because it uses its own built in kernel. On the other hand VirtualBox uses the original operating system kernel. So converting from XEN to VirtualBox images is not really possible. Many packages will offer to convert the file system structure, but that doesn't mean the image will be able to boot.

The type of image you need is not up to you. It is determined by the virtual machine software of the host site. For example a XEN virtual machine will require a XEN image. Support for image formats other then the native format of the VM is very limited and in most cases non-existent and or unreliable.

Key parameters of images are:

• Virtual Machine Format
• Storage space

Why is storage space on the list

When you create an image file, its size needs to be specified, which represents a fixed geometry of the virtual disk. It is not possible to change the size of the virtual hard disk later. If you have a fixed-size image of e.g. 10 GB, an image file of roughly the same size will be created on your host system. There are also dynamically expanding images these will initially be small and not occupy much space for unused virtual disk sectors, but the image file will grow every time a disk sector is written to for the first time to some max size which can not be made bigger once the full size is reached.

When you run your job at some remote site you will need to write the data somewhere. There are mapped network drives and such, but the most convenient space to write is in the image it's self. So the total data of the node can not be bigger then the max size of the image. We can express it like this:

( [OS] + [swap space] + [STAR software] + [your data] ) < ( [Image max size] ) 

Now that we have gotten the parameters out of the way that are specific to virtual machines there are some parameters specific to the software installed on the image.

Key parameters of the software installed on the image are:

• STAR libraries installed
• Operating System
• Kernel Version
• Instruction set architecture
• Instruction set architecture word size (32bit / 64bit)

One image may hold many different library versions, all of the other parameters may only have one value at a time.  The data08 volume is devoted to grid work. It is the location of STARs image repository.

1. Note: Even though more then one star software library version may reside in an image this is hard to do because of the size of the image. So we are assuming only one library per image.
2. Note:In the case that an image is more then one file an additional directory will be needed, the directory will take the file naming convention.

The path to the repository and scheme used to derive the name of the image is below:

/star/data08/OSG/APP/vm/[VM]/[Operating System]_[Instruction set architecture]_[Instruction set architecture word size]_[STAR lib version]_[maxsize]_[addition detail].[extension]

Examples:

/star/data08/OSG/APP/vm/xen/sl5.3_x86_32_sl05c_8GB_ec2.img
/star/data08/OSG/APP/vm/virtualBox/ubuntu9.10_x86_32_sl05c_10GB_ec2.img

In addition there will be a text file with the .checksum extension holding an MD5 checksum hash of the image.

Example of making the hash:

[rcas6016] xen/> ls
sl4_x86_32_sl08e_8GB_ec2.img
sl4_x86_32_sl08e_8GB_ec2.txt
[rcas6016] xen/> md5sum sl4_x86_32_sl08e_8GB_ec2.img > sl4_x86_32_sl08e_8GB_ec2.checksum
/star/data08/OSG/APP/vm/virtualBox/ubuntu9.10_x8

In addition there will be a text file with the .txt extension giving more detail about the contents of the image.

Examples:

/star/data08/OSG/APP/vm/xen/sl5.3_x86_32_sl05c_8GB_ec2.txt
/star/data08/OSG/APP/vm/virtualBox/ubuntu9.10_x86_32_sl05c_10GB_ec2.txt

Recommendations for security and standardization (but not yet implemented):

Users will need to be able to login without editing the /etc/shadow file.

1)There will be a account “root” on all images with a password.

Note: In the case of Ubuntu just make the first account root.

2) There should be a hard password that changes regularly. This can be done by scripting the below command to run every time the image is started (by putting in /etc/rc.local for example):

date '+%y%m SEED=someLongString' | md5sum | base64 | sed 's|\(...........\).*|\1|' | passwd --stdin username

Then the command below can be placed in the text description of the image. The user instantiating the image can run the command to get the password. Example:

[rcas6007] ~/> date '+%y%m SEED=someLongString' | md5sum | sed 's|\(...........\).*|\1|' | \
base64 | sed 's|\(...........\).*|\1|' 
YjNkNTE5YWJ

If the command is compromised the seed will need to be changed.  

Alternatively:

There could also be a repository of ssh public keys available via a network connection which images can pull in.

3) There will be an account “star” on all images. This account will have the STAR environment (startup scripts). This is the account under which the actual jobs are run.

Ganglia

This page has moved to Ganglia monitoring system.

Metrics and Accounting

• SUMS Grid Job Statistics
  
• Lidia's job status URL's:
  daily jobs submission status
  plots with job efficiency
• OSG ML reporting for the STAR VO

SUMS and Grid snapshots

GSI Enabled MySQL

GSI

• secure communication
• security across organizational boundaries
• single sign-on for users of the Grid

MySQL

By default, MySQL is not SSL enabled, since using encrypted connections to access the database would slow down transactions and MySQL is, by default, optimized fo speed. Read the MySQL documentation on Using Secure Connections for details on how to set up MySQL for SSL, including how to create and set up the user certificates and grant the proper privleges for a user to authenticate.

The current implementation requires that the Certificate Authority (CA) certificate which signs the user and server certificates be available for the SSL/X.509 configuration to work. This is fine for applications which do not work with GSI enabled applications. It does not, howerver fit with the GSI model for authentication. The CA only need sign user and service certificates to use GSI. An example of a successful implementation of GSI using SSL on legacy software is the GSI Enabled OpenSSH.

Testing

• MySQL with SSL and X.509 Certificates
• GSI Enabled OpenSSH

Presentations

• PPDG Collaboration Meeting presentation, June 10, 2003 - HTML - PPT