Receive Trap SNMP in Hobbit 🔗 link

Hello,

 I'm using several monitoring tools but I want Hobbit the main console. I'm
using already hobbit to monitor a couple of servers & network appliance and the
other monitoring tools are specific.
 The other monitoring tools can forward SNMP traps. I would like Hobbit to
receive the SNMP trap and set alerts according to the result.

 Is there a way to do this? I've checked
http://cerebro.victoriacollege.edu/hobbit-trap.html but I look a little bit
complicated.
 I'm aware of any suggestion who could be as much reliable/flexible  as
possible.

  Thanks by advance.

UP ;)

Anyone have an idea about it please ?

  Thanks by advance, LMJ

Selon user-78bb6d5d9024@xymon.invalid:

I sincerely ask that you search the mailing list archives, please.  You will
find more then enough information to get started with the results.

On 1/20/08, user-78bb6d5d9024@xymon.invalid <user-78bb6d5d9024@xymon.invalid> wrote:

-- 

Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX

Those who don't understand UNIX are condemned to reinvent it, poorly.
--- Henry Spencer

Hi Henrik

I don't know if this has been mentioned before, but Solaris has a bug in
df, which under the correct conditions, can cause Hobbit not to monitor
certain file systems.
I couldn't find a reference to it in the Hobbit mailing list archive, so
apologies if this has been discussed before.

In ~client/bin/hobbitclient-sunos.sh the line FSTYPES= uses /bin/df -n
-l | awk '{ print $3 '}
However, if the file-system path is longer than 19 characters, the
output format changes.
# /bin/df -n -l
/                  : ufs
/devices           : devfs
/system/contract   : ctfs
/proc              : proc
/etc/mnttab        : mntfs
/etc/svc/volatile  : tmpfs
/system/object     : objfs
/lib/libc.so.1     : lofs
/dev/fd            : fd
/var               : ufs
/tmp               : tmpfs
/var/run           : tmpfs
/opt               : ufs
/local/dsk/zpools/bambi-thumper: zfs                        <-----
/local/dsk/zpools/bambi-thumper/data1: zfs                  <-----
/local/dsk/zpools/bambi-thumper/data2: zfs                  <-----
/local/dsk/zpools/bambi-thumper/data3: zfs                  <-----
/local/dsk/zpools/bambi-thumper/scratch: zfs                <-----
/nfs/bambi/scratch : lofs
/nfs/bambi/img     : lofs

Notice there is no space between the file-system path and the : on the
longer path entries.
(marked with <----- )
This means the awk '{ print $3 }' prints an empty string instead of the
fs type.
In the case above, zfs is not being picked up as a file system type, in
the variable FSTYPES, so no zfs file systems are being monitored.

This is not normally an issue, but with things like zfs and vxfs, the
file system paths can get rather long.
If there was a short path file system of type zfs, all zfs file systems
will be picked up and monitored.
This bug only impacts hobbit if all the file systems of a specific type
have long paths - as in the case above, where all the instances of zfs
have long paths.

Can I propose this update to the hobbitclient-sunos.sh (we use cut
instead of awk)
FSTYPES=`/bin/df -n -l| /bin/df -n -l| cut -d":" -f2 |sed 's/\
//g'|egrep -v
"^lofs|^proc|^fd|^mntfs|^ctfs|^devfs|^objfs|^nfs"|sort|uniq`
(This line also includes the ^lofs in the egrep regex, as discussed here
in the list, which is specific to Solaris 10 zones
http://www.hswn.dk/hobbiton/2006/08/msg00487.html )

This change should work on the older versions of Solaris, and should
still work if at any time Sun correct the problem.

Regards
    Vernon

NOTICE: This email and any attachments are confidential. 
They may contain legally privileged information or 
copyright material. You must not read, copy, use or 
disclose them without authorisation. If you are not an 
intended recipient, please contact us at once by return 
email and then delete both messages and all attachments.

Hello back,

  I'm getting really stuck with this issue. I'm aware of any tuts to handle
simply SNMPd traps inside Hobbit.

  Thanks by advance!

Selon Josh Luthman <user-4c45a83f15cb@xymon.invalid>: