XML-RPC server via xinetd

[Jos Vos]

Hi,

I'm trying to figure out how to implement a XML-RPC server that
is called by xinetd i.s.o. listening on a TCP socket itself.

I already have implemented a stand-alone XML-RPC server using
SimpleXMLRPCServer, but I now want something similar, that is
started via xinetd (i.e. reading/writing via stdin/stdout).

Any hints or code examples?

Thanks,

--
-- Jos Vos <jo*@xos.nl>
-- X/OS Experts in Open Systems BV | Phone: [phone]
-- Amsterdam, The Netherlands | Fax: [phone]

[Martin P. Hellwig]

Jos Vos wrote:

Hi,

I'm trying to figure out how to implement a XML-RPC server that
is called by xinetd i.s.o. listening on a TCP socket itself.

I already have implemented a stand-alone XML-RPC server using
SimpleXMLRPCServer, but I now want something similar, that is
started via xinetd (i.e. reading/writing via stdin/stdout).

Any hints or code examples?

Thanks,

Isn't this just a standard daemon functionality?
So if you could wrap up your program in a daemon like fashion (e.g.
http://homepage.hispeed.ch/py430/python/daemon.py) and then point the
xinetd configuration to the right script, it should just work?

Beware that I didn't try this myself yet ;-) though should do in the
near future so if you could give a head ups on your progress I would
appreciate it.

--
mph

[Jos Vos]

On Sun, Apr 16, 2006 at 10:13:19PM +0200, Martin P. Hellwig wrote:

Isn't this just a standard daemon functionality?
What is "a standard daemon"? :-)
So if you could wrap up your program in a daemon like fashion (e.g.
http://homepage.hispeed.ch/py430/python/daemon.py) and then point the
xinetd configuration to the right script, it should just work?

In fact, the standard use *is* a daemon (that is, accepting connections
on a certain port) and I want it to be *not* a daemon. For the daemon
method I use something similar to "daemonize", but now I want it to
*not* do the binds etc. to listen on a port.

The problem is that the server initialization *requires* a server
address (host, port pair), but I don't see how to tell it to use
the stdin socket (and I'm afraid this is not possible, but I'm not
sure).

--
-- Jos Vos <jo*@xos.nl>
-- X/OS Experts in Open Systems BV | Phone: [phone]
-- Amsterdam, The Netherlands | Fax: [phone]

[Martin P. Hellwig]

Jos Vos wrote:
<cut>

The problem is that the server initialization *requires* a server
address (host, port pair), but I don't see how to tell it to use
the stdin socket (and I'm afraid this is not possible, but I'm not
sure).

If I understood it correctly you want the python server bind be
depending on whatever is configured in xinetd.conf and not be defined in
the your program itself?

I tested a bit around with my FreeBSD machine but indeed the OS
environment gives me nothing interesting back, leaving that option out
but I do can specify command line arguments so you could pick them up
with sys.argv.

I looked up how you can specify arguments in xinetd and according to
various resources I filtered out (gotta over these gnu type
documentation...) that you can use "server_args" in the per service
configuration to specify arguments.

Although not really elegant it is doable to do an on the fly port binding.

Now I just hope I understood your problem :-)

--
mph

[Nick Craig-Wood]

Jos Vos <jo*@xos.nl> wrote:

I'm trying to figure out how to implement a XML-RPC server that
is called by xinetd i.s.o. listening on a TCP socket itself.

I already have implemented a stand-alone XML-RPC server using
SimpleXMLRPCServer, but I now want something similar, that is
started via xinetd (i.e. reading/writing via stdin/stdout).

Any hints or code examples?

UTSL ;-)

Look at /usr/lib/python2.4/SimpleXMLRPCServer.py (adjust as per your
distro) and in particular the definition of the CGIXMLRPCRequestHandler class.

That looks as thought it almost, or maybe completely, does what you
want, ie an XMLRPC subclass which reads from stdin and writes to
stdout.

--
Nick Craig-Wood <ni**@craig-wood.com> -- http://www.craig-wood.com/nick

[Jos Vos]

On Mon, Apr 17, 2006 at 02:07:37AM +0200, Martin P. Hellwig wrote:

If I understood it correctly you want the python server bind be
depending on whatever is configured in xinetd.conf and not be defined in
the your program itself?

I tested a bit around with my FreeBSD machine but indeed the OS
environment gives me nothing interesting back, leaving that option out
but I do can specify command line arguments so you could pick them up
with sys.argv.

I looked up how you can specify arguments in xinetd and according to
various resources I filtered out (gotta over these gnu type
documentation...) that you can use "server_args" in the per service
configuration to specify arguments.

Although not really elegant it is doable to do an on the fly port binding.

Now I just hope I understood your problem :-)

No, you didn't :-). I could add these options or even write an
xinetd-only program, that's all fine with me.

The problem is that I do not see how to let an SimpleXMLRPCServer
instance *not* bind to a port or what other class I can use to just
build a XML-RPC request handler reading/writing from stdin/stdout,
i.s.o. carrying all the server class stuff with it.

--
-- Jos Vos <jo*@xos.nl>
-- X/OS Experts in Open Systems BV | Phone: [phone]
-- Amsterdam, The Netherlands | Fax: [phone]

[Brian Quinlan]

Jos Vos wrote:

The problem is that I do not see how to let an SimpleXMLRPCServer
instance *not* bind to a port or what other class I can use to just
build a XML-RPC request handler reading/writing from stdin/stdout,
i.s.o. carrying all the server class stuff with it.

