- Xymon - Xymon mailman web

canceling acknowledgements
by lebarber＠gmail.com 12 Mar '14

12 Mar '14

Is there some way to cancel an 'ack' after it has been issued? Thanks, Larry Barber

4 5

Can't clear ghost clients
by kspringer＠innovateteam.com 12 Mar '14

12 Mar '14

I've got 6 ghost clients listed on my server webpage. I have a clean hosts.cfg file that definitely does not contain any of the names in the ghost list. The ghost names are from many months ago when I first setup the server. I've since change the names. I've attempted to clear the ghosts using the following commands but it doesn't clear anything. Buzzard is one of the hostnames in question. #cd /usr/lib/xymon/server/bin #xymon 127.0.0.1 "drop Buzzard" Anyone have a clue as to how to clear old ghosts and/or where to find the pesky files that are causing it? Thank you. ------------------------------------------------ Kris Springer

5 6

Support for ZFS?
by novosirj＠ca.rutgers.edu 12 Mar '14

12 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/11/2014 08:19 PM, Mark Felder wrote: > On Mar 11, 2014, at 18:49, Novosielski, Ryan > <novosirj at ca.rutgers.edu> wrote: > >> Didn't you see the other e-mail? Scott Brian says it does. > > Whoops, my apologies. It does seem to graph it strangely on > FreeBSD; I wasn't aware this was expected behavior. I was hoping > it would do a better job of being able to determine the true amount > of free space. None needed; I'm curious, is it handled differently on FreeBSD than Solaris? Solaris shows the total field for all of the FS in the same pool as the same value. So for example, pool1/fs1, pool1/fs2, etc. all have the same "total" space and the usage is a percentage of that total space. A different pool would have a different same value for the total size. You can change that, though, by assigning ZFS quotas; it sets a size cap for an FS, so the usage will be a percent of the capped size. - -- ____*Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Sr. Systems Programmer || \\ and Health | novosirj at rutgers.edu - 973/972.0922 (2x0922) || \\ Sciences | OIT/EI-Academic Svcs. - ADMC 450, Newark `' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMfu1wACgkQmb+gadEcsb78ogCfcLg4f5VTPlCyQn0QQvOe8z1F Nm8Anj7fQp83+XzodWIt2ftfOqUdUuL4 =Zv19 -----END PGP SIGNATURE-----

1 0

alert scripting
by KVerMeer＠peoplenetonline.com 11 Mar '14

11 Mar '14

In our hosts.cfg file, we include a NAME setting to standardize a naming convention for the several xymon clients. In creating alert scripts, I would like to display this name, rather than the clients hostname. Is this possible, without manually grepping through the hosts.cfg file? It appears that BBHOSTNAME displays the hostname rather than the value set by name. Suggestions appreciated.

2 2

XYmon in a DMZ
by linuxmasterjedi＠free.fr 11 Mar '14

11 Mar '14

Hi, Can someone explain me if I could do this with XYmon ! 1) DMZ hosts send all data to a "local DMZ xymon" 2) XYmon global server fetch all data from this "local DMZ xymon" I bet I have to use "xymonproxy", but I read and re-read the documentation, it's very cristal clear for me. Can someone explain to the big picture please ? Also, I have hosts in a remote site, I installed a Xymon server there. Remote hosts report to this remote XYmon server. For a few hosts, I add an extra IP to XYMSERVERS and it sends also data to my XYmon global server Is it the best to do it ? Like the previous questin, can the XYmon global server fetch data from the remote Xymon server. With my choice : 1 global xymon, 1 on each remote location, I have to watch a couple of the XYmon pages, I don't have an global overview... How do you guys do ? Any Xymon architecture advices is welcome ! Thanks -- LMJ "May the source be with you my young padawan"

4 3

Critical systems
by majones＠mnsi.net 10 Mar '14

10 Mar '14

