image and html filename issue

[miked73]

Apologies if this has been covered previously, but i am using Cacti 0.8.8c with weathermap version .98 and am having issues with the auto generated/written image and html files for my weathermap.

When the image file and html files are generated for my map (i only have 1) - they always generate as just .png and .html, with no actual filename - just the extension. I tried turning up the log level but i only see the following:
11/30/2017 12:46:14 PM - WEATHERMAP: Poller[0] [Map 25] Network-BWI.conf: Map: /var/www/html/cacti/plugins/weathermap/configs/Network-BWI.conf -> /var/www/html/cacti/plugins/weathermap/output/.html & /var/www/html/cacti/plugins/weathermap/output/.png

I tried adding "HTMLOUTPUTFILE" and "IMAGEOUTPUTFILE" in my map config, but it generates this file and still the .png and .html. This makes it so i can only have 1 weathermap at a time..
HTMLOUTPUTFILE /var/www/html/cacti/plugins/weathermap/output/Network-BWI.html
IMAGEOUTPUTFILE /var/www/html/cacti/plugins/weathermap/output/Network-BWI.png
I know, for cacti it says it ignores these options, but it does write the files - just not quite the way i want. When I look in the output direction i see:
[miked@zenoss output]$ ls -lasth
total 2.8M
136K -rw-rw-rw- 1 cacti cacti 131K Nov 30 12:51 .html <-- auto generated html file
136K -rw-r--r-- 1 cacti cacti 131K Nov 30 12:51 Network-BWI.html <-- html file from config
256K -rw-r--r-- 1 cacti cacti 250K Nov 30 12:51 Network-BWI.png <-- png image file from config
4.0K -rw-r--r-- 1 cacti cacti 4.0K Nov 30 12:51 .results.txt
4.0K drwxrwxrwx 2 cacti cacti 4.0K Nov 30 12:51 .
256K -rw-r--r-- 1 cacti cacti 250K Nov 30 12:51 .png <-- auto generated png image
32K -rw-r--r-- 1 cacti cacti 32K Nov 30 12:51 .thumb.png <-- auto generated thumbnail

Any input on what to look for would be greatly appreciated.

[Howie]

That's interesting... can you look in the weathermap_maps table in the cacti database? It should have something in the filehash field. Quickest thing to fix it if it doesn't is probably just to remove the map from the management screen and add it again. It generates one when a map is added. That forms the basis for the filename.

[miked73]

thank you for the reply...
I will try to see what the weathermap_maps table shows in the cacti database - im sort of a newb at this.
I did try and remove and re-add the map in the management screen a number of times, and it still does the same thing - uses just the extension without file name.

[MiskaM]

Hi all,

I was having the same issue, where the file hash was not created anymore. Only files like described by miked73 where created.
At that point, all consecutively created maps where sharing the same "empty" map-id and only the last one was shown.

I ran mysql and read a bit through it, as I am completely new to SQL:

Code: Select all

cacti:~$ mysql -u root -p
Enter password:

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| cacti              |
| information_schema |
| mysql              |
| performance_schema |
+--------------------+
4 rows in set (0.00 sec)

MariaDB [(none)]> use cacti;

MariaDB [cacti]> show tables;
+---------------------------+
| Tables_in_cacti           |
+---------------------------+
[..snip..]
| weathermap_auth           |
| weathermap_data           |
| weathermap_groups         |
| weathermap_maps           |
| weathermap_settings       |
+---------------------------+
57 rows in set (0.00 sec)

MariaDB [cacti]> SELECT * FROM weathermap_maps;
+----+-----------+----------+--------+----------------------+-----------+----------+--------------------------+----------------------+-----------+--------+-------------+--------------+----------+-----------+
| id | sortorder | group_id | active | configfile           | imagefile | htmlfile | titlecache               | filehash             | warncount | config | thumb_width | thumb_height | schedule | archiving |
+----+-----------+----------+--------+----------------------+-----------+----------+--------------------------+----------------------+-----------+--------+-------------+--------------+----------+-----------+
|  1 |         6 |        1 | on     | core.conf            |           |          | BGP and Upstreams        | efb99d5d29908ac73033 |         0 |        |         500 |          375 | *        | off       |
[...snip...]
| 19 |         1 |        1 | on     | services.conf        |           |          | Sold Services            |                      |         0 |        |         500 |          260 | *        | off       |
+----+-----------+----------+--------+----------------------+-----------+----------+--------------------------+----------------------+-----------+--------+-------------+--------------+----------+-----------+
6 rows in set (0.00 sec)

For data protection, I changed the real file names and title and removed some map-entries.
So in table weathermap_maps, the services.conf entry does not have a filehash inserted.
Reloading the map did not change anything, except the map-id, which was increasing by one every time I unloaded and loaded the map.

I did a search how that 10 byte filehash might have been created, but neither MD5 or SHA are using such lenghts.
So I gave it a try and created a random 20-hex hash:

Code: Select all

MariaDB [cacti]> UPDATE weathermap_maps SET filehash='f86341a433d42bf43697' WHERE id='20';

MariaDB [cacti]> SELECT * FROM weathermap_maps;
+----+-----------+----------+--------+----------------------+-----------+----------+--------------------------+----------------------+-----------+--------+-------------+--------------+----------+-----------+
| id | sortorder | group_id | active | configfile           | imagefile | htmlfile | titlecache               | filehash             | warncount | config | thumb_width | thumb_height | schedule | archiving |
+----+-----------+----------+--------+----------------------+-----------+----------+--------------------------+----------------------+-----------+--------+-------------+--------------+----------+-----------+
|  1 |         6 |        1 | on     | core.conf            |           |          | BGP and Upstreams        | efb99d5d29908ac73033 |         0 |        |         500 |          375 | *        | off       |
[...snip...]
| 20 |         1 |        1 | on     | services.conf        |           |          | Sold Services            | f86341a433d42bf43697 |         0 |        |         500 |          260 | *        | off       |
+----+-----------+----------+--------+----------------------+-----------+----------+--------------------------+----------------------+-----------+--------+-------------+--------------+----------+-----------+
6 rows in set (0.00 sec)

