Xymon Mailing List Archive search

Feature? svcs

10 messages in this thread

list Vernon Everett · Wed, 28 Jul 2010 14:38:27 +0800 ·
Hi all

I have noticed, if you run BBWin, you get the svcs column, showing all the
services running on the client.
And, the server understands this test. I can add entries into
hobbit-client.cfg along the lines of
HOST=foo
 SVC     "SomeService" startup=automatic status=started COLOR=red
and if the service isn't running it will change to a red status.

I want the same functionality for Solaris services.
I wrote a very simple test for Solaris services (see below), but of course,
that's a client-side test, and the services to alert on can't be configured
at server side.
(It will also only register services in maintenance mode, not disabled
services)
I thought maybe I could hack the hobbitclient-sunos.sh to send the stuff
under the [svcs] heading, like BBWin does, but that didn't work. (I assume
there is some logic defining what the server expects from each client type)
I even went so far as to massage the output of svcs -aH to look at least
similar to the BBWin svcs output.

I would like to be able to have a Solaris client, sending service info, and
be able to define entries in hobbit-client.cfg similar to this
HOST=foo
SVC     /system/cron     STATE=online   COLOR=red
And have the server bleat if that service isn't online.

What would that require to make work?

Regards
    Vernon


#!/bin/ksh
TEST="svcs"
SVCS=/usr/bin/svcs
TEMPFILE=$BBTMP/svcs.tmp
COLOUR="green"
date > $TEMPFILE
echo >> $TEMPFILE
$SVCS -x > $TEMPFILE.tmp
EXIT=$?
if [ $EXIT -eq 0 ]
then
   # Command ran OK
   if [ -s $TEMPFILE.tmp ]
   then
      # It's not empty - bad
      COLOUR=red
      echo "There are issues with configured services." >> $TEMPFILE
      echo "Please investigate" >> $TEMPFILE
      echo >> $TEMPFILE
   else
      # It is empty - All is good.
      echo "All services running OK" >> $TEMPFILE
      echo >> $TEMPFILE
   fi
else
   # Error running command
   COLOUR="yellow"
   echo "Error running $SVCS -x " >> $TEMPFILE
   echo "Please investigate" >> $TEMPFILE
   echo >> $TEMPFILE
fi

cat $TEMPFILE.tmp >> $TEMPFILE
rm $TEMPFILE.tmp
$SVCS -a >> $TEMPFILE

$BB $BBDISP "status $MACHINE.$TEST $COLOUR `cat $TEMPFILE`"
rm $TEMPFILE
list Martin Ward · Wed, 28 Jul 2010 09:30:21 +0100 ·
I have a script that is one step further than yours, the main difference
being that I have defined the services to be monitored in the
client-local.cfg file as you want:

In client-local.cfg for example:

[nmc-dhcp1]
log:/var/adm/messages:10240
svc:/network/ssh:default|svc:/site/network/dhcpd:default

Data from this file is sent to the client (in this case a server called
nmc-dhcp1) and stored in $BBTMP/logfetch.$MACHINEDOTS.cfg, so in the
client-side script I have:

SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`

I was being lazy so have separated the services with the | symbol in
client-local.cfg, this means I can then use the following code with no
pre-processing:

svcs -a | ${EGREP} "${SVCS}" > $SVCFILE

The reason I store the 'svcs -a' output is because I include it in the
data sent back to Xymon.

Service states are checked using the following code:

cat $SVCFILE | while read SVC
do
        STATE=`echo ${SVC} | ${AWK} '{print $1}'`

        case "${STATE}" in
'uninitialized'|'offline'|'degraded')
                if [ "${COLOUR}" != "RED" ]
                then
                        COLOUR="YELLOW"
                fi
                ;;
'maintenance'|'disabled')
                COLOUR="RED"
                ;;
        esac
        echo ${COLOUR} > $COLOURFILE
done

COLOUR=`cat ${COLOURFILE}`

To be honest I don't know why I am storing the colour in a file and then
re-reading it outside the loop, the value shouldn't change at the end of
the while loop. This script was thrown together so it's likely I
intended to remove it but forgot.

Anyway, after that loop I call $BB and pass it all the parameters.

It doesn't have the options that you want, but it does allow for
different return colours depending on the return state. I coded it to
return RED if a service is in a disabled state since I want to monitor
specific services rather than all of them.

The final code is here:

----
#!/bin/sh

# A Hobbit script to examine specific Solaris 10 services.

# Author: Martin Ward 19 Feb 2008.
# Version: 1.0 - Initial version.
# V1.1  Script now takes the list of services to monitor from the server
#       via the logfetch file.

# SVCS is a list of services to examine the status of. Each name must be
# specific enough to make it unique in the output from the 'svcs -a'
command.
# Separate each service with a | so that we can use ${EGREP} to search
for them.
# The services themselves are configured on the Hobbit server in the
# ~hobbit/server/etc/client-local.cfg file. The line will look something
like:
# svc:/network/ssh:default|svc:/site/tftpd:default

# Verify existence of the config file
if [ ! -f $BBTMP/logfetch.$MACHINEDOTS.cfg ]
then
        echo "Unable to retrieve services descriptions."
        exit 1
fi

SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`

# The name of the column in Hobbit
COLUMN=smf

# COLOUR defaults to green
COLOUR=GREEN

# When you modify a variable inside a while loop its value is local to
that
# loop. This means that when you reach the end of the loop the variable
will
# be the same value that it was before the loop was entered. For this
reason
# we have to store the services and colour in temporary files.
SVCFILE=/tmp/svcs.$$
COLOURFILE=/tmp/svcs.colour.$$

