Data Access configuration
Access to NXCALS system is based on Kerberos authentication. Any NXCALS client application must obtain a valid Kerberos ticket (or renew an existing one) using kinit tool. The acquired authentication is limited in time. Its issue and expiration timestamps can be verified using klist command.
Long-term encryption keys necessary to encrypt/decrypt Kerberos tickets for one or more access requesting accounts (principals) can be store in keytab file.
Configurations tasks that have to be performed for: * Kerberos installation * Generation of Kerberos keytab file (useful for user/service account impersonation and continuous execution) * Creation of a trustStore file for the JDK (optional - please see below)
1. Install Kerberos client
This will allow access to any Kerberos protected services once a user has successfully logged into the system.
Most likely the Kerberos software installation is not required on standard CERN machines (running Linux, Windows or Mac OSX), and the steps below can be simply omitted.
On the contrary if the installation is necessary please follow instructions below (given for Ubuntu Linux):
Install krb5-user package which provides the basic kinit, klist, kdestroy, and kpasswd clients:
sudo apt-get krb5-user
2. Configure local Kerberos client Configure Kerberos realm and write CERN.CH when requested to complete the realm after executing the following command:
sudo dpkg-reconfigure krb5-config
Kerberos keytab file generation
NXCALS client, by default will try to acquire the user Kerberos credentials from the locally available krb ticket cache. Thus, there is no need to specify any Kerberos related properties to run the client software. Even though, this approach is quite useful for one-go analysis execution, it comes with a cost. This authentication strategy relies on the cached ticket. The mechanism will stop working once the krb cache gets invalidated (around 24 hours since initialization).
If your intention is to run the client software constantly, like analysis that has to run for days, or periodically, without user interaction/supervision, then you will need to create a keytab file and declare its path on the corresponding NXCALS Kerberos properties.
Another way that you can solve this issue, is to add a cron job entry that will re-initialize your krb ticket, like the following:
* 8,12,19 * * * kinit -f -r 5d -kt /path/to/your.keytab [username] && aklog
Be aware that the krb ticket has a validity of max 24 hours, thus the provided cron schedule expression should not be less frequent than that.
This action is considered optional since NXCALS client tries to obtain the user credentials from the local Kerberos cache. If your goal is to impersonate another user/service account then the following steps can guide you through, on how to achieve that.
The preferred and the easiest method for obtaining keytab file is to generate it on lxplus machine by executing:
cern-get-keytab --user --keytab <keytab.file>
Once the .keytab file is created correctly we can check if obtaining Kerberos ticket works:
kdestroy && kinit -f -r 5d -kt /<path_to_keytab_file>/<user>.keytab <user> klist # Correct output Ticket cache: FILE:/tmp/krb5cc_14420 Default principal: <user>@CERN.CH Valid starting Expires Service principal 07/01/17 14:00:01 07/02/17 15:00:01 krbtgt/CERN.CH@CERN.CH renew until 07/06/17 14:00:01
Please note that this file should be well protected as it contains user's password
Troubleshooting Kerberos issues
Kerberos is relatively hard to debug. Messages coming from JVM can be difficult for diagnosing. Extra debugging information can be enabled for the client.
Please add the following settings to your Spark config under
spark.driver.extraJavaOptions -Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=true -Djava.security.debug=gssloginconfig,configfile,configparser,logincontext spark.yarn.appMasterEnv.HADOOP_JAAS_DEBUG true spark.yarn.am.extraJavaOptions -Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=true -Djava.security.debug=gssloginconfig,configfile,configparser,logincontext
CERN grid CA certificate installation
This action is considered optional since NXCALS client tries to obtain the CA certificates from the embedded trustStore file that is available on the resources.
If you still need to use your own or existing trustStore that contains the needed CERN certificates, then click on the following panel to see how you can achieve that.
Click to see how to manually install a CERN grid CA certificate...
Machines with JDK provided by BE-CO do not require creation of the truststore. It is already preinstalled. The steps below concerning certificate installation can be simply skipped.
1. Download certificate
Prefer to save the certificate with a name like: CERN_Grid_Certification_Authority.crt, as this name will be used as reference for the rest of this guide.
2. Generate SSL trustStore with JDK's keytool
For this step you need to have Java present on your system. In order to import the CERN grid CA certificate, you need to run the following command via java keytool:
/path/to/jdk/bin/keytool -import -alias cerngridcertificationauthority -file /path/to/CERN_Grid_Certification_Authority.crt -keystore nxcals_cacerts -storepass nxcals -noprompt
3. Reference certificate on NXCALS client applications
Once we have the CERN grid CA certificate imported to the JDK's keystore, we need to reference it on an NXCALS client application startup. In order to do that, we have to export the SSL trustStore and trustStore password as JVM related system properties.
For example, add the following:
System.setProperty("javax.net.ssl.trustStore", "nxcals_cacerts"); System.setProperty("javax.net.ssl.trustStorePassword", "nxcals");