FreeBSD / cacti ports / net-snmp hosts / Counter64 issues

[kiw0r]

Hi there,

I have a strange problem with cacti that is comming to make me mad...

I have installed a fresh cacti using freebsd ports and it seems that now some interfaces graphs are now showing only no traffic at all, version used is :

$ pkg_info | grep cacti
cacti-0.8.6g_41 Web-driven graphing interface for RRDTool

The strangest thing is that *was* working before upgrading to 0.8.6g what ever net-snmp host / library used...

So wtf with this version ?
(note that rtg/cricket/mrtg *see* the traffic, but cacti has decided to not se any traffic at all excepted on switches....)

/Xavier

[rony]

I'm hearing some people having issues with FreeBSD ports and the cacti version available. It has been modified from the original source, so I really have no clue what has been changed at this point.

What version does the ports say it has?

Does anyone have the maintainers email address?

[kiw0r]

I'm hearing some people having issues with FreeBSD ports and the cacti version available. It has been modified from the original source, so I really have no clue what has been changed at this point.

What version does the ports say it has?

Does anyone have the maintainers email address?

Maintainer email address is sem@FreeBSD.org ...

Here is some extract of freebsd port make file :

Version of cacti used : 0.8.6g

Patchs added :

# Vendor's patches
PATCH_SITES= http://www.cacti.net/downloads/patches/${PORTVERSION}/
PATCHFILES= short_open_tag_parse_error.patch \
graph_properties_zoom.patch \
script_server_snmp_auth.patch \
mib_file_loading.patch

There is nothing more than that... excepted a patch to move db setting in a sperate file...
That should be good to add maybe in mainstream

All port is in cvsweb : http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/cacti/

Any clues ? I am really going mad...

Also, I have tryed several times cactid on freebsd as web.... with bad result (nothing is polled neither rrd files are not updated as well... :/)...

[rony]

There is nothing more than that... excepted a patch to move db setting in a sperate file...
That should be good to add maybe in mainstream

The next major release of cacti, under heavy development, 0.9.0, does this. I will talk to the other developers about doing this in the 0.8.6 version. I do agree, this needs to be done.

But, back to your issue. Have you imported any templates? Have you set logging to debug and looked at the cacti.log?

[kiw0r]

But, back to your issue. Have you imported any templates? Have you set logging to debug and looked at the cacti.log?

I didn't imported yet any templates... I have just set debug. You can get poller.php log file here :
https://stats.openvisp.net/cacti/log/cacti.log

[georgew]

I have reported the freebsd problems to the list numerous times.

Freebsd 5.4, with a fresh and current ports collection, is unable to properly run the poller out of cron.

Everything works when you run it by hand, very little works
whenyou run it from cron.

I have had to write a script to loop on running the poller every 5 minutes.

As far as I can tell, it appears to be a environmental problem, several things that php does don't work out of cron. When php runs perl code for example. Of course when you run it by hand, other problems arise.

I don't know what the problem is. Clearly the port maintainer isn't testing the port on a fresh install, or his environment is masking the syptom, or he isn't even testing it at all. I've never had this problem before, but ever since 5.4, all of my cacti installs have required hand-hacks.

The port maintainer didn't "modify" the program, he simply packaged it for a freebsd-friendly installation. This means installing things in the proper place, etc. Every unix system has specific places for things, it is normal for each OS to have a different organization than linux. That doesn't mean it has been modified.

I think the FreeBSD problem is a php environment problem. The php port maintainer is not insalling a php.ini at all, so people are having to hack that together on their own to use php with nearly anything. I see a lot of problems that seem to flow from that problem.

It seems to be a symptom of FreeBSD being second to linux, all of the developers are spread thin.

Too bad too, as FreeBSD is the choice of the hard core pros. These are just the sorts of things that don't happen under freebsd... I've never had a freebsd box hacked, but linux boxes seem to be the secondary hacker target, just behind microsoft.

But it will get fixed some day I'm sure...

[brian]

You're running
snmpd out of ports, and not
bsnmpd that ships w/ 5.4, right?