# Set up the initial colour
echo "WHITE" > $COLOURFILE

# Get the svcs header line first
MSGH=`svcs -a | head -1`

# Scan through the svcs -a list. Use -a to ensure we get everything.
svcs -a | ${EGREP} "${SVCS}" > $SVCFILE

cat $SVCFILE | while read SVC
do
        STATE=`echo ${SVC} | ${AWK} '{print $1}'`

        case "${STATE}" in
'uninitialized'|'offline'|'degraded')
                if [ "${COLOUR}" != "RED" ]
                then
                        COLOUR="YELLOW"
                fi
                ;;
'maintenance'|'disabled')
                COLOUR="RED"
                ;;
        esac
        echo ${COLOUR} > $COLOURFILE
done

COLOUR=`cat ${COLOURFILE}`

# Tell Hobbit about it
$BB $BBDISP "status $MACHINE.$COLUMN $COLOUR `date`

${MSGH}
`cat ${SVCFILE}`
"

rm -f ${SVCFILE} ${COLOURFILE}

exit 0
----


|\/|artin

[Colt Disclaimer]
The message is intended for the named addressee only and may not be disclosed
to or used by anyone else, nor may it be copied in any way. The contents of
this message and its attachments are confidential and may also be subject to
legal privilege. If you are not the named addressee and/or have received this
message in error, please advise us by e-mailing user-51905b889b93@xymon.invalid and delete the
message and any attachments without retaining any copies. Internet
communications are not secure and Colt does not accept responsibility for this
message, its contents nor responsibility for any viruses. No contracts can be
created or varied on behalf of Colt Technology Services, its subsidiaries,
group companies or affiliates ("Colt") and any other party by email
communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to eliminate
potential viruses and unsolicited promotional emails. For more information
refer to www.colt.net or contact us on +44(0)20 7390 3900
list Vernon Everett · Thu, 29 Jul 2010 08:48:54 +0800 ·
Funny that. About a year ago I discussed using that method with a colleague.

We never got that far, and I forgot all about it.

And excellent way to do it.

Have you considered posting your script on Xymonton?
Here http://xymonton.trantor.org/doku.php/monitors

Cheers
    Vernon
quoted from Martin Ward


On Wed, Jul 28, 2010 at 4:30 PM, Ward, Martin <user-2d33a6eb6a05@xymon.invalid> wrote:
I have a script that is one step further than yours, the main difference
being that I have defined the services to be monitored in the
client-local.cfg file as you want:

In client-local.cfg for example:

[nmc-dhcp1]
log:/var/adm/messages:10240
svc:/network/ssh:default|svc:/site/network/dhcpd:default

Data from this file is sent to the client (in this case a server called
nmc-dhcp1) and stored in $BBTMP/logfetch.$MACHINEDOTS.cfg, so in the
client-side script I have:

SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`

I was being lazy so have separated the services with the | symbol in
client-local.cfg, this means I can then use the following code with no
pre-processing:

svcs -a | ${EGREP} "${SVCS}" > $SVCFILE

The reason I store the 'svcs -a' output is because I include it in the
data sent back to Xymon.

Service states are checked using the following code:

cat $SVCFILE | while read SVC
do
       STATE=`echo ${SVC} | ${AWK} '{print $1}'`

       case "${STATE}" in
'uninitialized'|'offline'|'degraded')
               if [ "${COLOUR}" != "RED" ]
               then
                       COLOUR="YELLOW"
               fi
               ;;
'maintenance'|'disabled')
               COLOUR="RED"
               ;;
       esac
       echo ${COLOUR} > $COLOURFILE
done

COLOUR=`cat ${COLOURFILE}`

To be honest I don't know why I am storing the colour in a file and then
re-reading it outside the loop, the value shouldn't change at the end of
the while loop. This script was thrown together so it's likely I
intended to remove it but forgot.

Anyway, after that loop I call $BB and pass it all the parameters.

It doesn't have the options that you want, but it does allow for
different return colours depending on the return state. I coded it to
return RED if a service is in a disabled state since I want to monitor
specific services rather than all of them.

The final code is here:

----
#!/bin/sh

# A Hobbit script to examine specific Solaris 10 services.

# Author: Martin Ward 19 Feb 2008.
# Version: 1.0 - Initial version.
# V1.1  Script now takes the list of services to monitor from the server
#       via the logfetch file.

# SVCS is a list of services to examine the status of. Each name must be
# specific enough to make it unique in the output from the 'svcs -a'
command.
# Separate each service with a | so that we can use ${EGREP} to search
for them.
# The services themselves are configured on the Hobbit server in the
# ~hobbit/server/etc/client-local.cfg file. The line will look something
like:
# svc:/network/ssh:default|svc:/site/tftpd:default

# Verify existence of the config file
if [ ! -f $BBTMP/logfetch.$MACHINEDOTS.cfg ]
then
       echo "Unable to retrieve services descriptions."
       exit 1
fi

SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`

# The name of the column in Hobbit
COLUMN=smf

# COLOUR defaults to green
COLOUR=GREEN

# When you modify a variable inside a while loop its value is local to
that
# loop. This means that when you reach the end of the loop the variable
will
# be the same value that it was before the loop was entered. For this
reason
# we have to store the services and colour in temporary files.
SVCFILE=/tmp/svcs.$$
COLOURFILE=/tmp/svcs.colour.$$

# Set up the initial colour
echo "WHITE" > $COLOURFILE

# Get the svcs header line first
MSGH=`svcs -a | head -1`

