D4Science Infrastructure

A VPN is overkill for this kind of activity. As soon as we have the IP addresses that need access, I'll grant access to them.

Andrea, they are going to need to contact also D4Science clusters such as Cassandra and MongoDB and jackrabbit repository and ElasticSearch

Massimiliano Assante wrote:

Andrea, they are going to need to contact also D4Science clusters such as Cassandra and MongoDB and jackrabbit repository and ElasticSearch

If we have a list of resources I still prefer to explicitly open the single services. A VPN would give open access to all our datacenter network.

Do we need to setup the same for the
staging.datasciencepro.eu (at least the db access)

and

www.datasciencepro.eu (194.149.136.227) for production site. Does it means that we will have to connect to another DB instance, and do we need to setup ldap sync with another ldap instance or the same is enough?

Regards,
Boro.

@andrea.dellamico@isti.cnr.it it seems that the elastic search node (elastic0-d-d4s.d4science.org) is not contactable from 194.149.136.225 (dev.datasciencepro.eu)

PORTAL] 1049431 [elasticsearch[Molly Hayes][transport_client_boss][T#1]{New I/O boss #17}] WARN  org.elasticsearch.transport.netty  - [Molly Hayes] exception caught on transport layer [[id: 0x99a98814]], closing connection
java.net.NoRouteToHostException: No route to host
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
    at org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:150)
    at org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
    at org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
    at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
    at org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:748)
[

The problem is not on our side:

# iptables -nvL | grep 194.149.136.225
    0     0 ACCEPT     tcp  --  *      *       194.149.136.225      0.0.0.0/0            state NEW tcp dpt:9200

Boro Jakimovski wrote:

Do we need to setup the same for the
staging.datasciencepro.eu (at least the db access)

I understand staging.datasciencepro.eu will be your preproduction instance. I think this should still point to the devEDISON VRE on D4Science PreProduction Infrastructure so the same nodes we authorised for dev.datasciencepro.eu

and

www.datasciencepro.eu (194.149.136.227) for production site.

In this case, this portal should point to the EDISON Virtual Organisation on D4Science Production Infrastructure

Does it means that we will have to connect to another DB instance, and do we need to setup ldap sync with another ldap instance or the same is enough?

Yes in the latter case you have to connect to totally different nodes, we will take care of opening the ports on our firewall for this node.

About LDAP

The script that we provide for exporting users on D4Science automatically retrieves the LDAP instance based on the infra. I can enable it on dev.datasciencepro.eu (and it will use our LDAP dev) but you should first perform a clean of the users in dev.datasciencepro.eu Liferay DB according to the rules we agreed in out last telCo.

Hope this helps,
M.

I just gave staging.datasciencepro.eu the same accesses that dev.datasciencepro.eu has.