Changeset 079055f in nscp

Timestamp:

02/17/05 22:41:31 (8 years ago)

Author:

Michael Medin <michael@…>

Children:

5ba0a58

Parents:

5969055

Message:

Verified NSCLient compatiblity for many commands and some minor tweaks (now most NSClient commands are OK)

Location:

trunk

Files:

• NSClient++.cpp (modified) (1 diff)
• TCPSocketResponder.cpp (modified) (1 diff)
• include/NSCHelper.cpp (modified) (2 diffs)
• include/NSCHelper.h (modified) (1 diff)
• modules/NSClientCompat/NSClientCompat.cpp (modified) (2 diffs)
• modules/NSClientCompat/NSCommands.cpp (modified) (1 diff)
• modules/SysTray/TrayIcon.cpp (modified) (1 diff)
• readme.txt (modified) (2 diffs)

trunk/NSClient++.cpp

@@ -260 +260 @@
         LOG_ERROR("Return buffer to small, need to increase it in the ini file.");
       } else {                  // Something else went wrong...
-        LOG_ERROR("Unknown error from handleCommand");
+        LOG_ERROR_STD("Unknown error from handleCommand: " + strEx::itos(c));
       }
     } catch(const NSPluginException& e) {

trunk/TCPSocketResponder.cpp

@@ -104 +104 @@
     client=accept(server, (struct sockaddr*)&from,&fromlen);
     if (client != INVALID_SOCKET) {
-      LOG_ERROR_STD("Accept returned: " + strEx::itos((DWORD)client));
       char *buff = new char[RECV_BUFFER_LEN+1];
       int n=recv(client,buff,RECV_BUFFER_LEN,0);

trunk/include/NSCHelper.cpp

@@ -14 +14 @@
  * @return NSCAPI::success unless the buffer is to short then it will be NSCAPI::invalidBufferLen
  */
-int NSCHelper::wrapReturnString(char *buffer, unsigned int bufLen, std::string str) {
+int NSCHelper::wrapReturnString(char *buffer, unsigned int bufLen, std::string str, int defaultReturnCode /* = NSCAPI::success */) {
   if (str.length() > bufLen)
     return NSCAPI::invalidBufferLen;
   strncpy(buffer, str.c_str(), bufLen);
-  return NSCAPI::success;
+  return defaultReturnCode;
 }
 /**
@@ -288 +288 @@
   if (retStr.empty())
     return NSCAPI::isfalse;
-  return NSCHelper::wrapReturnString(returnBuffer, returnBufferLen, retStr);
+  return NSCHelper::wrapReturnString(returnBuffer, returnBufferLen, retStr, NSCAPI::handled);
 }
 /**

trunk/include/NSCHelper.h

@@ -7 +7 @@
 namespace NSCHelper
 {
-  int wrapReturnString(char *buffer, unsigned int bufLen, std::string str);
+  int wrapReturnString(char *buffer, unsigned int bufLen, std::string str, int defaultReturnCode = NSCAPI::success);
   std::list<std::string> makelist(const unsigned int argLen, char **argument);
   std::string translateMessageType(NSCAPI::messageTypes msgType);

trunk/modules/NSClientCompat/NSClientCompat.cpp

@@ -86 +86 @@
  * This also handles a lot of the simpler responses (though some are deferred to other helper functions)
  *
- #define REQ_CLIENTVERSION  1 // x
- #define REQ_CPULOAD    2 // x
- #define REQ_UPTIME     3 // x
- #define REQ_USEDDISKSPACE  4 // x
- #define REQ_SERVICESTATE 5 // x
- #define REQ_PROCSTATE    6 // x
- #define REQ_MEMUSE     7 // x
- //#define REQ_COUNTER    8 // ! - not implemented
- //#define REQ_FILEAGE    9 // ! - not implemented
- //#define REQ_INSTANCES  10  // ! - not implemented
+ #define REQ_CLIENTVERSION  1 // Works fine!
+ #define REQ_CPULOAD    2 // Quirks
+ - Needs settings for default buffer size (backlog) and possibly other things.
+ - Buffer needs to be synced with the client (don't know the size of that)
+ - I think the idea was that the buffer would recursive to make a smaller memory footprint.
+  (ie. the first level buffer have samples from every second, next level samples from every minute, next level hours etc...)
+  (and I don't know the status of this, doesn't seem to be that way)
+ #define REQ_UPTIME     3 // Works fine!
+ #define REQ_USEDDISKSPACE  4 // Works fine!
+ #define REQ_SERVICESTATE 5 // Works fine!
+ #define REQ_PROCSTATE    6 // Works fine!
+ #define REQ_MEMUSE     7 // Works fine!
+ //#define REQ_COUNTER    8 // ! - not implemented Have to look at this, if anyone has a sample let me know...
+ //#define REQ_FILEAGE    9 // ! - not implemented Dont know how to use
+ //#define REQ_INSTANCES  10  // ! - not implemented Dont know how to use
  *
  * @param command 
@@ -109 +114 @@
   switch (id) {
     case REQ_CLIENTVERSION:
-      return NSCModuleHelper::getApplicationName() + " " + NSCModuleHelper::getApplicationVersionString();
-    
+      {
+        std::string version = NSCModuleHelper::getSettingsString("nsclient compat", "version", "modern");
+        if (version == "modern")
+          return NSCModuleHelper::getApplicationName() + " " + NSCModuleHelper::getApplicationVersionString();
+        return version;
+      }
     case REQ_UPTIME:
       return strEx::itos(pdhCollector->getUptime());
 
     case REQ_CPULOAD:
-      stl_args = NSCHelper::makelist(argLen, args);
-      if (stl_args.empty())
-        return "ERROR: Missing argument exception.";
-      return strEx::itos(pdhCollector->getCPUAvrage(strEx::stoi(stl_args.front())*(60/CHECK_INTERVAL)));
-
+      {
+        stl_args = NSCHelper::makelist(argLen, args);
+        if (stl_args.empty())
+          return "ERROR: Missing argument exception.";
+        std::string ret;
+        while (!stl_args.empty()) {
+          std::string s = stl_args.front(); stl_args.pop_front();
+          int v = pdhCollector->getCPUAvrage(strEx::stoi(s)*(60/CHECK_INTERVAL));
+          if (v == -1)
+            return ret;
+          if (!ret.empty())
+            ret += "&";
+          ret += strEx::itos(v);
+        }
+        return ret;
+      }
     case REQ_SERVICESTATE:
       return NSCommands::serviceState(NSCHelper::makelist(argLen, args));

trunk/modules/NSClientCompat/NSCommands.cpp

@@ -82 +82 @@
         state = error;
       if (!ret.empty()) ret += " - ";
-      ret += exe + " : Stopped";
+      ret += exe + " : not running";
     } else if (showAll) {
       if (!ret.empty()) ret += " - ";

trunk/modules/SysTray/TrayIcon.cpp

@@ -43 +43 @@
   case WM_INITDIALOG:
     addIcon(hwndDlg);
-//    return TRUE;
     break;
 

trunk/readme.txt

@@ +1 @@
+** ROUGH DRAFT **
+** Spelling missate etc... :) **
+
+
 NSClient++ is a windows service that allows performance metrics to be gathered by Nagios 
 (and possibly other monitoring tools). It is an attempt to create a NSClient compatible 
@@ -4 +8 @@
 
 
+Installation:
+NSClient++ -install
+Will install the NT service
+
+NSClient++ -uninstall
+Will uninstall the service
+
+NSClient++ -start
+Will start the service
+
+NSClient++ -stop
+Will stop the service
+
+NSClient++ -test
+Will start in interactive mode:
+enter exit<return> to exit. ANything else will be interpreted as a command ie: foo&bar<enter> will be interpreted as a command name foo with argument bar.
+It also listens to the port in this mode so it can be used to run the client standalone.
+Notice output is *NOT* piped t othe stdard output unless you enable the console logger module.
 
 
+
+
+
+The API is quite simple:
+The following functions are available for a module to "export": (think DLL)
+
+NSLoadModule
+- Loading of modules (done when the service starts)
+NSGetModuleName
+- Used to get a nice name for the module.
+NSGetModuleVersion
+- Not really used but...
+NSHasCommandHandler
+- Let the "core" know it can handle commands (from nagios)
+NSHasMessageHandler
+- Used to let the "core" know it wants to see all log/debug/error messages that are generated.
+NSHandleMessage
+- Used to digest a log/debug/error message.
+NSHandleCommand
+- Used to (possibly) digest a command.
+When a command is "injected" then command is parsed and then sent along to all plugins (which accept commands) in order (they are listed in NSC.ini) and they are allowed to act on the command. If they do act on the command the "injection" is aborted and the resulting "return string" is returned to the "injecter" (normaly check_nt through a TCP stream. The ordering can thus be used to 1, optimize if things are slow (though I fail to see that unless someone makes some pretty f*cked up modules) and priority if one module overlaps the command of another (though then I would recommend someone to change the plugin command strings :)
+
+NSUnloadModule
+- Used to unload and terminate "stuff" nicely. (Generally this is when the service terminates)
+NSModuleHelperInit
+- Used to send along callbacks to the module (for making calls to the "core". (Ie. To allow the module to inject commands, get versions, names, and settings)
+
+So the API is quite simple and straight forward (I hope :)
+
+To make a simple call graph:
+
+* Service starts:
+* For each plugin
+        - call NSLoadModule
+        - call NSModuleHelperInit
+        - if NSHasCommandHandler
+                . Send to "command plugin" stack
+        - if NSHasMessageHandler
+                . Send to "message plugin" stack
+* Wait for socket data
+        - Parse socket data
+        - For each "command plugin"
+                . call NSHandleCommand
+                . if Command handled abort
+
+<termination signal sent to service>
+* For each plugin
+        - NSUnloadModule
+* Terminate service
+
+<Log/debug/error message generated in a module>
+* On incoming message:
+        - For each "message plugin"
+                . call NSHandleMessage
+
+There are a few more things to this but overall I have tried to keep things simple.
+
+The extensions (to the API) I'm considering as of now (depending on the fallout) is:
+* "SettingsHandler" to allow registry/INI/* settings modules. As the overhead of reg/ini settings system is quite low, perhaps this is overkill. But I don't know: thinking wildly there might be a reason for someone to want to load settings from a central server or whatever :)
+
+* "SocketHandlers" though this will not be a specific handler I have considered to refactor out the code and allow the socket handler (that reads the TCP socket and parses the command) to be a plugin when I do SSL as I assume SSL will come with quite a high overhead and thus I might not need it all the time.
+
+Also as mentioned this might be a good place to do a NRPE socket parser module to allow compatibility with NRPE. But this I assume is a bit in the future as I need to get "NSClient++" before I can get "NRPEClient++"...
+
+As for PassiveChecks that could be implemented as a plugin today as any plugin can inject commands into the "core". Thus a plugin can be loaded, have a background thread that every X minutes calls "core".injectCommand(); and sends the result over to nagios. (This is how I assume that passive checks work)
+
+
+
+
+// Michael Medin - michael <at> medin <dot> name - http://www.medin.name