In my system I am attempting to do authenticaion via the roleMap in the authentication.conf file in the pooling space. To make this work I have 2 instances of the authentication.conf file, one in the pooling space containing all the data BUT the encrypted password, and one in etc/system/local which ONLY contains is the encrypted password.
When I start the server, it picks up all the values as I expect and runs as anticipated. BUT... when I look at the etc/system/local file immediately after the restart, it has been populated with roleMap data. Because of that, on subsequent restarts, the search head no longer picks up the pooled version of the roleMap, but the local one with the unwanted role stanza. I need to keep the etc/system/local file from being written to so that it only contains the password.
I would also note that using the gui for role modification in this configuration also creates a etc/system/local entry, but that is not what is happening in this case.
Any idea what is updating this file and how to keep it from doing that? I have tried to make the file read-only (chmod 400) but it gets modified anyway and the permissions reset to read-write (600).
Thanks for any suggestions -
I am also trying to achieve the same thing.
The encrypted information in system/local and rolemap info in shared authentication.conf, but after the restart the local authentication.conf gets edited. Did you achieve a solution for your problem?
Do you mind sharing it here?
We do the same thing. Encrypted password in the ../splunk/etc/system/local/authentication.conf and the rest of the information in an app that is used by all the searchheads in the pooled are /sharednfs/splunk/etc/apps/searcheadapp. This has worked fine for us in version 4.2.x and 4.3.2. Once we do this we can no longer use the gui to update the information because everything is controlled by the app.
You could use something like a "staging server" / admin-server ? A splunk instanse where you define common / shared knowledge settings, like authentication, authorize.conf etc etc that you later on, distributes to the search-heads / indexers via a custom app.
In search head pooling, only etc/apps and etc/users on your shared storage are shared by the search heads on the pool.
Search heads still use their own local etc/system directorys.
Agreed. That is why the RoleMap information needs to be in the shared directory only. On startup, the system reads and combines the config files on both the local and shared directories, and the local copy RoleMap stanza trumps the shared one. The shared one is the one that is maintained so I need to keep the local one from getting a RoleMap value and the system on startup is determined to copy values locally. My question is how to avoid that.