# Scan through the svcs -a list. Use -a to ensure we get everything.
svcs -a | ${EGREP} "${SVCS}" > $SVCFILE

cat $SVCFILE | while read SVC
do
       STATE=`echo ${SVC} | ${AWK} '{print $1}'`

       case "${STATE}" in
'uninitialized'|'offline'|'degraded')
               if [ "${COLOUR}" != "RED" ]
               then
                       COLOUR="YELLOW"
               fi
               ;;
'maintenance'|'disabled')
               COLOUR="RED"
               ;;
       esac
       echo ${COLOUR} > $COLOURFILE
done

COLOUR=`cat ${COLOURFILE}`

# Tell Hobbit about it
$BB $BBDISP "status $MACHINE.$COLUMN $COLOUR `date`

${MSGH}
`cat ${SVCFILE}`
"

rm -f ${SVCFILE} ${COLOURFILE}

exit 0
----


|\/|artin

[Colt Disclaimer]
The message is intended for the named addressee only and may not be
disclosed
to or used by anyone else, nor may it be copied in any way. The contents of
this message and its attachments are confidential and may also be subject
to
legal privilege. If you are not the named addressee and/or have received
this
message in error, please advise us by e-mailing user-51905b889b93@xymon.invalid and delete
the
message and any attachments without retaining any copies. Internet
communications are not secure and Colt does not accept responsibility for
this
message, its contents nor responsibility for any viruses. No contracts can
be
created or varied on behalf of Colt Technology Services, its subsidiaries,
group companies or affiliates ("Colt") and any other party by email
communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to eliminate
potential viruses and unsolicited promotional emails. For more information
refer to www.colt.net or contact us on +44(0)20 7390 3900

list David Baldwin · Thu, 29 Jul 2010 17:07:36 +1000 ·
Vernon,
quoted from Vernon Everett
I have noticed, if you run BBWin, you get the svcs column, showing all
the services running on the client.
And, the server understands this test. I can add entries into
hobbit-client.cfg along the lines of
HOST=foo
 SVC     "SomeService" startup=automatic status=started COLOR=red
and if the service isn't running it will change to a red status.
That is using the 'client' message type for reporting. On one of the
bbwin hosts svcs report you will notice a link near the bottom to
"client data" which shows the full report.
quoted from Vernon Everett
I want the same functionality for Solaris services.
I wrote a very simple test for Solaris services (see below), but of
course, that's a client-side test, and the services to alert on can't
be configured at server side.
(It will also only register services in maintenance mode, not disabled
services)
I thought maybe I could hack the hobbitclient-sunos.sh to send the
stuff under the [svcs] heading, like BBWin does, but that didn't work.
(I assume there is some logic defining what the server expects from
each client type)
I even went so far as to massage the output of svcs -aH to look at
least similar to the BBWin svcs output.
I assume there is some hard-coded testing in hobbitd based on client
type (win32/linux/solaris/etc) for the standard reports.

A general solution is to use a test that reports on the client channel.
Note that you can do initial filtering on the new client message header
for OS type, etc.

I've just spent a bit of time tidying up some code I've been meaning to
do for ages and put on xymonton.
http://xymonton.trantor.org/doku.php/monitors:check-client
http://xymonton.trantor.org/doku.php/monitors:xymonext.pm

It would be fairly easy to add to the solaris hobbitclient-solaris.sh to
add a [svcs] session, and then add a custom test to client-check.pl

David.

-- 
David Baldwin - IT Unit
Australian Sports Commission          www.ausport.gov.au
Tel 02 62147830 Fax 02 62141830       PO Box 176 Belconnen ACT 2616
user-cbbf693f2c89@xymon.invalid          Leverrier Street Bruce ACT 2617


Keep up to date with what's happening in Australian sport visit http://www.ausport.gov.au

This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.
list Martin Ward · Thu, 29 Jul 2010 11:49:31 +0100 ·
It's done: http://xymonton.trantor.org/doku.php/monitors:smf.sh

 
I hope I got the syntax right, it all looks good to me.

 
|\/|

--  

Martin Ward

Manager, Technical Services

 
DDI:+44 (0) 20 7863 5218 / Fax: +XX (X)XX XXXX XXXX /  www.colt.net
<http://www.colt.net/>; 

Colt Technology Services, Unit XX, Powergate Business Park, Volt Avenue,
Park Royal, London, NW10 6PW, UK.

 
Help reduce your carbon footprint | Think before you print. Registered
in England and Wales, registered number 02452736, VAT number GB 645 4205
50
quoted from Vernon Everett

 
From: Vernon Everett [mailto:user-b3f8dacb72c8@xymon.invalid] 
Sent: 29 July 2010 01:49
To: xymon at xymon.com
Subject: Re: [xymon] Feature? svcs

 
Funny that. About a year ago I discussed using that method with a
colleague. 
We never got that far, and I forgot all about it.

And excellent way to do it.

Have you considered posting your script on Xymonton?
Here http://xymonton.trantor.org/doku.php/monitors

Cheers
    Vernon


On Wed, Jul 28, 2010 at 4:30 PM, Ward, Martin <user-2d33a6eb6a05@xymon.invalid>
wrote:

I have a script that is one step further than yours, the main difference
being that I have defined the services to be monitored in the
client-local.cfg file as you want:

In client-local.cfg for example:

[nmc-dhcp1]
log:/var/adm/messages:10240
svc:/network/ssh:default|svc:/site/network/dhcpd:default