I think that the problem here is that we are confusing transport with
request handling.

If you take a look at CGIXMLRPCRequestHandler
(http://docs.python.org/lib/node564.html), you will see an example of
how to write an XMLRPCRequestHandler without HTTP.

Cheers,
Brian

[Jos Vos]

On Mon, Apr 17, 2006 at 12:10:15PM +0200, Brian Quinlan wrote:

If you take a look at CGIXMLRPCRequestHandler
(http://docs.python.org/lib/node564.html), you will see an example of
how to write an XMLRPCRequestHandler without HTTP.

Thanks, this might work for me, will try it.

--
-- Jos Vos <jo*@xos.nl>
-- X/OS Experts in Open Systems BV | Phone: [phone]
-- Amsterdam, The Netherlands | Fax: [phone]

[Jos Vos]

On Mon, Apr 17, 2006 at 03:30:04AM -0500, Nick Craig-Wood wrote:

UTSL ;-)

Look at /usr/lib/python2.4/SimpleXMLRPCServer.py (adjust as per your
distro) and in particular the definition of the CGIXMLRPCRequestHandler class.
I did this before posting my question, in fact, but I did not look
good enough maybe, as at first sight I thought tghe CGI... class
would be too CGI-specific (it looks for environment variables etc.
given by the HTTP server), but maybe it's good enough.
That looks as thought it almost, or maybe completely, does what you
want, ie an XMLRPC subclass which reads from stdin and writes to
stdout.

Will try...

--
-- Jos Vos <jo*@xos.nl>
-- X/OS Experts in Open Systems BV | Phone: [phone]
-- Amsterdam, The Netherlands | Fax: [phone]

[Brian Quinlan]

Jos Vos wrote:

On Mon, Apr 17, 2006 at 03:30:04AM -0500, Nick Craig-Wood wrote:

UTSL ;-)

Look at /usr/lib/python2.4/SimpleXMLRPCServer.py (adjust as per your
distro) and in particular the definition of the CGIXMLRPCRequestHandler class.

I did this before posting my question, in fact, but I did not look
good enough maybe, as at first sight I thought tghe CGI... class
would be too CGI-specific (it looks for environment variables etc.
given by the HTTP server), but maybe it's good enough.

I don't know exactly what your usage pattern is, but you might be able
to use SimpleXMLRPCDispatcher directly e.g.

s = SimpleXMLRPCDispatcher()
s.register_function(pow)
s._marshaled_dispatch('<?xml version="1.0"...)

'<?xml version="1.0"...

Cheers,
Brian

[Fredrik Lundh]

Nick Craig-Wood wrote:

Look at /usr/lib/python2.4/SimpleXMLRPCServer.py (adjust as per your
distro) and in particular the definition of the CGIXMLRPCRequestHandler class.

That looks as thought it almost, or maybe completely, does what you
want, ie an XMLRPC subclass which reads from stdin and writes to
stdout.

except that if the OP's expecting the other end to use an ordinary XML-RPC
library, he needs to implement some minimal HTTP handling as well.

import sys
import mimetools, xmlrpclib

command = sys.stdin.readline()
# optional: check command syntax (POST url HTTP/1.X)

headers = mimetools.Message(sys.stdin)
# optional: check content-type etc

bytes = int(headers.get("content-length", 0))
# optional: check request size, etc

params, method = xmlrpclib.loads(sys.stdin.read(bytes))

# handle the method
result = ...

# marshaller expects a tuple
result = (result, )

response = xmlrpclib.dumps(result, methodresponse=1)

print "HTTP/1.0 200 OK"
print "Content-Type: text/xml"
print "Content-Length:", len(response)
print
print response

(based on code from http://effbot.org/zone/xmlrpc-cgi.htm )

</F>

[Jos Vos]

On Mon, Apr 17, 2006 at 12:36:18PM +0200, Brian Quinlan wrote:

I don't know exactly what your usage pattern is, but you might be able
to use SimpleXMLRPCDispatcher directly e.g.

>>> s = SimpleXMLRPCDispatcher()
>>> s.register_function(pow)
>>> s._marshaled_dispatch('<?xml version="1.0"...)

'<?xml version="1.0"...

Will look at that too, but as I want to be able to use the same XML-RPC
client as I talk to with my SimpleXMLRPCServer (thus talking HTTP), I
think I need to CGI sugar.

Note that the main reason I'm looking to the "xinetd way" is that
I want to use proper SSL-based traffic and the SecureXMLRPCServer
flying around, using pyOpenSSL (or so), does not do a complete job
(because pyOpenSSL does not do a complete job IIRC) and needs to
be tweaked anyway, so I now hope to use stunnel.

--
-- Jos Vos <jo*@xos.nl>
-- X/OS Experts in Open Systems BV | Phone: [phone]
-- Amsterdam, The Netherlands | Fax: [phone]

[Jos Vos]

On Mon, Apr 17, 2006 at 12:42:00PM +0200, Fredrik Lundh wrote:

except that if the OP's expecting the other end to use an ordinary XML-RPC
library, he needs to implement some minimal HTTP handling as well.

Which makes me wondering why the classes (this also applies to
BaseHTTPServer / BaseHTTPRequestHandler) ae designed the way they
are. The underlying stream medium (TCP sockets or plain file
streams like stdin/stdout) should not be integrated with the
protocol (HTTP) handling, IMHO...

--
-- Jos Vos <jo*@xos.nl>
-- X/OS Experts in Open Systems BV | Phone: [phone]
-- Amsterdam, The Netherlands | Fax: [phone]