About pilzi81

pilzi81 · ‎06-06-2017

Since I created this thread I've seen this error on different UF versions (6.3.x, 6.4.x and our most recent UF version 6.5.3) as well as on different OS (windows, linux, macOS).

pilzi81 · ‎03-04-2016

Hi muebel, thx for your advice! I already know the pdf - a really good presentation, but it doesn't solve this particular problem... The status quo looks like this: Every server has its own certificates (signed by our private CA) - one for Inter-Splunk communication and one for web. All our Universial Forwarders are using one single certificate (signe by our private CA too). We configured the Universial Forwarder's outputs.conf to use our certificate (certificate-path and password). The outputs.conf is located in an app which is deployed via the Deployment Server. Funnily enough this password will be encrypted at restart of the Universial Forwarder. Therefore for the communication between Forwarder and Indexer our certificate is used and everything works fine. However the communication between the Forwarders and the Deployment Server is the problem. For this connection the Forwarder uses the default Splunk certificate (the server.conf in $SPLUNK_HOME/etc/system/default refers to it). Trying to deploy a new server.conf (in which our certificate is configured) via the app mentioned above didn't solve the problem because the provided cleartext password wasn't encrypted... Providing an encrypted password in the new server.conf is useless as well, because every Forwarder uses its own splunk.secret file to decrypt the password. cu

pilzi81 · ‎03-03-2016

Hi, we are using self-signed certificates in our Splunk environment. In general everything works fine, but at a closer look we found that the Universial Forwarders aren't using our self-signed forwarder-certificate. Instead they are using the Splunk default certificates. Examining the conf-files I found out, that the forwarder's server.conf ($SPLUNK_HOME/etc/system/default) refers to that certificate. Changing the server.conf via an app doesn't work because the certificate password will not be encrypted.... 😞 Has anyone an idea how we can deploy a new server.conf to our Universial Forwarder in an (Splunk supported/recommended) automated way...? Using of System Center or such other tools isn't a good option, because of lack of privileges but for several hundred Universial Forwarders it would be "a little bit" annoying to fix that problem manually. thx

pilzi81 · ‎02-16-2016

Hi there, By examining the _internal logs I found the following, Metric Error: ERROR Metrics - Metric with name thruput:thruput already registered It is reported by Universal Forwarders of several Clients spread over the entire day (with peaks in the morning hours - so I suppose that it's related to the client's start-up) The interesting thing is, that all of these clients are still reporting events to the Indexers... Questions: Why does this happen? And how can I avoid this? thx

Posts	4
Solutions	0
Karma Given	0
Karma Received	20
Member Since	‎02-08-2016

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

Connection between Universial Forwarder and Deploy...

Why are universal forwarders reporting error "Metr...

Re: Why are universal forwarders reporting error "...

Re: Connection between Universial Forwarder and De...

Connection between Universial Forwarder and Deploy...

Why are universal forwarders reporting error "Metr...