About mntbighker

mntbighker · ‎05-21-2014

I have been asking them to support SSL enabled forwarders in the web GUI and NOTHING has improved in many versions. In fact it takes major effort to make them understand what I mean, so I must presume that most people never bother with SSL (weird). Anyway, if they have this general attitude, then this situation about no support on expiring certs does'nt not surprise me in the least.

mntbighker · ‎02-11-2014

Is this being updated for Splunk version 6?

mntbighker · ‎04-24-2013

Thanks, that does the trick. I have used OSSEC rules before so it was familiar. I was mostly interested in the party line (best practice) on this situation.

mntbighker · ‎04-24-2013

Since this is potentially Splunk itself causing the extra messages I thought perhaps they would offer more guidance than "go set up a null route". But maybe the OSSEC integration is 3rd party? Not sure about that? I have already been trying and failing to get a null route to work for another issue I have with unneeded data. Thanks for the suggestion anyway

mntbighker · ‎04-23-2013

On my Splunk server I am seeing the following every 5 minutes: Apr 21 05:14:20 ts-sl-server sudo: root : TTY=pts/0 ; PWD=/opt/splunk/etc/apps/ossec/bin ; USER=root ; COMMAND=/var/ossec/bin/agent_control -l Apr 21 05:19:20 ts-sl-server sudo: root : TTY=pts/0 ; PWD=/opt/splunk/etc/apps/ossec/bin ; USER=root ; COMMAND=/var/ossec/bin/agent_control -l The consequence is the ossec app stats and graphs are meaningless because the local server sudo events totally outnumber the ones from the forwarders. Is this a common problem, and what are folks doing about it? Obviously I could remove "authpriv.* /var/log/secure" from syslog.conf, but that hardly seems like the smart play, and our security benchmark demands that to be there. Ideas?

mntbighker · ‎04-22-2013

It seems like you should be able to stop Splunk, edit a conf file, and enable/disable the delete function, then restart Splunk. This would allow you to do occasional cleanup activities after some event mucks everything up. The way we use Splunk it would be crazy to pay for a license, but it seems you should have the ability to stop anyone from using delete. Of course they have every right to make their money, but $2k a year for something that sits collecting forensic data "in case" would be pretty hard to justify to the bean counters. So I agree with mrjester. I was hoping that as well. Maybe the better question here would be, how hard is it to reclaim what someone deleted?

mntbighker · ‎04-22-2013

Can I use globbing in props.conf ... [host::the_bad_host.*] ?? So far this has not worked for me: props.conf: [host::compute-0-*.local] TRANSFORMS-nullhost = nullhost transforms.conf: [nullhost] REGEX=. DEST_KEY = queue FORMAT = nullQueue I am still getting stuff from compute-0-* appearing. I also looked at this: [root@ts-sl-server splunk]# /opt/splunk/bin/splunk cmd btool props list host [host::compute*] ANNOTATE_PUNCT = True BREAK_ONLY_BEFORE = BREAK_ONLY_BEFORE_DATE = True CHARSET = UTF-8 DATETIME_CONFIG = /etc/datetime.xml HEADER_MODE = LEARN_SOURCETYPE = true LINE_BREAKER_LOOKBEHIND = 100 MAX_DAYS_AGO = 2000 MAX_DAYS_HENCE = 2 MAX_DIFF_SECS_AGO = 3600 MAX_DIFF_SECS_HENCE = 604800 MAX_EVENTS = 256 MAX_TIMESTAMP_LOOKAHEAD = 128 MUST_BREAK_AFTER = MUST_NOT_BREAK_AFTER = MUST_NOT_BREAK_BEFORE = SEGMENTATION = indexing SEGMENTATION-all = full SEGMENTATION-inner = inner SEGMENTATION-outer = outer SEGMENTATION-raw = none SEGMENTATION-standard = standard SHOULD_LINEMERGE = True TRANSFORMS = TRANSFORMS-nullhost = nullhost TRUNCATE = 10000 maxDist = 100 It also occurs to me that the hosts I need to filter are the compute nodes in our clusters. So the forwarder is the head node. I'm not sure if the digester sees the forwarder as the host or if the fact the entries appear in Splunk with the hostname identified as the one I need to fileter should mean this should be working? update: I hit myself in the head and moved the nullhost rule from the server to the forwarders (duh), and now I have another source of noise eliminated. The pie charts and data are actually becoming somewhat useful for the first time since I started using Splunk several years ago.

