Re: Pyro issues with remote operation, binding IP addresses

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hello Jason

On 19-11-2012 20:19, Jason Beyers wrote:
> _Here's my problem:_
> 
> It seems that the host/ip specified for the client needs to exactly match the
> host/ip given to the nameserver and pyro daemons, even if other hostnames resolve
> to the same (public) ip address.  For example:
> 
> nameserver/pyro daemons run on myhost.mydomain.net, and the remote client looks
> for myhost.mydomain.net.  The client can only connect to myhost.mydomain.net, and
> the nameserver/pyro daemons can see/ping only myhost (not the full
> myhost.mydomain.net).
> 
> If the nameserver/pyro daemons try to bind to myhost.mydomain.net, the nameserver
> throws an exception stating "Failed to bind address", since I assume it is trying
> to bind to a public IP address that it doesn't control.  If the nameserver/pyro
> daemons bind just to myhost, and the client looks for myhost.mydomain.net, the
> client throws an exception stating "Temporary name resolution failure" without
> additional details.   In the latter case, the nameserver/pyro daemons are binding
> to something that resolves to the same public IP that the client is looking for -
> verified with nslookup - yet they still can't connect.  I can't tell if this is
> expected behavior.
> 
> Other server daemons like sshd or the Grinder's console process for example seem to
> bind to every valid ip address of the host system, making it easy for clients to
> connect (not picky).  However, the Pyro nameserver and/or pyro daemon(s) seem to be
> picky about what address clients use and I'm not sure how to get around it.
> Searching on google for these exceptions hasn't produced much.


It seems like you're suffering from the issue described here:
http://packages.python.org/Pyro4/tipstricks.html#multiple-network-interfaces

Unfortunately, there's currently no support for this, unless the 0.0.0.0 trick that is
mentioned there works for your setup.


> What I'm hoping to find is a way to run nameserver/pyro daemons on a "server"
> machine such that they can respond to any TCP connections on the proper nameserver
> and pyro daemon ports regardless of how the client is accessing them - private IP,
> public IP, public DNS, etc.  If these daemons can bind to the server machine's
> addresses this way, I could just provide socket.gethostname() in code or another
> valid way to identify itself, and the clients could connect with whatever host/ip
> that works for them - they wouldn't need to match, as long as they're valid.  SSH
> and the Grinder already behave like this, so how can I get Pyro to do it too?


Well, to be honest, I am not entirely sure what SSH and the Grinder actually do. Also
I feel that binding on all available interfaces is not the smartest thing to do by
default: it might have security implications for instance.

I'm open for suggestions about how to approach the multi-interface issue in Pyro4.
This issue doesn't have high priority on my list though, so it would really help if
someone else thinks up a possible solution and implementation ;-)


Regards,

Irmen de Jong.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Cygwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQqr6BAAoJEHC9o7RHFlf2W/oH/1Q5w45ycPHZ9sZkp/7W3lIm
yi49h8Ece+qA6UC+PXGW0azTGok6dvosA8foqNcznVvu78609q4vN+luzl+Sap2f
JSImOPDuLXekSkw109PAZ84UBJaGEZCMsVG5JQyCQ+SEiz6mEWjTIYtDlPb0oPML
TR8ND3zo+ooAYWXkGkORu4bNtFDtsDV7llu7TOEbIAit+EqZTayXLmoAtrvs50WA
QOzDoRC4pIARUt5nXUGeFhAwuJwJ6UxwF/CqZNGm5913uaOEm8V33uE1DhWCdk62
lYcOBpicaHzzxEZDyFByfC6HMnaWuKLN2wh+7H4i7UkyWFwBy4Zpdz5eY8kiUdc=
=FCG0
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov