Hi Experts
I am trying to disable an alert using below rest API example provided in the documentation. It returns back a XML response with all the attributes of the alert but do not disable the alert.
Example:-
curl -k -u admin:pass https://localhost:8089/servicesNS/admin/search/saved/searches/TestSearch/ \
disable -X POST
My curl command
curl -X POST -k -u admin:xxx https://server:9099/servicesNS/admin/search/saved/searches/test1234/disable
Reference :- http://docs.splunk.com/Documentation/Splunk/6.6.5/RESTUM/RESTusing
Any inputs, what is wrong here?
I would look further look into the namespace that is required to reach the saved search you are trying to disable.
https://docs.splunk.com/Documentation/Splunk/7.2.3/RESTUM/RESTusing#Namespace
As most likely is that the rest endpoint either doesn't have access to that search or is just creating a new search that its disabling automatically but is never hitting the originating saved search.
If this saved search name is unique an easy way to edit this search is by the following command:
curl -k -u admin:pass https://localhost:8089/servicesNS/-/-/saved/searches/TestSearch/ \
disable -X POST
As this will be looking over over all levels of access (private,app,global) for the saved search that matches TestSearch.
Can you try :
curl -X POST -k -u admin:xxx https://server:9099/servicesNS/admin/search/saved/searches/test1234/ \ disable
Thanks for your input but unfortunately This throws curl: (6) Could not resolve host: disable; Unknown error
instead of "server", can you try "localhost"?!?! or the full servername (FQDN, like abc.mycompany.com)
curl -X POST -k -u admin:xxx https://localhost:9099/servicesNS/admin/search/saved/searches/test1234/ \ disable
I guess the issue is not with the server name. The following Curl returns back the XML output but the alert is not disabling.
curl -X POST -k -u admin:xxx https://server:9099/servicesNS/admin/search/saved/searches/test1234/disable
try...
curl -k -u admin:xxx https://server:9099/servicesNS/admin/search/saved/searches/test1234/ disable -X POST
I think the "\" is for entering the command on the next line.. maybe, use it and see if it works..
curl -k -u admin:xxx https://server:9099/servicesNS/admin/search/saved/searches/test1234/ \
disable -X POST
No luck..The status of alert remains unchanged... Is this working in your environment. I am using Splunk 6.6.5
i am currently not having access to prod to test this.. ok, maybe, lets try to see if you are able to view the Access Control List of this search -
List the ACL properties of this alert -
curl -k -u admin:xxx https://server:9099/servicesNS/admin/search/saved/searches/test1234/acl
Yes, I got the following xml back.
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:s="http://dev.splunk.com/ns/rest" xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/">
<title>savedsearch</title>
<id>https://localhost:9099/servicesNS/admin/search/saved/searches</id>
<updated>2018-08-21T18:14:10+05:30</updated>
<generator build="b119a2a8b0ad" version="6.6.5"/>
<author>
<name>Splunk</name>
</author>
<link href="/servicesNS/admin/search/saved/searches/_new" rel="create"/>
<link href="/servicesNS/admin/search/saved/searches/_reload" rel="_reload"/>
<link href="/servicesNS/admin/search/saved/searches/_acl" rel="_acl"/>
<opensearch:totalResults>1</opensearch:totalResults>
<opensearch:itemsPerPage>30</opensearch:itemsPerPage>
<opensearch:startIndex>0</opensearch:startIndex>
<s:messages/>
<entry>
<title>test1234</title>
<id>https://localhost:9099/servicesNS/admin/search/saved/searches/test1234</id>
<updated>2018-08-21T13:54:46+05:30</updated>
<link href="/servicesNS/admin/search/saved/searches/test1234" rel="alternate"/>
<author>
<name>admin</name>
</author>
<link href="/servicesNS/admin/search/saved/searches/test1234" rel="list"/>
<link href="/servicesNS/admin/search/saved/searches/test1234/_reload" rel="_reload"/>
<link href="/servicesNS/admin/search/saved/searches/test1234" rel="edit"/>
<link href="/servicesNS/admin/search/saved/searches/test1234" rel="remove"/>
<link href="/servicesNS/admin/search/saved/searches/test1234/move" rel="move"/>
<link href="/servicesNS/admin/search/saved/searches/test1234/embed" rel="embed"/>
<link href="/servicesNS/admin/search/saved/searches/test1234/enable" rel="enable"/>
<link href="/servicesNS/admin/search/saved/searches/test1234/history" rel="history"/>
<content type="text/xml">
<s:dict>
<s:key name="eai:acl">
<s:dict>
<s:key name="app">search</s:key>
<s:key name="can_change_perms">1</s:key>
<s:key name="can_list">1</s:key>
<s:key name="can_share_app">1</s:key>
<s:key name="can_share_global">1</s:key>
<s:key name="can_share_user">1</s:key>
<s:key name="can_write">1</s:key>
<s:key name="modifiable">1</s:key>
<s:key name="owner">admin</s:key>
<s:key name="perms"/>
<s:key name="removable">1</s:key>
<s:key name="sharing">user</s:key>
</s:dict>
</s:key>
</s:dict>
</content>
</entry>
</feed>
just now i noticed this... are you using 8089 or 9089 ?
curl -X POST -k -u admin:xxx https://server:9099/servicesNS/admin/search/saved/searches/test1234/disable
OR
curl -X POST -k -u admin:xxx https://server:8089/servicesNS/admin/search/saved/searches/test1234/disable
Maybe, try this...
To disable email for an alert
curl -k -u admin:pass https://splunkserver:8089/servicesNS/nobody/search/saved/searches/MyAlert1 -d "actions="
To enable email for an alert
curl -k -u admin:pass https://splunkserver:8089/servicesNS/nobody/search/saved/searches/MyAlert1 -d "actions=email"
I am using my management port which is 9099
Found an interesting thing.. When we hit the disable endpoint, Splunk creates another alert with same name and same search,with private permission and disables it..
so, when you hit the disable endpoint, totally, you get two alerts.. one is enabled and one is disabled... in total, its the enabled one is still sending alerts?!?!?
yes thats right.. This is what I see in the Splunk UI.
this behavior looks strange... i dont know..maybe someone else can reply to you regarding this..
as this is really a strange behavior, you can consult splunk support.
(PS - you can upvote for comments as well 😉 .. at times, new users may think that only "answers" can be upvoted. so clarifying 😉 )
Thanks for reminding about the up vote.
I will try to reach out to splunk and raise this as a bug.
Update- It works on the private alert but not on the shared alert.
nice to know that it worked as private alert..
on shared alert.. not sure.. maybe, that is how the "shared alerts" maybe designed.
one thought.. "shared" to others with just read access or write/edit access to the alert?!?!