Knowledge Management

Bug: Unable to Reassign Knowledge Objects with colons in the name

kaeleyt
Path Finder

Hi fellow Splunkers!

I am an admin for our Splunk Enterprise Environment and when we have users on any of the teams that we support leave their teams or leave the company we try to stay on top of reassigning the knowledge objects that they owned to a current member of that team. We do this from the UI because we run 2 clustered environments with 3 SH's each.We reassign these objects by navigating to Settings > All configurations > Reassign Knowledge Objects

I have come across an issue where I am unable to reassign field extractions with colons in their name.

Examples:

  • wineventlog:security : EXTRACT-WindowsSecurityFields
  • source::/var/opt/jfrog/artifactory/logs/request.log : EXTRACT-Action

When I attempt to reassign these I get the following error:

Answers.PNG

Has anyone else run into this? Has anyone found a solution (other than reassigning these from the back end)? Any feedback is appreciated!

Labels (2)
0 Karma

kaeleyt
Path Finder

UPDATE: I have actually noticed that Data Models can't be reassigned either as they also don't show up here

0 Karma

pamaro
Splunk Employee
Splunk Employee

Hello,

This is not a Search, it's a fields extraction and we can not reassign fields extraction.

You'll have to delete the fields extraction instead of reassigning the knowledge objects.

0 Karma

kaeleyt
Path Finder

That actually isn't true....

I can re-assign all other "non-search" objects from the "All configurations" page:

  • props-extract (except for source based or ones with sourcetypes with colons.... see examples below)
  • transforms-extract
  • views
  • transforms-lookup
  • macros
  • eventtypes
  • fvtags
  • fieldaliases
  • workflow-actions

The only thing missing completely is calculated fields which I cannot reassign from this UI which doesn't seem to make sense when we can reassign all other objects from the UI.

I can reassign all other extracted fields and field transformations from the UI. The only ones that I cannot reassign are the ones that are source-based or are sourcetype based with a colon in the sourcetype name.

Sourcetype example:

Sourcetype: wineventlog:taskscheduler
Name: WinEventLogTaskScheduler-EventCode103Message
Regex: Task Scheduler failed to launch action \"(?P<FailedAction>[^\"]+)\" in instance \"\{(?P<FailedInstance>[^\"]+)\}\" of task \"(?P<Task>[^\"]+)\"\. Additional Data\: Error Value\: (?P<ErrorValue>[^\.]+)\. 
Field Extraction Name: wineventlog:taskscheduler : EXTRACT-WinEventLogTaskScheduler-EventCode103Message
***Please note the colon in the sourcetype name

Source example:
***I don't have a good source example that I would be able to post on here but for a fake example:

Source: this/is/a/pretend/source.log
Name: Destination
Regex: ^\w+\s\d+\s\d{2}:\d{2}:\d{2}\s(?<dest>\S+)
Field Extraction Name: source::this/is/a/pretend/source.log : EXTRACT-Destination
***Note that splunk adds the "source::" before the source.... I think the colons may be conflicting

I don't know for sure that the colon is the issue since I don't know how Splunk does the reassignment behind the scenes but based on some extensive testing I've done in my own environment (running on 8.1.3) this seems to be a common denominator....

I do have a bug investigation open with support to look into this issue.

0 Karma

jimmoriarty
Path Finder

I've encountered this issue as well - any update on how to resolve it?

Tags (1)
0 Karma

kaeleyt
Path Finder

The fix they recommended to me was to use the REST method. Our team does not want to use this since that is not ideal in a clustered environment. I can update this thread if anything comes from the bug investigation that was submitted.  Fingers crossed it gets updated in a future version because the UI method is so much more convenient 🤞

0 Karma

jimmoriarty
Path Finder

I used the REST method, and found that it worked even in a clustered environment (Search Heads and indexers).

Command used on a search head:
curl -k -u admin:<password> https://localhost:8089/servicesNS/<old  owner>/ING-SA-Search/data/props/extractions/<object>/acl -d 'owner=<new owner>' -d 'sharing=app'

Where object is the urlencoded version of the full field extraction name, e.g.
my:srctype : EXTRACT-SomethingInteresting
Becomes
my:srctype%20:%20EXTRACT-SomethingInteresting

I found that this change was then replicated to the other search heads appropriately

0 Karma
Did you miss .conf21 Virtual?

Good news! The event's keynotes and many of its breakout sessions are now available online, and still totally FREE!