Difference: ServiceReferenceCard (6 vs. 7)

Revision 72011-05-05 - MassimoSgaravatto

Line: 1 to 1
 
META TOPICPARENT name="SystemAdministratorDocumentation"

CREAM Service Reference Card

Line: 8 to 8
  The following processes should run on a CREAM CE:
Changed:
<
<
  • tomcat ( /usr/lib/jvm/java/bin/java -server -Xms128m -Xmx512m -Dglite.log.path=/var/log/cream -Dcatalina.ext.dirs=/usr/share/tomcat5/shared/lib:/usr/share/tomcat5/common/lib -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSource)
>
>
  • tomcat (e.g. /usr/lib/jvm/java/bin/java -server -Xms128m -Xmx512m -Dglite.log.path=/var/log/cream -Dcatalina.ext.dirs=/usr/share/tomcat5/shared/lib:/usr/share/tomcat5/common/lib -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSource)
 
  • blahpd ( /usr/bin/blahpd). This is automatically started by starting tomcat
Line: 74 to 74
  log4j.logger.org.glite=info, fileout
Changed:
<
<
 
with:
>
>
$ : with:
 
      log4j.logger.org.glite=debug, fileout
Changed:
<
<
 
You may also change the attributes log4j.appender.fileout.MaxFileSize and log4j.appender.fileout.MaxBackupIndex to change the maximum file size and the maximum number of log files to be kept.
>
>
$ : You may also change the attributes log4j.appender.fileout.MaxFileSize and log4j.appender.fileout.MaxBackupIndex to change the maximum file size and the maximum number of log files to be kept.
 
  • The glexec log files. glexec by default logs on syslog but it is also possible to log on file instead. Check the meaning of the variables GLEXEC_CREAM_LOG_DESTINATION, GLEXEC_CREAM_LOG_FILE, GLEXEC_CREAM_LCASLCMAPS_LOG in the yaim reference guide. The verbosity can be changed editing the glexec configuration file /etc/glexec.conf.

  • The new BLAH blparser log files (/var/log/cream/glite-ce-bnotifier.log and /var/log/cream/glite-ce-bupdater.log) if the new blparser is used
Deleted:
<
<
  * The gridftp log files (globus-gridftp.log and gridftp-session.log)

Open ports

Line: 97 to 96
 
Notifications by BLparser and JobWrapper {WN, Blparser host} * CREAM-CE 9091 Specified by LRMS_EVENT_LISTENER_PORT in CREAM conf file
CREAM job sensor CEMon host * CREAM-CE 9909 Specified by CREAM_JOB_SENSOR_PORT in CREAM conf file. CEMON Host is usually the CREAM CE
LB locallogger WN C CREAM-CE 9002  
Changed:
<
<
LB locallogger CREAM-CE C LB server 9001
>
>
LB locallogger CREAM-CE C LB server 9001
 
mysql CREAM-CE * mysql server 3306 By default the mysql server is the CREAM CE
Changed:
<
<
BDII Site BDII * CREAM-CE 2170
>
>
BDII Site BDII * CREAM-CE 2170
 
Old BLparser listening port CREAM-CE * Blparser host 33333 Specified by yaim variable BLP_PORT
Old BLparser CREAM listening port CREAM-CE * BLparser host 56565 Specified by yaim variable CREAM_PORT
Changed:
<
<
C: Controllable Ephemeral range (e.g. 20000-25000). Note: In practice, although this port-range is locally configurable using the GLOBUS_TCP_PORT_RANGE environment variable, the values applying at a remote service cannot be predicted. Consequently reliable connection can only be established if all ports >1023 are left open for outbound connections.
>
>
C: Controllable Ephemeral range (e.g. 20000-25000). Note: In practice, although this port-range is locally configurable using the GLOBUS_TCP_PORT_RANGE environment variable, the values applying at a remote service cannot be predicted. Consequently reliable connection can only be established if all ports >1023 are left open for outbound connections.
 

Possible unit test of the service

Line: 142 to 139
 
  • Authorization with ARGUS
  • Authorization with gJAF
Added:
>
>
Argus is a system meant to render consistent authorization decisions for distributed services (e.g. compute elements, portals). In order to achieve this consistency a number of points must be addressed. First, it must be possible to author and maintain consistent authorization policies. This is handled by the Policy Administration Point (PAP) component in the service. Second, authored policies must be evaluated in a consistent manner, a task performed by the Policy Decision Point (PDP). Finally, the data provided for evaluation against policies must be consistent (in form and definition) and this is done by the Policy Enforcement Point (PEP). Argus is also responsible to manage the Grid user - local user mapping.
 
Changed:
<
<
Argus is a system meant to render consistent authorization decisions for distributed services (e.g. compute elements, portals). In order to achieve this consistency a number of points must be addressed. First, it must be possible to author and maintain consistent authorization policies. This is handled by the Policy Administration Point (PAP) component in the service. Second, authored policies must be evaluated in a consistent manner, a task performed by the Policy Decision Point (PDP). Finally, the data provided for evaluation against policies must be consistent (in form and definition) and this is done by the Policy Enforcement Point (PEP). Argus is also responsible to manage the Grid user - local user mapping.

gJAF (Grid Java Authorization Framework) provides a way to invoke a chain of policy engines and get a decision result about the authorization of a user. The policy engines are divided in two types, depending on their functionality. They can be plugged into the framework in order to form a chain of policy engines as selected by the administrator in order to let him set up a complete authorization system. A policy engine may be either a PIP or a PDP. PIP collect and verify assertions and capabilities associated with the user, checking her role, group and VO attributes. PDP may use the information retrieved by a PIP to decide whether the user is allowed to perform the requested action, whether further evaluation is needed, or whether the evaluation should be interrupted and the user access denied. In CREAM CE VO based authorization is supported. In this scenario, implemented via the VOMS PDP, the administrator can specify authorization policies based on the VO the jobs' owners belong to (or on particular VO attributes). When gJAF is used as authorization mechanism, the Grid user - local user mapping is managed via glexec,

>
>
gJAF (Grid Java Authorization Framework) provides a way to invoke a chain of policy engines and get a decision result about the authorization of a user. The policy engines are divided in two types, depending on their functionality. They can be plugged into the framework in order to form a chain of policy engines as selected by the administrator in order to let him set up a complete authorization system. A policy engine may be either a PIP or a PDP. PIP collect and verify assertions and capabilities associated with the user, checking her role, group and VO attributes. PDP may use the information retrieved by a PIP to decide whether the user is allowed to perform the requested action, whether further evaluation is needed, or whether the evaluation should be interrupted and the user access denied. In CREAM CE VO based authorization is supported. In this scenario, implemented via the VOMS PDP, the administrator can specify authorization policies based on the VO the jobs' owners belong to (or on particular VO attributes). When gJAF is used as authorization mechanism, the Grid user - local user mapping is managed via glexec,
  For what concerns authorization on job operations, by default each user can manage (e.g. cancel, suspend, etc.) only her own jobs. However, the CREAM administrator can define specific super-users who are empowered to manage also jobs submitted by other users.
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback