Hi,
We are testing some auto-provisioning with the REST API, and I noticed that the serverclass that is in the gui, is not in the $SPLUNK_HOME/etc/system/local/serverclass.conf file. Shouldn't it be there?
Also, has there been any thought into putting an actual "append" feature into the deployment server REST API? Have to tell you, trying to implement an agile env, using the deployment server? Just not possible...you have to query it, get each entry, and then repost. Crazy beyond belief.
Oooo oooh! I think I know this one. Pick me teacher, pick me! ::hand waves in the air::
I'm willing to be the REST call is specifying an app context and as a result, the serverclass def got thrown into an app context. I always forget to be in the system context when doing this in the UI and end up having config creep. Here's how I address this (and embarrassingly often to be honest):
btool serverclass list --debug | grep -v "system"
If btool
isn't in your path then make sure to run ./splunk
in front. Essentially, you're pulling out all the serverclass stanzas that aren't already in system/local
or system/default
(which started appearing in more recent versions). Once you find entries, you can append it to your system/local
:
cat $SPLUNK_HOME/etc/apps/
where <app_name>
is the app where the serverclass was found.
Alternatively, if you have faith that you don't have bad config, you can probably just run a find command to directly append the contents into your system/local and zero/rm the old location. Then reload the DS. Doing that in one command is a little too risky for my comfort so I prefer the manual approach I mentioned.
Oooo oooh! I think I know this one. Pick me teacher, pick me! ::hand waves in the air::
I'm willing to be the REST call is specifying an app context and as a result, the serverclass def got thrown into an app context. I always forget to be in the system context when doing this in the UI and end up having config creep. Here's how I address this (and embarrassingly often to be honest):
btool serverclass list --debug | grep -v "system"
If btool
isn't in your path then make sure to run ./splunk
in front. Essentially, you're pulling out all the serverclass stanzas that aren't already in system/local
or system/default
(which started appearing in more recent versions). Once you find entries, you can append it to your system/local
:
cat $SPLUNK_HOME/etc/apps/
where <app_name>
is the app where the serverclass was found.
Alternatively, if you have faith that you don't have bad config, you can probably just run a find command to directly append the contents into your system/local and zero/rm the old location. Then reload the DS. Doing that in one command is a little too risky for my comfort so I prefer the manual approach I mentioned.
I never used the API and i got a serverclass.conf in search/local.
-10 points for gryffindor.
So, what "app" should I be in on the deployment server ensure that new serverclasses are put in the ../etc/system/local/serverclass.conf file?
I'd put system
. Throw us the URI you're using and we can be a bit more confident.
here's the url that's called for this serverclass:
I want to know:
1) when creating a serverclass, how do i ensure that it ends up creating it in the ../etc/system/local directory?
2) what url to use to reference serverclasses in the ../etc/system/local/serverclass.conf file?
the nobody
in that is the user to associate the config with. the search
after that is the app context for the config to live in. You -
as a wildcard when searching for config in any context:
/servicesNS/-/-/deployment/server/serverclasses
To create config in system, try:
/servicesNS/nobody/system/deployment/server/serverclasses
I chopped off the end of those URIs to avoid clutter but you should add them back in. Give that a shot to see if I remember this correctly (ie, I haven't tested this before posting).
Yeah, you're right. Ugh. At least it's on dev.
Now, about that append feature...
In all seriousness, I don't see how Splunk can expect anyone to use the deployment server in a cloud or agile environment, given the deployment server and the rest api limitations. I've stated this many times...all I hear is...crickets.
Frustrating, to say the least.
I found a serverclass.conf nestled way down in the etc/apps/search/local directory recently on a deployment server we're migrating off of. I had no idea it would work from that location until we migrated the clients over the new server and the data stopped coming in. Went digging around and found this odd copy that was actually working from that location.