I'm working on enabling our Nagios system to restart some drivers that periodically stop -- Google drivers, due to API limits exceeded, and almost always in the middle of the night. A simple restart usually does the trick, but I'm trying to sort out a way that the ops on-call person doesn't get paged unless there's a problem that a restart (or two) won't fix.

I've gotten my script working, but only with way more permissions allowed for the Nagios user than I'm comfortable with. Before this testing, the Nagios user had read/compare access to DriverSet.IDM.services, but that's not sufficient for "dxcmd -start" to work.

I don't want to use the tree admin account. During testing, granting full write access to DriverSet.IDM.services (inherited) lets Nagios start a driver, but that is way too much permission for what I want. After Nagios did restart a driver, I checked via iMonitor for any attributes on the driver object modified by the Nagios user, thinking that would let me figure it out. But no luck there.

I also tried using RBS (assigning DirXML-Management for the scope DriverSet.IDM.services) and that works as well, but I'm concerned that it's also potentially too much access if the Nagios account were ever compromised.

So does anyone know what specific attribute(s) I need write access to in order to dxcmd -start a driver? Thanks for any insights (or even a link to TFM I can R).