Due to the amount of systems I wanted to add to the critical systems file I did it via a script. For example I added this line. accesscontrol.wndson17.mnsi.net|conn||||3|anyone|call|mjones 2014-02-10 09:11:14 Once I then updated an entry via the web interface the entry became the following accesscontrol.wndson17.mnsi.net|conn|1||||2|anyone|call now|mjones 2014-03-07 09:42:22 accesscontrol.wndson17.mnsi.net|conn|2||||3|anyone|call|mjones 2014-02-10 09:11:14 accesscontrol.wndson17.mnsi.net|conn|3||||3|anyone|call|mjones 2014-02-10 09:11:14 accesscontrol.wndson17.mnsi.net|conn|4||||3|anyone|call|mjones 2014-02-10 09:11:14 accesscontrol.wndson17.mnsi.net|conn|5||||3|anyone|call|mjones 2014-02-10 09:11:14 Any ideas what might be wrong? Mark Jones

2 2

Question about client-local.cfg
by colin.coe＠gmail.com 10 Mar '14

10 Mar '14

On Mon, Mar 10, 2014 at 6:38 AM, Colin Coe <colin.coe at gmail.com> wrote: > Hi all > > Server info: > Host - RHEL6.5 > Version - 4.3.17 > Packaged by J Cleaver (Terabithia) > > I'm having a problem with a definition in /etc/xymon/client-local.cfg. > --- > [host=dmz_ap01] > file:`ls -ltr /home/enmac/customer-data/CUST9100REP*CSV | tail -n 1` > --- > The problem is that Xymon reports bad (red) with the page showing > --- > -rw-r--r-- 1 username groupname14314345 Mar 10 2014 > /home/username/customer-data/CUST9100REP20140310002349.CSV > File is missing > --- > Now, the file is not missing, and Xymon is correctly showing its mode, > size, ownership details, etc. > Any ideas what I've done wrong here? > > Thanks > > CC > Apologies all, subject now supplied... -- RHCE#805007969328369

5 6

BBwin 0.13 and Mountpoints
by rower.master＠gmail.com 10 Mar '14

10 Mar '14

