setting XML value using xmlrpc & python

Question

Hi , I need to set the value of a field in an XML file which exists on a remote Linux box. How do I find out which port I should connect to ? But even a proper ping is not happening:

import xmlrpclib
server = xmlrpclib.ServerProxy('http://10.77.21.240:9000')
print server.ping()
print "I'm  in hurray"

bUT instead I got:

Traceback (most recent call last):
  File "ping.py", line 3, in <module>
    print server.ping()
  File "C:\Python26\lib\xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "C:\Python26\lib\xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "C:\Python26\lib\xmlrpclib.py", line 1235, in request
    self.send_content(h, request_body)
  File "C:\Python26\lib\xmlrpclib.py", line 1349, in send_content
    connection.endheaders()
  File "C:\Python26\lib\httplib.py", line 892, in endheaders
    self._send_output()
  File "C:\Python26\lib\httplib.py", line 764, in _send_output
    self.send(msg)
  File "C:\Python26\lib\httplib.py", line 723, in send
    self.connect()
  File "C:\Python26\lib\httplib.py", line 704, in connect
    self.timeout)
  File "C:\Python26\lib\socket.py", line 514, in create_connection
    raise error, msg
socket.error: [Errno 10061] No connection could be made because the target machine actively refused it.

What did I do wrong?

Answer 1

A couple of things to try / think about:

1. Go to a command prompt on the remote host and type "netstat -nap | grep 9000". If you don't get back something interesting it means that nothing is running at port 9000.

2. You show the remote host at 10.77.21.240. This is an unroutable address on the net (AKA Private Network), so is the server itself (not just your app) pingable? If you are on windows, goto Start -> Run and type "cmd". At the prompt type, "ping 10.77.21.240" and see what you get.

3. One more thought: the process may be up and running at 9000 on a reachable host, but it may have opened the port as 127.0.0.1:9000 instead of 0.0.0.0:9000. The first address will only be reachable by processes on the same machine, the second one will open the port on all available IP addresses the machine has.

Update in response to comment: The fact that it shouldn't be a problem doesn't eliminate the possibility it is. When you are debugging something that should be working, but isn't, you need to get fairly pedantic about checking each step, allowing yourself no room for 'Oh, I know that couldn't be the problem.' -- this is a verbal 'handwave' (often accompanied by a real handwave). You'd be surprised how often the problem exists in exactly the area you are handwaving! It takes 3 seconds to do the ping test. If it works, you move on, if it doesn't work ...

The first three steps in dealing with any system problem are:

1. Is it plugged in?
2. Is it turned on?
3. Is it configured properly?

And you have to do this for each and every piece of hardware/software in the food chain from your keyboard to the app. I'd guess 80% of 'sudden' failures are items 1 or 2 -- yes, really. Cables are a huge pain in the ass.

When on the phone with novices I normally start by going for the long pass -- if they can get news.google.com in a browser and then click on a random story, then I know that in general the network is OK. Why the news and why a random story? To sidestep browser cache issues. I've lost count of the number of times my older sister has called me up and announced "The Internet is broken!" The first thing we do is the google news test. 99% of the time it works, so I have her fire up reverse-WinVNC (UltraVNC's SingleClick is a God-send), I get on her machine, and then we see what the real problem is.

If the long pass doesn't work, then I see if they can get to their router. Etc. etc.