<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Paul, Paul Millar a écrit : <blockquote cite="mid200704271839.57255.p.millar@physics.gla.ac.uk" type="cite"> <pre wrap="">Hi Mathieu, I'm a little confused by what you're saying, so my apologies if we're talking at cross-purposes. On Friday 27 April 2007 14:01, Mathieu Grzybek wrote: </pre> <blockquote type="cite"> <pre wrap="">Concerning communication between remote modules/plugins I found a problematic infrastructure: servers behind proxies. How can you communicate through a proxy server? </pre> </blockquote> <pre wrap=""> OK, I'm a bit confused about what the problem here is actually. You mention "remote modules/plugins". Are we talking about: a. NPRE (on a remote machine) and Nagios trying to communicate, or b. log2dno, file2sock or ndomod trying to communicate with ndo2db (or perhaps both)? I'm confused because you mention both NDOutils and NPRE below. </pre> </blockquote> In fact I thought of ndomod/ndoutils. I must have written too fast ! <blockquote cite="mid200704271839.57255.p.millar@physics.gla.ac.uk" type="cite"> <pre wrap="">I'm also confused why a proxy is the problem? >From what I understand, ndoutils' ndo2db listens on a TCP port (port 5668, by default) for incoming TCP connections. However, this is contengent on the remote server's being on a routable part of the network: it must be possible for IP packets from the Nagios server to traverse the network and end up on the remote server. I guess this could not happen for a number of reasons. The two that I can think of are: if the remote server has a private IP address and routed through a NAT box, if the remote server is behind a firewall that blocks port 5668. So, I'm guessing some firewall/NAT-box is the real issue here: that all external traffic is blocked. </pre> <blockquote type="cite"> <pre wrap="">To solve this problem I began to replace the socket-based communication process of NDOutils by gSOAP services (HTTP+XML). </pre> </blockquote> <pre wrap=""> So, the machine running ndo2db is behind a firewall, blocking all ports. The only communication with this machine is via a web-proxy. </pre> </blockquote> This is a company with a HQ and several independant sites. The monitoring database is hosted in the HQ. The servers running Nagios+ndomod in the other sites are behind a firewall and the only way to communicate with the world is a web proxy server. This case is very common. Everyone can't rent a wide intranet connection and/or a VPN. In most cases there is a website hosting by the HQ. No new port needed, just mod_soap and ndo2db. <blockquote cite="mid200704271839.57255.p.millar@physics.gla.ac.uk" type="cite"> <pre wrap="">Yes, using web-services is certainly one way to proceed. There are some other solutions that spring to mind: XML-RPC (a more light-weight solution, which gSOAP supports), embedding webserver (e.g. lighttpd) for a more RESTful approach, implement a proxy relay for NDOutils communication, get your sys-admin to allow the TCP connections you need. The last one isn't flippant. (If I've understood correctly) your real problem here is TCP connections not going through. Perhaps drifting slight off-topic (and perhaps a slightly contentious point-of-view), but web-services exist because of contention between sys-admins (trying to lock down access to a machine) and programmers (wanting to allow remote communication). If you allow someone to tell a remote machine to do something, that machine is potentially vulnerable. Now, practically the only ports you're pretty much guaranteed to have open is for web traffic (ports 80 and 443, maybe ports 8080 and 8443). So, to "bypass" the firewalls, RPC communication is now done via a web port. But, the underlying problem remains: allowing someone to tell a remote machine to "do something" results in a potential security vulnerability. And, of course, people have noticed this. See (for example) <a class="moz-txt-link-freetext" href="http://www.xmlhack.com/read.php?item=630&v=1&t=comment%3A623">http://www.xmlhack.com/read.php?item=630&v=1&t=comment%3A623</a> This has led to products to "protect" against this sort of problem: <a class="moz-txt-link-freetext" href="http://www.xtradyne.com/products/ws-dbc/ws-dbc.htm">http://www.xtradyne.com/products/ws-dbc/ws-dbc.htm</a> (this was just the first one Google found, I'm sure there's more out there). </pre> </blockquote> This problem is everywhere. Buffer overflows are dangerous for socket connections. Nothing is perfect. <blockquote cite="mid200704271839.57255.p.millar@physics.gla.ac.uk" type="cite"> <pre wrap=""> Using webservices will solve your problem now; but, if the firewalls are altered to block all SOAP messages, then you have no solution again :-( This is also true for other RPC-like communication (like XML-RPC). I must confess to not being very keen on SOAP. I've found its suffers from being fragile against WSDL updates and the message encapsulation is (to my mind) overly complex. If you do want to implement a webservice, I'd do it as a translation service rather than replacing the existing TCP communication. </pre> </blockquote> Do you mean encapsulating the actual protocol ? <blockquote cite="mid200704271839.57255.p.millar@physics.gla.ac.uk" type="cite"> <pre wrap=""></pre> <blockquote type="cite"> <pre wrap="">Moreover, using this process, NRPE could get its config file easily when a process between it and nagios is established. </pre> </blockquote> <pre wrap=""> True, but the same could be implemented through the existing communication. The protocol between Nagios and NRPE is quite primitive at the moment (i.e. quite robust! :-), but I guess it could be extended to include downloading configuration files. However, do you really want someone to be able to download a new config that defines the "check_pw" command as "cat /etc/passwd /etc/shadow" or a "check_rm" command as "rm -rf /"? </pre> </blockquote> NRPE can be run with limited privileges and use sudo for some event handlers. In large structures I think it's more convient than creating a new deployment process with OCS Inventory. <blockquote cite="mid200704271839.57255.p.millar@physics.gla.ac.uk" type="cite"> <pre wrap=""></pre> <blockquote type="cite"> <pre wrap="">What do you think of my idea ? </pre> </blockquote> <pre wrap=""> Sorry, I guess I don't fully understand what the problem is here. Ultimately, if you cannot access (via TCP) the machines and cannot alter this, why are you trying to monitor them? </pre> </blockquote> The IT boss doesn't want to control the servers but wants to know if it runs. <blockquote cite="mid200704271839.57255.p.millar@physics.gla.ac.uk" type="cite"> <pre wrap="">Cheers, Paul. </pre> </blockquote> Cheers, Mathieu </body> </html>