Thanks for the response. I'm actually trying to find out if anyone is able to get the feature working while using a non-root user. It works great when I tested it as root, but I've been having a heck of a time with it trying to use a different username. I have a support case open, so we'll see what happens.
I just wanted to provide a follow up to this question, and for the issue that prompted the inquiry.
As part of the IPAM functionality, your user will login to the box and run 'named-checkconf -z -t "<directory to chroot>" <path to config>'. By default, however, non-root users are not allowed to run chroot. As Support explained it:
As to the -t parameter, this is done from a management perspective to allow IPAM to send the config files on the machine into the temp location to prevent the need to overwrite the originals. This then allow it to perform a check to insure everything is ok if the config file is in the chroot directory. As the credential requirements designate it to have permissions for the service, the same applies in this regard to prevent the DNS from being negatively affected if something the application did affected the original config file.
So the issue is that you have to be root to run the named-checkconf as implemented in IPAM, but you don't want to have to use root to monitor BIND from IPAM.
After working with Solarwinds support, they were able to provide me a workaround where we use setcap to add the 'cap_sys_chroot' capability to the named-checkconf utility, via the command 'setcap cap_sys_chroot+ep <path_to_named-checkconf>'. This allows chroot to be called and the utility will function as needed. And of course, all of the other permissions outlined in the Tech Tip have to be correct as well.
Now, I'm no super linux security expert, but this seems to be a legit work around without giving away the key to the castle, as it were. If there's a Linux person out there who knows why this might be an extraordinarily bad idea, please let us know.