mntbighker · ‎09-07-2012

Thanks for the help

mntbighker · ‎09-07-2012

It seems that on Aug. 15th my vanilla Splunk SSL cert expired: 09-07-2012 17:28:38.987 -0700 ERROR TcpInputProc - Error encountered for connection from src=xxx.xxx.xxx.xxx:3353. error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate expired I have never wanted or needed to mess with my own cert. Our only requirement has been to encrypt over the wire. So all my log aggregation it seems came to a grinding halt 3 weeks ago. Is Splunk going to publish a process to fix this or will it be an excruciating manual process involving every host including the forwarders and the server? I'm running 4.3.3 on the server.

mntbighker · ‎04-07-2011

I see these errors from a Windows Server 2003 machine and my log machine is way under utilized?

mntbighker · ‎03-21-2011

We have only one indexer now but may add another later. It only happens on 4.2 and it's both Windows and Linux here. It also happens with the LightForwarder package. As of today I finally have a useable "system". With a couple of "TRANSFORM=" statements in props.conf I'm not getting two copies of every server in Hosts so now I'm ready to learn how to actually make some use of the data.

mntbighker · ‎03-18-2011

Add autoLB=false to senders outputs.conf although this is probably still a bug and it should not be necessary.

mntbighker · ‎03-18-2011

I added autoLB = false to outputs.conf and the problem disappears. Maybe that should be the default? What percentage of people do load balancing?

mntbighker · ‎03-18-2011

I could only find 2 things with 30 second default timings. A heartbeat interval and the load balance interval. I tried changing the heartbeat interval and nothing changed. This happens with one receiver and one sender by the way. It happens with 4.1.7 running on receiver and 4.2 running on sender. Is there a way to kill any load balancing functions on the senders since there is no load balancing going on here anyway?

mntbighker · ‎03-18-2011

I would need some level of assurance the trace was sent to a "dependable" recipient. It contains info considered sensitive by NASA.

mntbighker · ‎03-17-2011