Hi All, I´m trying to fix the issue with the graphs creation for windows mountpoints and bbwin 0.13. The issue is that we only have graphs for the single drive letters and not for the mountpoints using the bbwin 0.13. Another problem is even if the graphs were working we could not have duplicated names for different drive letters. Filesystem 1K-blocks Used Avail Capacity Total Size Free Space Type Status Mount Point C 62811132 49966236 12844896 79% 59.90 GB 12.25 GB FIXED green N/A D 116043772 1100880 114942892 0% 110.67 GB 109.62 GB FIXED green N/A E 943848444 533077788 410770656 56% 900.12 GB 391.74 GB FIXED green N/A F 943848444 495800916 448047528 52% 900.12 GB 427.29 GB FIXED green N/A J 20970492 14764648 6205844 70% 20.00 GB 5.92 GB FIXED green N/A DadosLocal_Diversos_A 1237451772 928809832 308641940 75% 1.15 TB 294.34 GB FIXED green J:\DadosLocal_Diversos_A\ DadosLocal_Diversos_B 1782825980 1216555488 566270492 68% 1.66 TB 540.04 GB FIXED green J:\DadosLocal_Diversos_B\ Tempdb 104869884 54526796 50343088 51% 100.01 GB 48.01 GB FIXED green J:\Tempdb\ Log_Local 199235580 135337320 63898260 67% 190.01 GB 60.94 GB FIXED green J:\Log_Local\ I´ve already modified the winPSclient to consider the mountpoints and If I use this client I have all the graphs created without any problem. But I don´t want to continue changing or adding a server agent everytime a server administrator configure a mountpoint in a server. WinPSCLient output example where I have all graphs created: Mon 06 Jan 16:44:55 2014 - Filesystems OK Filesystem 1K-blocks Used Avail Capacity Mounted Summary(Total\Avail GB) C 52377596 39455096 12922500 75% /FIXED/C 49.95gb\12.32gb D 90254332 82510624 7743708 91% /FIXED/D 86.07gb\7.38gb F 10482684 91992 10390692 1% /FIXED/F 10.00gb\9.91gb F:\ORAARCHIVE 10482684 85608 10397076 1% /FIXED/F:\ORAARCHIVE 10.00gb\9.92gb F:\ORABACKUP01 10482684 1638116 8844568 16% /FIXED/F:\ORABACKUP01 10.00gb\8.43gb F:\ORADATA01 41939964 31552684 10387280 75% /FIXED/F:\ORADATA01 40.00gb\9.91gb I 10482684 84468 10398216 1% /FIXED/I 10.00gb\9.92gb I:\ORAARCHIVE 5239804 54772 5185032 1% /FIXED/I:\ORAARCHIVE 5.00gb\4.94gb I:\ORABACKUP01 52425724 93492 52332232 0% /FIXED/I:\ORABACKUP01 50.00gb\49.91gb I:\ORADATA01 209712124 98292 209613832 0% /FIXED/I:\ORADATA01 200.00gb\199.90gb J 10482684 96676 10386008 1% /FIXED/J 10.00gb\9.90gb J:\OraArchive 5239804 125628 5114176 2% /FIXED/J:\OraArchive 5.00gb\4.88gb J:\ORADATA01 207614972 136793092 70821880 66% /FIXED/J:\ORADATA01 198.00gb\67.54gb J:\ORATEMP 41939964 33645564 8294400 80% /FIXED/J:\ORATEMP 40.00gb\7.91gb I´ve tried some modifications on do_disk.c but without sucess. I´ve created a new dsystype called DT_MOUNTPOINT: *else if (strstr(msg, "Mount Point")) dsystype = DT_MOUNTPOINT;... if ( (dsystype == DT_MOUNTPOINT) && (*(columns[9])) && (strchr(columns[11], '/')) ) dsystype = DT_MOUNTPOINT;if ( (dsystype == DT_MOUNTPOINT) && (*(columns[9])) && (strchr(columns[11], ':')) ) dsystype = DT_MOUNTPOINT;* And here at the "case DT_MOUNTPOINT" is where the things are not good. I´ve tried to get the the column[11] but unfortunately we have backslashes. I´ve tried several ways, but I´m not good in c as I would like to and after many many tests I´m asking for a help or if you can put this on Xymon todo list. I´m using xymon 4.3.0-beta2 , sorry if this was already solved in the last version. I´ve checked the do_disk.c file on the last stable but couldn´t see this solution. *case DT_MOUNTPOINT: diskname = xstrdup(columns[11]); if (strstr(diskname, "N/A")) { diskname = xstrdup(columns[0]); } else { diskname = xstrdup(columns[11]); } /*sprintf(diskname, "/%s", columns[11]);*/ p = strchr(columns[4], '%'); if (p) *p = ' '; pused = atoi(columns[4]); aused = str2ll(columns[2], NULL); break;* I´ve tried to use the diskname as columns[0] but doesn´t work for the mountpoints too. The case DT_BBWin format that works for the winPSclient doesn´t work if I use the diskname as columns[0] or columns[11]. case DT_BBWIN: *diskname = xmalloc(strlen(columns[0])+2); sprintf(diskname, "/%s", columns[0]);* Thanks in advance, Mario

3 4

[xymon] canceling acknowledgements
by novosirj＠rutgers.edu 10 Mar '14

10 Mar '14

