INFN wiki

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 stable release (3.2.3 as of writing) is https://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel7.repo

[root@htc-ce ~]# cd /etc/yum.repos.d
[root@htc-ce ~]# wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel7.repo
[root@htc-ce ~]# cd /root
[root@htc-ce ~]# wget http://research.cs.wisc.edu/htcondor/yum/RPM-GPG-KEY-HTCondor
[root@htc-ce ~]# rpm --import RPM-GPG-KEY-HTCondor

Suggestion: in the slaves (WNs) it’s better to create and set the working dir for HTCondor jobs; the configuration proposed in the following lines reflect this.

[root@htc-ce ~]# mkdir -p /home/condor/execute/
[root@htc-ce ~]# chown -R condor:condor /home/condor/
[root@htc-ce ~]# chmod 755 /home/condor/

This configuration isn't the default for HTCondor. In the WNs configuration change accordingly the EXECUTE variable value in this way
EXECUTE = /home/condor/execute/

This follow the strategy you may already have implemented with old CE to the placement of the user’s home and the exchange of input and output sandbox on a separate device from the one of the operating system.

[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 8.8.10, condor-ce 3.4.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 static 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

An entry has to be ADDED to the condor_mapfile to match the certificate DN for the hosts at your site. These are mapped to the value defined by UID_DOMAIN (i.e. "t2-lp" in the following example) in HTCondor and HTCondor-CE.

[root@htc-ce ~]# grep -v -E '^#|^$' /etc/condor-ce/condor_mapfile
GSI "\/C=IT\/L=Frascati\/O=Istituto Nazionale di Fisica Nucleare\/.*CN=([A-Za-z0-9\-]*).lnl.infn.it$" \1@t2-lp
GSI (.*) GSS_ASSIST_GRIDMAP
GSI "(/CN=[-.A-Za-z0-9/= ]+)" \1@unmapped.htcondor.org  (default)
CLAIMTOBE .* anonymous@claimtobe                                (default)
FS (.*) \1                                                      (default)

Note on the first line the regular expression to match a set of Site certificates, it’s a perl RegExp.
The GSI (.*) GSS_ASSIST_GRIDMAP line is the magic that exploit the external argus auth/authZ: do not modify all the other default lines.
Warning: the host that is installing as 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.

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.

condor_ce_config_val usage examples:

• find where and how is defined an identifier (Knob) whose name is exactly known:

[root@htc-ce ~]# condor_ce_config_val -v HTCONDORCE_VONames
HTCONDORCE_VONames = alice, atlas, cdf, cms, dteam, lhcb, virgo
# at: /etc/condor-ce/config.d/06-ce-bdii.conf, line 14 

• see names and value for identifiers matching a part:

[root@htc-ce ~]# condor_ce_config_val -d HTCONDORCE
# Configuration from machine: ce03-htc.cr.cnaf.infn.it
# Parameters with names that match HTCONDORCE:
HTCONDORCE_BDII_ELECTION = LEADER
HTCONDORCE_BDII_LEADER = ce03-htc.cr.cnaf.infn.it
HTCONDORCE_CORES = 16 # cores per node
[…] 

Most of the predefined values already have reasonable values and there should be no reason to alter them; by individually inspecting the configuration files there are comments providing hints about what should be customized.

Worth to mention entries are :

HTCONDORCE_VONames = alice, atlas, cdf, cms, dteam, lhcb, virgo
DAEMON_LIST = $(DAEMON_LIST), CEVIEW, GANGLIAD

from file /etc/condor-ce/config.d/05-ce-view.conf. This enables a CE monitoring webtool (CEView) which is visible as http://your.ce.fully.qualified.name:80

Warning: the best practice should be to edit only the file /etc/condor-ce/config.d/99-local.conf and a file with the def. of jobrouter. In this way the software updates don't overwrite local configuration file.

The following are examples based on configuration in Legnaro-Padova T2:

[root@t2-cce-03 ~]# cd /etc/condor-ce/config.d/
[root@t2-cce-03 config.d]# ll
total 36
-rw-r--r-- 1 root root 2351 Jul  1 23:48 01-ce-auth.conf
-rw-r--r-- 1 root root 4000 Jul  2 16:20 01-ce-router.conf
-rw-r--r-- 1 root root 1029 Jul  1 23:48 01-common-auth.conf
-rw-r--r-- 1 root root 1149 Jul  1 23:48 01-pilot-env.conf
-rw-r--r-- 1 root root  476 Jul  1 23:48 02-ce-condor.conf
-rw-r--r-- 1 root root  240 Jul  1 23:48 03-managed-fork.conf
-rw-r--r-- 1 root root  364 Jul  1 23:48 05-ce-health.conf
-rw-r--r-- 1 root root  902 Jul  1 23:48 05-ce-view.conf
-rw-r--r-- 1 root root  291 Jul  1 23:48 50-ce-apel.conf
lrwxrwxrwx 1 root root   47 Oct 14 15:28 99-z10-ce-site-security.conf -> /sx/condor/shared/10-ce-grid-site-security.conf
lrwxrwxrwx 1 root root   44 Oct 14 15:28 99-z20-ce-job-routes.conf -> /sx/condor/shared/20-ce-grid-job-routes.conf
lrwxrwxrwx 1 root root   39 Oct 14 15:28 99-z30-ce-local.conf -> /sx/condor/shared/30-ce-grid-local.conf

[root@t2-cce-03 ~]# cat /etc/condor-ce/config.d/99-z10-ce-site-security.conf
DEFAULT_DOMAIN_NAME = lnl.infn.it

FRIENDLY_DAEMONS = $(FULL_HOSTNAME)@daemon.htcondor.org/$(FULL_HOSTNAME) condor@users.htcondor.org/$(FULL_HOSTNAME) condor@child/$(FULL_HOSTNAME), $(FULL_HOSTNAME)@$(UID_DOMAIN)/$(FULL_HOSTNAME), *@$(UID_DOMAIN), condor@$(UID_DOMAIN)/$(FULL_HOSTNAME), condor@child/$(FULL_HOSTNAME), *@$(DEFAULT_DOMAIN_NAME)
USERS = *@users.htcondor.org, *@$(UID_DOMAIN)
ALLOW_DAEMON = $(FRIENDLY_DAEMONS), $(FRIENDLY_DAEMONS)
SCHEDD.ALLOW_WRITE = $(USERS), $(FULL_HOSTNAME)@daemon.htcondor.org/$(FULL_HOSTNAME), $(FULL_HOSTNAME)@$(UID_DOMAIN)/$(FULL_HOSTNAME), *@$(UID_DOMAIN)
COLLECTOR.ALLOW_ADVERTISE_MASTER = $(FRIENDLY_DAEMONS), $(FRIENDLY_DAEMONS), *@$(UID_DOMAIN)
COLLECTOR.ALLOW_ADVERTISE_SCHEDD = $(FRIENDLY_DAEMONS), $(FRIENDLY_DAEMONS), *@$(UID_DOMAIN)
COLLECTOR.ALLOW_ADVERTISE_STARTD = $(UNMAPPED_USERS), $(USERS), $(FRIENDLY_DAEMONS), *@$(UID_DOMAIN)
SCHEDD.ALLOW_NEGOTIATOR = $(FULL_HOSTNAME)@daemon.htcondor.org/$(FULL_HOSTNAME), $(FULL_HOSTNAME)@$(UID_DOMAIN)/$(FULL_HOSTNAME), *@$(UID_DOMAIN)
ALLOW_ADMINISTRATOR = $(FULL_HOSTNAME)@daemon.htcondor.org/$(FULL_HOSTNAME), $(FULL_HOSTNAME)@$(UID_DOMAIN)/$(FULL_HOSTNAME), condor@$(UID_DOMAIN)/$(FULL_HOSTNAME)


[root@t2-cce-03 ~]# cat /etc/condor-ce/config.d/99-z20-ce-job-routes.conf
JOB_ROUTER_ENTRIES @=jre
[
name = "condor_pool_dteam";
TargetUniverse = 5;
Requirements = (regexp("dteam", TARGET.x509UserProxyVoName));
#copy_requirements = "original_requirements";
#set_requirements = original_requirements;
MaxJobs = 20;
MaxIdleJobs = 10;
]
[
name = "condor_pool_cms";
TargetUniverse = 5;
Requirements = (regexp("cms", TARGET.x509UserProxyVoName));
#copy_requirements = "original_requirements";
set_requirements = (TARGET.t2_wn_cms =?= true);
MaxJobs = 1000;
MaxIdleJobs = 500;
]
@jre

[root@t2-cce-03 ~]# cat /etc/condor-ce/config.d/99-z30-ce-local.conf
# ALL_DEBUG = D_FULLDEBUG D_CAT
# ALL_DEBUG = D_FULLDEBUG D_CAT D_SECURITY
# MASTER_DEBUG = D_ALWAYS:2 D_CAT
# SCHEDD_DEBUG = D_ALWAYS:2 D_CAT
# GSS_ASSIST_GRIDMAP_CACHE_EXPIRATION = 0

# NETWORK_HOSTNAME = ce01-htc.cr.cnaf.infn.it
# NETWORK_INTERFACE = 131.154.193.64

# emable ceview app
DAEMON_LIST = $(DAEMON_LIST), CEVIEW, GANGLIAD

UID_DOMAIN = t2-lp

# t2-ccm-03.lnl.infn.it is the Central Manager
JOB_ROUTER_SCHEDD2_POOL = t2-ccm-03.lnl.infn.it:9618
START_LOCAL_UNIVERSE = False
START_SCHEDULER_UNIVERSE = $(START_LOCAL_UNIVERSE)
SUBMIT_EXPRS = getenv
DELEGATE_JOB_GSI_CREDENTIALS_LIFETIME = 0
MERGE_JOB_ROUTER_DEFAULT_ADS = True
JOB_ROUTER_DEFAULTS = $(JOB_ROUTER_DEFAULTS_GENERATED) [set_Periodic_Hold = (NumJobStarts >= 1 && JobStatus == 1) || NumJobStarts > 1;]

HTCONDORCE_SPEC = [ specfp2000 = 3326; hep_spec06 = 11.088; specint2000 = 2772 ]

The files before "99-z*" are installed by the condor RPMs and you should not modify them.

The UID_DOMAIN is the same you chosen on the condor batch system side. It’s suggested to not set it as a network domain name as to distinguish objects on the logs.

The job router config is a very basic example!
The copy_requirements = "original_requirements"; statement is for advanced configuration to exploit very well defined user requirements.
t2_wn_cms is a custom tag defined internally by the site on condor batch system WNs dedicated to CMS experiment.

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 

Warning: 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_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 

NB: there is a bug that cause the stop of the daemon to be very slow (order of minutes): at the end the master daemon will issue a kill -9. You can do it yourself without worries.

From a User Interface having the htcondor-ce-client rpm, after generating a valid proxy, the htc-ce can be tested by

[root@ui ~]# condor_ce_trace <fqdn del CE> 

use the –debug option to get more details.

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