Frequently asked questions (FAQ)

Virtual Tenants were created but the Virtual Tenants UI does not show any content

As of today, we do not support role inheritance when it comes to the RBAC configuration of the Virtual Tenants.

This means that a user needs be a proper explicity member of either any of the administrative roles, or the user roles for TrackMe to grant access to the tenant(s).

In short, you can review the workflow as follows:

trackmeload custom command

What TrackMe does is first calling the custom command called trackmeload, this custom command be called as follows:

| trackmeload

The custom command verifies the role membership of the current user, and compares these with the roles defined at the level of the Virtual Tenant KVstore collection:

| inputlookup trackme_virtual_tenants | eval keyid=_key
| table tenant_id, tenant_owner, tenant_roles_admin, tenant_roles_user

If you enable the DEBUG logging level, the trackmeload custom command logs activity traces, similar to:

index=_internal sourcetype=trackme:custom_commands:trackmeload trackmeload.py "check if username_role" OR "username="

Example:

2023-02-13 21:03:37,101 INFO trackmeload.py generate 105 username="admin", roles="['admin']"
2023-02-13 21:03:37,122 DEBUG trackmeload.py generate 147 check if username_role="admin" is in {'trackme_admin'} or {'trackme_user'}

If the current user is not an explicit member of the roles defined in the Virtual Tenant, or admin or sc_admin, the custom command will not grant access to these tenants.

How can I manage priority using a third party source?

You can manage the priority of your entities using any third party data available to Splunk, using some SPL techniques.

For instance, if we have a Virtual Tenant named mytenant, entities for the splk-dsm tenant would be stored in a KVstore collection that can be retrived as follows:

| inputlookup trackme_dsm_tenant_mytenant | eval keyid=_key

You can then schedule a custom report to retrieve or manage the priority according to your needs, for instance:

| inputlookup trackme_dsm_tenant_mytenant | eval keyid=_key
| lookup my_lookup object OUTPUTNEW new_priority
| eval priority=coalesce(new_priority, priority)
| outputlookup append=t key_field=keyid trackme_dsm_tenant_mytenant

Schedule this logic in a custom report, which will manage your priority automatically.

Python error with module splunklib.results has no attribute JSONResultsReader

If you encounter this error when using TrackMe, then you have an issue in your environment which is improperly overriding the Splunk Python SDK used by TrackMe.

The symptoms lead to TrackMe various failures with the message:

module 'splunklib.results' has no attribute 'JSONResultsReader'

This happens if TrackMe is forced to use an incompatible and outdated version of the Splunk SDK for Python which does not have the JSONResultsReader module.

You can verify the version of the SDK which TrackMe uses by opening a Python interpreter and running the following command:

/opt/splunk/bin/splunk cmd python

Then paste the following code and press enter:

import sys, os
splunkhome = os.environ["SPLUNK_HOME"]
sys.path.append(os.path.join(splunkhome, "etc", "apps", "trackme", "lib"))

import splunklib.results as results
import pkg_resources

def get_package_version(package_name):
    try:
        return pkg_resources.get_distribution(package_name).version
    except pkg_resources.DistributionNotFound:
        return None

sdk_version = get_package_version("splunk-sdk")
if sdk_version:
    print("Splunk SDK for Python Version:", sdk_version)
else:
    print("The Splunk SDK for Python is not found or its version can't be determined.")

The expected output should show the SDK version which should match what TrackMe is shipped with, the SDK version can be found in:

trackme/lib/splunklib/__init__.py

Example:

__version_info__ = (1, 7, 4)

This is also the case for every other Splunk application shipping the Python SDK, once you have identified the application causing this, you can either manually upgrade the SDK or identify where a custom configuration such as a modification of environments variables (ex: PYTHONPATH) leads to this unexpected behaviour.

You can also execute the following Python code in the interpreter to show the value of the PYTHONPATH from the perspective of Splunk:

import os
import sys

# Print the PYTHONPATH environment variable
pythonpath = os.environ.get('PYTHONPATH')
if pythonpath:
    print("PYTHONPATH:", pythonpath)
else:
    print("PYTHONPATH is not set.")

# Print the current sys.path
print("\nsys.path:")
for path in sys.path:
    print(path)