After the next map calculation, the same hash could be found in the output folder.
On the website I also see the map with the correct hash within the URL.

When I tried to create another map, it showed up with an empty filehash again.
Doing the same steps as above with another created filehash worked fine for this one, too.

So this might be a workaround if someone else gets this strange behaviour.
At this point, I don't know a permanent fix in order to get maps created with their respective filehash.

For general information, maybe it helps to find the root cause:
- The weathermap plugin seems to use the www-data user with empty password. As that user was missing at some point in the past, I created it manually. Since then, the plugin is working fine.
- In the past, I played a lot inside the cacti configs and also changed file permissions forth and back. Maybe there is still something broken, but not showing up as an "everyday-error". If anyone knows at which exact point the filehash is being created, I can have a closer look for that particular part or script.

Best regards, Miska

[Howie]

Please add a new map, and check the cacti.log for errors.

The actual contents of the hash doesn't matter - it's just a random string to stop users from guessing the URLs/filenames for other maps.

It's generated when the map is first added. So if you add a map, you should see any errors caused. This was a problem once with older weathermap versions vs newer mysql versions, but that was some time ago. You didn't mention what versions of anything you have...

[MiskaM]

Good morning Howie,

I created a completely new conf-file, but there are no errors at all.

Code: Select all

11/20/2019 06:49:25 AM - SYSTEM STATS: Time:263.7669 Method:cmd.php Processes:96 Threads:N/A Hosts:640 HostsPerProcess:7 DataSources:292076 RRDsProcessed:98269
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] Weathermap 0.98 starting - DEBUG mode is on
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] DEBUG: [weathermap_memory_check@poller-common.php:11] MEM Initial: memory_get_usage() says 37.5MBytes used. Limit is 512M
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] DEBUG: [weathermap_run_maps@poller-common.php:109] Iterating all maps.
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] DEBUG: [weathermap_run_maps@poller-common.php:120] [Map 22] test-2.conf: FIRST TOUCH
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] [Map 22] test-2.conf: Map: /usr/share/cacti/site/plugins/weathermap/configs/test-2.conf -> /usr/share/cacti/site/plugins/weathermap/output/.html & /usr/share/cacti/site/plugins/weathermap/output/.png
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] DEBUG: [weathermap_memory_check@poller-common.php:11] [Map 22] test-2.conf: MEM starting 0: memory_get_usage() says 37.5MBytes used. Limit is 512M
[..snip..]
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] DEBUG: [DrawMap@Weathermap.class.php:3420] [Map 22] test-2.conf: Writing PNG file to /usr/share/cacti/site/plugins/weathermap/output/.tmp.png
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] [Map 22] test-2.conf: Wrote map to /usr/share/cacti/site/plugins/weathermap/output/.png and /usr/share/cacti/site/plugins/weathermap/output/.thumb.png
[..snip..]
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] DEBUG: [weathermap_run_maps@poller-common.php:212] [Map 22] test-2.conf: Wrote HTML to /usr/share/cacti/site/plugins/weathermap/output/.html
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] DEBUG: [ProcessString@Weathermap.class.php:538] [Map 22] test-2.conf: Trace: ProcessString(FEC test, map)
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] DEBUG: [weathermap_run_maps@poller-common.php:274] [Map 22] test-2.conf: TIME: /usr/share/cacti/site/plugins/weathermap/configs/test-2.conf took 0 seconds.
11/20/2019 06:49:25 AM - WEATHERMAP: Poller[0] DEBUG: [weathermap_memory_check@poller-common.php:11] [Map 22] test-2.conf: MEM after 0: memory_get_usage() says 38MBytes used. Limit is 512M

As you can see from the log, the cacti poller finished it's job and the weathermap process starts with the new test-2 map number 22.
The lines I snipped out are only debug messages, telling which data was used and so on, so nothing suspicious there.
The 6th line already shows the empty file names, as no filehash was created when I added the map via the web interface.
There was also no error before this - for example when I clicked the "add" button a moment earlier.

Below are my version numbers. Sorry, was too busy writing the above post, so I forgot to add them.

Cacti version 0.8.8h
Weathermap plugin version 0.98
PHP 5.6.40-0+deb8u2 (cli) (built: Mar 30 2019 20:26:13)
SQL Server version: 10.1.41-MariaDB-0+deb9u1 Debian 9.9

I'm using PHP5 as this is working fine and I saw some posts, where PHP7 could cause some other serious trouble with Cacti.

Best regards, Miska

[netniV]

Are you using the latest version of 0.98 which includes support for PHP 7.2? If not, I would make sure that you definitely have that

[Howie]

Could you check the httpd error.log? I think somewhere you will have a SQL error message from the time when you added the map (not when the poller ran).

But yeah, I would definitely try weathermap 0.98a - there are quite a few bugfixes in there. Definitely some were related to newer MySQL/MariaDB (5.6+). In fact, 0.98a uses completely different database access (PDO vs the old mysql_xxxx functions)

0.98a works with either PHP 5.6 or 7, but only Cacti 0.8.8 versions. I believe those versions have problems with PHP 7, even if weathermap itself doesn't - they are pretty old now. Next weathermap release (eventually) should make this simpler again with Cacti 1.x support.