D4Science Infrastructure

I've seen the following ticket for the last installation in preproduction environment #4718 . Please @nunzioandrea.galante@eng.it could you indicate the packages required by fhn-manager. This part is not provisioned.

The documentation about the packages needed is available at the following link: https://wiki.egi.eu/wiki/Fedcloud-tf:CLI_Environment.

It's way too generic.

As I already wrote we have a couple of roles that cover the tools installation and we should have a valid configuration for the VO too.
But other parts need clarifications: what certificates have to be used, where to take them, where to install them so that the service works.
All the steps should avoid any manual intervention.

I try to report what i remember cause i did these operations much time ago.
No certificate must be available on the node cause the service extracts it directly from the Information System and dinamically a short-time one needed to access to the federation of cloud is created.
For sure we need to install the script provided from EGI able to install both VOMS and OCCI-client (http://go.egi.eu/fedcloud.ui).
Once done this, it is necessary to edit the informations related both to the VOMS server and the VO d4science.org in /etc/grid-security/vomsdir/d4science.org and /etc/vomses.
If i do not get wrong, there should have to be a particular set of certificates to download from somewhere and to deploy in /etc/grid-security/certificates. It was provided to me by EGI.
I make myself fully available to cooperate with you in this task.

I'm not able to access to fhn-manager-t.pre.d4science.org Please @tommaso.piccioli@isti.cnr.it could you give me access when it is ready?

You have it now.

Dear @roberto.cirillo@isti.cnr.it , the configuration is ok.
Anyway, i realized that maybe there is a small bug in the service.
I try to explain: the service extracts the voms certificate from the Information System and create a new temporary certificate file to interact with the fedcloud infrastructures; until now we have considered the name of such file as static and univocal and everything was ok for all the environments in which the service has been deployed.
Unfortunately, this is not always true, cause the name of the certificate changes depending on the ID of the user; for instance, according to /etc/passwd file, the gcube user has id 1001 for the fhn-manager-t.pre.d4science.org and id 1000 for the node75.d4science.org.
So maybe a new version of the service containing these really minor changes is needed. I will test in dev and perform an etics build within tomorrow and later, if you believe is feasibile, we could deploy this new version.
What do you think?

Nunzio Andrea Galante wrote:

Dear @roberto.cirillo@isti.cnr.it , the configuration is ok.
Anyway, i realized that maybe there is a small bug in the service.
I try to explain: the service extracts the voms certificate from the Information System and create a new temporary certificate file to interact with the fedcloud infrastructures; until now we have considered the name of such file as static and univocal and everything was ok for all the environments in which the service has been deployed.
Unfortunately, this is not always true, cause the name of the certificate changes depending on the ID of the user; for instance, according to /etc/passwd file, the gcube user has id 1001 for the fhn-manager-t.pre.d4science.org and id 1000 for the node75.d4science.org.
So maybe a new version of the service containing these really minor changes is needed. I will test in dev and perform an etics build within tomorrow and later, if you believe is feasibile, we could deploy this new version.
What do you think?

I think it is reasonable. Please, fix the issue, perform a remote build and let me know the new service version. Thanks in advance.

Please @roberto.cirillo@isti.cnr.it , according to http://paste.research-infrastructures.eu/index.php?id=20170928162015_21293 a library needed to the service seems to be missing.
Could you please check?

Has this exception been thrown by the service? if yes could you indicate the file that contains this exception, please?

We have fixed the issues: the new version is the 1.2.4-4.7.0-154701 (actually in staging).
Such version will be released in 4.8.0 since it seems to be late to involve in 4.7.

Let me add that we are having some issues (in the recent past they were not) with the voms-client usage both with the dev and preprod environment.
Since these problems do not occur by going to perform some test locally, we are afraid that there could be some misscomunications with Ubuntu 14. By the way, we are investigating on it and we will let you know more as soon as possibile.

Please, could you specify what issue have you resolved? In addition, could you report the error/exception for the other issues, please?

The solved issues are listed at post #12 of the current thread.
The exceptions are instead related to task #9863.

Nunzio Andrea Galante wrote:

Please @roberto.cirillo@isti.cnr.it , according to http://paste.research-infrastructures.eu/index.php?id=20170928162015_21293 a library needed to the service seems to be missing.
Could you please check?

Has this exception been thrown by the service? if yes could you indicate the file that contains this exception, please?

Nunzio Andrea Galante wrote:

Please @roberto.cirillo@isti.cnr.it , according to http://paste.research-infrastructures.eu/index.php?id=20170928162015_21293 a library needed to the service seems to be missing.
Could you please check?

Yes, the service throws such exception when the voms-proxy-init is invoked.
It can be verified to /home/gcube/tomcat/logs/catalina.out
Actually on this new VM is still deployed the old version of the service.

I have done a comparison between this VM and the one we have in dev.
It seems to be missing the library commons-io.jar in /var/lib/voms-clients3/lib.
This could solve this issue.

The exception that you are reporting is not throws by service. I've checked and attached the catalina.out files from 27 September to now. So this is not a service problem.

Sorry, maybe there was a misunderstading. I mean, the service invokes the voms and the voms thorws the exception.
By the way, this exception should have to disappear once deployed the aforementioned library.

Nunzio Andrea Galante wrote:

I have done a comparison between this VM and the one we have in dev.
It seems to be missing the library commons-io.jar in /var/lib/voms-clients3/lib.
This could solve this issue.

The clients version is the same on every instance. Was that library added manually?

As far as i remember, not.
I have verified also that node75 contains such library as well.
So this is an issue just related to this VM.

So, the same package version sometimes has a bug and sometimes not.

Production VM node65 has no bug as well.

That doesn't help. All that hosts were manually configured and we do not know how. The new preproduction host is the first try at getting back in control of all the pieces.