BotFodder / dpdiscover

DPDiscover Cacti Plugin
http://runningoffatthemouth.com/?p=1067
GNU General Public License v2.0
5 stars 2 forks source link

Manually added device #2

Closed Fabrice35 closed 8 years ago

Fabrice35 commented 8 years ago

Hi,

I have three problems when manually add device :

1) When I manually added device from discover tab, values "Ping Timeout Value" and "Ping Retry Count" are zero. 2) The name of the description field is "FQDN", while the option is not checked in the settings "DPDiscover". 3) When a device is discovered and added to cacti, it goes into "known" in the protocol column. When the device is added manually, it remains "CDP"

Thank you very much.

Fabrice

BotFodder commented 8 years ago

1) That's a bug and once I get a chance to go through the code, I'll fix it. It's probably a matter of just pulling the defaults out of the settings before trying to add the device.

2) Hm. The brain is not working well today but I'm guessing I need to either use FQDN or DNS depending on the setting (I'll have to review a bit to figure out what it should do). Again, a bug ... this one might take a bit more to fix since I'll have to look at a bit more of the code and handle conditions properly.

3) This is kind of by design. The "discover" tab results (which you should probably clear out once in a while because it's subject to cruft - there's a thing in System Tools for this I think) are all figured out at the end of a run - it's not updated live. So, if a device is successfully added during a run of dpdiscover, it's considered "known". When you add it manually, the status in the "discover" tab is kept as whatever discover protocol it was discovered as ... until the next run of dpdiscover, at which time it should show up as known.

I think I can change this to be a little more timely (essentially change the status when you go through the add process). This I consider less of a "bug" and more of an "enhancement".

I'll see if I can get them fixed early next week.

Fabrice35 commented 8 years ago

3) You're right. Yet I thought doing a discover (findhosts.php) ... Manually added devices are now seen as "protocol known" .... Probably after the polling DPDiscover ...

Sorry.

BotFodder commented 8 years ago

1) This should be fixed in repo (only dpdiscover.php changed).

2) This too should be fixed in repo.

3) This I can't "fix" ... not easily, anyway. The "Add" button pops you into the "host.php" from the main cacti and lets you preview the additions before actually adding the new device. There are problems with either of the solutions in my head (either I have to duplicate the "add" code in the main cacti or you end up with the table saying you added something even if you don't finish the add), so I'm leaving as is.

If you are comfortable with pulling the changes from the master repo, please let me know if the results for 1 and 2 meet with your expectations so I can close the issue with a clean conscience. I'll update the version numbers in setup.php and README just before I close the issue.

Fabrice35 commented 8 years ago

It's just perfect ! The "Description" field and the "ping" values are correctly added.

thanks a lot.

BotFodder commented 8 years ago

Closing as "fixed in 1.50". :)

BotFodder commented 8 years ago

Hey - can you do me a favor and pull the master repo and test a change I made?

If you add a device from the report with the provided "description" and "hostname", next time you load the report it should change the "Add" button to the word "ADDED".

If you change either of those values, it would be unable to determine if the host was added as everything stands now.

Perhaps this would be an acceptable alternative to changing the value to "Known" from a discovery protocol?

If it works, I'll update the setup.php/README for a new version.

BotFodder commented 8 years ago

Actually hold off on this I screwed something up ... I'll let you know though when it's ready to test.

BotFodder commented 8 years ago

Okay this should be ready for testing. I actually found a host to test it with on one of my servers, and it worked as I expected.

Fabrice35 commented 8 years ago

ok, I'll test as soon as possible. But I have a little problem ...

In the "discover" tab, I had listed materials that were not on the network or has been renamed. It seemed no longer be updated. I then did a "./findhosts.php php -r -f -d", and since I do not have any equipment in the list! I get the same thing after "php ./findhosts.php -f -d".

At the end of discover, I receive an email with the list of new materials but not added. Yet I have no filter ("Parental Filter" or "Exclude Host Filters")

I then programmed while a discover every hour (Poller Frequency), but I obitient this msg in cacti logs: " 02/23/2016 3:22:43 PM - POLLER: Poller [0] DP Discover is now running 02/23/2016 3:22:43 PM - POLLER: Poller [0] DP Discover ended: from finding HAD DPDiscover Templates, exiting. "

What is happening ?

BotFodder commented 8 years ago

If it's actually: DP Discover ended: had issues finding DPDiscover Templates

it means that somewhere along the line it failed to find a DPDiscover Template.

You probably know, but as a full explanation:

Under "Templates" you should see "DP Discover Templates" which is where you match up a "Host Template" with some text you'd expect to see in the System Description as pulled via SNMP.

Did you do an uninstall/install of the plugin? It may have wiped the table on you. A simple upgrade (which shouldn't require anything on your part) shouldn't make any database modifications.

You can run:

SELECT plugin_dpdiscover_template.*, host_template.name FROM plugin_dpdiscover_template LEFT JOIN host_template ON (plugin_dpdiscover_template.host_template=host_template.id)

On your MySQL Cacti database and see what the plugin should see. The plugin of course wants some data there (it does an array and length check).

And if you don't see the "DP Discover Templates" option, double check the user's (if you're not "admin") "Realm Permissions".

Fabrice35 commented 8 years ago

sorry ... I completely forgot templates. I had indeed uninstall / reinstall the plugin because the "devices" were detected but not added.

I recreated the templates and a revived discover (there for an hour ...).

Fabrice35 commented 8 years ago

It's good for the addition. The "ADD" button changes to "ADDED" and the protocol column.

I was really upset yesterday when I found that there were more devices from the list ... I never been able to get the list in "cli" mode (findhosts) ... had to wait the polling for devices that appear. Is this the normal operation ?

It started when I did a "findhosts -r", hoping to update the list. For it seems that the discovered devices are not updated (name change ...) Are there a way to force this update?

BotFodder commented 8 years ago

You could try using:

php -q findhosts.php -r -f

To "force" the run. In addition, adding "-d" will provide you command line debugging output that might help you figure out why things aren't working the way you want.

I'm guessing what's happening here is that:

  1. Arguments are parsed and the -r causes the table to be dropped and recreated.
  2. However, findhosts.php then checks to make sure it's okay to run, and does all the math/checks to ensure that it's not currently running, and sufficient time has passed since it last ran, and decides (silently, if you don't use the -d option) not to continue past that point.

Note that using the -f, while forcing a run, won't update "last run" times, so the next run will occur as originally scheduled after the last non-forced run time.

In addition, if you use the -d option, findhosts.php won't actually add any hosts to Cacti or the "discover" tab report (it will only report what it would have done if it wasn't in a "debug" situation). Perhaps at some point I'll give it a numerical option so that you can get the text and still update the database, but it's not a high priority thing right now.

So - what you'd want to run to clear out the table and rebuild it fully is probably to just run "findhosts.php -r -f" and wait for a little bit.

Closing this issue - if you have additional questions, please do not hesitate to open new issues.