Differences

This shows you the differences between two versions of the page.

--- progetti:htcondor-tf:htcondor-ce5 [2022/03/12 10:25] – dalpra@infn.it
+++ progetti:htcondor-tf:htcondor-ce5 [2022/03/18 08:37] (current) – dalpra@infn.it
@@ Line 1: / Line 1: @@
+ ==== HTCondor-CE 5 - manual setup ====
+Current official documentation has been improved. For further details Refer to the official documentation: [[https://htcondor-ce.org]] (and select instructions for HTCondor-CE 5).
+**Note:** WLCG is going to dismiss ''x509'' based authentication according to this [[https://docs.google.com/document/d/1HK2QSwKVUzfUHyWi-nPTlTzzc9k8hmSKDbfzoYkqJXQ/|Globus Retirement Timeline]]. HTCondor-CE 5 support token based Authentication and this document provides specific configuration examples.
+=== Prerequisites  ===
+The HTCondor-CE (htc-ce) must be installed on a HTCondor Submit Node (schedd), that is a machine where a SCHEDD daemon runs:
+<code>[root@htc-ce ~]# condor_config_val DAEMON_LIST
+MASTER, SCHEDD
+</code>
+The schedd shoud be already tested, a local user shoud be able to submit jobs to the HTCondor slaves (WNs).
+Furthermore:
+   * The htc-ce must hold a valid X509 grid server certificate (IGTF)
+   * The htc-ce must have a public IP and be reachable from everywhere to the TCP port 9619.
+   * The htc-ce relies on Argus for authorization, so it needs an Argus server already configured for the site auth/authZ: the server could be installed on the htc-ce node but for sites with more than one CE it is recommended to have a centralized one.
+**Suggestion:** if you manage an HTCondor cluster, it’s a best-practice to set in all the machines (control manager, schedd, WNs, CE,…) the same uid and gid for the condor user.
+== Common HTCondor rpm installation (valid not only for the condor-ce) ==
+The repo for the latest HTCondor-CE release (5.1.3 as of writing) is in the same repository of HTCondor 9.0.x
+**Note:** As of HTCondor 9 the naming convention and version numbering has changed:
+''9.0.x'' is the **Long Term Support** Release (formerly said //stable release//)
+''9.n.x'' is a **New features** Release for ''n > 0'' (formerly said //development// release).
+We refer to Long Term Support here
+=== HTCondor-CE setup ===
+== Certificate configuration ==
+<code>[root@htc-ce ~]# mkdir /etc/grid-security
+[root@htc-ce ~]# cd /etc/grid-security/
+[root@htc-ce ~]# ll
+-rw-r--r-- 1 root root 2366 Aug 12 14:40 hostcert.pem
+-rw----- 1 root root 1675 Aug 12 14:40 hostkey.pem</code>
+Install grid CA certificates and VO data into /etc/grid-security:
+it needs the EGI-trustanchors.repo [[http://repository.egi.eu/sw/production/cas/1/current/repo-files/EGI-trustanchors.repo]] in /etc/yum.repos.d/
+<code>[root@htc-ce ~]# yum install ca-policy-egi-core</code>  (CA certs go to /etc/grid-security/certificates)\\
+Copy the "VO data" /etc/grid-security/vomsdir (lsc files in the right hierarchy). From a cream-ce it’s a matter of a simple copy:
+<code>[root@cream-ce]# scp -r /etc/grid-security/vomsdir htc-ce:/etc/grid-security/ </code>
+== Rpms installation ==
+* Needed RPMs are:
+     *  htcondor-ce-bdii, htcondor-ce-client, htcondor-ce-view, htcondor-ce, htcondor-ce-condor
+<code>[root@htc-ce ~]# yum install htcondor-ce-condor htcondor-ce-bdii htcondor-ce-view</code> currently condor version 9.0.11, condor-ce 5.1.3\\
+Check the status of the service and eventually enable it
+<code>[root@htc-ce ~]# systemctl enable condor-ce</code>
+at the end of the configuration remember to start the condor-ce
+<code>[root@htc-ce ~]# yum install fetch-crl</code>
+Run the following command to update the CRLs the first time, it will take a while (several minutes) to complete so you can run it in background or from another shell:
+<code>[root@htc-ce ~]# /usr/sbin/fetch-crl
+[root@htc-ce ~]# systemctl enable fetch-crl-cron
+[root@htc-ce ~]# systemctl start fetch-crl-cron</code>
+== GSI and authorization ==
+HTCondor-CE relies on Argus for authorization. Refer to the official documentation: [[https://argus-documentation.readthedocs.io/en/stable/|ARGUS]] for general help about installation and configuration (It is possible to go with LCAS/LCMAPS but is not well documented and there is no out-of-the-box receipt for it).\\
+It needs the UMD-4-updates.repo in /etc/yum.repos.d/. Then
+<code>[root@htc-ce ~]# yum install argus-gsi-pep-callout</code>
+As root create the file /etc/grid-security/gsi-authz.conf. Its content is
+<code>[root@htc-ce ~]# cat /etc/grid-security/gsi-authz.conf
+globus_mapping /usr/lib64/libgsi_pep_callout.so argus_pep_callout</code>(a newline at the end is not needed)
+It needs a copy of the certificates that will be accessed with non-root credentials:
+<code>[root@htc-ce ~]# cp -a /etc/grid-security/hostcert.pem /etc/grid-security/condorcert.pem
+[root@htc-ce ~]# cp -a /etc/grid-security/hostkey.pem /etc/grid-security/condorkey.pem
+[root@htc-ce ~]# chown condor:condor /etc/grid-security/condorcert.pem /etc/grid-security/condorkey.pem</code>
+As root create the file /etc/grid-security/gsi-pep-callout.conf
+<code>[root@htc-ce ~]# cat /etc/grid-security/gsi-pep-callout-condor.conf
+pep_ssl_server_capath /etc/grid-security/certificates/
+pep_ssl_client_cert /etc/grid-security/condorcert.pem
+pep_ssl_client_key /etc/grid-security/condorkey.pem
+pep_url https://your.argus.server:8154/authz      ##put you argus server reference
+pep_timeout 30 # seconds
+xacml_resourceid http://<argus server>/condor-ce</code>
+== HTCondor-CE registration in the Argus server ==
+The HTCondor-CE has to be registered in the Argus server.\\
+In the Argus server, as root, execute:\\
+<code>[root@argus ~]# pap-admin lp >policies.txt      ## dump current policies
+[root@argus ~]# cp policies.txt policies-htcceAdd.txt</code>
+Add the new resource to the service (here an example, modify it as needed):
+<code>[root@argus ~]# cat policies-htcceAdd.txt
+ resource "http://your.argus.server/condor-ce" {              ## put your argus server reference
+     obligation "http://glite.org/xacml/obligation/local-environment-map" {
+     }
+     action ".*" {
+         rule permit { vo="ops" }
+         rule permit { vo="dteam" }
+         rule permit { vo="alice" }
+         rule permit { vo="belle" }
+         rule permit { vo="cms" }
+         rule permit { vo="lhcb" }
+         rule permit { vo="cdf" }
+     }
+ }</code>
+Reset old policies and import new one:
+<code>[root@argus ~]# pap-admin rap ; pap-admin apf policies-htcceAdd.txt
+[root@argus ~]# pap-admin lp      ## list policies </code>
+You can consider installing the Argus service on the HTCondor-CE host itself. This would probably ease early setup.\\
+Be aware that Argus need read/write access to the /etc/grid-security/gridmapdir directory, which is usually hosted on a shared filesystem.
+== Argus client installation ==
+Install an Argus pep client on your HTCondor-CE
+<code>[root@htc-ce ~]# yum install argus-pepcli</code>
+== Verify Argus service registration ==
+To verify that your Argus service is properly configured to work with your htc-ce you have to:
+  * Create a valid proxy of a supported VO i.e.: <code>[root@htc-ce ~]# voms-proxy-init --voms cms</code>
+  * Copy the proxy on the root dir of your htc-ce as ''user509.pem''
+  * Execute the following example command (adapt to your case)
+<code>[root@htc-ce ~]# pepcli --pepd https://your.argus.server:8154/authz --keyinfo user509.pem --capath /etc/grid-security/certificates --cert /etc/grid-security/hostcert.pem --key /etc/grid-security/hostkey.pem --resourceid "http://your.argus.server/condor-ce" -a pippo  ##put your argus server reference, -a pippo is needed as a whatever string</code>
+On a working setup you should see an output like:
+<code>Resource: http://your.argus.server/condor-ce
+Decision: Permit
+Obligation: http://glite.org/xacml/obligation/local-environment-map/posix (caller should resolve POSIX account mapping)
+Username: cms195
+Group: cms
+Secondary Groups: cms</code>
+As a further check (i.e. Argus service) you should see that the empty file
+''/etc/grid-security/gridmapdir/cms195'' has a hard link whose name is derived from the User DN Subject, which can be identified this way:
+<code>[root@argus ~]# ls -li /etc/grid-security/gridmapdir/cms195
+-rw-r--r-- 2 root root 0 26 giu  2019 /etc/grid-security/gridmapdir/cms195
+[root@argus ~]# ls -li /etc/grid-security/gridmapdir/ | grep 383663
+-rw-r--r-- 2 root root 0 26 giu  2019 %2fdc%3dch%2fdc%3dcern%2fou%3dorganic%20units%2fou%3dusers%2fcn%3dsurname%2fcn%3d606831%2fcn%3dname%20surname:cms:cmsprd:cms
+-rw-r--r-- 2 root root 0 26 giu  2019 cms195</code>
+== HTCondor-CE mapfile ==
+//HTCondor-CE 5 comes with a dedicated directory ''/etc/condor-ce/mapfiles.d'' with method specific files.
+The only files to edit should be ''10-gsi.conf'' for ''x509'' based auth*n and ''10-scitokens.conf'' for token based auth*n.
+//
+<code>
+[root@ce07-htc mapfiles.d]# grep -v -E '^#|^$' /etc/condor-ce/mapfiles.d/10-gsi.conf
+GSI /^\/DC=org\/DC=terena\/DC=tcs\/C=IT\/L=Frascati\/O=Istituto Nazionale di Fisica Nucleare\/OU=CNAF\/CN=(host\/)?([A-Za-z0-9.\-]*)$/ \1@t1htc_90
+</code>
+**Note1**: in the example above, ''t1htc_90'' is the value of ''UID_DOMAIN'', which is kept at the same value both in HTCondor and HTCondor-CE.
+**Note2**: The file ''50-gsi-callout.conf'' should not be changed.
+=== Notes for token authentication ===
+**Note1** There is no callout service such as ''argus'' or ''LCMAPS''. The mapping to the local username is based on the //issuer// and //subject//.
+The general mapping is
+<code>
+# SCITOKENS /<TOKEN ISSUER>,<TOKEN SUBJECT>/ <USERNAME>
+</code>
+leaving An empty ''<TOKEN SUBJECT>'', every token from the same ''issuer'' is mapped to a single local username.
+**Hint**: the username can remind the CE hostname, as in the example below:
+<code>
+[root@ce07-htc mapfiles.d]# egrep '^SCI' 10-scitokens.conf
+# For the subject list by VO refer to https://github.com/opensciencegrid/topology/blob/master/virtual-organizations
+SCITOKENS /^https:\/\/atlas-auth.web.cern.ch\/,7dee38a3-6ab8-4fe2-9e4c-58039c21d817/ atlasprd007
+SCITOKENS /^https:\/\/atlas-auth.web.cern.ch\/,750e9609-485a-4ed4-bf16-d5cc46c71024/ pilatlas007
+SCITOKENS /^https:\/\/atlas-auth.web.cern.ch\/,5c5d2a4d-9177-3efa-912f-1b4e5c9fb660/ atlassgm007
+SCITOKENS /^https:\/\/cms-auth\.web\.cern\.ch\/,345b20e0-14a6-4614-8493-4865c9ba5645/ cmssgm007
+SCITOKENS /^https:\/\/cms-auth\.web\.cern\.ch\/,490a9a36-0268-4070-8813-65af031be5a3/ pilcms007
+SCITOKENS /^https:\/\/cms-auth\.web\.cern\.ch\/,bad55f4e-602c-4e8d-a5c5-bd8ffb762113/ cmsprd007
+# Personal token for testing purposes
+SCITOKENS /^https:\/\/wlcg\.cloud\.cnaf\.infn\.it\/,9fe3233a-be7c-0d36-8441-3526961b827d/ dteam007
+</code>
+**Note** the host that is being installed as a HTCondor-CE is also a HTCondor Submit Node. For this reason in both the condor configuration files the value of UID_DOMAIN has to be the same.
+= HTCondor-CE config files =
+The default configuration path is ''/etc/condor-ce/config.d/''. A tool ''condor_ce_config_val'' is provided to inspect configurations, in the same way as condor_config_val for HTCondor batch system.
+Default configuration from the rpm is almost fine already and only few local settings are to be set or redefined. Best practice is to set them in a
+''/etc/condor-ce/config.d/99-local.conf'' (configuration files are visited in alphabetical order).
+See below an example configuration, used at INFN-T1:
+<code>
+[root@ce07-htc ~]# cat /etc/condor-ce/config.d/99-local.conf
+UID_DOMAIN = t1htc_90
+CENTRAL_MANAGER = htc-1
+JOB_ROUTER_SCHEDD2_POOL = $(CENTRAL_MANAGER).cr.cnaf.infn.it:9618
+AUTH_SSL_SERVER_CERTFILE = /etc/grid-security/hostcert.pem
+AUTH_SSL_SERVER_KEYFILE = /etc/grid-security/hostkey.pem
+AUTH_SSL_SERVER_CADIR = /etc/grid-security/certificates
+AUTH_SSL_SERVER_CAFILE =
+AUTH_SSL_CLIENT_CERTFILE = /etc/grid-security/hostcert.pem
+AUTH_SSL_CLIENT_KEYFILE = /etc/grid-security/hostkey.pem
+AUTH_SSL_CLIENT_CADIR = /etc/grid-security/certificates
+AUTH_SSL_CLIENT_CAFILE =
+#disable cache (useful when troubleshooting)
+#GSS_ASSIST_GRIDMAP_CACHE_EXPIRATION = 0
+FRIENDLY_DAEMONS = $(FRIENDLY_DAEMONS) *@$(UID_DOMAIN)
+# Higher log verbosity
+#ALL_DEBUG = D_ALWAYS:2 D_CAT
+MASTER.SEC_DEFAULT_AUTHENTICATION_METHODS =
+# useful to override common values on a single machine
+include ifexist : /usr/share/htc/90/py/ce-conf/$(HOSTNAME).conf
+</code>
+== JobRouter ==
+With HTCondor-CE 5 JobRouter rules can be written with the new syntax.
+Here is an excerpt from ''INFN'T1'', with routes for both ''GSI'' and ''SCITOKENS''
+<code>
+# By default the old syntax is enabled; this is to enable the new syntax
+JOB_ROUTER_USE_DEPRECATED_ROUTER_ENTRIES = False
+# Jobs can only start once.
+JOB_ROUTER_TRANSFORM_PeriodicHold @=jrt
+  SET Periodic_Hold = (NumJobStarts >= 1 && JobStatus == 1) || NumJobStarts > 1
+@jrt
+# Workaround for bug:
+# https://opensciencegrid.atlassian.net/browse/HTCONDOR-662
+#
+JOB_ROUTER_TRANSFORM_NumCores @=jrt
+  REQUIREMENTS MY.xcount > 1 || MY.RequestCpus > 1 || False
+  SET RequestCpus max({$(MY.xcount:1),$(MY.RequestCpus:1)})
+@jrt
+JOB_ROUTER_PRE_ROUTE_TRANSFORM_NAMES = $(JOB_ROUTER_PRE_ROUTE_TRANSFORM_NAMES) PeriodicHold NumCores
+JOB_ROUTER_ENTRIES =
+JOB_ROUTER_ENTRIES_FILE =
+JOB_ROUTER_ENTRIES_CMD =
+#This matches x509 dteam jobs OR wlcg jobs by token subject, for testing purposes
+JOB_ROUTER_ROUTE_dteam @=jrt
+  REQUIREMENTS (x509UserProxyVoName =?= "dteam") || (AuthTokenSubject =?= "6e0ebc78-7015-45cc-88e0-7bb4683b02a6")
+  UNIVERSE VANILLA
+  #SET MaxJobs 100
+  #SET MaxIdleJobs 4
+@jrt
+# This is to match the virgo jobs having: x509UserProxyFirstFQAN = "/virgo/virgo/Role=NULL/Capability=NULL"
+JOB_ROUTER_ROUTE_virgovirgo @=jrt
+  REQUIREMENTS x509UserProxyVoName == "virgo" && (split(x509UserProxyFirstFQAN,"/")[1] == "virgo")
+  UNIVERSE VANILLA
+  SET MaxJobs 100
+  SET MaxIdleJobs 4
+@jrt
+# This is to match the virgo jobs having: x509UserProxyFirstFQAN = "/virgo/ligo/Role=NULL/Capability=NULL"
+JOB_ROUTER_ROUTE_virgoligo @=jrt
+  REQUIREMENTS x509UserProxyVoName == "virgo" && (split(x509UserProxyFirstFQAN,"/")[1] == "ligo")
+  UNIVERSE VANILLA
+  SET MaxJobs 100
+  SET MaxIdleJobs 4
+@jrt
+JOB_ROUTER_ROUTE_ops @=jrt
+  REQUIREMENTS x509UserProxyVoName == "ops"
+  UNIVERSE VANILLA
+  SET Requirements (TARGET.GPFS_OK =!= False) && (TARGET.t1_allow_sam =?= true)
+@jrt
+# This route should match both x509 and scitokens
+JOB_ROUTER_ROUTE_atlas_sam @=jrt
+  REQUIREMENTS (x509UserProxyVoName =?= "atlas" && x509UserProxyFirstFQAN =?= "/atlas/Role=lcgadmin/Capability=NULL") || (AuthTokenIssuer =?= "https:
+//atlas-auth.web.cern.ch/" && AuthTokenSubject =?= "5c5d2a4d-9177-3efa-912f-1b4e5c9fb660")
+  UNIVERSE VANILLA
+  SET Requirements (TARGET.t1_allow_sam =?= true) && (!StringListMember("gpfs_atlas",t1_GPFS_CHECK ?: "",":"))
+@jrt
+JOB_ROUTER_ROUTE_atlas @=jrt
+  REQUIREMENTS (((x509UserProxyVoName =?= "atlas") || (AuthTokenIssuer =?= "https://atlas-auth.web.cern.ch/" && StringListMember(AuthTokenSubject ?: "", "7dee38a3-6ab8-4fe2-9e4c-58039c21d817:750e9609-485a-4ed4-bf16-d5cc46c71024", ":"))) && (queue == "atlas"))
+  UNIVERSE VANILLA
+  SET Requirements (!StringListMember("gpfs_atlas",t1_GPFS_CHECK ?: "",":")) && (t1_allow_sam =!= true)
+  SET MaxJobs 3500
+  SET MaxIdleJobs 1280
+@jrt
+JOB_ROUTER_ROUTE_alice @=jrt
+  REQUIREMENTS (x509UserProxyVoName == "alice")
+  UNIVERSE VANILLA
+  SET Requirements (t1_allow_sam =!= true)
+  SET MaxJobs 3500
+  SET MaxIdleJobs 1280
+@jrt
+JOB_ROUTER_ROUTE_cms @=jrt
+  REQUIREMENTS ((x509UserProxyVoName =?= "cms") && (x509UserProxyFirstFQAN =!= "/cms/Role=lcgadmin/Capability=NULL")) || (AuthTokenIssuer =?= "https://cms-auth.web.cern.ch/" && StringListMember(AuthTokenSubject ?: "", "bad55f4e-602c-4e8d-a5c5-bd8ffb762113:490a9a36-0268-4070-8813-65af031be5a3", ":"))
+  UNIVERSE VANILLA
+  SET Requirements (!StringListMember("gpfs_tsm_cms",t1_GPFS_CHECK ?: "",":")) && (t1_allow_sam =!= true)
+  SET MaxJobs 3500
+  SET MaxIdleJobs 1280
+@jrt
+JOB_ROUTER_ROUTE_cms_sam @=jrt
+  REQUIREMENTS ((x509UserProxyVoName =?= "cms") && (x509UserProxyFirstFQAN =?= "/cms/Role=lcgadmin/Capability=NULL")) || (AuthTokenIssuer =?= "https://cms-auth.web.cern.ch/" && AuthTokenSubject =?= "345b20e0-14a6-4614-8493-4865c9ba5645")
+  UNIVERSE VANILLA
+  SET Requirements (!StringListMember("gpfs_tsm_cms",t1_GPFS_CHECK ?: "",":")) && (t1_allow_sam =?= true)
+  SET MaxJobs 3500
+  SET MaxIdleJobs 1280
+@jrt
+JOB_ROUTER_ROUTE_NAMES = $(JOB_ROUTER_ROUTE_NAMES) virgovirgo virgoligo atlas_sam atlas cms_sam cms
+</code>
+**Note** More *experimental* configurations can be seen [[https://twiki.cern.ch/twiki/bin/view/LCG/HTCondorCEtokenConfigTips#Experimental_configurations|here]]
+== BDI configuration in the HTCondor batch system ==
+The rpm creates two configuration files and python script:
+<code>[root@htc-ce ~]# rpm -ql htcondor-ce-bdii
+/etc/condor/config.d/50-ce-bdii-defaults.conf
+/etc/condor/config.d/99-ce-bdii.conf
+/var/lib/bdii/gip/provider/htcondor-ce-provider </code>
+**Note:**: the path is under ''/etc/condor/'', thus these are HTCondor configurations, not HTCondor-CE;
+In the /etc/condor/config.d/99-ce-bdii.conf write here details about your site and BDII node.\\
+Here the example related to Legnaro
+<code>[root@htc-ce ~]# cat /etc/condor/config.d/99-ce-bdii.conf
+HTCONDORCE_SiteName = INFN-LNL-2
+HTCONDORCE_HEPSPEC_INFO = 10.63-HEP-SPEC06
+HTCONDORCE_SPEC = [ specfp2000 = 2506; hep_spec06 = 10.63; specint2000 = 2656 ]
+# CPU  Benchmarks
+HTCONDORCE_VONames = alice, cms, lhcb, dteam
+HTCONDORCE_BDII_ELECTION = LEADER
+HTCONDORCE_BDII_LEADER = t2-cce-02.lnl.infn.it
+HTCONDORCE_CORES = 16 # cores per node
+GLUE2DomainID = $(HTCONDORCE_SiteName)
+</code>
+To check that the configuration is formally fine just execute
+<code>[root@htc-ce ~]# /var/lib/bdii/gip/provider/htcondor-ce-provider </code>
+a dump of the glue2 schema shoud appear on stdout.
+Finally, activate the service with
+<code>[root@htc-ce ~]# systemctl enable bdii
+[root@htc-ce ~]# systemctl start bdii </code>
+== Create grid-users in the HTCondor-CE ==
+You must define all the local users that the Argus will map on the CE and all the WNs (it is supposed that you already gridified the WNs with also the same local users)
+Here an example based on yaim (CE side):
+<code>[root@htc-ce ~]# yum install glite-yaim-core
+[root@htc-ce ~]# /opt/glite/yaim/bin/yaim -r -s </path/to>/my-site-info.def -f config_users
+>&1 | tee /root/conf_yaim_users.`hostname -s`.`date +%Y-%m-%d-%H-%M-%S`.log </code>
+as default this command returns “INFO: Assuming the node types: UI”. Press “y” because the config_users isn’t supported in the UI profile.
+It’s supposed that your WNs are all “grid-ified” (meddleware, users, configs..)
+== Start HTCondor-CE process ==
+<code>[root@htc-ce ~]# systemctl start condor-ce </code>
+== Testing the HTCondor-CE ==
+=== Authenticating with GSI ===
+From a User Interface having the htcondor-ce-client rpm, after generating a valid proxy, the htc-ce can be tested with ''condor_ce_trace''. This is a simple tools submitting a ''/bin/env'' job and is useful to check that all the fundamentals steps are correctly working.
+<code>[user@ui ~]# export _condor_SEC_CLIENT_AUTHENTICATION_METHODS=GSI ; condor_ce_trace <your CE> </code>
+use the -debug option to get more details.
+If the previous test fails because of authorization or authentication problems, An useful tool is ''condor_ce_ping''. This verify that the WRITE operation succeeds
+<code>
+[sdalpra@ui-htc ~]$ export _condor_SEC_CLIENT_AUTHENTICATION_METHODS=GSI ; condor_ce_ping -pool ce01t-htc.cr.cnaf.infn.it:9619 -name ce01t-htc
+WRITE command using (AES, AES, and GSI) succeeded as dteam042@htc_t1test to schedd ce01t-htc.cr.cnaf.infn.it.
+</code>
+add the ''-table all'' option to check all possible operations:
+=== Authenticating with SCITOKENS ===
+First give yourself a token file
+<code>
+[sdalpra@ui-htc ~]$ oidc-add sdptok
+Enter decryption password for account config 'sdptok':
+success
+[sdalpra@ui-htc ~]$ umask 0177 && oidc-token sdptok > sdptok
+</code>
+Then let HTCondor-CE know where your token is. Three ways are possible:
+  - <code>[sdalpra@ui-htc ~]$ export BEARER_TOKEN_FILE=$HOME/sdptok</code>
+  - <code>[sdalpra@ui-htc ~]$ export BEARER_TOKEN=`oidc-token sdptok`</code>
+  - <code>[sdalpra@ui-htc ~]$ cat sdptok > /tmp/bt_u`id -u`</code>
+Then verify ''SCITOIKENS'' authentication using ''condor_ce_ping''
+<code>
+[sdalpra@ui-htc ~]$ export _condor_SEC_CLIENT_AUTHENTICATION_METHODS=SCITOKENS ; condor_ce_ping -pool ce01t-htc.cr.cnaf.infn.it:9619 -name ce01t-htc
+WRITE command using (AES, AES, and SCITOKENS) succeeded as dteam001@htc_t1test to schedd ce01t-htc.cr.cnaf.infn.it.
+</code>
+If authentication succeeds you can test further with ''condor_ce_trace'' or by submitting an actual job.
+**Note** of course the <code>export _condor_SEC_...</code> can be done once per session only.
+=== Tips and trick ===
+== generating a token for testing purposes ==
+Assuming you work from a User Interface as unprivileged user, add the following snippet to your .bashrc
+<code>
+OIDC_ENV=$HOME/.oidcenv
+mkdir -p $OIDC_ENV
+export OIDC_SOCK=`sed -ne 's/^OIDC_SOCK=\(.*\)$/\1/p' $OIDC_ENV`
+export OIDCD_PID=`sed -ne 's/^OIDCD_PID=\([0-9].*\)$/\1/p' $OIDC_ENV`
+# echo "PRIMA:"
+# echo "OIDC_SOCK=$OIDC_SOCK"
+# echo "OIDCD_PID=$OIDCD_PID"
+kill -0 $OIDCD_PID || eval `oidc-agent`
+# echo "DOPO:"
+# echo "OIDC_SOCK=$OIDC_SOCK"
+# echo "OIDCD_PID=$OIDCD_PID"
+echo "OIDC_SOCK=$OIDC_SOCK" > ${OIDC_ENV}
+echo "OIDCD_PID=$OIDCD_PID" >> ${OIDC_ENV}
+</code>
+Then generate a token:
+<code>
+[sdalpra@ui-htc ~]$ oidc-gen wlcg
+[1] https://wlcg.cloud.cnaf.infn.it/
+[...]
+[17] https://oidc.scc.kit.edu/auth/realms/kit/
+Issuer [https://wlcg.cloud.cnaf.infn.it/]:
+The following scopes are supported: openid profile email offline_access wlcg wlcg.groups storage.read:/ storage.create:/ compute.read compute.modify co
+mpute.create compute.cancel storage.modify:/ eduperson_scoped_affiliation eduperson_entitlement
+Scopes or 'max' (space separated) [openid profile offline_access]: openid profile offline_access wlcg wlcg.groups compute.read compute.modify compute.c
+reate compute.cancel
+Registering Client ...
+Generating account configuration ...
+accepted
+Using a browser on any device, visit:
+https://wlcg.cloud.cnaf.infn.it/device
+And enter the code: ******
+Enter encryption password for account configuration 'wlcg':  ********
+Confirm encryption Password:  *********
+Everything setup correctly!
+</code>
+== How to change the uid and gid of an already created condor user ==
+old condor uid,will be mapped to 601, 990 old condor group will be mapped to 601
+<code>stop condor
+id condor
+find / -xdev -uid 993 -exec ls -lnd {} \; | wc -l
+find / -xdev -gid 990 -exec ls -lnd {} \; | wc -l
+vim /etc/passwd
+vim /etc/group
+find / -xdev -uid 993 -exec chown 601 {} \;
+find / -xdev -gid 990 -exec chgrp 601 {} \;
+find / -xdev -uid 601 -exec ls -lnd {} \; | wc -l
+find / -xdev -gid 601 -exec ls -lnd {} \; | wc -l
+reboot </code>
+== If condor does not start correctly (config from shared FS) ==
+Sometimes, if you have the HTCondor configuration of nodes in a shared (nfs, gpfs,…) file system, it could happen the nfs client is ready even if not all mount points still completely mounted.\\
+The solution is to add the mount point (in the example is named “sx”) in the /usr/lib/systemd/system/condor.service file:
+<code>After=network-online.target nslcd.service ypbind.service time-sync.target
+nfs.client.target autofs.service sx.mount </code>
+The example is referred to a mount point described in the fstab as:
+<code>gwc:/sx                 /sx                     nfs     defaults,bg,intr   0 0 </code>
+== Alternative solution to Argus service (to be implemented) ==
+Assuming to use LCMAPS, the configuration of files is like the configuration of cream-ce
+<code>[root@cream-ce cream]# cat /etc/grid-security/gsi-authz.config
+globus_mapping /usr/lib64/liblcas_lcmaps_gt4_mapping_.so lcmaps_callout
+[root@htc-ce config.d]# cat /etc/grid-security/gsi-authz.conf
+globus_mapping liblcas_lcmaps_gt4_mapping.so lcmaps_callout </code>
+(gsi-authz.conf must end with a new line as reported in [[https://opensciencegrid.org/docs/security/lcmaps-voms-authentication/#optional-configuration]])
+== /etc/grid-security content details ==
+If you have the Argus server installed on another host, the only files you need are:
+<code>drwxr-xr-x  2 root   root   53248 Aug 26 14:40 certificates (managed by fetch-crl)
+-rw-r--r--  1 condor condor  2366 Aug 12 14:40 condorcert.pem
+-rw-------  1 condor condor  1675 Aug 12 14:40 condorkey.pem
+-rw-r--r--  1 root   root      66 Aug 26 14:53 gsi-authz.conf
+-rw-r--r--  1 root   root    3121 Aug 26 17:48 gsi.conf (from condor install, generally you do not need to modify it)
+-rw-r--r--  1 root   root     502 Aug 27 16:40 gsi-pep-callout.conf
+-rw-r--r--  1 root   root    2366 Aug 12 14:40 hostcert.pem
+-rw-------  1 root   root    1675 Aug 12 14:40 hostkey.pem
+drwxr-xr-x 13 root   root    4096 Sep 11  2016 vomsdir </code>
+In case you install the Argus server on the same node, or you plan to use lcas/lcmaps, you will need all the staff you know very well from a CREAM CE, so in addition you must have:
+<code>lrwxrwxrwx  1 root   root      43 Aug 26 16:26 gridmapdir -> /shared/from/file/system
+-rw-r--r--  1 root   root    2938 Aug 26 18:29 grid-mapfile
+-rw-r--r--  1 root   root    2854 Aug 26 18:24 groupmapfile
+-rw-r--r--  1 root   root    2938 Aug 20 12:26 voms-grid-mapfile
+-rw-r--r--  1 root   root    2938 Aug 20 12:26 voms-mapfile </code>
+The gridmapdir is shared among all nodes that actually map a grid user to a local user.\\
+The voms-grid-mapfile and voms-mapfile generally are a copy of the grid-mapfile and voms-mapfile; on the Argus serverinstance  they are not needed (see the argus config files to track witch files are sourced).
+== Alias for HTCondor command ==
+It’s useful to define the alias in /root/.bashrc
+<code>alias ccv='condor_config_val'
+alias cccv='condor_ce_config_val' </code>
+== The restart of HTCondor startd (WNs) kills running jobs ==
+Instead of the restart of services, in order to apply a new configuration, use the ''condor_reconfig command''.
+== gsi-pep-callout.conf (file name details) ==
+If you already have a production Argus, your defaults could be different and depends of what decided by your farming department that manage the hosts installation and configuration processes (puppet/foreman/whatever,…).\\
+The name of this file come from the definition file here (the version numbers could be different):\\
+''/usr/share/doc/argus-gsi-pep-callout-1.3.1/gsi-pep-callout.conf''\\
+(installed by argus-gsi-pep-callout-1.3.1-2.el7.centos.x86_64.rpm) and could be modified in:\\
+''/etc/sysconfig/condor-ce''
+== Se also ==
+Other references on configuring a HTCondor-CE
+  * [[https://htcondor.com/htcondor-ce/]]
+  * [[http://www.hep.ph.ic.ac.uk/~dbauer/grid/condor/htcondorce.html]]