This information is for Intermediate Users: and even so, be careful!
So - Maybe, if you are brave and careful, you can edit the file...
Code: Select all
/usr/local/nagiosxi/html/includes/dashlets/custom-dashlet/custom-dashlet.inc.php
And in there, look for the 'refresh' related settings. There are Default settings there for creating a dashboard. There are also settings that read the saved dashboard.
Line 83 implies that the data is coming from a saved dashlet entry.
Code: Select all
// Vars from input form (or saved dashlet info)
After that, there are some lines that looks interesting. Maybe you can hard code something there instead of using the default code.
Look at line 88.
For maybe a Simple Answer look here and hard code something
Code: Select all
$refresh = (!empty($args["refresh"])) ? $args["refresh"] : 9999;
Also look at line 93.
Code: Select all
$refresh_rate = $args["refresh"] * 1000;
There are refresh and refresh_rate variables. Instead of letting them get the data from a DB, maybe you could hard code them for now until you get time to actually fix the dashboard entries. Basically there is no "FIX" - you have to delete and add them back. Any changes to hard code a number will affect All the Custom Dashlets. But it has to be better than the default of 60 seconds.
Caveat: Any PHP changes should be considered temporary until you deal with your real solution.
If this works for you then stop reading here.
This information below is for Advanced Users: and even so, be careful!
------------------------------- it is like a Brain teaser...
In addition - the Dashboards are stored in the nagiosxi DB but...
You have to figure out the json-like data syntax stored in the nagiosxi database which is a lot of fun. If you do try manually updating the database, be prepared to spend time restoring it back to the original data if and when you get it wrong. You can see dashboard data if you look here in the nagiosxi database. The keyvalue can be thousands of characters long.
Code: Select all
use nagiosxi;
select keyname, keyvalue from nagiosxi.xi_usermeta where keyname = 'dashboards';
You may want to redirect this to a file. It is impossible to see otherwise. I actually only exported the data from my Dashboard Admin user. Just the one field. Then I wrapped it in text that allowed me to import it back after making changes. I kept 2 files. One to import the original data for when what I tried did not work, and one to import my modified data. That saved my bacon while I figured out how to change http to https. I had to also change the size numbers. But I didn't know that yet. Read on.
Here is a Hint on how I changed http to https (slightly obscurred for your protection) I implemented the SSH for the Nagios GUI - And after changing to https for my Nagios XI GUI - every dashboard required me to allow untrusted access. No Fun there. So I figured out a solution that works for me. Below is a snip of some text for a single users dashboard entry in the sql. The solution requires that you do this for all http occurrences. And the data is a very very large single line of text in the database field. For One user. One long line that defines all the dashboards for a single user.
Code: Select all
s:3:\"url\";s:58:\"http://-----------------------------.com/nagiosxi/---.html\"
To change to https you need to understand that preceding the http is a size - s:58 - and that tells how many characters follow in the next location.
So if you add s to http, you have to also increment the preceeding s - as follows:
Code: Select all
s:3:\"url\";s:59:\"https://-----------------------------.com/nagiosxi/---.html\"
See how much fun Nagios XI dashboards are?
For more fun - look at refresh in the data (the word refresh is 7 characters long) and I have 3600 second refresh (the number 3600 is 4 characters long)
I have been able to edit the database when I changed from using http to https. It is quite a long learning curve. I suggest creating a special user in Nagios XI that is used only for making Dashboards. Make the dashboards as the user, and push them to the normal users with settings that prevent them from making changes. If they want to something different, or to change stuff, they can make their own dashboard.
My edit method was to export the single user entry, edit it at the OS level, and Import it again to the database overwriting the previous field. this is how I imported the original data back, and how I pulled in my test data.
Code: Select all
cat restore.sh
#!/bin/bash
set -x
# Syntax to get data back into postgresql
# uncomment to revert
# this is the original data aoutput from sql
#psql -d nagiosxi -U nagiosqry -a -f /tmp/73-dash.txt
# to import the changed file
psql -d nagiosxi -U nagiosqry -a -f /usr/local/src/Restore/73https-dash.txt
The SQL syntax for import was hard to come by since I am not a PG person. I found that google is once again my best friend.
I found my Dashboard Admin user ID in the database - so I could select just that data. To import to PG I learned that I needed to null out the existing keyvalue data before I was allowed to pull in new data. This is what the first line of my text became. Note that the user_id is 73 for Dashboard Admin.
Code: Select all
UPDATE xi_usermeta SET keyvalue = NULL where xi_usermeta.keyname = 'dashboards' and xi_usermeta.user_id = '73';
The second (last) line of the text file starts with (and has no CR/LF - it is a VERY long line)
Code: Select all
UPDATE xi_usermeta SET keyvalue = '
and ends with
Code: Select all
' where xi_usermeta.keyname = 'dashboards' and xi_usermeta.user_id = '73';
and everything between the ' ' marks is the data from the DB field.
For me, this 2 line file is 53,000 characters long. that one field in the DB is long, convoluted, and confusing. But JSON is JSON. Even when it is coded kind of funky.
If I need to do this again, I need to translate to using MySQL next as I am no longer using the postgresql on my system.
Also - Beware this information. You are better off deleting the Dashboard an adding it back than doing this. If you have Many dashboards maybe take this route to do the DB changes... The refresh rate is captured in the database too. Definitely change the 'Default" refresh rate in the php code so any newly created dashboards use 9999 like the code shows. I make that a default. In Custom Dashboards, if I want a refresh, I click the dashboard name again.
Some Nagios employee is most likely going to put a a large disclaimer to do this at your own risk. And Rightly So. Trever - don't bust a gasket and don't skirt the issue.
This can ruin your day if you are not careful. Always save the DB to a file before doing this. Some things are worth a risk. To me the DB update for https was worth it.
If you get nothing else from this information, at least make sure you create a special Dashboard Admin user, and always masquerade as that user to make and deploy dashboards. I know you already do this - The advise is for others that read this far. I edited the DB entry for the one Dashboard Admin user and all the other users inherited the updates. Saved me a ton of trouble after converting to SSH.
I hope you enjoyed my "Book" above. I felt the need to document what I learned and share it. I expect a Dashboard rewrite that will make all this information obsolete at some point, but for now it helps.
Have fun and be careful. I did everything shown above and was successful.
Steve B
It is a great write up, though.