After looking through the code, and then astutely reading the README, I saw the following:
If you are installing the server, you need to put in in inetd. A
+line like this one should cut the mustard:
nrpep stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nrpe
+p -c /usr/local/nagios/etc/nrpep.cfg
(All one line)
The "nrpep" part is an entry in /etc/services for the port that nr
+pep needs to run on. The "default" is 8086. I pulled it out of my a
+ss. If it conflicts with anything, let me know. Otherwise, that's t
+he default.
An example:
nrpep 8086/tcp
So, although I haven't done any socket programming using inetd, I'm going to make a big assumption that inetd is in fact handling the listening server socket and passing the info to what appears to be <STDIN> and <STDOUT> for the nrprep server.
In looking at the check_nrprep code, it does a use Socket; right near the start. The client opens a socket connection and goes out to the server that is already listening via inetd.
Hope that explains it (also hope I was right!)
| [reply]
[d/l] |
Thank you for pointing out the modification needed in inet.d. nrpep is coded to run as a service and I rather run it as a deamon for future deployment purpose. I switched the role of server and client in the original msg because I kept thinking nagios was the server and remote hosts were clients. But obviously, nrpep has this role reversed =). Thank you so much for your help
| [reply] |
The client has to communicate somehow ... but given that this is perl, it may not be as obvious as a direct call to socket(). It could be Net::Cmd, for example. There is a huge myriad of modules on CPAN that can do socket programming - and an even larger myriad which use those lower-level modules as a base for their own abstractions.
That said, a client will generally not need to listen to a socket (non-passive FTP being the only well-known exception I'm aware of). So if you had a client/server application where both sides were listening, that would be an anomoly in my experience.
My understanding of the definition of client/server, not being a computer major in university, is that a server listens for connections, while a client initiates them. A scenario where both sides are listening kinda confuses the issue - many peer networks do this (if we serve each other, then we must be peers!). So does middleware - software that sits between clients and servers. Middleware acts as a server for the clients (waits for clients to connect to it) while acting as a client for the final server. Or, perhaps, the next server, if there is more than one level of middleware. This is not necessarily proxying as middleware is often database-based applications such that you use an application client, talking to the application server, which itself is a database client talking to the database server. So, for each context, the middleware acts as either a client, or a server, but not both (although it likely acts as both for a given transaction).
Now that I've thrown out more comp sci terms than I know, I'll leave it to someone else to answer further questions you may have on this topic.
Note also that I've probably grossly simplified these terms, so please don't quote me if you're in comp sci and about to take your midterms.
| [reply] |