Hi. QUESTION #1: search peer login credentials In previous versions, i'm talking about v7 and/or v8, in my memory, login credential to search peers were stored into filesystem, inside /var/... in some files named search_peer#1.something, search_peer#2.something etc.. Now i upgraded to 9.4 version, and can't find them anymore. Where are credentials stored? In KVSTORE? I ask this question since today i need to untar a 9.4 version over a same 9.4 version to take some files a user deleted for error🤦‍♂️and after doing it, it was a searchpeer/indexer, on the SearchHead and Deployer (Management Console) the peer was DOWN, i needed to reinsert the login credential again as first time to make it UP & Healthy again. Is it for security or is it a bug? I remember i need to do it also months ago when we upgraded 9.3 to 9.4!!! After upgrading, all peer credentials was gone. I thought it was a temporary bug, but now it seems to be the normal behaviour: reinstalling an instance, over the same, removes all previous registered credentials for searchpeers? QUESTION #2: Splunk upgrading removes all $SPLUNK_HOME/bin/scripts/ And, also, after upgrading, all out custom scripts in $SPLUNK_HOME/bin/scripts/ was totally deleted, SPLUNK UPGRADER remove all of them, i found only the "readme.txt", we had something like 50 custom scripts, all gone 🙄 obviously we have a backup!!! But is it normal??? Thanks. ... View more

Hi. OK, this question is totally theory, but i came in case of pratical issue on such problem. So, let's think i have an App that writes the new log file every 00:00 and writes, I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. 12/02/2025 00:30:00 log #1 12/02/2025 00:30:01 log #2 12/02/2025 00:30:02 log #3   PREMISE: every day, at 00:00 the log is totally rewritten from 0 byte with same headers.   So, Splunk UF the first day should take the first 256 bytes for CRC and should take the log entry since it's new for it and send to indexers. Next day it should block it, thinking it's the same as the day before, since the 256b CRC it's the same, so i should find something like in UF log, File will not be read, is too small to match seekptr checksum [...]   And find only the entries of yesterday. Now i force an "initCrcLen = 1024", and now i should start on indexing since the file has, for example, I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. I'M STARTING TO WRITE. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. AND NOW I START TO LOG. 12/02/2025 00:30:00 log #1 12/02/2025 00:30:01 log #2 12/02/2025 00:30:02 log #3   The next day, initCrcLen to 1024 bytes wil be the same, UF tags the log as already sent yesterday and blocks it again. OK, now i force a new "crcSalt = <SOURCE>" to the input. But in few days both initCrcLen = 1024 [same header size] crcSalt = <SOURCE> [same file path] will calculate a same identical CRC, so the UF will think the log is still the same and it will be blocked! Am i wrong? I know the question is an old and always discussed question. But it's interesting to know if it's possibile to tell UF: "read the file without thinking about it's CRC, if i have still indexed it, read it, do anything other, and send to indexers!" 😉😉😉 ... View more

A simple, but not trivial, question. When searching a log file, we sometimes find fields previously extracted "on-the-fly" from the search SH, in various ways (Regex, Field_Delimiter), or directly from the Indexer, again in different ways. NOW, the question: it often happens that we spend a lot of time searching for the exact config from which the extraction comes, sifting through the various SH and Indexer configs... eventually, between one thing and another, we get there. But, as mentioned, it often wastes a lot of time... just an example: i have a log where, in many years, many users put an hand, any user inserted his field extraction for a single field, creating something like 20/30 conf for a single log and for 20/30 fields... bothersome when debugging and seeking a single field (as said with the search form you get it quite soon, but...)!!! 🙄 Is there a quick way to understand WHERE a particular field extracted from the log COMES FROM? A "detailed-field-inspector" that tells us exactly: "this field is extracted from the SH, Regex, 'Sourcetype: my_extract_conf'"? Thanks. ... View more

Hello. I'm having new issues after upgrading a DS from V.9.1 to V.9.4.5. Every phone-home from the UFs (i have about 2000 UFs), gives a 0 [ZERO] in UI. I can see UFs connected to 8089 of my DS Listener, many errors on Splunk logs, AdminHandler:AuthenticationHandler [289178 TcpChannelThread] - Denied session token for user: splunk-system-user On UFs i have the classic "deploymentclient.conf", with a simple, [target-broker:deploymentServer] targetUri = myDS:8089 With previous versions i never had issues. Has something changed in 9.4 for UFs to DS connect? Thanks.   ... View more