Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Rugby Question

 [1/22] from: mattsmac:ho:tmail at: 28-Oct-2003 10:33


If I'm using rugby to serve functions outside of a firewall, so that the client will not be able to see the internal IPs of the server, do I need to use rexec and sexec to remotely execute all of the functions? Or is there a way to use the standard import method. Basically what is happening is that I keep getting errors on the server that says that it can't connect to the servers internal IP. Matt

 [2/22] from: maarten:vrijheid at: 28-Oct-2003 20:22


Matt, What do your server functions do? It sounds like your firewall prevents accessing the business logic here, i.e. this is a network problem. You can have a Rugby server running on one ip address when it's a dual network-card server, that's what most people would do. Then allow incoming calls only on one card, and sandwich the box between two routers and two firewalls. If you get the router and firewall configs right there should be no problem. --Maarten

 [3/22] from: mattsmac::hotmail::com at: 28-Oct-2003 15:05


They do database reads mostly. The firewall is set up to allow incoming and outgoing connections on the ports I need. For instance "r: open tcp://ip-address:8001" works. But if I do this: server: context get-rugby-service tcp://ip-address:8001 and then try something like t: server/probe-messages userid, then i get an error on the client machine (outside of the firewall) that says that it cannot connect to 10.10.1.14 which is the internal IP address of the server. But it shouldn't be trying to connect to that IP address at all, it should be trying to connect to port 8000 on the firewall's external IP which then routs it internally to the server. I'm not super knowledgable when it comes to networks, but I'm not seeing why it should be trying to access that internal IP in the first place. Thanks for any help, Matt ------------------------------------ Matt, What do your server functions do? It sounds like your firewall prevents accessing the business logic here, i.e. this is a network problem. You can have a Rugby server running on one ip address when it's a dual network-card server, that's what most people would do. Then allow incoming calls only on one card, and sandwich the box between two routers and two firewalls. If you get the router and firewall configs right there should be no problem. --Maarten

 [4/22] from: maarten:vrijheid at: 28-Oct-2003 21:49


The latest version on http://www.koopgoedkoop.net/rugby.zip uses for sure the address used by the client when doing get-rugby-service. Are you using that one? --maarten

 [5/22] from: mattsmac:hotm:ail at: 29-Oct-2003 10:13


I just downloaded the latest version of Rugby, which fixes the problem. The only problem I have now is that in the old version of Rugby I could issue a statement like "useport: server/__rugby-server-address/port-id" that would return the local port that the server is using. When trying to issue this statement in the new version (4.3) I get an error that says "Invalid path value: __rugby-server-address" Is there anyway to issue a similar statement in the new version? Thanks, Matt --------------------------------------- The latest version on http://www.koopgoedkoop.net/rugby.zip uses for sure the address used by the client when doing get-rugby-service. Are you using that one? --maarten

 [6/22] from: mattsmac::hotmail at: 29-Oct-2003 10:50


In addition to that, I would also need to be able to lookup the incoming connection's IP address. Is there a way to do that? Matt

 [7/22] from: maarten:vrijheid at: 29-Oct-2003 20:09


