Page History

Local  Offline Overview

 The The local offline processes LDF into digi and uses calibrations that are installed in the SLAC database to produce reconstructed and high level data analysis files. The goal is to have a way to quick debug and characterize the beam during the set-up.   If there is a copy of the database locally then we can use it to process events even when the connection to SLAC is down.

There will also be an offline monitoring running locally. 

Computer names in the PS area

Currently being updated, under construction.  The names of the computers and IP's have to be updatedCern is filtering ports below 1024! sshd is running on port 22 by default. I was setting it on 2222 temporarily, but this was not appreciated. Hence, the computers are not accessible from outside CERN.

"Socket-Gleam" PC: name ??? (at Pisa, was called pcglast37), IP ??? pcglast37.cern.ch, IP 137.138.66.137, username online, password * **(ask somebody!).   Intended for online analysis using socket-Gleam.  BeamtestRelease installations are found in /data/users/online/builds. The latest build is *BR v4r0909p3 in /data/users/online/builds/BeamtestRelease-v4r0909p3-rh9_gcc32opt. For detailed instructions on how to use GLAST software, check the workbook (link?). Here, a quick list only to analyze data:

• source /data/users/online/builds/BeamtestRelease-v4r0909p3-rh9_gcc32opt/BeamtestRelease/v4r0909p3/cmt/setup.sh
• ln -s /pathToDataDir/nameOfLdfFile.ldf file.ldf
• $GLEAMROOT/$CMTCONFIG/Gleam.exe $BEAMTEST06ROOT/jobOptions/ldf2digi.txt
• $GLEAMROOT/$CMTCONFIG/Gleam.exe $BEAMTEST06ROOT/jobOptions/readigi_runrecon.txt

With some luck, you should have digi.root, recon.root, merit.root, and calTuple.root. For creating the beamtest tuple, check $BEAMTESTTUPLEROOT/src/envVarOptions.dat. Set the appropiate env variables, and execute:

• $BEAMTESTTUPLEROOT/$CMTCONFIG/RunRootAnalyzer.exe $BEAMTESTTUPLEROOT/srv/envVarOptions.txt
  For updating the calibration database description and the external libraries, there is a simple script ~online/bin/syncWithSLAC. It asks for your SLAC afs user name and password, runs rsync, and destroys the afs token again.

"Data-server" PC: name ??? (at Pisa, was called pcglast30), IP ??? pcglast30.cern.ch, IP 137.138.66.138, username online, password *** (ask somebody!).   Has ca. 500GB disk space.  Doesn't have a monitor.  Intended as data server only.   Should store the root files produced in the SLAC pipeline.   We need a concept how to do it.

...

mysql> grant usage on . to glastreader@localhost identified by 'glastpassword';
mysql> grant select on calib.* to glastreader@localhost identified by 'glastpassword';
(and maybe...)
mysql> grant usage on . to glastreader@"%" identified by 'glastpassword';
mysql> grant select on calib.* to glastreader@"%" identified by 'glastpassword';
mysql> select host, user, password from mysql.user;
------------------------------

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

------------------------------
6 rows in set (0.00 sec)
'xxxx...' is the encrypted form of the password you just typed in... Actually, it's not 'xxxx...' but I x'ed it out so you wouldn't see it. It's what MySQL uses to check the plaintext password. The password 'glastpassword' is the same one that you got from Leon or Joanne, above.

You also want to protect your 'root' user with a password:mysql>set password for root@localhost = password('mynewpassword');
Query OK...
mysql> set password for root@"%" = password('mynewpassword');
Query OK...
mysql> select host, user, password from mysql.user;
------------------------------

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

------------------------------
6 rows in set (0.00 sec)

...

Finally, if you see a blank user, you should get rid of it:mysql%gt delete from mysql.user where host='localhost' and user="";
Query OK...
mysql%gt delete from mysql.user where host="&" and user="";
Query OK...
mysql> select host, user, password from mysql.user;
------------------------------

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

------------------------------
4 rows in set (0.00 sec)

...