[solved] some DS are not accessibles on a distant server
|
|
---|---|
Hi, I encountered an issue while trying to access a DS running on a TANGO server from a distant client. My configuration is the following : - a TANGO server with a TangoTest and DataBaseds DS running (Debian 9/TANGO 9) - a TANGO client with jive and atkpanel (Ubuntu 16.04/TANGO 9) When I launch on the client command, I got an export exception with following shell output:
Into jive, the Device info is the following:
However, when I launch the same command on the server, the ATKPanel window appears normally.Moreover, when I launch command on the same client, the DS ATKPanel window appears normally.The server has only one (public) network interface. Do you have any idea what occurs here? Thank you.
- Philippe
|
|
|
---|---|
Hi Philippe, Difficult to debug from the information you provided… Seems weird indeed… Do you see anything strange in the Device Info from sys/database/2 when you compare it to sys/tg_test/1? Nothing special on your network between the 2 machines? No firewall? No TCP port blocked? TANGO_HOST environment variable well defined on both sides?
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new. |
|
|
---|---|
I do not see anything in the Device info from sys/database/2. It only contains:
When comparing to the output of Device info of sys/tg_test/1, there is one thing which difffers: the error message.
Since the sys/databaseds/2 and sys/tg_test/1 are executed from the same client, TANGO_HOST is defined for both of them. There is no blocked port and no firewall is locally configured, I will check with the sysadmin if some ports are blocked on the network.
- Philippe
|
|
|
---|---|
Hi Reynald, I got confirmation that port 59621 is filtered so I need to specify to OmniORB a port range. So I launched this DS executing command
as it is described in the doc at page https://tango-controls.readthedocs.io/en/latest/development/device-api/device-server-writing.html?highlight=myserver%20myinstance_name%20-ORBendPoint%20giop%3Atcp%3A%3A%3Cport%20number%3E#running-a-c-device-server and my problem disappeared. Thank you for your fast help. :)
- Philippe
|
|
|
---|---|
Hi Philippe, note that events might not work as the zmq sockets cannot be specified AFAIK. Zmq will choose sockets that are free based on its own internal algortihm. If you need events to work through your firewall then you should put in a feature request. Another way of accessing a device via a public network is to use the REST api. You need the REST server for Tango to do the translation form http to CORBA/ZMQ. Cheers Andy |
|
|
---|---|
Ok, thank you for the precision Andy. It should not be necessary, we currently use the public network for testing, but we do not access to real devices through this.
- Philippe
|
|
|
---|---|
After some time, I wonder if there is any way to configure the port DS will use when launching automatically? Currently, one can specify a port when launching through command line with
It could be nice to configure once the port constraint, since it will avoid an error if someone launch a DS without remembering this port constraint. The goal could be either to keep the same port or to impose a port in a given range.
- Philippe
|
|
|
---|---|
Hi philippeg,philippeg You mean to have a property in the database per instance of a server with the port number? If yes, this is how we do it at ALBA. We define a free property in the database, called "ORBendPoint", to which we add one property per server instance e.g. "Pool/XXX" with the value equal to "giop:tcp::YYYYY". Then in the launcher we can use, for example, in this way:
I don't know if this is the recommended way, but hope it helps you, Zibi |
|
|
---|---|
Thank you Zibi. I missed you answer and just discovered it. In fact, I wondered if it could be useful to integrate for each device a property "ORBendPoint" with the dedicated port for each instance. In case the property is not found or is empty, a random port could be used.
- Philippe
|
|
|
---|---|
Yes, this feature could avoid using of these conventions and specific launchers.. Then these property would be on the administrator devince level (dserver/…/…), right? |