Menu ▾ ▴

#9 Automatic configuration

1.0
closed
nobody
2016-10-07
2015-11-25
No

Currently the the applications and clients need configuration files that both include the server adresses of the applications and port ranges. Both files are exhaustive descriptions of the system. The client needs to know the address of the nameserver AND the adresses and ports of app-servers. This to my oppinion is too cluttered and complicates the system setup.

Why must the client know all the ports and the addresses of the servers in addition to the nameserver? Shouldn't the nameserver provide these to the client? If the client already knows the addresses of the server by configuration what is the point of the nameserver anyway?

My proposal:
Client side:
Add a mechanism to provide the ports and addresses of applications via the nameserver.
Only nameserver address and the application signatures are needed on the client side script.

Server side:
Add automatic port randomization for added security.
SSH port and nshost-port should be configured manually.

-OLLI

Discussion

  • Vit Smilauer

    Vit Smilauer - 2016-03-26

    Dear Olli,
    you are right that there are redundancies on a client side - the client needs to specify server's IP, nat, and port which could be obtained elsewhere. I was excited about your idea which would simplify things which turned out to be recurrent problem. Let us take example/Example06 as a reference case. A client needs to know server details in order to set up ssh tunnel. Once the tunel is there, the communication happens through Pyro4 and we need no further details of server.

    Looking into implementation, it would have to go along this line; the nameserver only registers object (e.g. PYRO:obj_f34f351039574668a8cdde64b730d677@127.0.0.1:5555) but stores no data of those object, they are on a server. If you want to obtain server's details, you need some connection to the server which is unknown at this time. Even the nameservers registers the object, there is no connection to that object if the object is e.g. behind firewall. So you need to setup connection to server first to obtain data about that connection. This would not simplify anything (you could benefit maybe a bit to obtain NATports for JobManager but that is really negligible). Your idea would work if data could be stored on a nameserver which does not happen.

    Currently, MuPIF uses creastion of ssh tunnels inside. There are other options such as VPN or creation of ssh tunnels outside of MuPIF. Ralph is using external tunnels since he has better control what is going on. In such particular cases, connection details must be known in advance.

    Randomization of ports will hit the same difficulty - they need to be synchronized both on client and server. You know that there is an option -p (ssh) or -P (putty) to specify other port than 22 for ssh client. Ssh server port can be modified accordingly.

    Best regards. Vit

     
  • Borek Patzak

    Borek Patzak - 2016-10-07
    • status: open --> closed
     

Log in to post a comment.