D4Science Infrastructure

info.d4science.org is misleading. The name should be resourceregistry.d4science.org or simpler registry.d4science.org

I'm not sure why info.d4science.org would be misleading but i'm fine with registry.d4science.org

also registry.d4science.org is misleading. ICProxy offer only access to the IC and also this name is already used for the node where the registryService is deployed

Lucio Lelii wrote:

also registry.d4science.org is misleading. ICProxy offer only access to the IC and also this name is already used for the node where the registryService is deployed

ok then registry is not possible

Yes we have registry-voname and it would be misleading for the infrastructure manager, but it won't be my problem :) It's ok for me

ok then "registry.d4science.org" is approved.

We also need instructions to automate the ic_proxy installation. I see that was manually deployed both in dev and in production (node79 was created as a demo server a lot of time ago, so it has been recycled)

forgot to add the the registry node should be registered in the /d4science.research-infrastructures.eu

@lucio.lelii@isti.cnr.it this service must be enabled on all the scopes ... is there a way just for this service to not use the token?

<dependency>
  <groupId>org.gcube.information-system</groupId>
  <artifactId>icproxy</artifactId>
  <version>1.1.1-4.2.1-142273</version>
  <type>war</type>
</dependency>

@lucio.lelii@isti.cnr.it is this version (1.1.1-4.2.1-142273) the one with the correct serviceclass?

yes

to it reachable for every scope you must add the exclude tag on th egcube-app.xml file in WEB-INF :

<exclude handlers='request-validation'>/*</exclude>

by applying such exclude the token won't be necessary anymore, is that correct?

What's the status here? i think we only need to deploy the war with the exclude handler and we're good?

I am fixing the exclude tag in ansible playbook

The nginx reverse proxy configuration was missing. Can you try now?

I see. But I'm not able to investigate further: I need someone able to verify the smartgears scopes and the icproxy version. I see that the latest from the maven repository was installed but you specified a version. If they are different we will need to reinstall.

any news? Still does not work @lucio.lelii@isti.cnr.it please reply to @tommaso.piccioli@isti.cnr.it

It worked for me right now.
We still don't know what changes to the configuration are needed.

The exclude tag must be removed, I was wrong

OK, so we do not need to touch gcube-app.xml at all, is it correct?

the fix in gcube-app.xml is needed to enable the services on all the VREs, I guess @lucio.lelii@isti.cnr.it ?

so after chatting with lucio it seems that we need the 4.4.0 version

@andrea.dellamico@isti.cnr.it yes.
@massimiliano.assante@isti.cnr.it the new common-smartgears-2.1.2 released in 4.4.0 solves the problem about scopes, but I have released it today.

Roberto Cirillo wrote:

I've notice node79.d4science.org is still running under gCubeApps VO and with a different IP. Is there any reason for that? if not, please could you shoutdown and dismiss this VM?

I don't know of any reason, I guess that after the ticket were close everybody forgot about that VM.

I think so, too. I think we can dismiss it now. I've stopped the container on node79.d4science.org.

And removed the nagios configuration.