Deployment Architecture

Changing local.meta to maintenance user or deleting local.meta lines?

Path Finder

I am removing a large group of users that own things in my Splunk and I am wondering if there is a best approach to changing object ownership?

Are there any disadvantages to just removing the local.meta lines with users that are being removed so that the owner appears as "nobody"? Or should I be changing these objects to a new user as the owner?

Also- do I have to restart Splunk after making changes to local.meta or can I just run server:8000/en-US/debug/refresh?

0 Karma
1 Solution

Communicator

I'm not sure how search quotas would apply to scheduled searches owned by "nobody", if there's a lot then it's possible that they could all be treated as one user from the scheduler's perspective, but I haven't actually seen that problem happen. I prefer to change them to a new user so there is clear ownership, especially if an app is being used by multiple teams and I need to have some idea of who owns which content within it.

Changing ownership to a new owner also forces the teams who should be responsible for the content to evaluate whether they still need it and avoid duplicating it rather than just having it sit in the environment forever after the original owner leaves because no one takes responsibility for it. I have heard mentions of performance problems caused by large local.meta files due to entries for old/unused content, so forcing cleanup and clear content ownership is probably a good thing.

You should also note that if you're looking specifically at cases where knowledge objects were orphaned due to the user being removed, there is now an option to reassign ownership through Splunk Web which seems a lot less painful than doing it in local.meta, but I haven't tried it myself yet.

If you're changing local.meta directly, the debug/refresh REST endpoint should work, but it wouldn't be a bad idea to check after hitting it that the ownership did actually change.

View solution in original post

0 Karma

Communicator

I'm not sure how search quotas would apply to scheduled searches owned by "nobody", if there's a lot then it's possible that they could all be treated as one user from the scheduler's perspective, but I haven't actually seen that problem happen. I prefer to change them to a new user so there is clear ownership, especially if an app is being used by multiple teams and I need to have some idea of who owns which content within it.

Changing ownership to a new owner also forces the teams who should be responsible for the content to evaluate whether they still need it and avoid duplicating it rather than just having it sit in the environment forever after the original owner leaves because no one takes responsibility for it. I have heard mentions of performance problems caused by large local.meta files due to entries for old/unused content, so forcing cleanup and clear content ownership is probably a good thing.

You should also note that if you're looking specifically at cases where knowledge objects were orphaned due to the user being removed, there is now an option to reassign ownership through Splunk Web which seems a lot less painful than doing it in local.meta, but I haven't tried it myself yet.

If you're changing local.meta directly, the debug/refresh REST endpoint should work, but it wouldn't be a bad idea to check after hitting it that the ownership did actually change.

View solution in original post

0 Karma

Path Finder

@traxxasbreaker thank you for the help! Do I need to change ownership of all objects with the removed users listed in local.meta as the owner or does it only matter for saved searches? For example- I have local.meta info on indexes, lookups, etc for the removed users.

0 Karma

Communicator

That would depend on the permissions set per object. If you have a lookup that was only writeable by the removed user, then you'd want to change ownership so someone who's still around can modify it. If the lookup is already writeable by other people, then it won't matter as much at least in terms of short term functionality.

Honestly though, it's probably easier to just change all the objects from the removed user to the new one, that way you don't have to sift through everything to figure out where the new ownership matters or potentially miss something resulting in people coming back to you months later because they can't modify an object that they need to. Remember that the person taking over the ownership is likely going to be taking a good look at all the objects they inherit regardless of type and they'll just remove something if they don't need it, so even though it's a little more work up front to change the ownership to a different user it will save you some cleanup down the road.

0 Karma

Path Finder

Hi @traxxasbreaker I changed all of the ownership in local.meta to my username and then I ran server:8000/en-US/debug/refresh, but I got the following errors. Can you help me understand how to fix these and what impact these have?

Refreshing admin/collections-conf BadRequest
In handler 'collections-conf': Must use user context of 'nobody' when interacting with collection configurations (used user='katz.r')

Refreshing admin/indexes InternalServerError
In handler 'indexes': reload is not safe since a path has been deleted or modified for an index, or an index has been disabled. You must restart the Splunk Server, for your changes to take effect.

Refreshing admin/remote_indexes BadRequest
In handler 'remote_indexes': The following required arguments are missing: repositoryLocation.

Refreshing admin/search-head-bundles SplunkdConnectionException Splunkd daemon is not responding: ("Error connecting to /servicesNS/katz.r/search/admin/search-head-bundles: ('The read operation timed out',)",)

Refreshing admin/transforms-reload ResourceNotFound
In handler 'transforms-reload': Invalid action for this internal handler (handler: transforms-reload, supported: list|_reload, wanted: list).

I did this for a user that was already removed in the past and object ownership not transferred, but I am still getting this error below.

When I search index=_internal sourcetype=splunkd log_level=ERROR I am still getting the error "0400 ERROR UserManagerPro - Failed to get LDAP user=(name of removed user) from any configured servers

0 Karma
State of Splunk Careers

Access the Splunk Careers Report to see real data that shows how Splunk mastery increases your value and job satisfaction.

Find out what your skills are worth!