I had to add
bsnmpd_enable="NO" # Run the SNMP daemon (or NO).
bsnmpd_flags="" # Flags for bsnmpd.
snmpd_enable="YES"
to my rc.conf.

Seems obvious but I missed it at first.

[kiw0r]

I have reported the freebsd problems to the list numerous times.
Freebsd 5.4, with a fresh and current ports collection, is unable to properly run the poller out of cron.

Strange, this is working for me (tm)

I don't know what the problem is. Clearly the port maintainer isn't testing the port on a fresh install, or his environment is masking the syptom, or he isn't even testing it at all. I've never had this problem before, but ever since 5.4, all of my cacti installs have required hand-hacks.

Seems that even when upgrading the port I get some graphs that has stopped to be generated... I am even considering to use portdowngrade...

Too bad too, as FreeBSD is the choice of the hard core pros. These are just the sorts of things that don't happen under freebsd... I've never had a freebsd box hacked, but linux boxes seem to be the secondary hacker target, just behind microsoft.

But it will get fixed some day I'm sure...

I have same problems is some languages (Pike for example) where I get some bugs only on Freebsd for years (more than 3 years...) just because I use FreeBSD....

[Towneh]

I've been using the latest release of Cacti on FreeBSD 5.4, which has been working perfectly. However, this is not from the ports collection but from the cacti.net downloads page.

So it would seem the issue is with the port itself. Worst comes to worst you can always try the tarball from the site

[brian]

kiw0r:

The poller does work just fine, out of ports or not.

The directions are broken, not the poller.

The readme (even from ports) states

7. Add a line to your /etc/crontab file similar to:

*/5 * * * * cactiuser php /var/www/html/cacti/poller.php > /dev/null 2>&1


1. you can't specify a user in this way
2. php won't be in any user's path

write

*/5 * * * * /usr/local/bin/php /usr/local/share/cacti/poller.php > /dev/null 2>&1

in whichever user's crontab

or
/usr/local/bin/php5/php
or
/usr/bin/php
or
whatever

[kiw0r]

kiw0r:

The poller does work just fine, out of ports or not.

The directions are broken, not the poller.

Humm...

I use /etc/crontab for poller :

*/5 * * * * cacti /usr/local/bin/php /usr/local/share/cacti/poller.php > /dev/null 2>&1
or
*/5 * * * * root /usr/local/bin/php /usr/local/share/cacti/poller.php > /dev/null 2>&1

I currenly use php 4.4.1 port, and I really syspect something strange with cacti because Catalyst switch gets correct stat, net-snmp are polled (whatever the method I use) but on NetSNMP the interfaces statistics gets borken... and shown empty stats...

PHP4 modules installed :

# pkg_info | grep php4
php4-4.4.1_3 PHP Scripting Language (Apache Module and CLI)
php4-bz2-4.4.1_3 The bz2 shared extension for php
php4-gd-4.4.1_3 The gd shared extension for php
php4-gettext-4.4.1_3 The gettext shared extension for php
php4-iconv-4.4.1_3 The iconv shared extension for php
php4-mbstring-4.4.1_3 The mbstring shared extension for php
php4-mcrypt-4.4.1_3 The mcrypt shared extension for php
php4-mysql-4.4.1_3 The mysql shared extension for php
php4-openssl-4.4.1_3 The openssl shared extension for php
php4-pcre-4.4.1_3 The pcre shared extension for php
php4-posix-4.4.1_3 The posix shared extension for php
php4-session-4.4.1_3 The session shared extension for php
php4-snmp-4.4.1_3 The snmp shared extension for php
php4-xml-4.4.1_3 The xml shared extension for php
php4-zlib-4.4.1_3 The zlib shared extension for php

This really puzzle me a lot... and going to make mad :/

/Xavier

[kiw0r]

$ snmpwalk -v 2c -c read2oav gw.core-vel-1.kazar.net .1.3.6.1.2.1.31.1.1.1.10.5
IF-MIB::ifHCOutOctets.5 = No Such Object available on this agent at this OID

