Rugby Question
[1/22] from: mattsmac:h:otmail 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:hotma:il 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:hotm:ail 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:hotmai:l 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:ho:tmail 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:hot:mail 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:h:otmail 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:hot:mail 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::hotmail 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