How does precedence work for authorize.conf?

[ddrillic]

On the deployer server we have the authorize.conf under /opt/splunk/etc/shcluster/apps/key_all_authentication/local and on the search heads we ended up having authorize.conf under etc/system/local. Apparently the one under etc/system/local takes precedence, which seems to me a bit strange as search time precedence order starts usually with the apps...

What am I missing?

[bheemireddi · Accepted solution]

Yes, Splunk applies different precedence for the configuration files in global context vs app/user context. Below link should explain in detail. Since authorize.conf is a system configuration file and not a user/app context.

http://docs.splunk.com/Documentation/Splunk/6.6.2/Admin/Wheretofindtheconfigurationfiles

Precedence order within global context:
When the context is global (that is, where there's no app/user context), directory priority descends in this order:

1. System local directory -- highest priority
2. App local directories
3. App default directories
4. System default directory -- lowest priority

[ddrillic]

Perfect - thank you.

[bheemireddi]

Configs under system/local always gets precedence over the apps//system/local.
In regards to authorize.conf, since these are clustered search heads and you use deployer, would be better to use under apps to avoid confusion.

[ddrillic]

Fair enough. Since it's search time the following, in my mind, should apply

Configuration file precedence

It says

Precedence order within app or user context

When there's an app/user context, directory priority descends from user to app to system:

1. User directories for current user -- highest priority
2. App directories for currently running app (local, followed by default)
3. App directories for all other apps (local, followed by default) -- for exported settings only
4. System directories (local, followed by default) -- lowest priority

An attribute in savedsearches.conf, for example, might be set at all three levels: the user, the app, and the system. Splunk will always use the value of the user-level attribute, if any, in preference to a value for that same attribute set at the app or system level.