Data from this file is sent to the client (in this case a server called
nmc-dhcp1) and stored in $BBTMP/logfetch.$MACHINEDOTS.cfg, so in the
client-side script I have:

SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`

I was being lazy so have separated the services with the | symbol in
client-local.cfg, this means I can then use the following code with no
pre-processing:

svcs -a | ${EGREP} "${SVCS}" > $SVCFILE

The reason I store the 'svcs -a' output is because I include it in the
data sent back to Xymon.

Service states are checked using the following code:

cat $SVCFILE | while read SVC
do
       STATE=`echo ${SVC} | ${AWK} '{print $1}'`

       case "${STATE}" in
'uninitialized'|'offline'|'degraded')
               if [ "${COLOUR}" != "RED" ]
               then
                       COLOUR="YELLOW"
               fi
               ;;
'maintenance'|'disabled')
               COLOUR="RED"
               ;;
       esac
       echo ${COLOUR} > $COLOURFILE
done

COLOUR=`cat ${COLOURFILE}`

To be honest I don't know why I am storing the colour in a file and then
re-reading it outside the loop, the value shouldn't change at the end of
the while loop. This script was thrown together so it's likely I
intended to remove it but forgot.

Anyway, after that loop I call $BB and pass it all the parameters.

It doesn't have the options that you want, but it does allow for
different return colours depending on the return state. I coded it to
return RED if a service is in a disabled state since I want to monitor
specific services rather than all of them.

The final code is here:

----
#!/bin/sh

# A Hobbit script to examine specific Solaris 10 services.

# Author: Martin Ward 19 Feb 2008.
# Version: 1.0 - Initial version.
# V1.1  Script now takes the list of services to monitor from the server
#       via the logfetch file.

# SVCS is a list of services to examine the status of. Each name must be
# specific enough to make it unique in the output from the 'svcs -a'
command.
# Separate each service with a | so that we can use ${EGREP} to search
for them.
# The services themselves are configured on the Hobbit server in the
# ~hobbit/server/etc/client-local.cfg file. The line will look something
like:
# svc:/network/ssh:default|svc:/site/tftpd:default

# Verify existence of the config file
if [ ! -f $BBTMP/logfetch.$MACHINEDOTS.cfg ]
then
       echo "Unable to retrieve services descriptions."
       exit 1
fi

SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`

# The name of the column in Hobbit
COLUMN=smf

# COLOUR defaults to green
COLOUR=GREEN

# When you modify a variable inside a while loop its value is local to
that
# loop. This means that when you reach the end of the loop the variable
will
# be the same value that it was before the loop was entered. For this
reason
# we have to store the services and colour in temporary files.
SVCFILE=/tmp/svcs.$$
COLOURFILE=/tmp/svcs.colour.$$

# Set up the initial colour
echo "WHITE" > $COLOURFILE

# Get the svcs header line first
MSGH=`svcs -a | head -1`

# Scan through the svcs -a list. Use -a to ensure we get everything.
svcs -a | ${EGREP} "${SVCS}" > $SVCFILE

cat $SVCFILE | while read SVC
do
       STATE=`echo ${SVC} | ${AWK} '{print $1}'`

       case "${STATE}" in
'uninitialized'|'offline'|'degraded')
               if [ "${COLOUR}" != "RED" ]
               then
                       COLOUR="YELLOW"
               fi
               ;;
'maintenance'|'disabled')
               COLOUR="RED"
               ;;
       esac
       echo ${COLOUR} > $COLOURFILE
done

COLOUR=`cat ${COLOURFILE}`

# Tell Hobbit about it
$BB $BBDISP "status $MACHINE.$COLUMN $COLOUR `date`

${MSGH}
`cat ${SVCFILE}`
"

rm -f ${SVCFILE} ${COLOURFILE}

exit 0
----


|\/|artin

[Colt Disclaimer]
The message is intended for the named addressee only and may not be
disclosed
to or used by anyone else, nor may it be copied in any way. The contents
of
this message and its attachments are confidential and may also be
subject to
legal privilege. If you are not the named addressee and/or have received
this
message in error, please advise us by e-mailing user-51905b889b93@xymon.invalid and
delete the
message and any attachments without retaining any copies. Internet
communications are not secure and Colt does not accept responsibility
for this
message, its contents nor responsibility for any viruses. No contracts
can be
created or varied on behalf of Colt Technology Services, its
subsidiaries,
group companies or affiliates ("Colt") and any other party by email
communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to
eliminate
potential viruses and unsolicited promotional emails. For more
information
refer to www.colt.net or contact us on +44(0)20 7390 3900
list Vernon Everett · Thu, 29 Jul 2010 19:50:14 +0800 ·
Looks good.
I will try it on our systems tomorrow, when I get back to the office.

Thanks.

Regards
    Vernon
quoted from Martin Ward


On Thu, Jul 29, 2010 at 6:49 PM, Ward, Martin <user-2d33a6eb6a05@xymon.invalid> wrote:
 It's done: http://xymonton.trantor.org/doku.php/monitors:smf.sh


I hope I got the syntax right, it all looks good to me.


|\/|

--

Martin Ward

*Manager, Technical Services*


DDI:+44 (0) 20 7863 5218 / Fax: +XX (X)XX XXXX XXXX /  www.colt.net

Colt Technology Services, Unit XX, Powergate Business Park, Volt Avenue,
Park Royal, London, NW10 6PW, UK.


Help reduce your carbon footprint | Think before you print. Registered in
England and Wales, registered number 02452736, VAT number GB 645 4205 50


