==== 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: [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. == 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 == [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/ == Rpms installation == * 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 == 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 [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:///condor-ce == 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:\\ [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. == Argus client installation == Install an Argus pep client on your HTCondor-CE [root@htc-ce ~]# yum install argus-pepcli == 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.: [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 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. // [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. === 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 # SCITOKENS /,/ leaving An empty '''', 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 == 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'' # 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 [[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: [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 == 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): [root@htc-ce ~]# yum install glite-yaim-core [root@htc-ce ~]# /opt/glite/yaim/bin/yaim -r -s /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..) == Start HTCondor-CE process == [root@htc-ce ~]# systemctl start condor-ce == 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. [user@ui ~]# export _condor_SEC_CLIENT_AUTHENTICATION_METHODS=GSI ; condor_ce_trace 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: === Authenticating with SCITOKENS === 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: - [sdalpra@ui-htc ~]$ export BEARER_TOKEN_FILE=$HOME/sdptok - [sdalpra@ui-htc ~]$ export BEARER_TOKEN=`oidc-token sdptok` - [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. === 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 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! == How to change the uid and gid of an already created condor user == 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 == 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: 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 == Alternative solution to Argus service (to be implemented) == 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]]) == /etc/grid-security content details == 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). == Alias for HTCondor command == It’s useful to define the alias in /root/.bashrc alias ccv='condor_config_val' alias cccv='condor_ce_config_val' == 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]]