INFN wiki

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 Globus Retirement Timeline. HTCondor-CE 5 support token based Authentication and this document provides specific configuration examples.

The HTCondor-CE (htc-ce) must be installed on a HTCondor Submit Node (schedd), that is a machine where a SCHEDD daemon runs:

[root@htc-ce ~]# condor_config_val DAEMON_LIST
MASTER, SCHEDD

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.

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

[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

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/

[root@htc-ce ~]# yum install ca-policy-egi-core

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

[root@cream-ce]# scp -r /etc/grid-security/vomsdir htc-ce:/etc/grid-security/ 

* Needed RPMs are:

• htcondor-ce-bdii, htcondor-ce-client, htcondor-ce-view, htcondor-ce, htcondor-ce-condor

[root@htc-ce ~]# yum install htcondor-ce-condor htcondor-ce-bdii htcondor-ce-view

currently condor version 9.0.11, condor-ce 5.1.3
Check the status of the service and eventually enable it

[root@htc-ce ~]# systemctl enable condor-ce

at the end of the configuration remember to start the condor-ce

[root@htc-ce ~]# yum install fetch-crl

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:

[root@htc-ce ~]# /usr/sbin/fetch-crl
[root@htc-ce ~]# systemctl enable fetch-crl-cron
[root@htc-ce ~]# systemctl start fetch-crl-cron

HTCondor-CE relies on Argus for authorization. Refer to the official documentation: 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

[root@htc-ce ~]# yum install argus-gsi-pep-callout

As root create the file /etc/grid-security/gsi-authz.conf. Its content is

[root@htc-ce ~]# cat /etc/grid-security/gsi-authz.conf
globus_mapping /usr/lib64/libgsi_pep_callout.so argus_pep_callout

(a newline at the end is not needed) It needs a copy of the certificates that will be accessed with non-root credentials:

[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

As root create the file /etc/grid-security/gsi-pep-callout.conf

[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

The HTCondor-CE has to be registered in the Argus server.
In the Argus server, as root, execute:

[root@argus ~]# pap-admin lp >policies.txt      ## dump current policies
[root@argus ~]# cp policies.txt policies-htcceAdd.txt

Add the new resource to the service (here an example, modify it as needed):

[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" }
     }
 }

Reset old policies and import new one:

[root@argus ~]# pap-admin rap ; pap-admin apf policies-htcceAdd.txt 
[root@argus ~]# pap-admin lp      ## list policies 

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.

Install an Argus pep client on your HTCondor-CE

[root@htc-ce ~]# yum install argus-pepcli

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

  [root@htc-ce ~]# voms-proxy-init --voms cms

• Copy the proxy on the root dir of your htc-ce as user509.pem
• Execute the following example command (adapt to your case)

[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

On a working setup you should see an output like:

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

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:

[root@argus ~]# ls -li /etc/grid-security/gridmapdir/cms195
383663 -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
 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
 383663 -rw-r--r-- 2 root root 0 26 giu  2019 cms195

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.

[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

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.

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

# SCITOKENS /<TOKEN ISSUER>,<TOKEN SUBJECT>/ <USERNAME>

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:

[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

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:

[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

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

# 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

Note More *experimental* configurations can be seen here

The rpm creates two configuration files and python script:

[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 

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

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

To check that the configuration is formally fine just execute

[root@htc-ce ~]# /var/lib/bdii/gip/provider/htcondor-ce-provider 

a dump of the glue2 schema shoud appear on stdout.

Finally, activate the service with

[root@htc-ce ~]# systemctl enable bdii
[root@htc-ce ~]# systemctl start bdii 

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

[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
2>&1 | tee /root/conf_yaim_users.`hostname -s`.`date +%Y-%m-%d-%H-%M-%S`.log 

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

[root@htc-ce ~]# systemctl start condor-ce 

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.

[user@ui ~]# export _condor_SEC_CLIENT_AUTHENTICATION_METHODS=GSI ; condor_ce_trace <your CE> 

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

[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.

add the -table all option to check all possible operations:

First give yourself a token file

[sdalpra@ui-htc ~]$ oidc-add sdptok
Enter decryption password for account config 'sdptok': 
success
[sdalpra@ui-htc ~]$ umask 0177 && oidc-token sdptok > sdptok

Then let HTCondor-CE know where your token is. Three ways are possible:

1. [sdalpra@ui-htc ~]$ export BEARER_TOKEN_FILE=$HOME/sdptok

2. [sdalpra@ui-htc ~]$ export BEARER_TOKEN=`oidc-token sdptok`

3. [sdalpra@ui-htc ~]$ cat sdptok > /tmp/bt_u`id -u`

Then verify SCITOIKENS authentication using condor_ce_ping

[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.

If authentication succeeds you can test further with condor_ce_trace or by submitting an actual job. Note of course the

export _condor_SEC_...

can be done once per session only.

Assuming you work from a User Interface as unprivileged user, add the following snippet to your .bashrc

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}

Then generate a token:

[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!

993 old condor uid,will be mapped to 601, 990 old condor group will be mapped to 601

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 

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:

After=network-online.target nslcd.service ypbind.service time-sync.target
nfs.client.target autofs.service sx.mount 

The example is referred to a mount point described in the fstab as:

gwc:/sx                 /sx                     nfs     defaults,bg,intr   0 0 

Assuming to use LCMAPS, the configuration of files is like the configuration of cream-ce

[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 

(gsi-authz.conf must end with a new line as reported in https://opensciencegrid.org/docs/security/lcmaps-voms-authentication/#optional-configuration)

If you have the Argus server installed on another host, the only files you need are:

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 

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:

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 

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

It’s useful to define the alias in /root/.bashrc

alias ccv='condor_config_val'
alias cccv='condor_ce_config_val' 

Instead of the restart of services, in order to apply a new configuration, use the condor_reconfig command.

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

Other references on configuring a HTCondor-CE

• https://htcondor.com/htcondor-ce/
• http://www.hep.ph.ic.ac.uk/~dbauer/grid/condor/htcondorce.html