6 hours 3 minutes
Hello and welcome back to the Splunk Enterprise Certified Administrator Course on Cyber. And this lesson, we're gonna be doing a lab to talk about how you would manage forwarders in your distributed Splunk environment.
So the core concepts that we're gonna cover in this video are basically what the deployment server is, how to configure a device so that it is a deployment server, how to set up clients so that they report to a deployment server
and then how to use the deployment server to deploy APS to those to those clients.
So let's get started working on that. So toe look at the deployment server. You can just log into your slung server that's going to act as the deployment sever. This could be a standalone device or if you don't have a whole lot of clients in your environment, if you have less than,
say, 50 clients that will be reporting to the deployment server,
this could be combined with some other management device as well.
For the purpose of this lab, I'm just using an all in one Splunk instance to demonstrate this doesn't really change anything. Most of the time,
there are at least for the demonstrations. Purpose? Yeah, It being an all in one won't change the way anything looks or how you go about doing any of the management. So should serve the purpose.
So the first thing to do if you were trying to review your deployment server is to go into Splunk Web,
go to settings and then Ford or management.
So, as you can see, this screen is not,
this device is not considered deployment server. If it was, you would get a management screen here for creating server classes, deploying APS, seeing which hosts are phoning home.
So there's two ways to get a to get this screen to populate. And basically, that is also the two ways you could have ah, device be recognized, this unemployment server and you can see it's actually set right here.
Distributes deployment APS to spawn clients. No clients or APS are currently available on this deployments ever.
So that's your answer. You either need a client to phone home or you need APS to be populated,
so we're gonna just do, um, this part and make an app available.
Eso Basically all you have to do for that is open command line to your device.
Go to the appointment APS directory, which is where any APS that are gonna be sent to deployment clients need to reside so up Splunk at sea deployment maps.
So as you can see, this is empty. And because it's empty, this server is not recognized as a deployment server. But if if I just make an app called appointment,
this is now going to register as a deployment server because it has
the deployment uploaded. So if we go back here
and refresh the screen, you can see how changes. Now this device is officially deployment server theme. Other way to get this to happen is on your individuals. Universal forwarders. If you set deployment client dot com s O that it phones home so that that devices configured to phone home
to this device, then it would have clients, and that would also make it be recognized as a deployment server. So, as you can see, here's our APS.
We don't have any server classes. And what a server class is, Is it basically just maps an app or a group of APS with clients? And so this dictates which APS air sent to who
so basically, these are the three components that make up the deployment server. You have, ah, bunch of deployment APS. You have clients there phoning home and that the deployment server has connection to. Then you have server classes, which you create to to specify which app see one deployed. Which clients
and this is how you do your configuration management and split basically.
just for the purpose of demonstration, let's create a server class. So we have this deployment at
Let's let's do, ah, a legitimate example. So
So this is something you should do if you have. If you're using the deployment server
rather than having an Etsy system, local deployment client dot com
set it up so that all of your deployment clients are configured via an app.
And the reason that you want to do this is because, as we talked about before at sea system, local will always take the highest precedence. So if on your deployment clients you're setting this configuration in etc. System local, the deployment server cannot overwrite that, because what's gonna happen
when you push an app from
deployment APS on the deployment server to a client, it will go in there etc. App directory, which means
that they can never take a higher precedence than etc. System local, so you can't manage.
You can't centrally manage any configurations there made a Nazi system local because the deployment server can't right
any files at a higher precedence level than that.
So where this could be a problem is if down the road, you need to change your I P address or the hosts or the DNS name or um, or migrate to a new deployment server altogether, you won't be able to just push an app that has a new setting. You'll have to manually change all of those deployment clients.
So it's a lot better if you just configure it as an app
to begin with.
the way you would do that is basically just on the actual deployment client maker, and you would make you make whatever the APP is gonna be named. I tend to dio I would call mine. They're all deployment clients.
Okay, so you see that snap and then within that I would make a new directory
and we'll just have it be. Default is fine
and we would make
appointment Flying's got
and in here we're gonna have to specify basically the settings that will dictate where that phone home to. So in order to find that you can just search Splunk deployment client dot com and you'll find the admin manual
file for this. And so these air great references for figuring out how to do basically any configuration and Splunk.
They'll show you examples. They'll give you documentation on all the different options. Etcetera, etcetera was very awesome. As you can see, this is the default. So this is what I was saying, where when APS are pushed, this is the directory they go to,
so that's where that's actually defined. You can change that if you want to, but you should not unless you know what doing.
we're gonna just look through here down at the example, and we'll see these air. The settings you need to configure your,
um, deployment client dot com to send to
your deployment server. So we would make,
uh, we'll just copy that will paste it in here.
You can set phone home
inter role in seconds
to how often you want the deployment client to phone home to the deployment server to figure out if there's any new APS or changes taps they already had. So you can specify
when you're when you're setting it up. Initially, 60 seconds is good, just so like have it pinging home so that you can make sure that it
ends up working. And then once, once everything settled in, I normally ramp that up to, like 600 seconds because you know, once once everything's in place, you know it's working. You have the initial APS deployed. You're not really gonna be updating it that much, so you can just cut down the amount of
traffic that's coming into your deployment server
by just increasing how often, uh,
for reducing how often the client's phone home.
So we specify the target. You are. I It is best to use a domain name, and the reason is,
then when you give the I P address ever changes,
he doesn't really matter. You just have to get your DNS record, and your deployment clients will still be fine. But in this case, I don't have a
Deena's record in place, so I'm just for demos sake. I am just
using the I P address. But you would specify
Target your I equals
either the domain name or like a address. Coghlan's Blunk Management Port, which by default is 80 89. And I would not recommend changing that ever.
The one other thing to note is, obviously, you'll need firewall connectivity between all of your deployment clients and the deployment server on Port 80 89.
But so this is the setting you would make. So this says to all those hosts that they should check into the deployment server every 60 seconds and that this is the your eye they can use to reach the deployment server. That's all the settings that you need.
And so you would make this app locally on the deployment clients.
And then you would have a server class
in the deployment server that pushes this app, and basically the deployment server
will overwrite the existing app, and then it will treat it as a managed app from then on. And so you consensually manage that configuration versus if you made it locally, you would not be able to do that.
So now you can see that this app exists here and the way you would deploy that is by creating a new server class, and I tend to just call these like. I like to make my server classes pretty modular so that I know exactly what they dio, who they apply to, what app there delivering. So I'll just name it the same thing all deployment client.
And so I know that the app I want to send is my old deployment clients at.
It's the only app I want to send through here.
I'm gonna edit it so that it does a restart so that the configuration actually takes a perfect when that's deployed,
and then I'll return to this screen and specify which clients need this setting. And with your all deployment clients, it's all clients, so you could just specify star Now, as you can see, you can specify a client name, a host name and I p address or DNS name. And if you had devices phoning home here,
they would show up here, and you could toggle
to see which ones you're naming convention or your wild card or matching
you could. Also you can also like views like a naming convention like
my host star. Maybe there's a series of numbers after that, but you can use stars anywhere in their toe. Specify naming convention. But in the case of this all deployment client app, every deployment clients gonna need it. So just use a star and apply to everything
so you can save. And just for your knowledge, you can also specify by machine type. So if I had devices phoning in and there was Lennix and there's Windows, some options would show up here. So I could specify which hosts descend to based on the machine type, which is pretty useful if you're like deploying, like the Lenox App or
or the Windows app and you just specify only go to the proper operating system,
so we'll save that. And so now,
um, it says we have a client's because I'll have any reportings an unmatched my criteria but assumes I had a client. It would would meet that naming convention, and then this app would automatically be deployed. And that's basically how the deployment server works. You can, um,
make is many of these server classes as you want, so I tend to do like I would have another one, probably for,
um, all outputs,
which would just be outputs dot com and we're all forward or outputs, probably is what I would call it, and I would have it pointing to the index or tear.
And then I'd probably have
one for basically. Like say, I have assist Log Server somewhere I would put all my sis log t A's. Um, all the different ta is that Apply to the data that's coming into the assist log in there and deploy that to the CIS log server so that it has all of its abs.
Yeah, you just This is this is how you do your central config management in splitting. He just
upload the APS that you need to that op Splunk at sea deployment deployment APS directory. You create a server class to push it, too.
That pushed the proper APS to the proper clients. And obviously, you need to have this set and configured on your clients so your clients actually phone home here so they can get the settings. But that basically covers what you need to know about the deployment server.
What makes it the deployment server, which is either that it has deployment APS or that has deployment clients phoning home.
Realistically, it needs both to be a deployment server. Then we talked about how where APS have to reside. So it's in that deployment APS directory. How to use server classes to map APS to clients. Andi talked also about this app and how we want
that deployment client configuration to be centrally managed.
So you wanted in an app, know, etc. System local configurations on your forwarders. Otherwise you cannot manage them remotely,
so that is very important.
But that covers everything you need to know about the deployment server. That should be enough information to get you started using it in your own environment and also it hearing the best practices. So that's going to wrap up this lab, and we will catch you in the next one.