Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- About astackpole
astackpole
Path Finder
Member since:
01-18-2020
03-04-2021
Community Statistics
| Posts | 15 |
| Solutions | 1 |
| Karma Given | 8 |
| Karma Received | 0 |
| Member Since | 01-18-2020 |
Activity Feed
- Posted Re: Index Routing/Separation Across Multiple VPCs on Security. 03-03-2021 02:16 PM
- Karma Re: Index Routing/Separation Across Multiple VPCs for manjunathmeti. 03-03-2021 02:16 PM
- Posted Re: Index Routing/Separation Across Multiple VPCs on Security. 03-03-2021 06:39 AM
- Posted Index Routing/Separation Across Multiple VPCs on Security. 02-25-2021 07:06 AM
- Tagged Index Routing/Separation Across Multiple VPCs on Security. 02-25-2021 07:06 AM
- Tagged Index Routing/Separation Across Multiple VPCs on Security. 02-25-2021 07:06 AM
- Tagged Index Routing/Separation Across Multiple VPCs on Security. 02-25-2021 07:06 AM
- Karma Re: How to configure DMC for heavy forwarder monitoring? for pellegrini. 01-15-2021 12:15 PM
- Karma FIPS and Splunk Compatibility for plymalebl. 01-13-2021 01:20 PM
- Posted Re: TA-meraki Not Logging all Events to Splunk on Getting Data In. 01-13-2021 01:12 PM
- Karma Re: Permissions on /var/log for jawaharas. 11-25-2020 08:43 AM
- Posted Re: Send events from TA to different indexes depending on hostname on Getting Data In. 11-25-2020 06:14 AM
- Posted TA-meraki Not Logging all Events to Splunk on Getting Data In. 11-16-2020 01:18 PM
- Posted Re: User is unable to see the data in TA-Meraki App on All Apps and Add-ons. 11-16-2020 01:03 PM
- Posted Re: Blacklist lookup - search query on Splunk Search. 11-09-2020 02:48 PM
- Posted Blacklist lookup - search query on Splunk Search. 11-09-2020 11:46 AM
- Karma Re: LINE_BREAKER regex for </issue><issue> for amiftah_splunk. 11-03-2020 01:24 PM
- Posted Re: LINE_BREAKER regex for </issue><issue> on Getting Data In. 10-30-2020 09:21 AM
- Posted LINE_BREAKER regex for </issue><issue> on Getting Data In. 10-30-2020 07:20 AM
- Tagged LINE_BREAKER regex for </issue><issue> on Getting Data In. 10-30-2020 07:20 AM
Topics I've Started
| Subject | Karma | Author | Latest Post |
|---|---|---|---|
| 0 | |||
| 0 | |||
| 0 | |||
| 0 | |||
| 0 | |||
| 0 |
03-03-2021
02:16 PM
I really like that idea and am looking into it moving forward....however, with multiple apps (windows/linux) it still didn't separate the logs correctly. What I ended up doing is more tedious but worked. I created the following apps and then created 6 serverclasses to break them down by OS and host. Splunk_TA_nix Splunk_TA_nix_cd Splunk_TA_nix_ef Splunk_TA_windows Splunk_TA_windows_cd Splunk_TA_windows_ef I'd like to change this in the future though if anyone using props/transforms for this scenario is willing to share alternative methods.
... View more
03-03-2021
06:39 AM
This solution worked until I needed to add more indexes to the VPC. Since the host have multiple indexes I've changed the files to go by source and am trying to indicate the prefix of the hostnames in the transforms REGEX section. My current problem and set-up is, VPC Name Hostnames Prefix per VPC Inputs Indexes vpcX ab- Linux and Windows os, windows, wineventlog, msad, perfmon vpcY cd- Linux and Windows os_cd, windows_cd, wineventlog_cd, msad_cd, perfmon_cd vpcZ ef- Linux and Windowws os_ef, windows_ef, wineventlog_ef, msad_ef, perfmon_ef My current props.conf for Splunk_TA_nix is, [source::/var/*]
TRANSFORMS-routing = osCd
TRANSFORMS-routing = osEf
[source::/etc/*]
TRANSFORMS-routing = osCd
TRANSFORMS-routing = osEf
[source::Linux*]
TRANSFORMS-routing = osCd
TRANSFORMS-routing = osEf
(etc. I've added every source found in the Splunk_TA_nix add-on) and transforms.conf is where the REGEX is referencing the hostname prefix, [osCd]
SOURCE_KEY = MetaData:Source
REGEX = .+cd.+
DEST_KEY = _MetaData:Index
FORMAT = os_cd
[osEf]
SOURCE_KEY = MetaData:Source
REGEX = .+ef.+
DEST_KEY = _MetaData:Index
FORMAT = os_ef Am I writing the REGEX correctly to search on the hostname in addition to the source that is referenced in props.conf? Or is there another parameter/method to specify this?
... View more
02-25-2021
07:06 AM
Hello Everyone, I have an environment consisting of three VPC's (say x, y, and z). Each VPC holds Linux, Windows and AWS logs. I have successfully set-up the AWS log ingest using separate indexes (aws_vpcx, aws_vpcy, aws_vpcz). However, I'm struggling to get the Linux/Windows data to index the same way. The unique identifier I'm using is hostnames. The following holds true for all hostnames per VPC, VPC X has hostnames == vpcX*** VPC Y has hostnames == vpcY*** VPC Z has hostnames == vpcZ*** For Linux logs I tried to add the following : Inputs.conf currently has (index=os_vpcX) so the default is for all Linux hosts in VPC X which is why it's not in the props and transforms files below. Currently all VPCs are sending to the os_vpcX index instead of all three and I need to figure out why the below config isn't working. I'm doing this from the cluster master and pushing it to the indexer cluster. props.conf [host::vpcY*]
TRANSFORMS-osVpcY = osVpcYTrans
[host::vpcZ*]
TRANSFORMS-osVpcZ = osVpcZTrans transforms.conf [osVpcYTrans]
REGEX = vpcX.+
DEST_KEY = _MetaData:Index
FORMAT = os_vpcy
[osVpcZTrans]
REGEX = vpcY.+
DEST_KEY = _MetaData:Index
FORMAT = os_vpcz My second question is the same but for the Windows add-on..this seems more difficult with the single inputs.conf file having multiple indexes in it. Is there a way for me to specify more than one 'unique' thing about the stanza? For example, this is the default windows inputs.conf containing multiple indexes...I will need the windows index to go to either windows, windows_vpcY, or windows_vpcZ depending on the host that's sending the logs..but then I will also need that same separation for the wineventlog data (wineventlog, wineventlog_vpcY, wineventlog_vpcZ). ###### WinEventLog Inputs for DNS ######
[WinEventLog://DNS Server]
disabled = 0
renderXml=true
index = wineventlog
###### DHCP ######
[monitor://$WINDIR\System32\DHCP]
disabled = 0
whitelist = DhcpSrvLog*
crcSalt = <SOURCE>
sourcetype = DhcpSrvLog
index = windows Thanks in advance to anyone that can help!
... View more
Labels
- Labels:
-
access control
-
audit
01-13-2021
01:12 PM
Meraki responded to us stating that not all Meraki logs are designed to be ingested by syslog when you configure the syslog option. So basically, it's expected to see logs in the Meraki dashboard you're not finding in Splunk. Sorry, I'm sure it's not the answer you were looking for. Hopefully Meraki updates this moving forward!
... View more
11-25-2020
06:14 AM
Were you able to get this problem resolved? I am facing the same issue in my environment now and any guidance you may have would be appreciated!
... View more
11-16-2020
01:18 PM
I've successfully installed and configured the TA-meraki app and have all the CIM compliant data coming into Splunk, my question is...why am I not getting all the logs in Splunk that appear in the Meraki Dashboard? I'm currently receiving events for the following apps/roles in Splunk (below on the right), but when comparing it to the Roles configured on the Meraki-side (to the left), we're not receiving anything from the Security Events Role in Splunk, although it's logging fine into the Meraki dashboard. Any help would be GREATLY appreciated!
... View more
Labels
- Labels:
-
syslog
11-16-2020
01:03 PM
Yes, you need to set the index and sourcetype to meraki so the inputs.conf should look like this (if you're still using udp 514): [udp:514]
index=meraki
sourcetype=meraki In addition, make sure the TA-meraki app is also installed on your indexers. Once both of these changes are made you should see CIM-compliant data for Meraki on your Search Head.
... View more
11-09-2020
11:46 AM
I have a blacklist.csv file that looks like the following, name description *vpn* VPN was found. *putty* Putty was found. I'm trying this search and it's showing events match, but not outputting the name/description fields from the lookup. index=os
| lookup blacklist.csv name OUTPUT description
| table name description
My goal is to search each event for every value in the name column, so the basic query I'm trying to match with the use of a lookup file is, index=os
| search *vpn* OR *putty* What lookup query do I need to implement this type of search and display the results?
... View more
Labels
- Labels:
-
lookup
10-30-2020
09:21 AM
I just did and am not seeing much of a difference in results. Is there a way to ensure it matches exactly to <issue></issue>? Within the tags are different tags also including the word issue, which I think may be causing the problem. Below shows one full event, which should be multiple events. <issues exportTime="Tue Oct 13 22:44:25 GMT 2020">
<issue>
<serialNumber>7183386942052660224</serialNumber>
<type>5244672</type>
<name><![CDATA[Session token in URL]]></name>
<host ip="0.1.2.3">http://0.1.2.3</host>
<path><![CDATA[/vulnerabilities/csrf/]]></path>
<location><![CDATA[/vulnerabilities/csrf/]]></location>
<severity>Medium</severity>
<confidence>Firm</confidence>
<issueBackground><![CDATA[<p>Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.</p>]]></issueBackground>
<remediationBackground><![CDATA[<p>Applications should use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.</p>]]></remediationBackground>
<vulnerabilityClassifications><![CDATA[<ul>
<li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200: Information Exposure</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/384.html">CWE-384: Session Fixation</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/598.html">CWE-598: Information Exposure Through Query Strings in GET Request</a></li>
</ul>]]></vulnerabilityClassifications>
<issueDetail><![CDATA[The URL in the request appears to contain a session token within the query string:<ul><li>http://0.1.2.3/vulnerabilities/csrf/?password_current=password&password_new=password&password_conf=password&Change=Change&user_token=126d0ea7389c980cb3ba9872f77f2851</li></ul>]]></issueDetail>
<issueDetailItems>
<issueDetailItem><![CDATA[http://0.1.2.3/vulnerabilities/csrf/?password_current=password&password_new=password&password_conf=password&Change=Change&user_token=126d0ea7389c980cb3ba9872f77f2851]]></issueDetailItem>
</issueDetailItems>
<requestresponse>
<request method="GET" base64="true"><![CDATA[BASE64 STRING]]></request>
<response base64="true"><![CDATA[BASE64>
<responseRedirected>false</responseRedirected>
</requestresponse>
</issue>
<issue>
<serialNumber>8062343294186323968</serialNumber>
<type>5244672</type>
<name><![CDATA[Session token in URL]]></name>
<host ip="0.1.2.3">http://0.1.2.3</host>
<path><![CDATA[/vulnerabilities/xss_r/]]></path>
<location><![CDATA[/vulnerabilities/xss_r/]]></location>
<severity>Medium</severity>
<confidence>Firm</confidence>
<issueBackground><![CDATA[<p>Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.</p>]]></issueBackground>
<remediationBackground><![CDATA[<p>Applications should use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.</p>]]></remediationBackground>
<vulnerabilityClassifications><![CDATA[<ul>
<li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200: Information Exposure</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/384.html">CWE-384: Session Fixation</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/598.html">CWE-598: Information Exposure Through Query Strings in GET Request</a></li>
</ul>]]></vulnerabilityClassifications>
<issueDetail><![CDATA[The URL in the request appears to contain a session token within the query string:<ul><li>http://0.1.2.3/vulnerabilities/xss_r/?name=nXfPJPjp&user_token=7137bd1753e1e9b101ebc483f3f1c703</li></ul>]]></issueDetail>
<issueDetailItems>
<issueDetailItem><![CDATA[http://0.1.2.3/vulnerabilities/xss_r/?name=nXfPJPjp&user_token=7137bd1753e1e9b101ebc483f3f1c703]]></issueDetailItem>
</issueDetailItems>
</issue>
<issue>
<serialNumber>8136360890162158592</serialNumber>
<type>5244672</type>
<name><![CDATA[Session token in URL]]></name>
<host ip="0.1.2.3">http://0.1.2.3</host>
<path><![CDATA[/vulnerabilities/xss_r/]]></path>
<location><![CDATA[/vulnerabilities/xss_r/]]></location>
<severity>Medium</severity>
<confidence>Firm</confidence>
<issueBackground><![CDATA[<p>Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.</p>]]></issueBackground>
<remediationBackground><![CDATA[<p>Applications should use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.</p>]]></remediationBackground>
<vulnerabilityClassifications><![CDATA[<ul>
<li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200: Information Exposure</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/384.html">CWE-384: Session Fixation</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/598.html">CWE-598: Information Exposure Through Query Strings in GET Request</a></li>
</ul>]]></vulnerabilityClassifications>
<issueDetail><![CDATA[The URL in the request appears to contain a session token within the query string:<ul><li>http://0.1.2.3/vulnerabilities/xss_r/?name=MbMaFuRM&user_token=64dc95dcaa45bb1162514d0a9285b200</li></ul>]]></issueDetail>
<issueDetailItems>
</issueDetailItem>
</issueDetailItems>
<requestresponse>
<request method="GET" base64="true">
<responseRedirected>false</responseRedirected>
</requestresponse>
</issue>
<issue>
<serialNumber>4136405686680984576</serialNumber>
<type>5244672</type>
<name><![CDATA[Session token in URL]]></name>
<host ip="0.1.2.3">http://0.1.2.3</host>
<path><![CDATA[/vulnerabilities/sqli_blind/]]></path>
<location><![CDATA[/vulnerabilities/sqli_blind/]]></location>
<severity>Medium</severity>
<confidence>Firm</confidence>
<issueBackground><![CDATA[<p>Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.</p>]]></issueBackground>
<remediationBackground><![CDATA[<p>Applications should use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.</p>]]></remediationBackground>
<vulnerabilityClassifications><![CDATA[<ul>
<li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200: Information Exposure</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/384.html">CWE-384: Session Fixation</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/598.html">CWE-598: Information Exposure Through Query Strings in GET Request</a></li>
</ul>]]></vulnerabilityClassifications>
<issueDetail><![CDATA[The URL in the request appears to contain a session token within the query string:<ul><li>http://0.1.2.3/vulnerabilities/sqli_blind/?id=185006&Submit=Submit&user_token=40edd90de7cbcb3775313c679511c516</li></ul>]]></issueDetail>
<issueDetailItems>
<issueDetailItem><![CDATA[http://0.1.2.3/vulnerabilities/sqli_blind/?id=185006&Submit=Submit&user_token=40edd90de7cbcb3775313c679511c516]]></issueDetailItem>
</issueDetailItems>
<requestresponse>
<request method="GET" base64="true"><![CDATA[BASE64 STRING]]></request>
<response base64="true"><![CDATA[BASE64 STRING]]></response>
<responseRedirected>false</responseRedirected>
</requestresponse>
</issue>
<issue>
<serialNumber>8478452543278705664</serialNumber>
<type>5244672</type>
<name><![CDATA[Session token in URL]]></name>
<host ip="0.1.2.3">http://0.1.2.3</host>
<path><![CDATA[/vulnerabilities/sqli/]]></path>
<location><![CDATA[/vulnerabilities/sqli/]]></location>
<severity>Medium</severity>
<confidence>Firm</confidence>
<issueBackground><![CDATA[<p>Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.</p>]]></issueBackground>
<remediationBackground><![CDATA[<p>Applications should use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.</p>]]></remediationBackground>
<vulnerabilityClassifications><![CDATA[<ul>
<li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200: Information Exposure</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/384.html">CWE-384: Session Fixation</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/598.html">CWE-598: Information Exposure Through Query Strings in GET Request</a></li>
</ul>]]></vulnerabilityClassifications>
<issueDetail><![CDATA[The URL in the request appears to contain a session token within the query string:<ul><li>http://0.1.2.3/vulnerabilities/sqli/?id=872225&Submit=Submit&user_token=84b74af6bd7645aa202c7f370b7ef6a8</li></ul>]]></issueDetail>
<issueDetailItems>
<issueDetailItem><![CDATA[http://0.1.2.3/vulnerabilities/sqli/?id=872225&Submit=Submit&user_token=84b74af6bd7645aa202c7f370b7ef6a8]]></issueDetailItem>
</issueDetailItems>
<requestresponse>
<request method="GET" base64="true"><![CDATA[BASE64 STRING]]></response>
<responseRedirected>false</responseRedirected>
</requestresponse>
</issue>
<issue>
<serialNumber>4828258302681230336</serialNumber>
<type>5244672</type>
<name><![CDATA[Session token in URL]]></name>
<host ip="0.1.2.3">http://0.1.2.3</host>
<path><![CDATA[/vulnerabilities/csrf/]]></path>
<location><![CDATA[/vulnerabilities/csrf/]]></location>
<severity>Medium</severity>
<confidence>Firm</confidence>
<issueBackground><![CDATA[<p>Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.</p>]]></issueBackground>
<remediationBackground><![CDATA[<p>Applications should use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.</p>]]></remediationBackground>
<vulnerabilityClassifications><![CDATA[<ul>
<li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200: Information Exposure</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/384.html">CWE-384: Session Fixation</a></li>
<li><a href="https://cwe.mitre.org/data/definitions/598.html">CWE-598: Information Exposure Through Query Strings in GET Request</a></li>
</ul>]]></vulnerabilityClassifications>
<issueDetail><![CDATA[The URL in the request appears to contain a session token within the query string:<ul><li>http://0.1.2.3/vulnerabilities/csrf/?password_current=password&password_new=password&password_conf=password&Change=Change&user_token=cd07548bd2d7109e5e57b4e9830bbcee</li></ul>]]></issueDetail>
<issueDetailItems>
<issueDetailItem><![CDATA[http://0.0.0.0/vulnerabilities/csrf/?password_current=password&password_new=password&password_conf=password&Change=Change&user_token=cd07548bd2d7109e5e57b4e9830bbcee]]></issueDetailItem>
</issueDetailItems>
<requestresponse>
<request method="GET" base64="true"><![CDATA[BASE64 DATA]]></response>
<responseRedirected>false</responseRedirected>
</requestresponse>
</issue>
</issues>
... View more
10-30-2020
07:20 AM
I have XML files I'm trying to break-up into individual events based on the following XML format. I need to break these up based on the info between each <issue> and </issue>. Also, these <issue>'s are not the top-level XML tag, which I think is causing my issues. <issue>
<finding info>
<more info, etc. etc.>
</issue>
<issue>
next finding info
</issue>
<issue>
third finding info
</issue> I've been trying to use the following with no luck. [xml-2]
DATETIME_CONFIG = CURRENT
SHOULD_LINEMERGE = false
LINE_BREAKER = \s\s(<\/issue>)\s\s\s(<issue>) I've also tried BREAK_ONLY_BEFORE as well as KV_MODE = xml with the above configuration. Any help on this would be GREATLY appreciated!
... View more
- Tags:
- line_breaker
- regex
Labels
- Labels:
-
props.conf
09-02-2020
10:03 AM
I'm also getting this error on restart for the Eval commands if this is helpful as well- Checking conf files for problems... Invalid key in stanza [sourcetype] in /opt/splunk/etc/apps/app/local/props.conf, line 14: Eval-Attack_Vector (value: case(Attack_Vector="AV:N", "Network", Attack_Vector="AV:A")).
... View more
09-02-2020
08:56 AM
Hmm, that didn't seem to fix the issue. I had been using the following case statements in the UI for dashboard queries as a temporary solution. Is there a way to convert the following into something extractable/usable in props.conf? It seems since eval doesn't take wild characters the case statement won't work the way you mentioned in props.conf until the calculated fields are successfully split by their slashes. | eval vecs=split(field_to_extract_from,"/") | eval C=mvindex(vecs,5) | eval I=mvindex(vecs,6) | eval A=mvindex(vecs,7) | eval DCO=case(C = "C:H", "High", C="C:M", "Moderate", C="C:L", "Low", C="C:N", "None")
... View more
09-02-2020
07:52 AM
I have a field I am trying to split into new fields and it's not taking. The strings look similar to this- "AV:N/AC:P/PR:X" and I'm trying to extract the vector to equal just the first values (AV:N). I am trying to extract each part between the slashes (var1= AV:N, var2=AC:P) but am not sure why it's not taking. My props.conf below, any help with the regex or why this may not be working is greatly appreciated! [sourcetype] EXTRACT-vector = AV:(?<field_trying_to_extract_from>\w+) [sourcetype] Eval-vector = case(vector="AV:N", "Network", vector="AV:A", "Adjacent", vector="AV:L", "Local", vector="AV:P", "Physical")
... View more
Labels
- Labels:
-
development
03-16-2020
08:14 AM
Is there a setting that is able to be added to the indexes.conf on the Indexers to move the drive the SmartStore Cache Manager resides on? The Splunk environment is currently on one drive and we need the cache manager to reside on another.
Any guidance is greatly appreciated!
... View more
Labels
- Labels:
-
smartstore
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
03-04-2021
05:35 PM
|
Karma given to
