WS-PGRADE is able to communicate with several resource managers, and these managers often lack an application database of sorts. UNICORE excels in this aspect and keeps all applications registered in an incarnation database, but this seems to be the exception.
This portlet lets the administrator of the WS-PGRADE portal to register applications, thus, extending WS-PGRADE by adding its own application database. It also offers read-only access via a minimalistic REST-API.
Access: [portal-url]/ApplicationManagerPortlet/rest/apps.
The output is an XML file similar to:
<resources>
<resource name="c153-110.localcloud" type="pbs">
<queue name="batch"/>
<application name="blast" version="1.4" description="Basic local allignment search tool." path="/share/bin/blast"/>
</resource>
</resources>It offers a simpler configuration tool for uploaded workflows. After being edited, you can export them to any other WS-PGRADE instance or use them in the current portal.
- Java 1.8
- maven
If you want to deploy the files yourself, you will also need Apache ant with the jsch.jar 0.1.54 or later (for scp and sshexec ant tasks), which you can find here.
Java repositories should not contain binaries, but at some point between the creation of this project and the release of it, one of the repositories holding required dependencies was not reachable anymore. Sadly, code that is not maintained by us refers to a repository that is not reachable, so we are distributing the needed files in the dependencies folder.
Go to the dependencies folder and execute the following commands to install the dependencies in your local repository:
$ mvn install:install-file -DpomFile=portal-service.pom -Dfile=portal-service.jar
$ mvn install:install-file -DpomFile=unicore6-api.pom -Dfile=unicore6-api.jar
$ mvn install:install-file -DpomFile=externals.pom -Dfile=externals.pom
$ mvn install:install-file -DpomFile=unreleased.pom -Dfile=unreleased.pom
To build the extensions, simply run:
$ mvn package
No. You just need to install the generated portlets into your WS-PGRADE instance by following WS-PGRADE user's manual.
There are two ways in which you can deploy the portlets on a WS-PGRADE instance. Regardless of which way you choose, you need to restart the WS-PGRADE portal.
Once you've built the portlets, ApplicationManager.war, WorkflowImporter.war, you will need to log-in to your WS-PGRADE instance as an administrator, then, go through the following steps:
- Access the control panel
- Locate the App Manager in the control panel bar:
- Click on Install:
- Select File upload and then click on the Choose file button:
-
Navigate to the folder on which the portlets were built (typically, under the
targetfolder), select one of the portlets and click on the Install button. You will need to repeat this step for each portlet. -
Restart the WS-PGRADE portal.
maven's job finishes at packaging. After the portlets have been built, you will need to execute the build.xml ant script to deploy the portlets on WS-PGRADE.
Create a copy of deployment.properties.example and save it as deployment.properties. Fill in the pertinent information. Once you're done, make sure the portlets have been built by executing [mvn] as follows:
$ mvn package
Then execute ant like so:
$ ant deploy
This last command will copy the portlets into the deploy folder of your WS-PGRADE instance. After deployment finishes, don't forget to restart the WS-PGRADE portal.
As already discussed, these portlets allow you to access a UNICORE instance and query its incarnation database (IDB). As you might know, UNICORE relies on the use of certificates. Chances are that if your WS-PGRADE instance, on which you will install this portlet, can submit jobs on a UNICORE grid, then you're good to go. However, we think there is some value in documenting the followed process in order to connect a WS-PGRADE instance to a UNICORE grid.
The very first thing you need is a way to identify your WS-PGRADE server. This is done by using a server certificate. Server certificates are issued by a so-called Certificate Authority, CA. This is just a fancy name for an institution that, among other services, can issue digital certificates, which is just a fancy name for a file with numbers in it. This step depends on where you work/live, but at the very least, you will need a Certificate Signing Request CSR. You will need a simple-yet-powerful tool called OpenSSL. With it you can do all sorts of wonderful things, for instance, create a CSR.
Before generating a CSR, you will need to generate a private key for your server. Other parties will never have access to your private key, but they can access your public key (see [https://en.wikipedia.org/wiki/Public-key_cryptography] for more information). This key is the private part of the public-private key encryption process. The following OpenSSL command generates a private RSA key using 2048 bytes in the server-key.pem file:
$ openssl genrsa -out server-key.pem 2048
Generating a CSR.
The following OpenSSL command generates a CSR in PEM format under the file mycsr.pem. Notice how this step requires a private key (server-key.pem), which you already generated. You will be prompted to input information about the server, namely, its location, its DNS name, etc. You will also be prompted for a challenge password.
$ openssl req -new -key server-key.pem -out csr.pem -outform PEM
As suggested in [http://www.shellhacks.com/en/HowTo-Create-CSR-using-OpenSSL-Without-Prompt-Non-Interactive], you can also use the -subj command line option to set most of the certificate's subject information without using the prompt (you will still be asked for a password):
$ openssl req -new -key server-key.pem -out csr.pem -outform PEM -subj /C=DE/O=GridGermany/OU=Fake\ University/CN=myserver.edu
Your newly generated CSR, stored in csr.pem would look like:
-----BEGIN CERTIFICATE REQUEST-----
YADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADA
YADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYADA
...
YADAYADAYADAYADAYADAYADAYADAYADAYADAYADAYA
-----END CERTIFICATE REQUEST-----
At this point, you have a private key, server-key.pem, and a CSR, csr.pem. The next step is to go to your CA and request for a server certificate. Depending on your CA, you will get your certificate in a different format, but let's assume that you got it in PEM format, stored it under server-cert.pem and it looks similar to this:
-----BEGIN CERTIFICATE-----
NANANANANANANANANANANANANANANANANANANANANANANANANANANANANANANANA
NANANANANANANANANANANANANANANANANANANANANANANANANANANANANANANANA
...
NANANANANANANANANANANANANANANANABATMAN
-----END CERTIFICATE-----
Using UNICORE's API
With your newly acquired certificate, you are a step closer to query UNICORE grids. There are still a couple of things to do. UNICORE requires your server certificate stored in a PKCS12 file, along with the root certificate of your CA in a Java keystore file. Let's see how to achieve this.
Exporting your server's certificate to PKCS12 format
Once your CA has issued your server's certificate, use OpenSSL to store it in a PKCS12 file, like so:
$ openssl pkcs12 -export -out server-store.p12 -inkey server-key.pem -in server-cert.pem -name myalias
This will generate a file in PKCS12 format, in which your server's certificate will be contained. In order to make things friendlier, you are allowed to use an alias for your server, in this case, we chose myalias. You will be prompted for a password. Let's assume that you chose server-store-pass as a password.
Exporting your CA's root certificate into a Java keystore
The UNICORE API also requires a keystore in which your CA's root certificate has been included. Check your local CA's documentation to obtain the root certificate. Let's assume that you stored in PEM format in the file ca-root.pem and that it looks similar to:
-----BEGIN CERTIFICATE-----
CANTTOUCHTHISCANTTOUCHTHISCANTTOUCHTHISCANTTOUCHTHISCANTTOUCHTHIS
CANTTOUCHTHISCANTTOUCHTHISCANTTOUCHTHISCANTTOUCHTHISCANTTOUCHTHIS
...
CANTTOUCHTHISCANTTOUCHTHISSTOPHAMMERTIME
-----END CERTIFICATE-----
You will need Oracle's keytool to generate a Java keystore, which is usually shipped in the Java Software Development Kit (Java SDK). Executing the following command will import your CA's root certificate into a keystore and save it under a file named truststore.jks:
$ keytool -import -keystore truststore.jks -trustcacerts -file ca-root.pem
Again, you will be prompted for a password. Let's assume you entered ca-root-pass.
This is a checklist of the things you need to make your WS-PGRADE instance talk to a UNICORE grid:
- A file in PKCS12 format containing your server certificate under a certain alias, along with the password you used for its generation (e.g.,
server-store.p12containingserver-cert.pemwith themyaliasalias usingserver-store-passas password) - A Java keystore file containing your CA's root certificate, along with the password you use for its generation (e.g.,
truststore.jksusingca-root-passas password) - A running WS-PGRADE instance
You now need to configure your WS-PGRADE instance so it can interact with a UNICORE grid. Navigate to <wspgrade-instance-url>/dci_bridge_service/conf and enter your Apache Tomcat admin password. Click on Grids and then on UNICORE. Add a new UNICORE service by clicking on the Add new tab. The following table shows the values you should use (note that all paths refer to file paths on your WS-PGRADE server):
- UNICORE grid name: the DNS name of a UNICORE instance, e.g.,
unicore.server.edu:8081 - Status: click on
Enabled - Path of keystore file for resources(pkcs12): the path, on your WS-PGRADE server, of the PKCS12 file containing your server certificate (e.g., the path of the
server-store.p12file) - Password of resource keystore: the password you used to generate the Java keystore (e.g.,
server-store-pass) - Alias of new resource: the alias you used when importing your server's certificate into the Java keystore (e.g.,
myalias) - DN of new resource: the domain name of your server (e.g.,
CN=myserver.edu, OU=Fake University, O=GridGermany, C=DE) - Path of keystore file for CA-s(jks): the path of the Java keystore file containing your CA's root certificate (e.g., the path of the
truststore.jksfile) - Password of CA keystore: the password you use to generate the Java keystore (e.g.,
ca-root-pass)
After clicking on the Save button, click on the Middleware settings tab and make sure that the Enable plugin option is set to Enabled. Click on the Save button and after a restart of your WS-PGRADE instance you should be ready to go.