Why does 0.8.6g / 0.8.6h does use HCOutOctets when doing 95percentile Bits/sec ?

This is really new behavior isn't it ?

And why doesn't fall back to old system (eg Counter32) ???

Thanks !

[georgew]

You're running
snmpd out of ports, and not
bsnmpd that ships w/ 5.4, right?


I had to add
bsnmpd_enable="NO" # Run the SNMP daemon (or NO).
bsnmpd_flags="" # Flags for bsnmpd.
snmpd_enable="YES"
to my rc.conf.

Seems obvious but I missed it at first.

Yes, I missed this too... another pet peve of mine is the inconsistancy in after-install instructions from FreeBSD ports. Some apps tell you what you need to know, others let you spend days finding all of the config issues on your own.

If port maintainers maintain a port on a machine that has already been installed, then shame on them for not testing in a new environment. That is the common problem, so they forget to tell us about the 5 or 6 config files you need to create or edit. This has only happened for the last two years... before that FreeBSD was much better about the ports being working and/or documented...

I will test with your suggested changes to my rc.conf file... as I did miss those. That would explain some of the other problems I have noticed, such as the localhost not reporting on memory usage.

I did spot the bad cron example, but I thought that was a linuxism slipping in, it never occured to me to try /etc/crontab.... I generally just stick to crontab -e, which uses /var/cron/tabs/username... I keep forgetting /etc/crontab exists...

I'll report back if this fixes things... My bad for not paying attention to the list of port daemons that needed to be enabled in cron... though clearly this is missing from the port post-install instructions...

FreeBSD needs to create a way to handle after-port-install instructions. All dependancies get installed without giving the user time to read the post-install instructions. The top port should reproduce post-install instructions for all lower ports, and the post install instructions need to include all required rc.conf entries.


Thanks!
George

[georgew]

Ok, first of all thanks to kiw0r and brian for the pointers on /etc/crontab and /etc/rc.conf. Turns out neither of these solved the problem at all.

poller works the same as always. everything works, but it gets bad data back from the perl scripts.

Turns out I had already fixed my rc.conf. The /etc/crontab with the username field works identically to /var/cron/tabs/username. So that fixed nothing. Of course you need the php path, but I know that when I created my first crontab line.

I get graphs fine, except for graphs relating to perl scrips that don't return any data, unless I run poller by hand.

So all of my perl scripts are failing, unless I turn off the cron line, and run poller every 5 minutes by hand. So that is what I will do till someone figures out the bug.

But to be clear, Poller is fine, but it cannot run perl scripts under freebsd, and successfully get any data back. The scripts /do/ seem to be running... though I would have to insert debug code to prove it.

Oh, when I run poller by hand, the perl scripts have to be executable. Normally they are not set with the execution bits on.

These are the scripts in /usr/local/share/cacti/scripts.

But in summary, I stand behind my original statement that cacti is broken on FreeBSD. not 100% broken, more like 10% broken. I'm sure it's not really the cacti code to blame, most likely a php/perl/freebsd problem.

I would love for someone prove me to be wrong... I would prefer to simply be the dumbass that can't configure cacti. But I'm not so sure this is the case. I think something is broken.

And one of the times I installed, I instaled from the cacti site, skipping ports. So you guys saying it's "ports" are wrong. It's broken either way.

Now if it's php, then it's an issue of what php you are using.... If you think it works fine under freebsd, then give me a copy of your php.ini file, perhaps I have something dorked in there...

Is anyone on Freebsd getting a memory usage grapg for localhost (that works)?

[kiw0r]

Most of problems seems to comming from usage of 64 counters in new versions.

I don't know where they are comming from but the "hack" I got from net-snmp archives and mailing lists doesn't solve anything.

I am asking Cacti developpers, is there any clues to not use those counters what ever snmp tree show them or not ?

By the way which the changelog doesn't show that ?

About Geogew, I have no problems at all with local stats whatever I use or not crontab... Issue is really because of usage of 64bits integer in interfaces counter that net-snmp don't allow and it is not working per default...