Difference: WMSSystemAdministratorGuide (38 vs. 39)

Revision 392013-03-26 - MarcoCecchi

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

System Administrator Guide for WMS for EMI

Line: 289 to 289
  MaxServedRequests: Long attribute limiting the number of operation served by each WMProxy instance before exiting and releasing possibly allocated memory. This value is overriden by GLITE_WMS_WMPROXY_MAX_SERVED_REQUESTS environment variable, if set. This feature can be disabled by setting a lower-or-equal to zero value
Changed:
<
<
OperationsLoadScripts: ClassAd type attribute where an internal attribute can be specified for any WMProxy provided operation. The names of these attributes are equal to the names of the server operations (e.g. for jobSubmit operation the attribute name to use is "jobSubmit"). This internal attributes are used to provide the path and the name of the script to be executed to verify the load of the WMProxy server for any provided operation. If the server load is too high the requested operation is refused. The path and the name of the script can be followed by user defined options and parameters depending on the specific script needs for arguments.

WMProxy provide a load script that can be used for any of the provided operations. The template load script glite_wms_wmproxy_load_monitor.template is installed by the rpm file glite-wms-wmproxy in the directory ${WMS_LOCATION_SBIN}.

To call the script glite_wms_wmproxy_load_monitor, when the operation jobSubmit is requested, with the options:

--load1 10 --load5 10 --load15 10 --memusage 95 --diskusage 95 --fdnum 500

add the attribute:
>
>
OperationsLoadScripts: ClassAd type attribute where an internal attribute can be specified for any WMProxy provided operation. The names of these attributes are equal to the names of the server operations (e.g. for jobSubmit operation the attribute name to use is "jobSubmit"). This internal attributes are used to provide the path and the name of the script to be executed to verify the load of the WMProxy server for any provided operation. If the server load is too high the requested operation is refused. The path and the name of the script can be followed by user defined options and parameters depending on the specific script needs for arguments.

WMProxy provide a load script that can be used for any of the provided operations. The template load script glite_wms_wmproxy_load_monitor.template is installed by the rpm file glite-wms-wmproxy in the directory ${WMS_LOCATION_SBIN}.

To call the script glite_wms_wmproxy_load_monitor, when the operation jobSubmit is requested, with the options:

--load1 10 --load5 10 --load15 10 --memusage 95 --diskusage 95 --fdnum 500

add the attribute:
 
OperationsLoadScripts [
   jobSubmit = "${WMS_LOCATION_SBIN}/glite_wms_wmproxy_load_monitor 
      --oper jobSubmit --load1 10 --load5 10 --load15 10 
Line: 536 to 538
 

0.1 Security related operations

Changed:
<
<

0.0.1 How to select specific VO resources

>
>

0.0.1 How authorization works

In the WMS, two different authorization mechanisms can be utilized. The default is local, based on the Gridsite GACL http://www.gridsite.org/wiki/GACL. The relevant entries are basically DN and FQAN, that can be used to set permission on single users and roles (i.e. user banning and so on). FQANs support wildcards to allow for easier handling. The GACL file is "${WMS_LOCATION_ETC}/glite_wms_wmproxy.gacl". It is a structurally simple xml file where policies are specified, either directly or through the siteinfo.def.

Another way to perform authorization is to use Argus as a site service. Argus is typically enabled via sitenfo.def, through the following variables.

USE_ARGUS=<boolean>
ARGUS_PEPD_ENDPOINTS="list_of_space_separated_URLs" # i.e.: "https://argus01.lcg.cscs.ch:8154/authz https://argus02.lcg.cscs.ch:8154/authz https://argus03.lcg.cscs.ch:8154/authz"

On the Argus server side, the policies to be defined will have to specify an action and a resource id. The WMS automatically sets the resource id to its service endpoint. The actions are the following:

getVersion
getJDL
getMaxInputSandboxSize
getSandboxDestURI
getSandboxBulkDestURI
getQuota
getFreeQuota
getOutputFileList
getJobTemplate
getDAGTemplate
getCollectionTemplate
getIntParametricJobTemplate
getStringParametricJobTemplate
getDelegationVersion
getProxyReq
putProxy
renewProxyReq
getNewProxyReq
destroyProxy
getProxyTerminationTime
getACLItems
addACLItems
removeACLItem
getProxyInfo
enableFilePerusal
getPerusalFiles
getTransferProtocols
getJobStatusOp
jobStart
jobSubmit
jobSubmitJSDL
jobRegister
jobListMatch
jobCancel
jobPurge

The profile used for creating the request complies to the glite profile.

0.0.2 How to filter out unwanted VOs

  It can be useful to force the WMS to only select resources specific to a certain VO as the matchmaking time is consequntly reduced.
Line: 560 to 617
  and thus the WMS would select only resources (i.e. CE/Views) belonging to CMS.
Deleted:
<
<

0.0.1 How to block/ban a user

Information about how to ban users is available in https://twiki.cnaf.infn.it/twiki/bin/view/EgeeJra1It/WMSServiceRefCard#How_to_block_ban_a_user

 

0.0.1 How to block/ban a VO

To ban a VO, it is suggested to reconfigure the service via yaim without that VO in the siteinfo.def

 
This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback