[update] net-snmp 5.7.2.1 + improvements

[jul_bsd@…]

• update
• startup as localhost only
• notes on initial setup

[yngwie.chou@…]

Note the following line for snmpd executable is incorrect:

startupitem.executable   ${prefix}/bin/snmpd -c ${prefix}/etc/snmpd.conf 127.0.0.1

actually snmpd will be installed in ${prefix}/sbin instead of ${prefix}/bin

[jul_bsd@…]

sorry. fix. I add also pid file but for some unknown reason, still get in system.log

Mar 30 14:55:07 host com.apple.launchd[1] (org.macports.net-snmp): Throttling respawn: Will start in 10 seconds

[yngwie.chou@…]

Replying to jul_bsd@…:

sorry. fix. I add also pid file but for some unknown reason, still get in system.log

Mar 30 14:55:07 host com.apple.launchd[1] (org.macports.net-snmp): Throttling respawn: Will start in 10 seconds

Not sure if using daemondo will be a good idea. If I run snmpd without launchctl or daemondo, no above log will be reported.

Also, I found that if I run snmptrapd with launchctl either with or without deamondo, the following log will be reported:

Apr  1 00:46:35 host snmptrapd[23524]: couldn't open udp:162 -- errno 48 ("Address already in use")

and a tiny suggestion for the plist name:

Sicne the net-snmp package also contains snmptrapd, maybe use:

org.macports.net-snmp/org.macports.net-snmp.snmpd.plist

might be than:

org.macports.net-snmp/org.macports.net-snmp.plist

because we might need to have:

org.macports.net-snmp/org.macports.net-snmp.snmptrapd.plist

for snmptrapd as well.

[yngwie.chou@…]

Hi jul_bsd,

Ok, I found the answer:

With damondo, need to use -f option.

[jul_bsd@…]

yeah, the throttling respawn is annoying but it normally shows because demonizing too fast ​https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html see required behaviors

Macports does not provide any way to create multiple startupitem, need to include the plist in the port for now. 'daemondo -h' does not document any -f switch or do you mean snmpd which correspond to the do not daemonize.

If you have a suggested plist for snmpdtrapd, please join it, eventually with a text notes. I'm not using it.

Joined patch w '-f'

[jul_bsd@…]

A strange thing, as I did uninstall/reinstall for the previous patch, this time I got cpu polling working. I have a cacti installed and before, nothing was output by the cpu usage graph and now, I got data.

maybe there is something which is not consistent for every installation...

[yngwie.chou@…]

Replying to jul_bsd@…:

A strange thing, as I did uninstall/reinstall for the previous patch, this time I got cpu polling working. I have a cacti installed and before, nothing was output by the cpu usage graph and now, I got data.

maybe there is something which is not consistent for every installation...

Thanks a lot jul_bsd! (My apology, I should have done this myself, but I'm not quite sure how to generate the patch file)

For the CPU polling, I would guess it is caused by the listening address. The current default implementation is to isten on 127.0.0.1 only. My approach is specify "udp:161" instead of "127.0.0.1", so that snmpd will listen to *:161.

[jul_bsd@…]

No problem. I choose to put sane/secure default on installation to avoid exposing unnecessary stuff. After, it depends a lot on what is the user input on snmpconf As also an OpenBSD user, I think it's better if system/package can by default offer secure/sane default and it's up to user to adjust is need but if he does not, he shouldn't be to threatened. Maybe, we can reinforce the notes with text like

"To open snmpd, just edit /path/to/plist and remove 127.0.0.1. You are advise to use snmp V3 for authentication and read-only configuration unless necessary

eg

$ snmpwalk -v3 -On -u <user> -l AuthPriv -a SHA -A <auth_password> -X <encryption_password> <HOST_IP> system "

[jul_bsd@…]

I just add the previous comment in the note to be crystal clear.

[ryandesign (Ryan Carsten Schmidt)]

Thanks for the patch.

I see you updated to the proper 5.7.2.1 tarball. I had not done so before because the tarball had been ​packaged incorrectly, but I see they re-packaged the tarball correctly on 2014-03-10 without mentioning that in the ticket.

Your patch re-enables parallel building, but nothing has changed in the code that would have solved the ​parallel building problem so I don't want to make that change.

In the notes you added to the port, you suggest the user can edit the launchd plist. We don't want to recommend users to edit files installed by the port, because those changes will be lost the next time the port is upgraded.

[jul_bsd@…]

not aware of the two tickets. On my box (10.9.2 MBP), it builds/destroot/run ok. Probably right to disable 24 parallel jobs...

As for plist, the question is how you handle options for it? is it possible? or do we directly listen everywhere. user still have to run configuration utility but maybe less awareness.

[jul_bsd@…]

any feedback?

[ryandesign (Ryan Carsten Schmidt)]

I committed several changes to net-snmp in r129760 which should reduce the changes from this ticket that are still needed to:

• use conf file
• use pid file (any particular reason a pid file is needed?)
• add notes

[jul_bsd@…]

there is also install.asroot yes

I don't remember exactly why I put the pid conf file but I'm not sure it is generated else and I think it was better for launchd.

[jul_bsd@…]

One problem seems linked with Yosemite. confirmed after a full system reinstall, still happen

Mar 12 19:09:44 HOST com.apple.xpc.launchd[1] (org.macports.net-snmp): The Debug key is no longer respected. Please remove it.
Mar 12 19:09:44 HOST com.apple.xpc.launchd[1] (org.macports.net-snmp): This service is defined to be constantly running and is inherently inefficient.
Mar 12 19:09:45 HOST com.apple.xpc.launchd[1] (org.macports.net-snmp): Service only ran for 1 seconds. Pushing respawn out by 9 seconds.
Mar 12 19:09:45 HOST.local ReportCrash[63714]: Saved crash report for snmpd[63792] version ??? to /Library/Logs/DiagnosticReports/snmpd_2015-03-12-190945_HOST.crash
Mar 12 19:09:55 HOST com.apple.xpc.launchd[1] (org.macports.net-snmp): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
Mar 12 19:09:55 HOST.local ReportCrash[63801]: Saved crash report for snmpd[63800] version ??? to /Library/Logs/DiagnosticReports/snmpd_2015-03-12-190955_HOST.crash

Problem is with current port in tree and still happen with patch. Debug is not a setting of Portfile AFAIK

[ryandesign (Ryan Carsten Schmidt)]

Replying to jul_bsd@…:

Mar 12 19:09:44 HOST com.apple.xpc.launchd[1] (org.macports.net-snmp): The Debug key is no longer respected. Please remove it.

Debug is not a setting of Portfile AFAIK

That's a bug in MacPorts base. I filed #49990 for this.

[chrstphrchvz (Christopher Chavez)]

net-snmp has since been updated by the maintainer to 5.7.3 and then to 5.8. Is this ticket still relevant?