I'm a little confused about some of this. For one, I don't ack servers for maintenance, I disable the affected tests. You can cancel a disable anytime you want. Also, since you acknowledge individual services, why would acknowledging one of them prevent you getting alerts on others. Do you mean, perhaps, alerts like on the "ports" test where failures can occur in different ways? On 03/10/2014 10:51 AM, john.r.rothlisberger at accenture.com wrote: > Oh, this is so old… > > > > There is a simple answer (IMO) as to why you would want to cancel and > ack’d alert – a new alert for an ack’d test has been received. > > > > This has been bugging me for years. Let’s assume you ack an alert for > the service “W3SVC” for 4 hours for maintenance, which you have stopped > on purpose for whatever reason. Let’s assume you also monitor services > for SQL, Java, etc. If one of those also fails during the 4 hours of > ack time – you won’t get an alert. There are 3 tests that can have > multiple components which I would like to know if new alerts arrive > while a test has been ack’d: disk, procs, & svcs. > > > > I have a situation currently where I have to address this exact > scenario. As described I have multiple services and processes that I > need to monitor, those are often ack’d but it doesn’t change the > importance of knowing if a different process/service needs attention. > Thus, I have written the perl script below which (being just written and > may not be 100% - YMMV) will monitor tests that have been ack’d and look > for changes. If there is a change that needs to be addressed the ack is > canceled by sending a temporary green status to the host.test. The next > update from the client triggers a new alert. > > > > Maybe this will help someone else too… > > > > Steps: > > Copy contents to ~bin/watch_ackd_alerts.pl > > Create directory ~server/tmp/ACKS > > Log file created in ~logs > > Create the following crontab entry > > */5 * * * * /home/xymon/bin/watch_ackd_alerts.pl > /dev/null 2>&1 > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > #!/usr/bin/perl > > # > ------------------------------------------------------------------------------------------------ > > # Script Name: watch_ackd_alerts.pl > > # Author: John Rothlisberger > > # Created On: March 10, 2014 > > # VERSION="1.03102014.09"; > > # > ------------------------------------------------------------------------------------------------ > > # Purpose: A script to monitor ack'd alerts and watch for changes. > > # Example: The C: drive fills up and sends out a red > alert. Knowing this will > > # take some time to fix you ack the alert for 60 minutes. > If, during that 60 > > # minute window the D: drive fills up you will not be > notified as the 'disk' test > > # has been acknowledged. This script is an attempt to > short circuit the ack and > > # allow for the new alert to be sent out. > > # > ------------------------------------------------------------------------------------------------ > > # Execution: Run every 5 minutes from xymon crontab: > > # */5 * * * * /home/xymon/bin/watch_ackd_alerts.pl > /dev/null 2>&1 > > # > ------------------------------------------------------------------------------------------------ > > > > # Setup COUNT and directory where to store ack info files. > > $COUNT=0; > > $ACKSDIR="/home/xymon/server/tmp/ACKS"; > > > > # Log file > > open(LOGFILE,">> /home/xymon/logs/ack_terminate.log") || die("can't open > port_watch.email: $!"); > > > > # input file example > > # > servername|test|color|flags|lastchange|logtime|validtime|acktime|disabletime|sender|cookie|line1|ackmsg|dismsg|msg > > > > # Open input file > > open ALERTS, "/home/xymon/server/bin/xymon 0 'xymondboard > color=yellow,red' |" or die "Couldn't execute: $!"; > > > > # Parse all active alerts > > while (<ALERTS>) { > > chomp; > > @LINE=split(/\|/,$_); > > $SERVERNAME=@LINE[0]; > > $TESTTYPE=@LINE[1]; > > $COLOR=@LINE[2]; > > $ACKTIME=@LINE[7]; > > $COOKIE=@LINE[10]; > > $LINE1=@LINE[11]; > > $ACKMSG=@LINE[12]; > > $DISMSG=@LINE[13]; > > $MSG=@LINE[14]; > > # Skip all alerts except disk, procs, and svcs (others are not tested) > > next if ((! $TESTTYPE == "disk") || (! $TESTTYPE == "procs") || (! > $TESTTYPE == "svcs")); > > > > # If the alert has been ack'd we want to watch for any changes. > > if ( $ACKTIME > 0) { > > $COUNT+=1; > > $REDS=0; > > $YELLOWS=0; > > $REDS_CMP=0; > > $YELLOWS_CMP=0; > > $NEED_COMP=0; > > > > print LOGFILE > "-------------------------------------------------------------------\n"; > > print LOGFILE "SERVERNAME: $SERVERNAME\n"; > > print LOGFILE "TESTTYPE: $TESTTYPE\n"; > > print LOGFILE "COLOR: $COLOR\n"; > > > > # If this is a new ack'd alert we will create a static file that holds > current test state. > > # We will use this file to decide if there have been changes to what has > been ack'd. > > > > if (! -e "${ACKSDIR}/${SERVERNAME}${TESTTYPE}${COLOR}${ACKTIME}" ) { > > open DETAILS, "/home/xymon/server/bin/xymon 0 'xymondlog > ${SERVERNAME}.${TESTTYPE}' |" or die "Couldn't execute: $!"; > > open OUTFILE, > ">${ACKSDIR}/${SERVERNAME}${TESTTYPE}${COLOR}${ACKTIME}" or die > "Couldn't execute: $!"; > > while (<DETAILS>) { > > chomp; > > if ( $_ =~ /^&/ ) { > > $_ =~ s/\&//; > > @DETLINE=split(/ /,$_); > > > > # Change colors to numbers red=2 yellow=1 anything else = 0 > > > > if ( "$DETLINE[0]" eq "red" ) { > > $COL_VALUE = "2"; > > } elsif ( "$DETLINE[0]" eq "yellow" ) { > > $COL_VALUE = "1"; > > } else { > > $COL_VALUE = "0"; > > } > > # Create the status file which will be used on subsequent runs. > > > > print OUTFILE "${COL_VALUE}:${DETLINE[1]}\n"; > > print LOGFILE "DATE: ${COL_VALUE}:${DETLINE[1]}\n"; > > } > > } > > close OUTFILE; > > > > # We have already recorded the initial state of the test and saved it to > a file. > > # Now we will check new status output with that file to see if the > alerts have changed. > > > > } else { > > open DETAILS, "/home/xymon/server/bin/xymon 0 'xymondlog > ${SERVERNAME}.${TESTTYPE}' |" or die "Couldn't execute: $!"; > > while (<DETAILS>) { > > chomp; > > if ( $_ =~ /^&/ ) { > > $_ =~ s/\&//; > > @DETLINE=split(/ /,$_); > > > > # Change colors to numbers red=2 yellow=1 anything else = 0 > > > > if ( "$DETLINE[0]" eq "red" ) { > > $COL_VALUE = "2"; > > } elsif ( "$DETLINE[0]" eq "yellow" ) { > > $COL_VALUE = "1"; > > } else { > > $COL_VALUE = "0"; > > } > > push (@COMP_contents, "${COL_VALUE}:${DETLINE[1]}"); > > } > > } > > > > # Get the initial ack file that was created. > > > > open INITFILE, > "<${ACKSDIR}/${SERVERNAME}${TESTTYPE}${COLOR}${ACKTIME}" or die > "Couldn't execute: $!"; > > while (<INITFILE>) { > > chomp; > > push (@INITFILE_contents, "$_"); > > } > > close INITFILE; > > > > # Create a hash that contains the initial ack file. > > > > %INITF = map(($_,1), at INITFILE_contents); > > foreach (@COMP_contents) { > > if ($INITF{$_}) { > > > > # No change to the alert - nothing to do. > > > > print LOGFILE "Alert hasn't changed: $_\n"; > > > > } else { > > > > # Alert has changed in some form. > > > > print LOGFILE "Alert has changed: $_\n"; > > @CURRENT=split(/:/,$_); > > $CUR_COLOR=$CURRENT[0]; > > $CUR_TEST=$CURRENT[1]; > > @ACKD_EVENT=grep (/:${CUR_TEST}/, @INITFILE_contents); > > @ACK_EVENT=split(/:/,$ACKD_EVENT[0]); > > $ACK_COLOR=$ACKD_EVENT[0]; > > $ACK_TEST=$ACKD_EVENT[1]; > > > > # Compare the current alert color with that which was saved initially. > > > > if ( $CUR_COLOR < $ACK_EVENT[0] ) { > > > > # New color is lower than initial color - leave ack alone. > > > > print LOGFILE "NO ACTION NEEDED (new level lower than > ack level).\n"; > > > > } elsif ( $CUR_COLOR > $ACK_EVENT[0] ) { > > > > # New color is greater than initial ack color, dump ack so new alerts > can be sent. > > > > if ( $ACK_COLOR == "" ) { > > > > # New alert not previously detected (different service, process, or disk > alerting) > > > > print LOGFILE "ACK COLOR $ACK_COLOR\n"; > > print LOGFILE "NEW ALERT - DISABLE ACK AND SEND NEW > ALERT.\n"; > > > > # Reset the server.test status to green. Next update will reset the > alert condition effectivly > > # canceling the acknowledge. > > > > open RESET, "/home/xymon/server/bin/xymon 0 > 'status+10 ${SERVERNAME}.${TESTTYPE} green Ack Reset New Alert Rcvd.' |" > or die "Couldn't execute: $!"; > > close RESET; > > > > } else { > > > > # Level of original alert has upgraded (typically yellow->red) > > > > print LOGFILE "ACK COLOR $ACK_COLOR\n"; > > print LOGFILE "OLD ALERT - DISABLE ACK AND SEND NEW > ALERT.\n"; > > > > # Reset the server.test status to green. Next update will reset the > alert condition effectivly > > # canceling the acknowledge. > > > > open RESET, "/home/xymon/server/bin/xymon 0 > 'status+1 ${SERVERNAME}.${TESTTYPE} green Ack Reset Alert Level > Changed.' |" or die "Couldn't execute: $!"; > > close RESET; > > } > > } else { > > # Nothing to do here. > > print LOGFILE "NO ACTION NEEDED (new level equals ack > level).\n"; > > } > > } > > } > > } > > } > > } > > > > # When there are no ack'd alerts clean out the ACK status directory. > > if ( $COUNT == 0 ) { > > unlink glob "${ACKSDIR}/*"; > > } > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > > > > Thanks, > > John > > Upcoming PTO: > > (none) > > > > _____________________________________________________________________ > > John Rothlisberger > > IT Strategy, Infrastructure & Security - Technology Growth Platform > > TGP for Business Process Outsourcing > > Accenture > > 312.693.3136 office** > > _____________________________________________________________________ > > > > *From:*Ryan Novosielski [mailto:novosirj at umdnj.edu] > *Sent:* Friday, October 22, 2010 5:23 PM > *To:* xymon at xymon.com > *Cc:* xymon at xymon.com > *Subject:* Re: [xymon] canceling acknowledgements > > > > I'm guessing, but I don't know, that these two things would work: > > 1) Remove the file created on the server that contains the ack notice. > 2) Ack the same test as the same person for 1 minute or something similar. > > I was thinking about this same one the other day. The conclusion I came > to was "Why on earth would I want to do that?" The only reason I could > think of was a case of ack'd by accident. > > ----- Original Message ----- > From: Larry Barber <lebarber at gmail.com <mailto:lebarber at gmail.com>> > Date: Friday, October 22, 2010 9:21 pm > Subject: [xymon] canceling acknowledgements > To: xymon at xymon.com <mailto:xymon at xymon.com> > >> Is there some way to cancel an 'ack' after it has been issued? >> >> Thanks, >> Larry Barber > > > ---- _ _ _ _ ___ _ _ _ > |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer > |$&| |__| | | |__/ | \| _| |novosirj at umdnj.edu > <mailto:|novosirj at umdnj.edu> - 973/972.0922 (2-0922) > \__/ Univ. of Med. and Dent.|IST/CST-Academic Svcs. - ADMC 450, Newark > > > ------------------------------------------------------------------------ > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise confidential information. If you > have received it in error, please notify the sender immediately and > delete the original. Any other use of the e-mail by you is prohibited. > Where allowed by local law, electronic communications with Accenture and > its affiliates, including e-mail and instant messaging (including > content), may be scanned by our systems for the purposes of information > security and assessment of internal compliance with Accenture policy. > ______________________________________________________________________________________ > > www.accenture.com -- ____*Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Sr. Systems Programmer || \\ and Health | novosirj at rutgers.edu - 973/972.0922 (2x0922) || \\ Sciences | OIT/EI-Academic Svcs. - ADMC 450, Newark `'

3 2

Recommendations for how I should set maint-senders ?
by john.thurston＠alaska.gov 10 Mar '14

10 Mar '14

the --maint-senders option for xymond is explained as: > Controls which hosts may send maintenance commands to xymond. > Maintenance commands are the "enable", "disable", "ack" and "notes" > commands. Format of this option is as for the --status-senders > option. It is strongly recommended that you use this to restrict > access to these commands, so that monitoring of a host cannot be > disabled by a rogue user - e.g. to hide a system compromise from the > monitoring system. But while exploring some unexpected client behavior today, it appears that --maint-senders is only enforced for hosts in hosts.cfg which are defined with explicit addresses. On line 71 of lib/ipaccess.c I found this: > if (strcmp(targetip, "0.0.0.0") == 0) return 1; /* DHCP hosts can report from any address */ It looks like regardless of how I set --maint-senders, anyone can send a 'disable' message for any host defined with 0.0.0.0 Since 90% of my 500 hosts are dynamically defined in hosts.cfg, it feels like trying to clamp down --maint-senders is kind of pointless for me. Can anyone suggest reasons why I shouldn't just blow that setting wide open? -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska

2 1