*From:* Vernon Everett [mailto:user-b3f8dacb72c8@xymon.invalid]
*Sent:* 29 July 2010 01:49
*To:* xymon at xymon.com
*Subject:* Re: [xymon] Feature? svcs


Funny that. About a year ago I discussed using that method with a
colleague.
We never got that far, and I forgot all about it.

And excellent way to do it.

Have you considered posting your script on Xymonton?
Here http://xymonton.trantor.org/doku.php/monitors

Cheers
    Vernon


 On Wed, Jul 28, 2010 at 4:30 PM, Ward, Martin <user-2d33a6eb6a05@xymon.invalid>
wrote:

I have a script that is one step further than yours, the main difference
being that I have defined the services to be monitored in the
client-local.cfg file as you want:

In client-local.cfg for example:

[nmc-dhcp1]
log:/var/adm/messages:10240
svc:/network/ssh:default|svc:/site/network/dhcpd:default

Data from this file is sent to the client (in this case a server called
nmc-dhcp1) and stored in $BBTMP/logfetch.$MACHINEDOTS.cfg, so in the
client-side script I have:

SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`

I was being lazy so have separated the services with the | symbol in
client-local.cfg, this means I can then use the following code with no
pre-processing:

svcs -a | ${EGREP} "${SVCS}" > $SVCFILE

The reason I store the 'svcs -a' output is because I include it in the
data sent back to Xymon.

Service states are checked using the following code:

cat $SVCFILE | while read SVC
do
       STATE=`echo ${SVC} | ${AWK} '{print $1}'`

       case "${STATE}" in
'uninitialized'|'offline'|'degraded')
               if [ "${COLOUR}" != "RED" ]
               then
                       COLOUR="YELLOW"
               fi
               ;;
'maintenance'|'disabled')
               COLOUR="RED"
               ;;
       esac
       echo ${COLOUR} > $COLOURFILE
done

COLOUR=`cat ${COLOURFILE}`

To be honest I don't know why I am storing the colour in a file and then
re-reading it outside the loop, the value shouldn't change at the end of
the while loop. This script was thrown together so it's likely I
intended to remove it but forgot.

Anyway, after that loop I call $BB and pass it all the parameters.

It doesn't have the options that you want, but it does allow for
different return colours depending on the return state. I coded it to
return RED if a service is in a disabled state since I want to monitor
specific services rather than all of them.

The final code is here:

----
#!/bin/sh

# A Hobbit script to examine specific Solaris 10 services.

# Author: Martin Ward 19 Feb 2008.
# Version: 1.0 - Initial version.
# V1.1  Script now takes the list of services to monitor from the server
#       via the logfetch file.

# SVCS is a list of services to examine the status of. Each name must be
# specific enough to make it unique in the output from the 'svcs -a'
command.
# Separate each service with a | so that we can use ${EGREP} to search
for them.
# The services themselves are configured on the Hobbit server in the
# ~hobbit/server/etc/client-local.cfg file. The line will look something
like:
# svc:/network/ssh:default|svc:/site/tftpd:default

# Verify existence of the config file
if [ ! -f $BBTMP/logfetch.$MACHINEDOTS.cfg ]
then
       echo "Unable to retrieve services descriptions."
       exit 1
fi

SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`

# The name of the column in Hobbit
COLUMN=smf

# COLOUR defaults to green
COLOUR=GREEN

# When you modify a variable inside a while loop its value is local to
that
# loop. This means that when you reach the end of the loop the variable
will
# be the same value that it was before the loop was entered. For this
reason
# we have to store the services and colour in temporary files.
SVCFILE=/tmp/svcs.$$
COLOURFILE=/tmp/svcs.colour.$$

# Set up the initial colour
echo "WHITE" > $COLOURFILE

# Get the svcs header line first
MSGH=`svcs -a | head -1`

# Scan through the svcs -a list. Use -a to ensure we get everything.
svcs -a | ${EGREP} "${SVCS}" > $SVCFILE

cat $SVCFILE | while read SVC
do
       STATE=`echo ${SVC} | ${AWK} '{print $1}'`

       case "${STATE}" in
'uninitialized'|'offline'|'degraded')
               if [ "${COLOUR}" != "RED" ]
               then
                       COLOUR="YELLOW"
               fi
               ;;
'maintenance'|'disabled')
               COLOUR="RED"
               ;;
       esac
       echo ${COLOUR} > $COLOURFILE
done

COLOUR=`cat ${COLOURFILE}`

# Tell Hobbit about it
$BB $BBDISP "status $MACHINE.$COLUMN $COLOUR `date`

${MSGH}
`cat ${SVCFILE}`
"

rm -f ${SVCFILE} ${COLOURFILE}

exit 0
----


|\/|artin

[Colt Disclaimer]
The message is intended for the named addressee only and may not be
disclosed
to or used by anyone else, nor may it be copied in any way. The contents of
this message and its attachments are confidential and may also be subject
to
legal privilege. If you are not the named addressee and/or have received
this
message in error, please advise us by e-mailing user-51905b889b93@xymon.invalid and delete
the
message and any attachments without retaining any copies. Internet
communications are not secure and Colt does not accept responsibility for
this
message, its contents nor responsibility for any viruses. No contracts can
be
created or varied on behalf of Colt Technology Services, its subsidiaries,
group companies or affiliates ("Colt") and any other party by email
communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to eliminate
potential viruses and unsolicited promotional emails. For more information
refer to www.colt.net or contact us on +44(0)20 7390 3900

list Vernon Everett · Fri, 30 Jul 2010 19:42:42 +0800 ·
Hi Martin

Gave it a try this arvo, and it looks good.
Then came the comments from my colleagues.
The comments were all good, but they wanted more. (Don't they always)

One of the features what the ability to monitor a service to ensure it was
disabled, and go red if it was enabled.

So, I started adding some features to your code. I thought I would do a
put-back as version 2.0
But it's slowly becoming very different.
Besides the feature above, it takes one service per line in client-local.cfg
and it's in ksh now. (I just prefer ksh over sh)

Once it's done, I will put it onto Xymonton as smf2 or something similar.
It's going to be different enough to warrant a new name.

Cheers
quoted from Vernon Everett
    Vernon


On Thu, Jul 29, 2010 at 7:50 PM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid>wrote:
Looks good.
I will try it on our systems tomorrow, when I get back to the office.

Thanks.

Regards
    Vernon


On Thu, Jul 29, 2010 at 6:49 PM, Ward, Martin <user-2d33a6eb6a05@xymon.invalid>wrote:
 It's done: http://xymonton.trantor.org/doku.php/monitors:smf.sh


I hope I got the syntax right, it all looks good to me.


|\/|

--

Martin Ward

*Manager, Technical Services*


DDI:+44 (0) 20 7863 5218 / Fax: +XX (X)XX XXXX XXXX /  www.colt.net

Colt Technology Services, Unit XX, Powergate Business Park, Volt Avenue,
Park Royal, London, NW10 6PW, UK.


Help reduce your carbon footprint | Think before you print. Registered in
England and Wales, registered number 02452736, VAT number GB 645 4205 50


*From:* Vernon Everett [mailto:user-b3f8dacb72c8@xymon.invalid]
*Sent:* 29 July 2010 01:49
*To:* xymon at xymon.com
*Subject:* Re: [xymon] Feature? svcs


Funny that. About a year ago I discussed using that method with a
colleague.
We never got that far, and I forgot all about it.

And excellent way to do it.

Have you considered posting your script on Xymonton?
Here http://xymonton.trantor.org/doku.php/monitors

Cheers
    Vernon


 On Wed, Jul 28, 2010 at 4:30 PM, Ward, Martin <user-2d33a6eb6a05@xymon.invalid>
wrote:

I have a script that is one step further than yours, the main difference
being that I have defined the services to be monitored in the
client-local.cfg file as you want:

In client-local.cfg for example:

[nmc-dhcp1]
log:/var/adm/messages:10240
svc:/network/ssh:default|svc:/site/network/dhcpd:default

Data from this file is sent to the client (in this case a server called
nmc-dhcp1) and stored in $BBTMP/logfetch.$MACHINEDOTS.cfg, so in the
client-side script I have:

SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`

I was being lazy so have separated the services with the | symbol in
client-local.cfg, this means I can then use the following code with no
pre-processing:

svcs -a | ${EGREP} "${SVCS}" > $SVCFILE

The reason I store the 'svcs -a' output is because I include it in the
data sent back to Xymon.

Service states are checked using the following code:

cat $SVCFILE | while read SVC
do
       STATE=`echo ${SVC} | ${AWK} '{print $1}'`

       case "${STATE}" in
'uninitialized'|'offline'|'degraded')
               if [ "${COLOUR}" != "RED" ]
               then
                       COLOUR="YELLOW"
               fi
               ;;
'maintenance'|'disabled')
               COLOUR="RED"
               ;;
       esac
       echo ${COLOUR} > $COLOURFILE
done

COLOUR=`cat ${COLOURFILE}`

To be honest I don't know why I am storing the colour in a file and then
re-reading it outside the loop, the value shouldn't change at the end of
the while loop. This script was thrown together so it's likely I
intended to remove it but forgot.

Anyway, after that loop I call $BB and pass it all the parameters.

It doesn't have the options that you want, but it does allow for
different return colours depending on the return state. I coded it to
return RED if a service is in a disabled state since I want to monitor
specific services rather than all of them.

The final code is here:

----
#!/bin/sh

# A Hobbit script to examine specific Solaris 10 services.

# Author: Martin Ward 19 Feb 2008.
# Version: 1.0 - Initial version.
# V1.1  Script now takes the list of services to monitor from the server
#       via the logfetch file.

# SVCS is a list of services to examine the status of. Each name must be
# specific enough to make it unique in the output from the 'svcs -a'
command.
# Separate each service with a | so that we can use ${EGREP} to search
for them.
# The services themselves are configured on the Hobbit server in the
# ~hobbit/server/etc/client-local.cfg file. The line will look something
like:
# svc:/network/ssh:default|svc:/site/tftpd:default

# Verify existence of the config file
if [ ! -f $BBTMP/logfetch.$MACHINEDOTS.cfg ]
then
       echo "Unable to retrieve services descriptions."
       exit 1
fi

SVCS=`grep '^svc:' $BBTMP/logfetch.$MACHINEDOTS.cfg`

# The name of the column in Hobbit
COLUMN=smf

# COLOUR defaults to green
COLOUR=GREEN

# When you modify a variable inside a while loop its value is local to
that
# loop. This means that when you reach the end of the loop the variable
will
# be the same value that it was before the loop was entered. For this
reason
# we have to store the services and colour in temporary files.
SVCFILE=/tmp/svcs.$$
COLOURFILE=/tmp/svcs.colour.$$

# Set up the initial colour
echo "WHITE" > $COLOURFILE

# Get the svcs header line first
MSGH=`svcs -a | head -1`

# Scan through the svcs -a list. Use -a to ensure we get everything.
svcs -a | ${EGREP} "${SVCS}" > $SVCFILE

cat $SVCFILE | while read SVC
do
       STATE=`echo ${SVC} | ${AWK} '{print $1}'`

       case "${STATE}" in
'uninitialized'|'offline'|'degraded')
               if [ "${COLOUR}" != "RED" ]
               then
                       COLOUR="YELLOW"
               fi
               ;;
'maintenance'|'disabled')
               COLOUR="RED"
               ;;
       esac
       echo ${COLOUR} > $COLOURFILE
done

COLOUR=`cat ${COLOURFILE}`

# Tell Hobbit about it
$BB $BBDISP "status $MACHINE.$COLUMN $COLOUR `date`

${MSGH}
`cat ${SVCFILE}`
"

rm -f ${SVCFILE} ${COLOURFILE}

exit 0
----


|\/|artin

[Colt Disclaimer]
The message is intended for the named addressee only and may not be
disclosed
to or used by anyone else, nor may it be copied in any way. The contents
of
this message and its attachments are confidential and may also be subject
to
legal privilege. If you are not the named addressee and/or have received
this
message in error, please advise us by e-mailing user-51905b889b93@xymon.invalid and delete
the
message and any attachments without retaining any copies. Internet
communications are not secure and Colt does not accept responsibility for
this
message, its contents nor responsibility for any viruses. No contracts can
be
created or varied on behalf of Colt Technology Services, its subsidiaries,
group companies or affiliates ("Colt") and any other party by email
communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to
eliminate
potential viruses and unsolicited promotional emails. For more information
refer to www.colt.net or contact us on +44(0)20 7390 3900

list Martin Ward · Fri, 30 Jul 2010 16:23:28 +0100 ·
You sure you want to rename it? I mean it does exactly the same thing,
monitoring the SMF, so I have no problems with you simply overwriting my
version and taking all the credit.

 
Actually, I do wonder if it shouldn't report back under the svcs column,
or is it considered bad form to have two different forms of data under
the same column heading (I do it already. I have a column called raid.
For some Sun servers it reports on metastat(1m) and on others it reports
on zfs(1m) output).

 
|\/|artin
quoted from Vernon Everett

--  

Martin Ward

Manager, Technical Services

 
DDI:+44 (0) 20 7863 5218 / Fax: +XX (X)XX XXXX XXXX /  www.colt.net
<http://www.colt.net/>; 

Colt Technology Services, Unit XX, Powergate Business Park, Volt Avenue,
Park Royal, London, NW10 6PW, UK.

 
Help reduce your carbon footprint | Think before you print. Registered
in England and Wales, registered number 02452736, VAT number GB 645 4205
50

 
From: Vernon Everett [mailto:user-b3f8dacb72c8@xymon.invalid] 
Sent: 30 July 2010 12:43
To: xymon at xymon.com
Subject: Re: [xymon] Feature? svcs

 
Hi Martin

Gave it a try this arvo, and it looks good.
Then came the comments from my colleagues.
The comments were all good, but they wanted more. (Don't they always)

One of the features what the ability to monitor a service to ensure it
was disabled, and go red if it was enabled.

So, I started adding some features to your code. I thought I would do a
put-back as version 2.0
But it's slowly becoming very different.
Besides the feature above, it takes one service per line in
client-local.cfg and it's in ksh now. (I just prefer ksh over sh)

Once it's done, I will put it onto Xymonton as smf2 or something
similar.
It's going to be different enough to warrant a new name.

Cheers
    Vernon

 
[Colt Disclaimer]
The message is intended for the named addressee only and may not be disclosed
to or used by anyone else, nor may it be copied in any way. The contents of
this message and its attachments are confidential and may also be subject to
legal privilege. If you are not the named addressee and/or have received this
message in error, please advise us by e-mailing user-51905b889b93@xymon.invalid and delete the
message and any attachments without retaining any copies. Internet
communications are not secure and Colt does not accept responsibility for this
message, its contents nor responsibility for any viruses. No contracts can be
created or varied on behalf of Colt Technology Services, its subsidiaries,
group companies or affiliates ("Colt") and any other party by email
communications unless expressly agreed in writing with such other party.
Please note that incoming emails will be automatically scanned to eliminate
potential viruses and unsolicited promotional emails. For more information
refer to www.colt.net or contact us on +44(0)20 7390 3900
list Vernon Everett · Sat, 31 Jul 2010 05:47:54 +0800 ·
When it's done, I'll send you the finished product, and we can discuss it
then.
And there is no way I can take all the credit - without you doing your
version, I wouldn't have bothered with mine :-)

Cheers
    Vernon
quoted from Martin Ward


On Fri, Jul 30, 2010 at 11:23 PM, Ward, Martin <user-2d33a6eb6a05@xymon.invalid> wrote:
 You sure you want to rename it? I mean it does exactly the same thing,
monitoring the SMF, so I have no problems with you simply overwriting my
version and taking all the credit.


Actually, I do wonder if it shouldn't report back under the svcs column, or
is it considered bad form to have two different forms of data under the same
column heading (I do it already. I have a column called raid. For some Sun
servers it reports on metastat(1m) and on others it reports on zfs(1m)
output).


|\/|artin

--

Martin Ward

*Manager, Technical Services*


DDI:+44 (0) 20 7863 5218 / Fax: +XX (X)XX XXXX XXXX /  www.colt.net

Colt Technology Services, Unit XX, Powergate Business Park, Volt Avenue,
Park Royal, London, NW10 6PW, UK.


Help reduce your carbon footprint | Think before you print. Registered in
England and Wales, registered number 02452736, VAT number GB 645 4205 50


*From:* Vernon Everett [mailto:user-b3f8dacb72c8@xymon.invalid]
*Sent:* 30 July 2010 12:43

*To:* xymon at xymon.com
*Subject:* Re: [xymon] Feature? svcs


Hi Martin


Gave it a try this arvo, and it looks good.
Then came the comments from my colleagues.
The comments were all good, but they wanted more. (Don't they always)

One of the features what the ability to monitor a service to ensure it was
disabled, and go red if it was enabled.

So, I started adding some features to your code. I thought I would do a
put-back as version 2.0
But it's slowly becoming very different.
Besides the feature above, it takes one service per line in
client-local.cfg and it's in ksh now. (I just prefer ksh over sh)

Once it's done, I will put it onto Xymonton as smf2 or something similar.
It's going to be different enough to warrant a new name.

Cheers
    Vernon


 [Colt Disclaimer] The message is intended for the named addressee only
and may not be disclosed to or used by anyone else, nor may it be copied in
any way. The contents of this message and its attachments are confidential
and may also be subject to legal privilege. If you are not the named
addressee and/or have received this message in error, please advise us by
e-mailing user-51905b889b93@xymon.invalid and delete the message and any attachments
without retaining any copies. Internet communications are not secure and
Colt does not accept responsibility for this message, its contents nor
responsibility for any viruses. No contracts can be created or varied on
behalf of Colt Technology Services, its subsidiaries, group companies or
affiliates ("Colt") and any other party by email communications unless
expressly agreed in writing with such other party. Please note that incoming
emails will be automatically scanned to eliminate potential viruses and

unsolicited promotional emails. For more information refer to www.colt.netor contact us on +44(0)20 7390 3900
list Vernon Everett · Tue, 3 Aug 2010 15:16:51 +0800 ·
Hi all

I have made some major changes to how Martin's smf.sh script works.
It has changed to the extent that *it is no longer a drop-in replacement for
smf.sh*, so I created a new entry for it on Xymonton.
Have a look here. http://xymonton.trantor.org/doku.php/monitors:smf2.ksh
As mentioned in the docs, if you like the simple way of doing things, stick
with smf.sh
smf2.ksh is substanially more complicated, but can do more.

Some might not like the idea of having two ways to do the same thing. If you
are one of those people, I pose to you the following question - "What do you
think of Unix?"

Or, to quote a master :
Historically speaking, the presence of wheels in Unix has never precluded
their reinvention. -- Larry Wall

Regards
     Vernon
quoted from Vernon Everett


On Sat, Jul 31, 2010 at 5:47 AM, Vernon Everett <user-b3f8dacb72c8@xymon.invalid>wrote:
When it's done, I'll send you the finished product, and we can discuss it
then.
And there is no way I can take all the credit - without you doing your
version, I wouldn't have bothered with mine :-)

Cheers
    Vernon


On Fri, Jul 30, 2010 at 11:23 PM, Ward, Martin <user-2d33a6eb6a05@xymon.invalid>wrote:
 You sure you want to rename it? I mean it does exactly the same thing,
monitoring the SMF, so I have no problems with you simply overwriting my
version and taking all the credit.


Actually, I do wonder if it shouldn't report back under the svcs column,
or is it considered bad form to have two different forms of data under the
same column heading (I do it already. I have a column called raid. For some
Sun servers it reports on metastat(1m) and on others it reports on zfs(1m)
output).


|\/|artin

--

Martin Ward

*Manager, Technical Services*


DDI:+44 (0) 20 7863 5218 / Fax: +XX (X)XX XXXX XXXX /  www.colt.net

Colt Technology Services, Unit XX, Powergate Business Park, Volt Avenue,
Park Royal, London, NW10 6PW, UK.


Help reduce your carbon footprint | Think before you print. Registered in
England and Wales, registered number 02452736, VAT number GB 645 4205 50


*From:* Vernon Everett [mailto:user-b3f8dacb72c8@xymon.invalid]
*Sent:* 30 July 2010 12:43

*To:* xymon at xymon.com
*Subject:* Re: [xymon] Feature? svcs


Hi Martin


Gave it a try this arvo, and it looks good.
Then came the comments from my colleagues.
The comments were all good, but they wanted more. (Don't they always)

One of the features what the ability to monitor a service to ensure it was
disabled, and go red if it was enabled.

So, I started adding some features to your code. I thought I would do a
put-back as version 2.0
But it's slowly becoming very different.
Besides the feature above, it takes one service per line in
client-local.cfg and it's in ksh now. (I just prefer ksh over sh)

Once it's done, I will put it onto Xymonton as smf2 or something similar.
It's going to be different enough to warrant a new name.

Cheers
    Vernon


 [Colt Disclaimer] The message is intended for the named addressee only
and may not be disclosed to or used by anyone else, nor may it be copied in
any way. The contents of this message and its attachments are confidential
and may also be subject to legal privilege. If you are not the named
addressee and/or have received this message in error, please advise us by
e-mailing user-51905b889b93@xymon.invalid and delete the message and any attachments
without retaining any copies. Internet communications are not secure and
Colt does not accept responsibility for this message, its contents nor
responsibility for any viruses. No contracts can be created or varied on
behalf of Colt Technology Services, its subsidiaries, group companies or
affiliates ("Colt") and any other party by email communications unless
expressly agreed in writing with such other party. Please note that incoming
emails will be automatically scanned to eliminate potential viruses and
unsolicited promotional emails. For more information refer to
www.colt.net or contact us on +44(0)20 7390 3900