Reportit: New install: script errors

[GlueGuy]

We have a new cacti install, and I'm trying to work the kinks out. I'm getting the following errors on all the reports that are running:

Notice: Undefined index: data_type in /var/www/html/plugins/reportit/cc_view.php on line 683
Notice: Undefined index: data_precision in /var/www/html/plugins/reportit/cc_view.php on line 684

We also get this error on the measurands:

Notice: Undefined index: in /var/www/html/plugins/reportit/lib_int/funct_shared.php on line 354

... which is referring to the "data_type: variable.

It looks like the setup.php script has not run, because that's where (I think) data_type is defined?

This is all with new PIA, and such. Here's the full rundown on what's loaded:

Cacti Version - 0.8.7g
Plugin Architecture - 2.9
Poller Type - Cactid v
Server Info - Linux 2.6.9-89.0.29.plus.c4
Web Server - Apache/2.0.63 (CentOS)
PHP - 5.1.6
PHP Extensions - libxml, xml, wddx, tokenizer, sysvshm, sysvsem, sysvmsg, standard, SimpleXML, sockets, SPL, shmop, session, Reflection, pspell, posix, mime_magic, iconv, hash, gmp, gettext, ftp, exif, date, curl, ctype, calendar, bz2, zlib, pcre, openssl, apache2handler, gd, ldap, mysql, mysqli, PDO, pdo_mysql, pdo_sqlite, snmp, eAccelerator
MySQL - 5.0.82sp1
RRDTool - 1.2.23
SNMP - 5.1.2
Plugins

• Large Site Performance Booster (boost - v4.2)
  Bloom - Cacti Migration Tool (Bloom - v0.6.5)
  Network Discovery (discovery - v1.1)
  docs
  Host Info (hostinfo - v0.2)
  Login Page Mod (loginmod - v1.0)
  Device Tracking (mactrack - v1.1)
  Device Monitoring (monitor - v1.2)
  Realtime Graph Viewer (realtime - v0.43)
  Cacti-ReportIt (reportit - v0.7.2)
  Router Configs (routerconfigs - v0.1)
  Global Plugin Settings (settings - v0.7)
  Network Tools (tools - v0.3)
  Update Checker (update - v0.4)
  WMI Query (wmi - v0.1)

Past problems have often come down to ownership and permissions. However, those parts seem OK (apache, etc.). Any clue to what I'm overloooking?

[GlueGuy]

To answer my own question, and (hopefully) help someone else with this issue....

I found that I can not just transfer the DB from an old(er) Reportit installation. I had to run the "uninstall.php" script to remove remnants of the old Reportit reports.

I then imported all my Reportit templates, and was able to create a new report that runs correctly.

Unfortunately, we have 60-some reports that I now need to re-create.

Would anyone have a suggestion on how to reload/reinstall all our old reports without having to re-create them from scratch?

[browniebraun]

Did you migrate the whole old Cacti database to that new box?
From my point of view this would be the best way to do it.
After this run two additional SQL statements to avoid an upgrade bug in 0.7.2. (see http://forums.cacti.net/viewtopic.php?p=192284#p192284

But if it is a complete new Cacti installation than you can not migrate ReportIt directly from that old box.
Internally ReportIt references always to the local_data_id as the key identifier. Due to the fact that these ones will change in a new installation you will have a logical break.

Best regards
-Andreas-

[GlueGuy]

Did you migrate the whole old Cacti database to that new box?
From my point of view this would be the best way to do it.
After this run two additional SQL statements to avoid an upgrade bug in 0.7.2. (see http://forums.cacti.net/viewtopic.php?p=192284#p192284

But if it is a complete new Cacti installation than you can not migrate ReportIt directly from that old box.
Internally ReportIt references always to the local_data_id as the key identifier. Due to the fact that these ones will change in a new installation you will have a logical break.

Best regards
-Andreas-

Thanks Andreas,

It was a little more complicated. I tried to migrate the whole database and everything using the Bloom plugin. That sort of worked, but not quite.

So then I abandoned that migration, and built a new CentOS 5.5 system with 64-bit architecture (old one was CentOS 4.8 32-bit).

Then I took the last backup from the previous server, and copied it and the DB to the new system. I think it still had the trouble with the data_type and data_precision columns, so I added them in per you suggestion.

I think it is all working now.

Kind regards,