The STAR experiment

This is intended as a practical introduction to mapfiles for admins of new sites to help get the *basics* working and avoid some common problems with grid user management and accounting.

It should be stressed that manually maintaining mapfiles is the most primitive user management technique.  It is not scalable and it has been nearly obsoleted by two factors:

IF

• Your SSH connections are closed from home
• You get disconnected from any nodes without any reasons?
• ... and you are a PuTTY user
• ... or an Uglix SSH client user

This page is for you. If you are another user, use different clients and so on, this page may still be informative and help you stabalize your connection (the same principles apply).

PuTTY users

PuTTY to connect to gateway (from a home connection), you have to

How to generate keys for about every platform ...

A selection of tips on how to log to the RCF
facility. We hope to augment those pages and add
information as user request or need.

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").

The information in a voms proxy is a superset of the information in a grid certificate proxy. This additional information includes details about the VO of the user. For users, the potential benefit is the possibility to work as a member of multiple VOs with a single DN and have your jobs accounted accordingly. Obtaining a voms-proxy (if all is well configured) is as simple as “voms-proxy-init -voms star” (This is of course for a member of the STAR VO).

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):

OFFLINE QA ISSUES

* Subsytem leaders have been asked to reassess QA needs/expectations
-> No responses yet

* Some question as to whether TPC+SVT tracks are separated from TPC-only tracks
 

• Remaining purchases
  • Web server
  • Tape purchase
• AIDE news
• IRMIS progress
  
• QA & other tool interaction with RunLog

Time	Talk	Presenter
14:00	Follow-ups ( 00:20 ) 0 files	All (All)
14:30	SDAS, requirements, current model, path forward ( 00:20 ) 0 files	All (All)
14:50	AOB ( 00:10 ) 0 files	All (All)
15:00	Offline and online QA ( 00:10 ) 0 files	Gene Van Buren & Jerome Lauret (BNL, BNL)

 

The panel recommends simulation
and optimization of the following possible configuration, one of which should
be chosen; either

• Two layers of active pixel sensors followed
  radially outward by a layer of ALICE
  style pixels (the HPD) located at a slightly larger radius than its present
  location, followed by the existing STAR SSD.
• Two layers of active pixel sensors followed
  radially outward by the IST1 and IST2 layers both at somewhat smaller radii
  than presently proposed, followed by the existing STAR SSD.

In the event the existing SSD can
not be counted on as part of the future mid-rapidity tracking system, the panel
recommends the following configuration be optimized: