Looking to update Nagios Users' API Keys: Suggestions?

[WillH]

Here's our use case:
We have 25 production XIs, and 3 dev and 13 disaster recovery servers.

When we built the initial servers we just applied a backup taken from one of the first servers. This brought over lots of great settings like performance tweaks, but most importantly it brought over all of the then core users and with the same API key per user on each server
So admin user BOB had API Key EVERYWHERE.

But as time has passed, people are coming and going, and our XIs busy enough and specialized enough, that this method is no longer so great.
In addition, we're going to be spinning off part of the company, and that means spinning up their own Nagios infrastructure.

So the question is, does anyone have any suggestions via API or direct manipulation of the mariadb to allow us to create a new user everywhere and give them the same API key? (because it makes automation and administration to not need a new key per server)

[benjaminsmith]

Hi Will,

You can update the user key directly in the database. For example:

Code: Select all

echo "UPDATE nagiosxi.xi_users SET api_key='thenewkey' WHERE  username='nagiosadmin';" | mysql -uroot -pnagiosxi

Let us know if that works for you.

--Benjamin

[WillH]

Thanks Ben. I'll try when I get back to the office.
<evil scientist voice>Then scripting time </evil scientist voice>

[benjaminsmith]

Hi,

Your welcome! Let us know if need anything.

[WillH]

Ben,
All is well, the sql works perfectly.
Sorry for the delay in response, it's been a rollercoaster of support issues the last 2 weeks

[WillH]

Actually,
Just got hit up by the support team with a related question: Where is the auth server data for ldap and AD stored away?
To ensure the "unique" authentication server ID is consistent across XIs.

[benjaminsmith]

Hi,

Haven't in heard from you in a while!

That information is stored in the nagiosxi database (see table xi_options ). However, it's encrypted by the application, so it cannot be viewed with a direct SQL query.

--Benjamin

[WillH]

Thanks Benjamin, that explains why my qry to find it was failing
Sorry for the long delays, July and August are crazy for our industry so we have many, many real and imagined emergencies that pull us away from things we want to do (improve our management of the platforms) to keep the lights on for our business partners or act as their security blankets

[benjaminsmith]

Hi,

You're welcome and I hope you will have time for a well-deserved break after August!

-- Benjamin