- Splunk Answers
- :
- Splunk Administration
- :
- Deployment Architecture
- :
- Why second serverclass.conf located in search app ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark Topic
- Subscribe to Topic
- Mute Topic
- Printer Friendly Page
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Why second serverclass.conf located in search app after restarting deployment server?
I ran into an issue today after restarting my deployment server. After restarting, it would no longer load the "Forwarder Management" page, stating that there was an error in serverclass.conf. In the process of trying to find the error, I used btool to list the serverclass configurations. I noticed that there were a few stanzas located in "/opt/splunk/etc/apps/search/local/serverclass.conf". I never created this file and it only had about 6 stanzas in it, while my main serverclass.conf file in etc/system/local has over 80 stanzas.
I'm trying to prevent this issue from repeating, but I have no idea how the serverclass.conf file in etc/apps/search/local even came to exist. Any ideas?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you use the Add Inputs wizard to create remote inputs, it will edit the etc/apps/search/local/serverclass.conf
I'm not sure why. I am also pretty sure that any changes made through the CLI will also be saved in etc/apps/search/local/serverclass.conf and not etc/system/local/serverclass.conf
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have two serverClasses and their associated stanzas defining the corresponding Deployment apps that appeared in ~/etc/apps/search/local/serverclass.conf and I did not do either of these two things. I have no idea why they landed there. That feels buggy to me. There must be something you can do before going to Forwarder management that causes it to place newly-defined serverClass(es) in the Search app's local.
I was freaking-out when I looked in ~/etc/system/local/serverclass.conf for a serverClass to remind myself what the Deployment app was and I did not find it, yet I found it in Forwarder management. I would not have guessed where it went until I saw https://answers.splunk.com/answers/236247/forwarder-management-serverclassconf-not-updating.html?chi...
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you by chance end up with the deployment server as a client of itself? We have ours blacklisted. And are you by chance distributing a search app via deployment-apps?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The deployment server hasn't ended up as a deployment client, we also have it blacklisted. We did deploy a search app via deployment-apps to our search heads, but later deleted it. The search app was located under etc/deploymentapps/search-2. That stanza, or anything related to it doesn't show up in the suspicious serverclass.conf file.
Welcome to the Splunk Community!
Tech Talk | Elevating Digital Service Excellence: The Synergy of Splunk RUM & APM
Adoption of RUM and APM at Splunk
