|
Size: 788
Comment:
|
Size: 1526
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| = Felix Frank = | |
| Line 6: | Line 5: |
| == Design decisions == | = Design decisions = |
| Line 8: | Line 7: |
| === announce_services === | == announce_services == |
| Line 13: | Line 12: |
| = SNMP trapping = Sun v20z keeps sending mystery traps. Normally, all SP-EVENT traps are supposed to be located under '''.1.3.6.1.4.1.9237.2.1.1.6''' (SP-MasterAgent-MIB::spEvent), we receive traps with the all-too-short OID of '''.1.3.6.1.4.1.9237''' (SP-MasterAgent-MIB::newisys), which is the beginning of Sun's (?) enterprise tree. The cause might be a bug in trapd2. TODO: 1. check back with nino and upgrade the original trapd 2. try and debug our solution 3. apply a workaround: it may well be possible that appending '''.2.1.1.6''' to the OIDs will have the traps make more sense. Still, no variables were ever received along a trap like that, and nothing appeared in any logs on the source machines, so they may still remain inconclusive |
Email: MailTo(ffrank@ifh.de)
Design decisions
announce_services
Queries for RPM packages. The initial idea was a construct like {{{ map { chomp; $installed{$_} = 1 } $rpm -qa;
}}} which would have allowed a fast and elegant check like use_service($service_name) if $installed{$package};. This would, however, require exact package names including version numbers in announce_nagios (like firefox-1.0.8-1.4.1.SL3.1.i386). BRSo i chose a different mode of retrieval of the packages installed: {{{ my $installed = 'XxX'.$rpm -qa; $installed =~ s/\n/XxX/g; }}} to allow a more flexible, yet slower query like use_service($service_name) if $installed =~ /XxX$package/;
SNMP trapping
Sun v20z keeps sending mystery traps. Normally, all SP-EVENT traps are supposed to be located under .1.3.6.1.4.1.9237.2.1.1.6 (SP-MasterAgent-MIB::spEvent), we receive traps with the all-too-short OID of .1.3.6.1.4.1.9237 (SP-MasterAgent-MIB::newisys), which is the beginning of Sun's (?) enterprise tree. The cause might be a bug in trapd2. TODO:
- check back with nino and upgrade the original trapd
- try and debug our solution
apply a workaround: it may well be possible that appending .2.1.1.6 to the OIDs will have the traps make more sense. Still, no variables were ever received along a trap like that, and nothing appeared in any logs on the source machines, so they may still remain inconclusive