Hi Matt, In the version you downloaded the client inserts the ip address that is used by get-rugby-service in the code returned by the server. The server ip address is simply the one you already use (or... a read dns://host in case of a hostname). Same for the port number. HTH, Maarten Matt MacDonald wrote:

 [8/22] from: mattsmac:ho:tmail at: 29-Oct-2003 14:46


Can you elaborate a little bit? I'm sorry, I'm having a slow day. What code returned by the server? Matt ------------------------- Hi Matt, In the version you downloaded the client inserts the ip address that is used by get-rugby-service in the code returned by the server. The server ip address is simply the one you already use (or... a read dns://host in case of a hostname). Same for the port number. HTH, Maarten Matt MacDonald wrote:

 [9/22] from: mattsmac:hotma:il at: 29-Oct-2003 14:50


Also, I am using multiple servers, so I will know what IPs they are on, but not necessarily the ports, becuase if one goes down, for instance, i need to find out which ones are still running by the port numbers.

 [10/22] from: maarten:vrijheid at: 29-Oct-2003 21:26


When a server start, it generates "stub" code, code that a client can retrieve and use to connect to a service. So.... get-rugby-service receives this code (essentially a block containing function defs) and you either do them or put them in an object. Now when the stub code is received the client replaces all *http* by the ip address it just used to connect. And when you invoke a function on a get-rugby-service'd retrieved stub it connects back, etc. --Maarten

 [11/22] from: maarten:vrijheid at: 29-Oct-2003 21:23


The ports are part of the URL you provide. Get-rugby-service is nothing more than a smart rexec to a running service, so those port numbers are the same as well. Ever considered adding a "ping" function that returns true (or an error if the connection is broken)? --Maarten

 [12/22] from: mattsmac:hotm:ail at: 29-Oct-2003 16:30


THanks I think that will help

 [13/22] from: mattsmac:h:otmail at: 30-Oct-2003 8:20


OK, so I'm seeing how the stubs contain the ip-address in the http-port local variable, but how do I get that out and into a useable form? The only thing I can think of is to echo a probe of the server to a file and parse for the http-port, but I'm sure there has got to be a better way than that. Matt -------------------------------- When a server start, it generates "stub" code, code that a client can retrieve and use to connect to a service. So.... get-rugby-service receives this code (essentially a block containing function defs) and you either do them or put them in an object. Now when the stub code is received the client replaces all *http* by the ip address it just used to connect. And when you invoke a function on a get-rugby-service'd retrieved stub it connects back, etc. --Maarten

 [14/22] from: maarten:vrijheid at: 30-Oct-2003 16:40


Matt, That ip address is the same as the one you use in get-rugby-service (get-rugby-service inserts it locally) so I suggest you store it when invoking get-rugby-service. --Maarten

 [15/22] from: mattsmac:ho:tmail at: 3-Nov-2003 14:13


Sorry, I had to put this problem aside for a minute. Ok Maarten, I followed your advise to keep a running list of the server ports when I connect to them, that makes sense, but I'm still not following how the server can keep track of the clients. Basically I need to do this on the server: alive: does [ client-IP: {get client IP and port from Rugby?} ] or something like that so that and then serve that function. This way the client can call that function periodically to let the server know that it is still running. I need to have the IP for security reasons so I can make sure that the client is coming from the same address every time. If you need any more specifics, let me know. Some code would really help. THanks again, Matt -------------------------------------------------------------------------------- When a server start, it generates "stub" code, code that a client can retrieve and use to connect to a service. So.... get-rugby-service receives this code (essentially a block containing function defs) and you either do them or put them in an object. Now when the stub code is received the client replaces all *http* by the ip address it just used to connect. And when you invoke a function on a get-rugby-service'd retrieved stub it connects back, etc. --Maarten

 [16/22] from: maarten:vrijheid at: 3-Nov-2003 21:42


Hi Matt,
> Sorry, I had to put this problem aside for a minute. Ok Maarten, I > followed > your advise to keep a running list of the server ports when I connect
to
> them, that makes sense, but I'm still not following how the server can > keep
<<quoted lines omitted: 4>>
> ] > or something like that so that and then serve that function. This way
the
> client can call that function periodically to let the server know that
it
> is > still running. I need to have the IP for security reasons so I can
make
> sure that the client is coming from the same address every time. If
you
> need any more specifics, let me know. Some code would really help.
You cannot get the client IP directly in Rugby. The ports are stored in the i/o engine (port-q and object-q), but you cannot see that when a function is invoked (you don't see what client is calling). You restrict access to a set of functions using the /restirct refinement, but I doubt that is what you want. Perhaps a simple private/public key scheme works best here. With all the spoofing going on that is a better idea anyway. --Maarten

 [17/22] from: mattsmac:hotmai:l at: 3-Nov-2003 15:52


What do you mean spoofing? ---------------------------------------------- Hi Matt,
>Sorry, I had to put this problem aside for a minute. Ok Maarten, I >followed >your advise to keep a running list of the server ports when I connect
to
>them, that makes sense, but I'm still not following how the server can >keep
<<quoted lines omitted: 4>>
>] >or something like that so that and then serve that function. This way
the
>client can call that function periodically to let the server know that
it
>is >still running. I need to have the IP for security reasons so I can
make
>sure that the client is coming from the same address every time. If
you
>need any more specifics, let me know. Some code would really help.
You cannot get the client IP directly in Rugby. The ports are stored in the i/o engine (port-q and object-q), but you cannot see that when a function is invoked (you don't see what client is calling). You restrict access to a set of functions using the /restirct refinement, but I doubt that is what you want. Perhaps a simple private/public key scheme works best here. With all the spoofing going on that is a better idea anyway. --Maarten

 [18/22] from: maarten:vrijheid at: 3-Nov-2003 22:52


Pretending your somebody else's ip address. Using Ip addresses is very waek, security-wise. --Maarten

 [19/22] from: mattsmac:hot:mail at: 4-Nov-2003 8:31


Yeah, I can see the risk in that. I'm using the secure functions of Rugby now, but I also wanted to track IPs so that within a session, a user doesn't show up on multiple IP addresses. Matt ---------------------------------------------------------------- Pretending your somebody else's ip address. Using Ip addresses is very waek, security-wise. --Maarten

 [20/22] from: mattsmac:hotmai:l at: 4-Nov-2003 11:06


Maaten, I think I found a way to get the functionality that I need, but it will require me to edit Rugby a little bit. All I need to do to it is add a current-ip field to the rugby-server object and then add the line rugby-server/current-ip: item/remote-ip to the process ports function. This way I can get the calling client's IP address from within the server functions by using "cIP: rugby-server/current-ip". Do you have any problems with me making this revision? You are welcome to use it in your distribution if you would like. Matt MacDonald

 [21/22] from: maarten:vrijheid at: 4-Nov-2003 17:52


I haven't got a problem with that. Send me your changes and I will include them. --Maarten

 [22/22] from: mattsmac:hotmai:l at: 4-Nov-2003 12:15


Here are the two changes, they are in the process-ports function and the hipe-serv object type I obviously have only tested these chages for my particular scenario process-ports: func [ {Processes all ports that have events.} portz [block!] {The port list} /local temp-obj ] [ repeat item portz [ either (is-server? item) [ either item/scheme = 'udp ;udp, so call our handler [ temp-obj: get-handler item temp-obj copy item ] [ init-conn-port item first item ] ] [ if item/scheme = 'tcp [ rugby-server/current-ip: item/remote-ip <------NEW temp-obj: select hipe-serv/object-q item temp-obj/lastaccess: now temp-obj/handler temp-obj ] ] ] hipe-serv: make object! [ ;Our list of server ports server-ports: copy [] ;Our server to handler mapping server-map: copy [] ; The list of ports we wait/all for in our main loop port-q: copy [] ; Mapping of ports to objects containg additional info object-q: copy [] ; Restricted server list restricted-server: make block! 20 ; Server restrictions? restrict: no ;The thread queue threads: copy [] current-thread: none conn-timeout: 0:0:30 current-ip: none <---------NEW max-thread-waiting: 100 Matt MacDonald

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted