config file precedence vs savedsearches

[emzed]

The main question is - Is the config file precedence applicable to the savedsearches.conf file?

The documentation for savedsearches.conf states that I should read the configuration file precedence.

https://docs.splunk.com/Documentation/Splunk/9.3.0/admin/Savedsearchesconf
https://docs.splunk.com/Documentation/Splunk/9.3.0/Admin/Wheretofindtheconfigurationfiles

According to the config file precedence page, the priority of savedsearches is determined by the application/user context, it is a reverse lexicographic order. That is, the configuration from add-on B overrides the configuration from add-on A.

I have savesearch defined in addon A (an addon from Splunkbase). There is a missing index call in the SPL. I created app B with savedsearches.conf. I created an identically named "stanza" there and provided a single parameter "search=". In the parameter I put a new SPL query that contains the paricula index call.

I was hoping that my new add-in named "B" would override the search query in add-in A, but it didn't. Splunk reports that I have a duplicate configuration.

I hope I described this in understandable way.

I must be missing something.

[dural_yyz24]

Have you eliminated app permissions/shares at the user level?  The saved search may run as user or as a default account(noone).

The btool has a switch for "-- user" which I'm not 100% familiar with but the docs do warn about having to use the switch "--app" as well, but then says the switch user does not consider knowledge object permissions when evaluating the user.

[richgalloway]

Your settings look good to me.

The first problem may be with the documentation.  Submit feedback on the docs page telling them that btool doesn't match the documentation and they should update the docs.

I'm not sure what can be done about the second problem other than ignoring it.

[richgalloway]

Despite the documentation, I've never seen reverse-lexicographic order applied to .conf files. 

If you need to override the settings in an app, the best way is to specify the new setting in the same app's /local directory.  If that's not possible, use an app that sorts before the app you want to override.

As always, btool is your friend.  It will tell you what settings will apply before you restart Splunk.

splunk btool --debug savedsearches list <<search name>>

[emzed]

I have my reasons. I don't want to impose changes on the local.

I need to use the original addon and add my correctly named addon to it, which would override the search= parameter in original one.

Orig add-on is
Splunk_TA_openldap

default/savedsearches.conf
[Update openldap_user_lookup KV Store collection]
request.ui_dispatch_app = search
disabled = 0
alert.track = 0
cron_schedule = */2 * * * *
dispatch.earliest_time = -4m
dispatch.latest_time = -2m
enableSched = 1
search = sourcetype="openldap:access" operation="BIND" | dedup conn cn | table conn op cn | rename cn as user | lookup openldap_user_lookup conn, op OUTPUTNEW _key AS _key | outputlookup append=t openldap_user_lookup

My append is
A10_aaa_ta_openldap

default/savedsearches.conf
[Update openldap_user_lookup KV Store collection]
search = `openldap_index` sourcetype="openldap:access" operation="BIND" | dedup conn cn | table conn op cn | rename cn as user | lookup openldap_user_lookup conn, op OUTPUTNEW _key AS _key | outputlookup append=t openldap_user_lookup

I know btool and I am using it. 

There are more problems.

One is that according to btool, the savedsearch.conf precedence does not behave as documented, i.e. app/user context with reverse reverse-lexicographic order.

The second is that Splunk reports a problem with duplicate configuration.

So far I haven't found any information in the documentation that savedsearches.conf should behave differently than for example macros, props etc.

[emzed]

I found out that the message about duplicated configuration is from ES (Enterprise Security). This check has a period of 10 minutes.

apps/SplunkEnterpriseSecuritySuite/bin/configuration_checks/confcheck_es_correlationmigration.py:MSG_DUPLICATED_STANZA = 'Configuration file settings can be duplicated in multiple applications: stanza="%s" conf_type="%s" apps="%s"'

I tested the above scenario on a clean Splunk Enterprise without ES and the behavior matches the documentation, but btool not.

[splunk@siemsearch01 apps]$ cat ATest_app/default/savedsearches.conf 
[ss]
search = `super_macro` atest

[splunk@siemsearch01 apps]$ cat Test_app/default/savedsearches.conf 
[ss]
search = `super_macro` test
request.ui_dispatch_app = search
disabled = 0
alert.track = 0
cron_schedule = */2 * * * *
dispatch.earliest_time = -4m
dispatch.latest_time = -2m
enableSched = 1

[splunk@siemsearch01 apps]$ cat ZTest_app/default/savedsearches.conf 
[ss]
search = `super_macro` ztest


[splunk@siemsearch01 apps]$ 
[splunk@siemsearch01 apps]$ /opt/splunk/bin/splunk btool savedsearches list --debug ss | grep "search ="
/opt/splunk/etc/apps/ATest_app/default/savedsearches.conf                 search = `super_macro` atest

btool returns:  search = `super_macro` atest

Gui returns:  index=ztest ztest, i.e. `super_macro` ztest