[Xymon] Question on filesystem line processing for Windows in do_disk.c for UNC resources

[Malcolm Hunter]

Hi Mark,

> ----- Original Message -----
> From: Deiss, Mark
> Sent: 04/12/12 02:25 PM
> To: xymon at xymon.com
> Subject: [Xymon] Question on filesystem line processing for Windows in do_disk.c for UNC resources
> 
> I am not sure about how BBWIN is reporting its Windows client metrics;
> MrBig for Windows reports file system usage in the following format:
> 
> 
> Filesystem 1k-blocks Used Avail Capacity Mounted
> C 15727603 8740006 6987597 55.6% /FIXED/C
> D 277225672 6502600 270723072 2.3% /FIXED/D
> 
> 
> Limits:
> Drive Yellow Red 
> D 70.0 80.0 
> C 70.0 80.0 
> Default 90.0 95.0 
> 
> We have some clustered Windows 2008 servers that are using shared
> resources that are only referenced by their UNC paths - they do not have
> logical drive assignments. Was wondering whether this would cause any
> issues with the processing in do_disk.c section:
> 
> 
> /* 
> * Some Unix filesystem reports contain the word
> "Filesystem".
> * So check if there's a slash in the NT filesystem
> letter - if yes,
> * then it's really a Unix system after all.
> */
> if ( (dsystype == DT_NT) && (*(columns[5])) &&
> (strchr(columns[0], '/')) )
> dsystype = DT_UNIX;
> 
> 
> Where the columns[5] would be referring to the "Mounted" column in the
> MrBig output, and columns[0] would be referring to the Filesystem
> column. The above logic is not being performed as a block step against
> the overall client's disk output but rather on a line by line basis of
> the disk output. The first occurrence matched will flip the subsequent
> data processing flow from Windows based to Unix based even for
> subsequent disk lines from the same client. 
> 
> My question is whether the presence of UNC only mounts would be
> represented with backslashes (\) with the BBWIN/MrBig/whatever Windows
> reporting modules or whether they may end up converted to forward
> slashes (/) and thus falsely trigger the dsystype switch. The only
> affect on the subsequent processing is whether the Filesystem column
> (Windows OS) is used for storing the diskname (and generation of the rrd
> file name) or the "Mounted on" column is used for the diskname (Unix
> OS).
> If the UNC representation can cause this false flip, then
> initial Windows disk lines that are using logical drive assignments
> would be stored and referenced using the one column reference and once a
> UNC line is encountered, then it and all subsequent lines (including
> logical drive assignment lines) would be using the other column
> reference convention.
> Things could get busy if the line order varies from time to time
> (i.e. addition/removal of a UNC resource); then a logical drive time
> stamped data line may go in at times as a "Filesystem" rrd file, other
> times as a "Mounted on" rrd file. 
> 
> setupfn2("%s%s.rrd", testname, diskname);
> 
> As I don't yet have any clients installed in these clustered Windows
> boxes or UNC only mounts on other boxes, I don't know what the "Mounted
> on" column output would look like for the UNC resource. If
> BBWIN/MrBig/whatever are not reporting on UNC resources then that's
> going to be an (separate) issue for us too. 
> 
> Possible fix if this is an issue:
> 
> Was wondering if all the Windows clients (BBWIN/MrBig/whatever) all
> reliable report the last column with the "Mounted" header tag and
> whether all the Unix/Linux/BSD variants report their last column with
> the "Mounted on" header tag. If so then maybe a better way to handle
> this is to run a check against the overall client disk msg block for the
> string pattern of "Mounted on" instead. Change do_disk.c section:
> 
> else if (strstr(msg, "Filesystem")) dsystype = DT_NT;
> else dsystype = DT_UNIX;
> 
> to
> 
> else if (strstr(msg, "Filesystem")) dsystype = DT_NT; /* This
> will trigger for Windows and Unix/Linux flavors */
> else if (strstr(msg, "Mounted on")) dsystype = DT_UNIX; /* Assuming all
> unix/linux/BSD clients report with "Mounted on" and Windows clients only
> report with "Mounted" in their header line */

See this update in Subversion trunk: http://xymon.svn.sourceforge.net/viewvc/xymon?view=revision&revision=6708

Malcolm
--
BBWin Development - The Windows client for Big Brother and Xymon

http://bbwin.sourceforge.net
http://xymon.sourceforge.net