Fresh install of Splunk 4.2 on CentOS. I'm testing with one client but have also tried many. I'm using splunktcp-ssl using light forwarding from Linux and Windows. I am getting data but since going to 4.2 I'm seeing these errors every 30 seconds for each client sending cooked data. If I downgrade the server to 4.1.7 I see the same errors from the 4.2 forwarders. 03-17-2011 13:49:30.072 -0700 ERROR TcpInputProc - Error encountered for connection from src=xxx.xxx.xxx.34:37573. Success 03-17-2011 13:50:00.072 -0700 ERROR TcpInputProc - Error encountered for connection from src=xxx.xxx.xxx.34:37666. Success 03-17-2011 13:50:30.072 -0700 ERROR TcpInputProc - Error encountered for connection from src=xxx.xxx.xxx.34:37765. Success Tweaking the heartbeat setting does not alter the 30 second timing. Here is some DEBUG: 03-17-2011 12:41:07.871 DEBUG S2S - In doConsume for LengthReadingState 03-17-2011 12:41:07.871 DEBUG TcpChannel - Before accept 03-17-2011 12:41:07.871 DEBUG TcpChannel - Creating polled fd from factory 03-17-2011 12:41:07.871 DEBUG StatusMgr - Updating status for TcpInputProcessor 03-17-2011 12:41:07.871 INFO StatusMgr - destPort=9979, eventType=connect_done, sourceHost=xxx.xxx.xxx.34, sourceIp=xxx.xxx.xxx.34, sourcePort=57370, statusee=TcpInputProcessor 03-17-2011 12:41:07.871 INFO TcpInputConn - Connection in cooked mode from src=xxx.xxx.xxx.34:5737003-17-2011 12:41:07.872 DEBUG TcpChannel - adding connection to factory created fd = 0xa64e7860 03-17-2011 12:41:07.872 INFO TcpChannel - Accepted connection 03-17-2011 12:41:07.880 DEBUG StatusMgr - Updating status for TcpInputProcessor 03-17-2011 12:41:07.880 INFO StatusMgr - sourcePort=9979, ssl=true, statusee=TcpInputProcessor 03-17-2011 12:41:07.909 ERROR TcpInputProc - Error encountered for connection from src=xxx.xxx.xxx.34:57370. Success 03-17-2011 12:41:07.909 INFO TcpInputConn - src=xxx.xxx.xxx.34:57370 closed connection 03-17-2011 12:41:07.909 DEBUG StatusMgr - Updating status for TcpInputProcessor 03-17-2011 12:41:07.910 INFO StatusMgr - destPort=9979, eventType=connect_close, sourceHost=xxx.xxx.xxx.34, sourceIp=xxx.xxx.xxx.34, sourcePort=57370, statusee=TcpInputProcessor And my input,output.conf: [splunktcp-ssl:9979] [SSL] password = $1$+tCc8wYTRIqB requireClientCert = false rootCA = $SPLUNK_HOME/etc/auth/cacert.pem serverCert = $SPLUNK_HOME/etc/auth/server.pem [tcpout] defaultGroup = Group1 [tcpout:Group1] server = xxx.xxx.xxx.101:9979 [tcpout-server://xxx.xxx.xxx.101:9979] sslCertPath = $SPLUNK_HOME/etc/auth/server.pem sslPassword = $1$NPPqXQDYcSWN sslRootCAPath = $SPLUNK_HOME/etc/auth/ca.pem sslVerifyServerCert = false

mntbighker · ‎02-25-2011

Me too... recently upgraded to 4.1.7 Drat, the splunk-launch.conf had splunk_home set wrong 😞 That would toss a wrench in the works. I'm surprised anything worked. I magically seems to work WAY better now in general 😉 The errors remain with the paths fixed up. The folders it's complaining about are not there to delete. How do I reset the buckets to forget about these old temp files? The paths seem to be buried in the actual database.

mntbighker · ‎02-25-2011

I'm getting this too with 4.1.7 on CentOS. I can get splunkd to crash just by going to the index health page. I can restart splunkd but going to the health page will reliably crash it again.

Posts	18
Solutions	0
Karma Given	0
Karma Received	4
Member Since	‎02-25-2011

Online Status	Offline
Date Last Visited	‎06-05-2020 02:02 AM

Version 6?

OSSEC app sudo messages gumming up the stats

Expired SSL Cert?

splunkd.log filling with these errors?

Re: Expired SSL Cert?

Version 6?

Re: OSSEC app sudo messages gumming up the stats

Re: OSSEC app sudo messages gumming up the stats

OSSEC app sudo messages gumming up the stats

Re: Disable Delete Capability - Free Edition

Re: How do I delete all references of a host so it...

Re: Expired SSL Cert?

Expired SSL Cert?

Re: ERROR HTTPClient - Should have gotten at least...

Re: splunkd.log filling with these errors?

Re: splunkd.log filling with these errors?

Re: splunkd.log filling with these errors?

Re: splunkd.log filling with these errors?

Re: splunkd.log filling with these errors?

splunkd.log filling with these errors?

Re: 4.1.7 upgrade from 4.1.4 new error message "Fa...

Re: Anyone know what a STMgr "out of memory failur...