snmptrap issues with Scalr 1.0 RC3 on fedora 7

[harrisb]

I am running Scalr 1.0 RC3 on a fedora 7 box with net-snmp and net-
snmp-utils (which contains snmptrap) installed.

My farms would start and the logs would show the instances had
initialized, but never finished host startup. After some
experimentation, I was able to correct this by forcing SendTrap in app/
src/LibWebta/library/NET/SNMP/class.SNMP.php to use port 162 instead
of 161. Now things seem to be running just fine, although I'm still
testing.

I am unfamiliar with snmp and snmptrap - should /usr/bin/snmptrap have
defaulted to port 162, making this a fedora-specific issue?

While I'm on the subject, I'm sure snmp/snmptrap are configured
correctly on the farm instances, but I'm not so sure about my Scalr
server. Does snmpd and/or snmptrapd need to be running? Are there
any specific configuration settings needed for either of these
daemons? I have them running in their default configuration, but the
snmptrap problem mentioned above makes me wonder what else I might
have missed.

Many thanks for your patience!

[Alex Kovalyov]

162/udp is a standard port for snmp traps and its being used on scalr.net

cat /etc/services|grep 162
snmptrap 162/udp snmp-trap # Traps for SNMP

> While I'm on the subject, I'm sure snmp/snmptrap are configured
> correctly on the farm instances, but I'm not so sure about my Scalr
> server. Does snmpd and/or snmptrapd need to be running? Are there
> any specific configuration settings needed for either of these
> daemons? I have them running in their default configuration, but the
> snmptrap problem mentioned above makes me wonder what else I might
> have missed.

Those need to be running on instances only.
Instance->Scalr communication goes over http.
I advise you to check syslog on one of instances - likely it's unable to
communicate with scalr/event_handler.php

[harrisb]

Instance->Scalr with scalr/event_handler.php is working fine.
Before I modified app/src/LibWebta/library/NET/SNMP/class.SNMP.php to
use port 162, the syslog on my instances showed requests coming in to
snmp on port 161. This was true even if I ran /usr/bin/snmptrap from
the command line on the Scalr server. That is, a command like
/usr/bin/snmptrap -v 2c -c 1234567890abcd 75.101.102.103 "" SNMPv2-
MIB::snmpTrap.12.1 SNMPv2-MIB::sysName.0 s "123456789012"
would fail, coming in to the instance on port 161, while
/usr/bin/snmptrap -v 2c -c 1234567890abcd 75.101.102.103:162 "" SNMPv2-
MIB::snmpTrap.12.1 SNMPv2-MIB::sysName.0 s "123456789012"
would succeed. Thus, /usr/bin/snmptrap on fedora 7 is defaulting to
port 161.

Again, I assume this is a fedora problem, but adding the port to the
SendTrap function cured the problem for me and shouldn't break it for
anyone else.

On Dec 11, 11:46 am, Alex Kovalyov <alex.koval...@gmail.com> wrote:
> 162/udp is a standard port for snmp traps and its being used on scalr.net
>
> cat /etc/services|grep 162
> snmptrap        162/udp         snmp-trap       # Traps for SNMP
>
> > While I'm on the subject, I'm sure snmp/snmptrap are configured
> > correctly on the farm instances, but I'm not so sure about my Scalr
> > server.  Does snmpd and/or snmptrapd need to be running?  Are there
> > any specific configuration settings needed for either of these
> > daemons?  I have them running in their default configuration, but the
> > snmptrap problem mentioned above makes me wonder what else I might
> > have missed.
>
> Those need to be running on instances only.
> Instance->Scalr communication goes over http.
> I advise you to check syslog on one of instances - likely it's unable to
> communicate with scalr/event_handler.php
>

[Alex Kovalyov]

Weird! Thanks for letting us know.
I've put a note on the matter in the installation guide until we test and
patch it.

Alex