This is, uh, Wednesday, July the 9th, 2025. It is the monthly general meeting of SLUBG, the St. Louis Linux Unix Users Group.
Our presenter tonight is Sean Tweehaus for both the, uh. Uh, basic tutorial.
And, uh, which is Ansible 101. And also for the main, which is Ansible Pull.
Uh, and uh…. Let's see… got some slides here.
About us. Uh, this is the St. Louis Unix Users Group, uh.
Obviously, the name, Unix, is kind of where we started. Uh, we have our general meeting on the second Wednesday of each month.
And we kind of deal with anything that's kind of open standards, so….
We're actually a legal…. 501c6 Corporation.
Uh, and uh…. We've got members who are basically involved in everything from Linux, BSD.
Basically, as I said, anything that's open standards. Been around and beating continuously since July of 1992, so….
Somebody do the math real quick. What does that make it? That makes it, uh….
33? 33 years? All right. All our meetings are free, open to the public.
Uh, there are no individual membership fees. Uh, let's see….
Try to provide some education, information, and support for Linux users.
Uh, we haven't met in physical since the beginning of the COVID, so we.
Always using the Gypsy or Zoom. Uh, let's see, we maintain, uh, try and maintain all of our presentations in archives.
Uh, so you can go back and look at our previous, uh.
Presentations. And, uh, there's also a few PDF handouts, sorted other links that we keep on our website.
Agenda for tonight, uh, should have started…. Thor, 4 minutes ago, at 6.30.
Uh, the arrival, uh. The system comes up at 6 o'clock, uh, just so people can check their, uh, microphones.
Screens, cameras. 6.30, we try and start our base tutorial topic.
Uh, after that, there's called the GUI middle of the meeting, and that's, uh, where we do introductions.
Announcements, questions, short Q&A. And at about 7.15, we'll get to the main topic.
Um, let's see, next slide. Okay, the base topic, uh, like I say, roughly about a half an hour.
Uh, we try and keep it simple. It is kind of….
Aimed at being a tutorial, a basic thing, uh, so it's up to our speaker to tell us if we're getting too much into the weeds.
Uh, and uh, I believe, Sean, I'll ask you at this point, would you like questions to interrupt you as you go, or you want to hold till….
Some period to ask questions.
Yep, interruptions welcome, haggling, welcome, less welcome, but still welcome. Questions welcome, bring it on.
Okay, alrighty. Um, so with that, uh, the gooey middle, uh….
See, as I say, we'll have… after the main presentation. Uh, we'll pause for this, uh, gooey middle of the meeting, where we'll.
Do the rest of the announcements and a short Q&A. Uh… I think everything else is covered there on the slide.
Um… do we do this now, Stan, or we wait till the GUI middle?
No, do this now. Go ahead. Who are you?
Okay. Uh, I'm Gary Meyer. I'm the MC for tonight. I'm the president of the group.
That other voice you just heard is Stan Reichert. Stan is doing all the production work.
Uh, as he always does, he's the vice president, and he's the one who really keeps everything running well.
Uh, Lee Lamert is, uh, here in the Batcave with me. Uh, he's our treasurer of our organization.
And, uh, our secretary slot's open right now. Anybody who'd like to volunteer, we'd love to have, uh.
Someone else helping to be an officer in the group. Chat Monitor, uh, that's something that just happens at these meetings, so if anyone would like to volunteer to just monitor the.
Chat in Zoom. That's where people can just type in a message while we're talking.
Uh, sometimes. Oh, okay, alrighty, we have a volunteer, good.
I don't want to spend my bill for my services.
Uh, topic wrangler? Uh, yeah, we could always use help, somebody helping to find speakers.
Topics to talk about. Um, so, yeah, topic wrangling, you don't have to volunteer tonight, but talk to me, or Stan, or Lee.
And, uh, we'll, uh, help get you organized. Speakers! That's the other thing we always need, is more speakers, uh, so….
Uh, if anybody has an idea for a topic, or wants to volunteer, wants to suggest somebody else.
We're all ears. Uh, with that, we'll stop now. Obviously, we've got a nice little set of slides here you can go back and review.
And we're going to turn it over to Sean Tweehaus. Who's going to give us the tutorial on Ansible 101?
Sean?
Thank you, you should be seeing my screen right now and the slides.
We see it. Solid black.
Solid mark.
Alright, I can't get to him back, there we go. Alright, I'm ready. So….
Uh, so we're gonna talk about Ansible. The first, uh, portion of the talk is gonna be just Ansible 101.
I'll turn my camera on. The first portion's gonna be Ansible one-on-one.
Uh, like, it's gonna be the more traditional way that people use Ansible all the time, uh, in large organizations and small places.
And then we're gonna flip it on its head and see how we can use Ansible even in, like, a home lab.
Type of environment using Ansible Pull. So, let's go ahead and get started with introducing Ansible. So….
For decades, years, long time, people have been doing manual… have mostly been doing manual configuration. This is where an administrator will use their hands.
To SSH in to each server, and we'll configure them manually with their hands, and probably they'll be following a Word document or something like that.
As they go, and you can imagine this is very time-consuming, very error-prone, like, what if somebody has a typo and doesn't notice, or what if somebody.
Uh, you know, skips a step on the Word document that they're following, and now they've missed a step or something.
So, there's a lot of, uh, problems that can arise when you're doing the sort of manual configuration.
And Ansible. Is a configuration management tool, and it kind of changes the game up a little bit. And so with Ansible, what you do is you use your hands.
To write an Ansible playbook. And then that playbook is what will actually configure the servers.
Still back. You're still black, no slides.
So, no more… Yes, sir? Oh.
Sorry about that, let me try again.
Nevertheless, it was a very dark slide.
It could have been. Black on black is always impressive.
Okay.
Still black, huh? This is fun.
Great show. Hmm.
Yep. It worked before the presentation.
Oh, yeah, of course it did, you know? Always works.
Beat your face.
We plugged the runway lights back in and leave them plugged in.
This is an airplane.
What about this screen?
Nope, solid black.
Okay, wow. Alright, well, I guess I'm gonna try to leave the call and rejoin.
Doom, doom-doom.
We've got the shadow puppet, Gary. And this… this is what makes these interesting meetings interesting.
Big thing, really, is the sound. I mean, we really have to have good sound.
Yeah, only the presenter needs to be really concerned about the video.
And, uh.
So, for the good sound, now we have Lee and the Omnitech!
Yeah. Otherwise….
Watching Gary dance around his chair.
Gary Dance around the chair.
Hey, we see something!
You didn't… there we go, we….
Okay, here we go. Yay!
Sorry about that. Like I said, we're good.
There we go.
Sorry about that.
Steve, put your last name in, please. There's a Steve Gomez here, we don't want Zoom.
Steve, what's your last name in, please? There's a Steve Goldman here, we don't want Zoom.
Okay, can I… is this working now? Can you hear me and see the screen?
Okay, can I… is this working out? Can you hear me and see the screen? Yes.
Yes, yes.
We've got about a…. 10 to 15-second echo….
Yes. We've got about a 10 to 15 second echo.
Okay, I think it'll be okay now. How's that?
Sounds better.
Okay, sorry about that. This is my first time using Zoom on Fedora here, so I'm….
Maybe you're running into some issues here, I'm not sure. Um, but I'm gonna try to continue.
So, like I said, uh, you know, the way that we were doing it before was manual configuration, use your hands, SSH into each server, set it up manually, probably following some documentation.
Um, down here at the bottom right, you can see the way that Ansible, uh, handles this, which is you use your hands to type in Ansible Playbook.
That Ansible Playbook will then be ran against one or more virtual machines, which will….
Configure those servers. For you, so you don't have to do it with your hands.
And one huge benefit of this is if you somehow need to manage a large amount of virtual machines.
Using the manual configuration method, you really have busy hands. Like, you know, if you go from one.
Set of servers to 4 sets of servers, well, you just tripled your workload if you're doing everything with… manually with your hands.
Uh, but using Ansible, yes, it does take a bit more work to write a playbook that is….
You know, robust enough to run against the whole fleet of virtual machines.
But it's definitely not, like, 3X, 4X as much work, right? It's definitely a lot easier.
And so you can write one playbook still, but then run it many times against many VMs. And so this is the big benefit of Ansible over.
Manual configuration is you can manage many, many more virtual machines without hiring a whole army of IT people.
And the ones you do hire will be… feel more empowered to.
Managed large fleet… large fleets without…. Feeling like they're being ran around, you know, like a chicken with their head cut off.
And feel free to interrupt me at any time with questions or comments, so….
So this is a high-level workflow of Ansible. So on the left side, we'll start on the left side, and we can see that.
We have an administrator typing up a playbook. So a playbook is a YAML file, basically, that says, perform task XYZ.
On hosts A, B, and C. And so what you'll do is you'll put that playbook on a control node.
And the control node is the one node in your whole fleet where you're going to install Ansible.
In a typical, uh, scenario, like we're talking about here. So you're gonna install Ansible on your control node, then you're gonna put your playbook.
On the control node. And then, you're going to run the Ansible playbook command.
On your control node, passing in that playbook as an argument.
And then what Ansible is going to do is it's going to translate your playbook into a bunch of Python scripts.
And then it's gonna SSH into each one of your inventory hosts, and it's gonna run those Python scripts on the inventory host, and the Python scripts are what is actually going to configure.
The servers. So, at this point, let's switch over to the terminal.
And I will show you…. An example.
The command you're typing is being…. Hidden, or the first line is being hidden by a….
Zoom control bar. Yep.
Y'all can see that? Love it.
I can see it too, I don't know how to get rid of it, sorry.
I'll just make sure I'm typing a little bit lower. So here, the command I'm running is Ansible-playbook, playbook.yaml. We'll take a look more in-depth at all this stuff in a minute.
But I just want you all to see what it looks like.
Choose hide video panel.
Uh…. Sorry, that didn't seem to do it.
Okay, anyway, let's, uh, let's keep going here. So…. So, I ran the playbook.
And up here, you can see that the first thing it declared was this play. Configure a new document route for HTTPD.
And then it did several tasks. That we see here. And if you are someone who doesn't know what Ansible is, I feel like you can still read this.
Pretty well. Like, if you saw… if you're an administrator, and you see.
Ensure HTTPD is installed. I feel like that's pretty self-explanatory, what this thing is doing, especially if it's called a task. You're like, oh….
It's probably installing HTTPD. Same thing with the rest of these tasks, where it's, you know, making sure the slash web directory exists, and making sure the index.html exists.
And it's just running through all of these tasks. Until… and you see here, all the tasks are changed. Changed, changed….
Until we get down to, like, here. This one says OK.
The firewall is enabled and running. That one says OK instead of changed, so it didn't actually do anything here, there was nothing changed by running this task.
That must be because the server already had the firewall enabled and running.
And then once we get down here, uh, you can see….
Uh, there's another play called Test…. Web connectivity.
And we can see that down here, we say all assertions passed when on the task, it's called.
Correct web content is returned. So not only are we doing some configuration of this server A.
But we're also then testing at the end to make sure that everything worked as we expected.
And so that's what it looks like to run an Ansible playbook.
And you could imagine doing, you know, you can imagine that, you know, writing.
This playbook took a significant amount… like, some amount of time, right, to write up all these tasks in YAML.
And to know how to do that took quite a bit of time.
But you can also imagine that doing each one of these steps by hand.
Would take quite a bit of time, right? Uh, but if I had to do the playbook on multiple servers.
That would be much easier to apply this automation to multiple servers than to do multiple servers by hand.
So that's basically just what I wanted to show with this very first, kind of.
Let's see Ansible in action, part of the presentation. And let's continue forward now.
Question, are there recipe books for these? These steps are like a man page or something.
Yeah, there's a ton of docs. The docs are decent. And there's a ton of modules, and anybody can make their own module.
If they want to, and you can, um, use other people's modules. They can put them on a place called Ansible Galaxy.
For anybody else that wants to use them can use them.
And so, yeah, there's a lot of sharing and reusability when it comes to modules and things like that.
Uh, and maybe we can get into that a little bit later, but yes, that definitely is a… is a thing.
So what you just saw…. What you just saw is, uh, you know, what we typically call configuration management, if you want to get specific, you can say configuration as code.
And some of the key benefits of configuration management over, like, manual configuration is that it's declarative.
And then you get several benefits that you basically get when you automate anything, right? When you automate something, it becomes easily repeatable.
Less error-prone and more verifiable. And that's true of, like, automating anything, so it's also true of automating.
Configuration management. And specifically, you saw the tool Ansible, which is open source, it's heavily backed by Red Hat.
Written in Python, and the most typical configuration is agentless. And that's because you install Ansible on only one machine, your control node, okay? You don't need to install Ansible.
On every host that is managed. That is under management, you only need to install Ansible on the control node.
This is different than some, like, I think Puppet is one.
Where you have to install the puppet agent on every node in order for it to work.
Ansible is agentless. Big selling point there.
And so now we've seen Ansible, and we decided we want to use it, so how do we get our control node set up? And remember, the control node is the one place where you install Ansible in most, uh.
Most common uses. Um, so to set up your control node, really, all you gotta do is install Ansible Core.
And that's going to require… most recent versions of Ansible Core are going to require, like, Python 3.8 or newer.
And then once you have Ansible Core installed on your control node, the only other big requirement is that you must have remote access to.
The hosts that you're trying to manage. So, in this case, we're managing Linux hosts, so we need SSH access.
To the host that we're trying to manage. But you can also manage Windows machines with Ansible, and so you could do WinRM.
As a way to basically sort of pseudo-SSH into Windows machines.
Once you have the control node set up, you also need the inventory host set up. So, Ansible is not really a good provisioner.
And when I say provisioner, what I'm talking about is kind of like.
Something that people often say is, infrastructure is code, and so when I'm talking about there is, like.
You know, allocating resources, like, so you could think of that as, like, creating a virtual machine with this much CPU, this much RAM, this much storage.
Ansible doesn't do that, really. It can… it can do it, but it's not really what it's best at.
Um, and then after you, you know, allocate the resources for, like, a VM or something like that.
Then you also need an OS installed. And once again, this is not something Ansible can do. Ansible is, like.
Ansible will manage a VM after, like, it's already been provisioned, but this is not something you do with Ansible.
Uh, and then also, you're gonna need Python installed, and you're gonna need the managed host to be remotely accessible via something like SSH.
And you're most likely going to need elevated privileges, right? And when you take all of these tasks on this slide together.
This is usually called provisioning. A host, right? And there are a ton of tools that can do this, like….
You know, for… if you're, uh, Red Hat, you might use Kickstart to do this. You know, with Kickstart.
You can easily, um…. You know, install an OS, get an IP address, configure SSH, all that stuff with Kickstart.
Or, if you're more, like, cloud-native. You might do this with, like, Terraform, with, like, AWS EC2, where you're creating an EC2 instance that already has, like, a.
Operating system and Python and SSH and all that. Or, if you're, like, using VMware or KVM or something, you might clone an existing virtual machine.
And that way, it'll automatically have an OS and all that. So there's tons of ways to provision.
A virtual machine. Um, but you have to do that before you can manage that virtual machine with Ansible. So these are all preconditions.
To a host being managed via Ansible. All right, so now, um, obviously we just saw this running, so I already have everything set up, but we can still kind of, uh….
We can still go through the motions here to see what it would be like.
So, the first thing that you'll need… so this is my control node that you're looking at right now.
It's a fedora machine, I don't think that really matters, but if I do pip list.
And we gripped that through Ansible. Uh, we can see that I do have Ansible installed on this host.
And there are a ton of ways to install Ansible. I usually install it via pip, because then you get, like, the most up-to-date.
Version. Um, you see we have, what do we have? Ansible 11.6, Ansible Core 2.18.6.
You can also install it probably through your package manager, so if I do DNF info Ansible.
We can see that it is available in the Fedora. Repositories….
Um, and it's actually even the same version, looks like, so really up-to-date in Fedora.
And then if I run, uh, ANTS…. Sorry.
Ansible dash dash version, we can see that it's installed, and it's on my path and all that.
And that's really all you need, right? That's really… to set up your control node, I mean, install Ansible, and you're pretty much good, you know?
And then, you know, uh, and then you gotta make sure your managed host is set up, right? So one of the hosts that I'm managing is called Server A.
So I'm going to do SSH student at server A. And we can see that I have SSH access into this server A.
And we can see that it's using a key, because I wasn't prompted for a password or anything like that, so I already have.
Ssh keys set up between these hosts. Which is good, and then if I run sudo-i, we can see that I do have.
As the student user, I have, uh, permissions to escalate my privileges like this.
So, I basically have SSH access and. Access to become root or escalate my privileges, which is….
Pretty much all you need, your managed host to be able to do.
I just need to SSH and sudo, and then you're good to go there.
So, what I've just proven is that we have both the control node.
And the managed host, set up with all the prerequisites. For Ansible to work.
Uh, right now. So, moving forward….
See, if you were in my class, now is when I would say.
Uh, Sean? Um, on, uh, the managed host….
Yeah.
Uh, what is… two… two questions. What are the minimal. Requirements for Python.
Which version?
I, uh, I actually don't know, but I would assume it's the same as Ansible itself, so 3.8, but that is an assumption.
Okay. Uh, and the other question, and this probably…. Obvious, but maybe not to me. Um….
When Ansible, the control node, is. Talking to the managed host.
Uh, and you say that… what does it do? Like, ship a Python script over there or something?
Yep.
Okay, and the other…. Host, the managed host does not need.
Like, any Python modules or packages installed, right? It's like…. You don't have to have PIP over there.
Right, you just need Python. Am I right?
And then, no, you do sometimes. It just depends. Um…. Most of the time, for most basic administration tasks, you don't need anything special on the managed host.
But I have seen some scenarios with some kind of more esoteric modules.
That do have additional requirements like that. Most of the time, the additional requirements are on the control node, not the managed hosts.
But, yeah, I mean, you can get into those situations where you need certain Python things on the managed host, but I would say it's.
Rare or very rare?
Okay, and so, just real quick, in a situation like that.
Ansible…. Ensure that that module has been installed.
Yep, yep, there's a pip module for Ansible. There's also, like, a… and these mod… some of these modules are maintained by the community, like I was talking about earlier.
So they're not shipped by default with Ansible, but you can install community modules.
That will use, like, pip, or there's even one for cargo, there's even one for UV if you're, like, a really, uh….
You know, trendy Python user, you probably like UV right now. So there's, like, a UV module in the community that'll install stuff with UV as well, so….
Yeah, there's a ton of community modules that can do all that kind of stuff.
Okay, thank you.
All right. So, I've been talking a lot about these managed hosts.
And I see…. Question. Does Ansible, uh, Ansible can manage multiple host patching? Yes, certainly.
Um, Ansible can manage packages on the managed hosts. And so the way that you update the packages on a remote… on a managed host is you just say.
I want you to install the star package, like the wildcard.
And I want you to put the latest version. And if you do that, what it's gonna do is it's going to update.
All of the installed packages to the latest version, so that's a very common….
Thing in Ansible that has done all the time. And yes, you can do that on a whole fleet of machines.
At the same, um, yeah. So, um….
So I, uh, so I've been talking about this Ansible inventory, or these managed hosts.
And, you know, you can't just run, and this is probably for your own safety, like, kind of taking away a foot gun.
But you can't just run…. Ansible against any host you can SSH into, right? Because….
You know, you gotta think about it, a lot of these playbooks, they do a lot of mutating, a lot of very destructive action, right?
You don't want to accidentally run the playbook on the wrong.
On the wrong host. You know, that would be bad. Um, and so, Ansible forces you to add the host that… that… that….
It will run against to something called an inventory file. And so Ansible only knows about the host that you add to this inventory file.
There's actually two ways to do an inventory. You can do a static one, or you can do a dynamic one.
Obviously, this being a more introductory talk, we're just going to talk about the static one.
But if you have some, like, ever-changing. Pleat of cloud EC2 instances.
There is ways for you to, like, dynamically, like, hey, give me all the….
Instances running right now, and then add those to your inventory.
And run your playbook against, you know. All of them. But let's just stick to static inventory.
And so here on the screen right now, you're gonna see, um, inventory.
This is… this is an inventory file, and you can see that it's just a list of server names. One on each line.
And at the bottom, I have an IP address, so you can put, just, like, raw IP addresses in.
Your inventory file, it is discouraged. But totally possible. And so, if I had an inventory file like this, what you're seeing on screen, that I could run.
A playbook against server A, server B, server C, server D, or whatever host is at 192.168.0.254.
Um, now, if I had an inventory file like this, I could not run a playbook against server E.
Right? Because it's not in the inventory. Ansible doesn't know about it.
You can also create custom groups. This is very, very important, I would say.
Um, so if you look at the inventory file up on the right, you can see this is actually an INI file, this is using INI syntax.
So on line 1, the square brackets denote a heading. In this case, that is a group.
So on line 1, I am denoting the web. Group, and on line 2, I'm saying that group has server A.lab.example.com.
And then on line 3, I'm specifying the app group. That has server B and server C in it.
And… and if you look down at the bottom. If you run the Ansible-inventory command.
It can actually show you what it sees in the inventory, so you can get a good sense of.
What is going… what Ansible thinks your groups and all that are, and you can see that it's made a little graph here.
And you can see the at the… on line 3 there, the app group has server B and C, and….
Line 6, the DB group has server D, and etc. So, this is very important to be able to group.
Your inventory host together. Because oftentimes, you'll get in a situation where you might have one playbook that you want to run against.
All of your hosts, uh, maybe just to upgrade packages. But then a lot of your playbooks, you're going to want to target specifically for your app server, or specifically for your database servers, and stuff like that.
And so these groups are very helpful. Also, you can.
Put different variables. Uh, for different groups, too, but we're not really going to get into that.
Tonight. Yep.
Before you move on, question. Um, can you put a server in multiple groups?
Yeah. And you can….
Okay, thank you.
Can you put… can you put multiple groups in…. In the inventory? Could you use….
What happened? But the….
Yep. You can nest groups, and you can nest…. Yeah, you can do all that. You can get very complicated. I'll show you… I'm gonna show you… we're about to get into that. I'm gonna show a basic example, and then I'm gonna show, like, a production-grade….
Example. Okay.
So…. Let me get my notes up here. Um, we're gonna run….
Uh, so let's just first take a look at the inventory.
Uh, let me do cats, because it's a little bit cleaner.
So, if we look at this inventory.ini file that I have in this project, we just have server A and server B.
It's, like, as basic as you can possibly get, and it works.
Okay? And if we did Ansible inventory-i, inventory.ini. Graph….
If we run this command. Then you'll see that this is very boring. We have… so, first of all, you have the all group by default, that includes all your servers.
We also have this ungrouped, this is, uh, one that is made for free, and so any of your ungrouped servers.
We'll be in this ungrouped, uh, group. Which is kind of ironic. But yeah, we can see that Ansible just sees we have server A and B, and there's no groups.
Now, if we were to look at a more complicated inventory, like, um….
This one…. We can see that….
Online 1…. I have… I'm declaring it in a web group, right? So you can imagine, this is, like.
All my web servers in North America, okay, for example. And then we have on line 3, the EU web group. And so you can imagine this is, like, all of my web servers in Europe, right?
And then on line 5, we have web, but then there's this colon in the middle, and then there's the word children.
So, basic… and then, underneath of that, we have NA and EU web.
Right? So basically, on line 5, I'm declaring a web group.
That contains the children. Of NAWeb and EU web.
So what does that mean? That means that my web group is going to contain all of my North America and European web servers.
Uh, together. So, if we run our little graph….
We will see that we have no ungrouped. But then we do have a web group.
And it contains the NA web group and the EU web group and all of their hosts.
And we can see that I've done the same thing for app and database and all that, but also, I didn't show this, but I also have a group for, like, NA. If I want to run some playbook against all my NA servers.
Then I can also put all of my servers in the NA group, so now my NA group contains.
All of my NA web servers, NA app servers, and NA database servers.
So, like I said, uh, it's as flexible as you need it to be. It's probably… you can probably go crazy with it. I don't know if you want to go crazy with it.
But it can definitely do something like this, which I feel like this could be, like, a, you know, production-grade, um….
Example of how this could work. Let's go back to the slides for one more.
Okay, and you'll notice that for those past two commands, I had to do, like, "-i.
Inventory, that INI, which is the name of the inventory file.
And that gets a little bit annoying to have to, like, pass that in all the time, the dash I, inventory INI.
Uh, so what you can do is you can have an Ansible.cfg file.
Uh, and if you look here, on line 1, I'm specifying defaults.
And then on line 2, I'm saying my inventory is in this file. Inventory.ini.
And if I do that, then I don't have to keep passing that in on the command line over and over again.
Another, uh, important one for this…. Is remote user.
Online 3. And this is the user that Ansible is going to SSH, or I guess WinRM?
N as…. And so, let's go ahead and take a look at that. So if we look at….
Um…. My Ansible config.
You can see that I have the inventory specified, and I have the remote user as student, right? That's the one that I demonstrated.
That SSH and pseudo is set up for. So that's… that's what I'm using there to SSH in.
And because I have these two lines set, that's why…. I was able to just run Ansible….
Playbook, and then the name of the playbook file, without needing to do the….
Inventory, you know, without needing to do that extra parameter, okay? No big deal.
Okay, now…. We're about to dive into a playbook, but before we can, we need to know a little something about YAML.
Okay, so, um…. You know, uh, playbook, an Ansible playbook.
Is a YAML file. The most important thing about YAML. The most important thing to know about YAML is that it has significant white space, like Python.
So if you do one space too many. Anywhere in the document, you're going to invalidate your whole document.
If you do one space too few, you're gonna invalidate your whole document, okay?
So you gotta be very careful with how many times you press the spacebar.
When you're indenting YAML. That's the most important thing.
Uh, the other thing is that YAML files are really just a bunch of key and value pairs.
Okay, so if we look at this line. Near the top, it says class, colon.
And we know that class is a key because it comes before a colon.
Okay, so class colon, okay, class is a key. And then on the right side of the key, it says IT-230.
That is a string value, okay? So we've got a key and a value pair. Class IT230.
On the next line, we have remote colon, and we know that's a key, because it comes before the colon.
And then after the colon, we have true with a lowercase t, and that's a Boolean value.
There are a ton of ways to do Boolean values. I think this might be like Python. I think Python might be similar.
Because you can do true with a lowercase t, true with a capital T, yes with a lowercase y, yes with a capital Y, or 1. Those are all truthy….
Values. The next line down, you can see teacher colon, so we know that teacher is the key, because it comes before a colon.
But then if we look at the right, ah, there's no value! Guys, there's no value next to teacher, man. Oh, no, we're doomed.
But wait, there is a value. How do we know? Because we look at the next line, and we see that it's indented.
So, if there's no value, and you look at the next line, and it's indented, then that indented line is the value. Can you believe it?
Crazy, right?
Except that it violates your one space. Rule. There's two spaces there.
You gotta have the same, right? So… so YAML actually doesn't care if you use two spaces or four spaces, as long… or any number of spaces.
As long as it's consistent. But if you do 1, 2, and 1, 3, game over.
So if you decide to use two spaces for your indent, you gotta use it everywhere. If you decide to use 7 spaces for your indent, fine, but you gotta use it everywhere.
The most common one I see is two spaces. That's the most common.
Um, okay. So, what teacher is, is a dictionary. That's what… that's the term we're going to use for YAML.
Quick question. Uh, is there any editor that….
Uh, that's the… I… yes?
Out there that might assist that with putting some kind of screwy.
Symbol in the spaces, like a squiggle or something like that?
Certainly. So, yeah, so, like, here's VS Code.
And this has a YAML lint. Installed, and so if I, like, mess this up.
It'll put squiggles in it, right? Um….
And then if I fix it, the squiggles will go away.
Hmm. Thank you.
So, it helps you a little bit. Um, and then, yeah, you can show, it's like, render….
Render white space or something? Uh, it doesn't quite work.
I must have it set, um, but I… oh, there we go, there it is.
So now, you might be able to see it, there's these faint gray dots.
That show that there's spaces. The how many spaces there are, right here.
I don't know if you can see that, it's pretty faint, but….
Yeah, there's definitely VS Code can definitely help you with that. I'm sure VIM can do it, too, if you configure it.
Okay, so that's dictionary. Dictionary also called… so dictionary is…. A set of key-value pairs. That's what a dictionary is, which is also sometimes called an object in some languages.
Uh, sometimes it's called a hash map. It's, uh, all different names for the same concept.
A set of key and value pairs. So teacher is a dictionary.
Because it has…. Two key-value pairs.
If we look below that at topics, once again, we have topics, colon, and then no value! Oh my god! Oh, but wait, we don't need to panic.
Because we know if there's no value, we just look at the next line to see if it's indented.
And in this case, it is. But the… we don't see a key.
Okay, it's indented, but the next line does not contain a key. Instead, it contains a dash as the first.
Non-whitespace character on that line. And that means that that is a list item, okay? So, topics is a list of strings.
And the list has two items. One item is Linux, and the other item is Ansible.
Okay? And then down below, you see students, that is a list of dictionaries.
But that's good enough for now. Let's move on. So now you know what YAML is.
Um, I could show an example, but let's keep going. So now you know what YAML is. Now, what is a playbook?
Well, a playbook contains a list of plays. And a play targets one or more hosts.
And contains a list of tasks. And a task uses a module to perform an action. Let's break that down, because it probably sounded a bit confusing.
So, an Ansible playbook is a YAML file that contains a list of plays.
So here, I'm showing you a file named playbook.yml. And we can see that.
This file, uh, on line 2, there's a dash. The first character is a dash. That means it's a list item.
Line 2 is a play. The play is called Configure a New Document Route for HTTPD.
And then, I have this folded in my editor, that's why you see that little, uh, greater than symbol to the left.
So it's folded in my editor, so the next line is 43.
And you see that that is also a list item, so that's another play in this playbook, and the name is Test Web Connectivity.
Yep.
So are you actually defining those plays. There, or are they references to plays defined.
Elsewhere. Okay, thank you.
They are defined right here. You can't… there are ways to import plays from other files.
Fair enough. Thank you.
I'm not doing that here, though. Here is… okay, so next we have Ansible. So next, so we know a playbook is a list of plays, what's a play?
A play is a dictionary. In a playbook file. It specifies the hosts and other properties that are going to run, you know, when the playbook runs.
And it contains a list of tasks. So here, starting on line 2, we see this is a list item, right, because this is in a playbook, this play is in a playbook.
And it has name, host. So this is what hosts the playbook's gonna run against.
It has become, okay, and what become true means is that when this play runs, it's going to become the root user. So this play.
Is going to run as the super user, as root, okay?
So these are the, uh, properties of the play, name, host, task, or become.
And then we have a tasks…. List, starting on line 5.
And we can see that, like, on line 6, and once again, I have these folded in my editor, in this view you're seeing here.
So line 6 is a task called EnsureHTTPD is installed. Uh, and then line 10 is another task that says ensure the web directory exists, and blah blah blah. So, a play is a dictionary that contains a list of tasks.
And then if we look at a task. A task is a dictionary within a plague.
So here, on line 6. We're looking at a task that's in a play, that's in a playbook.
And the task says ensure HTTPD is installed, and it's using the Ansible.builtin.dnf module, right? So a task.
Uses a module to perform an action. So, in this case, we're using the DNF module. For those of you that don't know, DNF is the name of the package manager.
On, like, REL-based systems, like Fedora, Red Hat, CentOS. Oracle, Linux, all that.
Um, so we're using the DNF Package Manager. We want to make sure that the HTTPD package is present.
That's what this is doing. And the… and this is a task that is using a module to install the HTTPD package.
And then a module is a dictionary inside of a task.
That performs an action. So here, we have another example. Ansible.builtin.service. That's the name of the module.
And we can see this module is making sure the HTTPD service is started and enabled.
And for those of you that are not familiar with SystemD, uh, when you enable a module, that just means it's gonna start on boot.
So every time the server boots up, an enabled service will start on boot.
Now, that's it. That's literally it. Well, there's a lot more to it, but that's all we're gonna go into now.
So let's walk through this play, what even, uh…. Okay, this is the right thing.
Okay, so this is the playbook. Is that big enough for everybody?
Yes.
Yeah, looks good.
This is the playbook that you saw me run earlier. And what you were seeing was I had it folded, like this. I had it folded in my editor like this.
And so now we see this playbook.yaml has two plays. And if I expand this play.
You can see that the play. Contains a properties.
Right? But then it also contains a list of tasks. And each… and then these are all the tasks.
And then each task…. Has a module.
Each module will have properties. Well, it could, doesn't have to. Could have properties.
And these properties will, you know, perform… this module will perform an action.
I have a question. What's mine 1?
Yes. So, okay, I didn't… I skipped this. This is an optional document start marker, okay? I don't know if that's what it's officially called, but….
In YAML. And when you put three dashes on the first line, that means it's starting a document.
And then if you look at the end. At the bottom, you can do dot dot dot.
Thank you.
To do the end of a document. And this is not super… it doesn't really matter, they're optional, but the reason why is you're supposed to be able to put.
Like, if you have one file, and you put a set….
That doesn't like that, but you're supposed to be able to put….
No? So what I was told is that the dashes are for if you want to put two separate YAML documents in one file, for some reason. I don't know why you would do that.
But if you wanted to, the dashes are supposed to be the way that you do that. It's giving me a squiggle here, so it doesn't like it.
But that's what I was told at one point in time.
But it's optional. Line 1 is optional.
I could see that if you were…. Treating the playbook instead of a standalone item.
As a snippet of text. That you're aggregating for multiple other.
Sources. Um, think, like, include files or something.
So you could build little libraries and then combine them together as necessary.
Yeah.
Yeah, I just removed it, and it doesn't seem to be yelling at me, so I don't know.
Maybe it's not important at all, maybe you're supposed to always have it, I can't get… I don't know.
Anyway, any questions about the playbook, though? Playbook contains plays, contains tasks.
Uses modules to perform an action.
I have an earlier question. You said in the preferred….
Yep.
Instead of IP numbers, it preferred. Domain names, the fully….
And it… and it…. Is there a particular reason? Because I've usually heard a lot of things that they prefer, uh.
Other way around, because you'd be…. Depended on, uh, a DNS server or something like that.
Yeah, exactly. Um, so…. The reason why… so the Ansible docs….
Are what, say, that you should prefer domain names over IP addresses, okay?
Right? Yeah.
And if you think about this example here, okay. Can you imagine if there was not a single name anywhere in this output, and everything was just an IP address?
It wouldn't be so bad, because we have very granular group.
Names, but it wouldn't be nearly as pleasant if all of these were IPs.
So, I think that's why the Ansible docs recommend you use names instead of IPs for when.
You have an inventory like this. And really, this inventory is just 6 hosts.
Right? But you can imagine if you had 50, you know?
Right, makes sense, makes sense.
Uh, quick, quick question, Sean. Will Ansible use SSH config if you….
Didn't have access to a DNS server?
Sorry, I didn't get that. What'd you say?
I would ask it as, does Ansible use. The OpenSSH client.
Directly and inherit all the capabilities it has, or does it use a.
An internal Python. Ssh client that doesn't have the same feature set.
That OpenSSH Client does.
I want to say it uses SSH on the client. Um, and the reason why I want to say that is because Ansible only works on Linux.
So if you try to install… like, you're… so your control node has to be Linux?
It can't be Windows. And I'm sure there's multiple reasons why that is. I'm a little bit confused by that, though, because it's just Python, and, like.
Python runs everywhere, but I wonder if the reason why that is is because they actually use SSH on the client.
I guess I could test it by uninstalling SSH and seeing if it'll work, but I don't want to do that right now.
Or just put your three host names in your SSA's config and see if it works.
Okay.
Yeah, Lee, I've run into the same type of problem where.
Particularly where I have to go through bastion hosts. Ssh config supports it beautifully.
Yeah.
But, uh, I've run into the Python SSH client having. No concept of that.
We should.
Alright, so what I've done here, and I, um…. Well, I'm done here, yes.
Sean? Um, if you're gonna write your own module, do you have to first be.
A really good Python programmer?
Or did I not understand the relationship between a module and a Python script?
Man, something's going wrong with my Zoom. You cut out, um… you cut out….
Oh, I'm sorry. Can you hear me?
We can hear you, Ed.
I hear it now, I know.
Can Sean hear me?
I hear you, yeah, sorry. You said… I heard you say if you wanted to develop a module, and then it blanked out.
Oh, okay, sorry. Um, yeah, if you want to write your own module, let's say, for example.
You know, on the app server. The app, the app….
Playbook, right? Um, if you wanted to…. Install, I don't know, Ruby and Rails.
Evident forbid, but let's say you wanted to do that, right? And there wasn't an existing.
Module for that? So there is, but…. Um, could you write your own? And if you did, do you have to be a Python programmer to do it?
Yes, I think so. Yeah, all the modules that I've ever seen are written in Python.
So you'd have to… I think you would have to program it in Python.
I'm not 100% on that, but that's my hunch, is that you would program it in Python.
But wait a minute, let me ask you this, then, uh….
And….
Is it, uh… because you said there's, like, really good, extensive documentation.
Well, if you…. Um, we're going to create a new module.
Is they're like, oh, here's, like, one to get you started, right? And all you have to do is kind of, like.
I had to more or less fill in the blanks.
Good examples? Is that the question?
Yeah, like, a good example, or… yeah, yeah. Like, the hello world, here's the hello world module.
And you start with a little world, and kind of go from there.
You know, I'm, um, written a module. But I just googled it, and yeah, the docks seem fairly decent, I don't….
Because at the end of the day, you're just running a… you're just writing a Python script, right? That, uh….
It's gonna execute on the remote host. And I would say, even if there's not a… there's so many modules built in, too, and, you know, Ansible is open source, so I would imagine you could find one that's doing.
Something adjacent to what you want to do, and uh… just, you know, start… use that as a base.
But I'm gonna be honest here, I've never written a module.
Okay, I'm just curious.
But I'll put the… I'll put the stocks in the chat, just in case you don't check it out.
Okay, so what I've done… Yep, yep, I put it right in the chat.
I would appreciate that.
Um, but before you write the module, though, make sure it doesn't already exist, because there's a ton of modules.
Oh, sorry, John, that you mentioned.
Uh, unless you want to… unless you just want to write one, then go ahead.
So what I've done here is I've done a… this is my SSH config on my Fedora machine. I did a host.
Config called madeup server, which is just, uh, pointed at server A.
And it's gonna use the student user, so let's go ahead and see….
So now, I will change my…. Inventory to say, made up… ah, crap, I forgot what I called it.
Made-up server.
Thank you. I was gonna remember as host or server. Okay, so now I want to… uh, you know, I have this, uh, everybody alias that.
I have this, um…. Made of server.
Okay, so this is another playbook, and all this does is just ping. Ping the host.
So this is a good one just for testing connectivity. It uses the ansible.builtin.ping module.
And you can see there's no properties on this module, it's just each clip… anyway.
Let me do Anschool…. Playbook, ping.yaml.
It worked! It worked. They used my… it used my SSH config.
So yeah, it must use the system's SSH.
Good to know.
Really?
Thank you for doing that, Sean.
Let's see, there's something else I wanted to… what was it?
Oh, I remember now. Yeah, yeah, yeah. So, the other thing I wanted to try was, if we open up this playbook.
So what I'm going to do now is I'm going to….
Uh, replace all instances of Server A with Server B. In this document.
And then, I'm gonna add in the host section, I'm gonna add Server A, comma.
So basically, what we have now is we… I have now the host server A.
And server B, uh, in this playbook. So now, if I run it again….
What we're gonna see…. Is that it's going to run against both of them.
So…. Nope, it's not. It's not doing that. Hold on a second, what did I do wrong?
Posts Server A, server will be….
Need a space in there?
What am I doing? This is interesting.
Maybe a space after the comma?
I don't think so. Could it be my… whatever I did to the inventory? I don't think so.
Michael? Played football, I had.
Told myself two days if I wanted to.
Mute yourself, Gary.
Well….
There we go. Why does the order matter? Was it a typo?
Sorry, I don't know why that was happening. I… maybe we can look into it later. But, uh, what we… what the result is….
Is that what we're seeing here is that, like. For all the server A, so this ran against both servers. Okay, server A and server B.
For server A, everything was okay. Because what… because Ansible, um, tries, and you have to do work to make it this way, but Ansible tries to be idempotent, okay? And the idea behind that.
Is you can run. A playbook against the server one time or 1,000 times.
And the end result will be the exact same every time.
And the way Ansible does that is those Python modules that we've been talking about, they're going to basically do a bunch of if statements, right? Like.
Like, for this task up here, that ensures HTTPD is installed.
It's gonna first check if. Httpd is not installed.
Then install it. Otherwise, do nothing, right? And so, that's essentially what's happening here.
So, all these for server A are saying, okay, okay, okay.
And all the ones for server B are saying change, change, changed, except for….
The top ones, because I, you know, I…. Ran it on accident, um, with just Server B before.
So… so, um, that was my mistake. So…. Um, so yeah, idempotency is a big thing with, uh, with Ansible, and it's almost….
For free, but not quite. Like, you do… there is work that's required on your end as the playbook writer.
To make sure your playbook is idempotent. And the benefit of that is you can prevent.
You can somewhat prevent configuration drift by doing that, right? So a lot of places will run their playbooks, like, every.
You know, every… anywhere from 15 minutes to 12 hours to, you know, 1 month, something.
But you just run your playbook over and over and over again against your host.
To make sure there's no configuration drift, right? And everything is just configured.
How you declared it in your playbook. Now, this can start a war within your IT department as well if you have, you know, Jim, who's like, I hate Ansible, I'll never learn configuration management.
And he's still SSH-ing into all your servers and changing things manually, and then the playbook's gonna run.
And it's gonna undo all of his changes, right? So if you have two administrators.
One is doing manual, and one is doing automated, you're going to start a war there. And so you gotta be a little bit careful.
So basically, you gotta buy all the way in if you want to use Ansible.
Who actually…. Would it actually… if you have one person doing things manually and another person using Ansible.
If your playbook was to install HTTPD. Create the directory, set the permissions.
If those were done manually without Ansible. Wouldn't Ansible's checks to make sure those things were done be satisfied?
Yes. Yes, but what I'm saying is, like, okay, so what if….
You know, what if, when you originally set the server up, it was slash web, and the Ansible playbook still says web.
But then, you know, Administrator Jim comes and changes everything to slash site, or something.
Well, the next time the playbook runs, it's gonna set it all back to web, you know, and then Jim's gonna have to log back in and set it all back to site.
You know what I mean? So it's just like…. You can start a war that way.
Okay. Yep.
Everybody has to be doing the same thing.
Or at least you need to have things separated, right? Like, okay, we use Ansible for this, and we use Manual for this, and we never cross-stream somehow, but that… I think that would just get too….
Confusing, or complicated.
Agreed.
Okay. I think that'll about do it for Ansible 101, unless there's any more questions, and then in the second half, we're going to flip this, right?
What if I want to use Ansible on my home lab, but my laptops and desktops are always asleep?
Well, all of a sudden, this control node and push-based configuration doesn't work anymore.
Because you can't push a configuration to a host that's asleep, right? Or powered off, or….
In a hotel somewhere. Right. So, we're gonna talk about how can we flip this around and use it in the home lab environment, and that's the second half of the talk.
Intermission, GUI middle.
Okay, wait a minute, before you start, I got a question.
Um…. So, one thing you didn't mention….
Was, uh, uh…. Errors and error rippling.
Right? You know, kind of cascading errors. So, for example, let's say, for example, you… because I've seen this happen.
Right? Um…. You've got a bunch of, uh, you know, servers, EC2 instances in the cloud, and.
And, uh, and all of a sudden. Soap starts happening in, uh, U.S. East, right?
And then… at a certain point, US East goes offline. Right. No, I don't think that's probably going to happen these days, but it could happen, right? And….
You start seeing, like, one or two servers. Um, you can't SSH into them.
Or, um, some other problem happens. Then all of a sudden, you get, like, oh, now the entire.
The entire East Coast has been, you know, Amazon's like, ah, crap.
So, what would happen to Ansible whenever you get an error? Like, does it… instead of saying OK.
Is it the error?
Yeah, I think it's configurable, but without… if you don't configure anything, what it'll do is….
Let's say I'm running a playbook on 3 hosts. And halfway through the run, host number 2, like, dies.
So, the first time that it encounters an error on host number 2, it's gonna report an error.
And then it's gonna take it out of the rest of the playbook run.
But server 1 and 3 will continue, right? So, if you have a situation where a whole site goes down, then yeah, it's just not going to be able to SSH into them, and it's gonna just….
Bomb out for all three.
Okay, right, okay. So you're saying, like, you could have….
Uh…. Because I was assuming, like, database and web and app.
We're separate servers, but they could all be in the same server, actually.
Oh, shit.
Okay.
Yeah, yeah, I typically think of them as separate, too, but yeah, I guess you could, you know.
Collapse it all into one server if you had to.
Okay. Do you get any kind of… do you get any kind of, like, notification about that? Like, does it….
Or it could be separate.
Uh, go over to, uh…. The, uh, like, I don't know, some kind of logging thing or something, or….
You know, where it sends your, you know, to your pager.
That's how it used to do it to me.
Yeah, so I don't… see, this is where we're getting kind of out of my depth here, but I know… so, if you're in, like, some huge organization, you have hundreds and hundreds of servers that you're managing with Ansible.
You're probably going to want to have, like, a Red Hat, Ansible subscription.
And you're probably… they have this tool called AWX, which is like a web-based GUI.
And I think when you get to, like, certain sizes of, like, hundreds or.
Thousands of machines, you're probably going to want something like that, and I have, like, no experience with that at all.
But if you're just running it like I'm running it on the command line, then yeah, you get a lot of output, and you can get… you can get a lot of output. If you just keep….
Passing dash Vs in, like, you can do up to four Vs.
On the command line, and you can get so much output that you can't even read it all between now and Christmas, you know?
So, it just depends on what level of output you want.
And then, yeah, if you want to pipe that to a log, or if you want to do something like that, but I think if you use, like, those more sophisticated AWX and stuff.
Those Ansible automation platform stuff from Red Hat. I'm pretty sure that has tie-ins for, like, pagers and on-call rotations and all that stuff, too, so….
So, you know, something like that is probably more enterprise-grade that you're looking for there.
Okay, thank you.
Too good, Gary. Okay, uh, unless there's something else immediate that Sean needs to talk about the tutorial?
Uh, we're now in the gooey middle of the meeting. Uh, as I mentioned earlier.
Uh, this separates the beginning tutorial session from our main talk.
Uh, we'll do some quick announcements, and uh…. Uh, a little quick Q&A.
And, uh, then we'll go on to the main event. Um, so, uh, I'm Gary Meyer, I'm our MC for this evening, I'm also the president of SLUG.
Uh, Stan Reichert, that name… or voice you've heard, uh, off and on here during the thing is.
Another, uh, of our officers, he's our vice president, and the man who.
Definitely is doing the vast majority of the production work here.
Lee Lamert, uh, is our treasurer, and uh…. We're looking for a secretary, uh, so anybody who cared to be an officer.
Please, uh…. So, um….
Uh, tonight we have the unusual situation. Our tutorial session is the same speaker as our main, so Shawn Tweehaus will be back with us.
In just a few minutes. And, uh, let's see, we've got a number of things that people may be interested in. Uh, archives, all of our, well.
We try and record our previous presentations. And make those, uh, video recordings.
Available on our archives. It's on our main page. My webpage, you can look it up by date or topic.
And, uh, find it there. We also maintain a calendar. Uh, uh, salute.org slash calendar.
Uh, it's divided up into local events, remote events, or out-of-town events.
And, uh, uh, what's the third thing? Oh, uh, Slug-sponsored events.
Uh, so you can kind of narrow down what's… what you're seeing on the calendar.
Uh, if anybody knows of anything that would be…. Of interest, uh, anywhere to our membership, please let us know, we'll add it to the calendar.
Okay. Um…. Let's see… call for help, uh….
Oh, no announcements. Okay, uh…. The next SLUG General Meeting will be the second Wednesday of August, that's August the 13th.
Uh, every month, 8 days after our general meeting, we have our St. Louis Linux.
Meeting, uh, St. Louis Linux user group, load meeting. Um, so that's usually the week after the main meeting, but sometimes, you know, whatever needed to get that 8-day count in there.
Usually likes to the third Thursday. And we just lost the announcements. Okay.
Sometimes it's 12 days.
Right. So…. Uh, you just have to look for it on the calendar, so….
Uh, let's see, 5 days after the fourth Tuesday is the new Linux meeting.
Uh, that's a group primarily oriented at new. People to Linux, uh, but I don't want to scare off the, uh, the old gray hairs.
Uh, because it's amazing, the interesting stuff, uh, you…. You'll find somebody talking about, you know.
A new user's question, and uh…. You'll go, hey, wait a second, I didn't know it worked that way.
So, uh, there is no formal presentation at that meeting. It's not a set topic, it's just whatever the.
The person who considers himself newest to Linux, uh, gets to ask the question and, uh, kind of drive the meeting that way.
So, uh, Slack is the St. Louis Area Computer Club. We'll even talk about Microsoft there if we have to.
Uh, speaking of Microsoft. Uh, this October, October the 14th specifically.
Microsoft Windows 10 is going to go away. Support for our will. It's end of life.
So, uh, we mentioned that here because. You'll all find that more and more of your friends and neighbors and colleagues start saying.
Oh, wow, my Windows machine is dying, or has died. Can I start using Linux?
So, uh, sure they can. Just be prepared to…. Tell them to come to our meetings, or how you might be able to help them, but uh….
I expect to see a lot of people. Moving off Microsoft with this, uh, event coming up in October.
The nice thing about this book is it… half of it….
Tells you how to go to Linux, the other tab tells you how to stay.
Or move on to Windows 11 and find… or find a machine that will one one.
Run Windows 11, etc. So….
So, yep, uh, details are there in those books, uh, PDFs, and we've done a presentation on it before.
Probably might again. So…. Okay, uh….
See, moving on, privacy and security. Uh, yes, we are recording tonight's, uh, meeting.
Uh, so don't say anything nasty that you don't want recorded.
Um, although it's our intention to put these up in the archive.
Obviously, most of you are aware, when you're in any Zoom meeting or jitsu meeting.
Anybody on that meeting could be running a recorder, so although we intend to post ours, anybody could be recording stuff.
And, uh, so…. At your own risk, say what you want.
Let's see….
Oh, this comment there at the end of the slide about simple screen recorder.
Uh, we've done presentations of that before, um, so…. These slides are available on our main homepage, so if you want to pick up any of that information, go back there and pick it up.
So, uh, Presentation Archives, as I said, it's available on the homepage at SLUG.
And, uh, we try and keep our stuff out there. Calendar, already mentioned that.
And, uh, mailing lists! Um, so, uh….
Those mailing lists shown there, uh, you can join any of those.
The announce, uh, it's a very limited amount of traffic. It's usually just stuff.
It was like saying that, yeah, this week. This general meeting is being held. Here's the topic.
The discussed mailing list is, uh, not moderated, so…. Anybody who's subscribed to it can put a posting out there, a question of an opinion.
Uh, sometimes it's amazing. You'll get two dozen replies in one day.
Other days, you put something out there, and it may not get answered for a couple of days, so it just kind of depends on how interesting it is.
Steering committee, um, there is a steering committee that tries to organize this group.
Uh, so, going to the steering committees and…. Going on this mailing list is like watching sausage being made, uh, but dang, it tastes good. We appreciate everybody who does.
Contribute and, uh, joins the steering committee. Sysadmin. It's a little bit more restricted of a membership to that group. We do, uh, maintain a couple of our own systems.
Uh, to maintain our mailing list, to maintain our databases. Um, so….
To run those, we've got our own set of people who volunteered to be the sysadmins on those.
And this is the mailing list for the people who are doing that work, so it's….
It's more of the nuts and bolts of how you actually do it on a particular machine. It's good practice, if you like.
You're welcome to join. Okay, next thing, uh, sponsored meetings.
I already mentioned the new Linux and the Slack. And, uh.
Log meeting there, St. Louis Linux, we try and keep more specifically on a Linux topic.
Call for help. As I said, uh…. We, uh, we will have time after the main presentation.
Uh, to go back to just an open Q&A, but for those of you who, uh.
Uh, afraid you may not be around that late into the evening, um….
Now's chance where, yeah, if you want to ask a. Question, see if somebody has an idea for you, some help for you, or just tell us something interesting you've been doing.
We'll do a little bit of it right now, a little quick Q&A. So, anybody got anything they'd like to ask right now?
You gotta keep rolling, Gary. There we go. Main presentations.
Okay, uh…. We obviously got Unix in our name, so DSD, Linux, macOS.
Any of the real Unixes, uh…. Um, that's kind of what….
What we usually try and focus on, but really, we've kind of broadened out to anything that is.
Either affecting the industry, the IT industry. Kind of of an open standards nature, where it's not necessarily proprietary to a particular company, but uh….
Something that's an open standard, so…. Um, we ask our presenters to put together notes, PDFs, uh, slides.
And we try and keep those on file for people to go back and look at.
Um, and uh…. We already mentioned that Sean tonight, our presenter, has said, sure, ask your questions in the middle.
Of what he's talking about. Don't hold him off till the end.
So… and I think probably would go to the next slide.
Okay, questions? Anybody got any questions?
So, Lee, I think in the chat window, I see one from Naveen about patching. Would people use it for patching?
Good catch.
I thought that was answered.
I have a question. Does Ansible support for the container platform?
Ansible support further. Container….
The container… containerization.
Uh, like, I don't know, it depends on what you… so the answer is sort of, but, like, it depends on what you're trying to do, I think.
Like, what are you trying to do with containers?
Um, my two cents on that would be Ansible is wanting to.
Ssh, or when remotely log into and control a system. So if you can log into inside of a container and do something.
You could probably use Ansible. Um, however, doing that might be against.
The idea that containers are created. Um, from recipes and….
Fully standalone, uh. But if you had SSH running in it.
You probably could.
I could see that not working too well, because. You could use Ansible to change a container.
But the next time you rebuild it, it goes back to whatever the config was before, besides.
Right.
The container itself is immutable. Any chance?
It depends on the container.
Well, okay, depends on the container. Anywhere, there would be problems with, uh.
Change is going away if you… if you rebuilt the container type of thing.
This is Stan. I'm trying to unshare my…. Screen, but Zoom won't let me find the button.
So, uh, when…. Sean is ready, he should just start sharing.
And that should kick my out… me out of this.
I want to make a quick comment of…. Uh… uh….
On the list of attendees tonight, the participants. Uh, some of you have put your full name, some of you are only putting down your initials.
Uh, I should point out that there are no dues to join the organization. If you attend.
Two of any of our meetings in the calendar year. Uh, you're considered a voting member, so you have the right to vote. So, uh, of course, the problem with that is, is.
If we don't know who you are by last name, it's hard to say that you were at the meeting, so….
You may want to, uh, uh…. On your participant name.
Make it something that is not something to be mistaken for somebody else, uh.
Sometimes two initials can easily be duplicated, or. Just a first name sometimes is too simple, so….
But, uh, you can do whatever you like there. Okay, any other questions that we want to do here in the middle, or should we go on to the main topic?
Main topic. Okay, Sean, uh, I'll mention very briefly, I didn't really introduce Sean, but….
Jean Twee House has been a member of our group for a number of years. I think Sean first got introduced to Linux in 2014.
In 2015, he started up working as a sysadmin and has been banging and keeping computers managed ever since.
Uh, and I think, probably, I think going back to 2015, if I remember you saying, Sean, I think that's when you started using Ansible.
So, uh, he had some experience with this. So with that, I'm going to turn it back over to Sean.
Uh-oh, Sean, black screen.
Yeah, I left and rejoined once. Let me try one more time, sorry.
Okay. Okay, now we can talk about Sean, since he's gone.
Um, Lee, can you monitor for a few minutes? I need to step away.
Yeah. Let's talk about June.
Sure.
Gary, do you know what we're going to have at the St. Louis Linux Users Group meeting next week?
Nope, we don't, not yet. If anyone. Has a, uh….
Something that they think they can have ready to present by next Thursday, i.e. 8 days from now.
Uh, by all means, speak up and, uh, let me know, or say you want to….
Get together with me here after the meeting. Uh, we can arrange something. If you have any suggestions, I'm open to suggestions.
I do have a couple of, uh, possibles that may, uh.
May be coming through, so, uh, but until we get a commitment, uh.
Yeah, let's talk. So….
And we have a whole…. List of suggestions.
Uh, if you go to www.slug.org. Slash planning.pdf, it'll show….
Stuff we've done in the past, and then further down, it's got a whole list of suggestions. The thing we don't have.
Is volunteers to do those. Suggested items.
So, we're not…. Adverse to people volunteering to do some of those things.
You know, especially a base session, where. Practically everybody here could do.
A base session into. Covers something that's very rudimentary.
And… the nice thing about it is. You may have approached some issue or something in a….
In a certain way, and a lot of times, you'll get a lot of….
Good suggestions and alternatives. From the gray hairs.
I've said enough.
Oh, man, my Zoom is really bugged out right now. Can y'all see and hear me? See the screen and hear me?
Yeah, Sean. Got your screen.
We see… we see you, and…. That's your screen.
All right. I'm gonna roll with it, um, very strange on my end. Okay.
Uh, I don't know if you noticed this, but I'm doing this presentation fully from within the terminal. I don't think I'll have to leave the terminal at all, I don't think. Well, I might, I don't know.
I'm not some kind of zealot, but there's this software called PresentTerm, where you can take a Markdown document and mark it up in such a way that it can be slides, like this.
And if you're using cool software like Kitty, like a modern terminal, you can have images like this.
So, uh, okay. So, automated workstation configuration with Ansible pull. So let's flip Ansible on its head and use it in our home lab.
So, this is the traditional Ansible approach, which is what we just spent over an hour talking about, and it's great.
We're always on servers. This is where you have a control node.
And then that control node will SSH into the different, you know, hosts and push configuration to them.
But, that's not gonna work in a home lab, or not gonna work for workstations, specifically.
Because your laptops are always asleep, or powered off, or in a hotel, or something.
And not reachable by SSH from your control node. So if I were to.
Have a control node, and if I were to put a cron job on that control node, that would push… try to push configuration to all of my hosts at, like, 3AM.
That would always fail, because when I'm sleeping, all of my workstations are sleeping as well, right?
And so, this push-based configuration is not gonna cut it. So, we need to switch the paradigm. We need to flip things around, we need to stop doing all this pushing and start doing some pulling.
And this configuration, you can see that we have no control node. Instead.
Each workstation is actually going to have Ansible installed. Specifically, it's going to have Ansible Pull installed.
And Ansible pull is going to be ran from the workstation when they're obviously awake and, you know.
Online and everything. And what Ansible Pool does is it reaches out to GitHub, in my case, but it can reach out to any Git Forge or anything like that, any URL.
It's gonna pull the latest version of the playbook and run it against itself. So it's gonna run it against the local host.
And so how does that work? Well, if we're just, like, bootstrapping a new workstation, for example, these are the steps that I perform.
So, first, I need to install, um, you know, I'm gonna use DNF to install the prerequisites. So, in this case, it's Python 3 pip.
Get, and WGit. Once I have those installed, then I'll use Python 3 pip.
To install Ansible, and if you notice, I'm doing that with sudo, which is not recommended usually… which is usually not recommended.
But I'm using sudo to install Ansible, so that way it'll be installed globally instead of just one user, instead of just for one user.
And you don't have to do that, I guess. There are ways you can make it work with installing Ansible for just your one user.
But in this case, I'm doing it with sudo, because I'm gonna….
Uh, we'll talk about it later. I don't want to get too involved right now.
And then, once I have Ansible installed, one of the binaries that that pulls down is anspil-pull.
So, in step 2, we can see that I'm running Ansible-pull.
And it takes several arguments. So the first one is dash dash limit localhost.
Um…. This one basically says, I don't care what hosts are listed in this playbook.
I'm only gonna run against localhost. Right? Because I don't want to get in a situation.
Where somehow, I get another hostname in that playbook, and then all of a sudden, I have this.
Running against some other host over there or something. I don't want… I never want that to happen. So, when we say limit local host, we're making sure that the playbook will only ever run.
Against this host, the local host itself. Then we have dash dash directory.
And this is specifying the directory that you want…. The remote playbook to be downloaded to. So in my case, I'm doing slash opt slash home lab dash automation.
Then we have dash dash URL, and here I'm giving it my GitHub URL, but you can… I'm pretty sure you can use any….
Um, URL to any Git repo, so if you like to use GitLab, I'm pretty sure that'll work. If you have your own custom thing, I think that'll work just fine.
The docs even mention… and sorry, I can't see chat. My, uh, my Zoom is too messed up right now.
So I apologize for that. But, um, the docs even mentioned that you can use, like, file-based URLs.
So if you have your playbook, like, on a shared drive or something, the docks have, like, a one-sentence thing that makes me think that might even work.
Um, but anyway, you just need to specify where is the….
Playbook, the remote playbook that we're pulling down. And then this down here.
Is the playbook that I want to run, okay? Um, and you'll see that I'm running a hostnameShort.yml.
And so, at this point, I think we need to go….
To my Git repo. Yeah.
Christian, before you leave that page. Um, where you, say, limit localhost.
Does localhost have to be defined in the playbook. Or is that translated and matches whatever the server's name is.
Only on localhost. Fair enough.
Great question, no clue. Actually, you know, I never even tested this.
I just kind of assumed, based on the docs, that it works.
We see how you are. You're doing a presentation on completely untested code, aren't you?
But I've never tested this.
Yeah, I, yeah, I have no idea what I'm talking about, you know?
It's obvious, Sean.
I'm just repeating, uh, what the docs say with no, yeah, with no clue. Okay.
Alright, so this is… let's go to this…. To up here. Okay, so this is the repo. This is the repo that we were just looking at in the slides.
And if you look…. Let me refresh the page.
One second, okay. If you look down here, um, you'll see that there's, like, Desktop16.yml.
And this is the… that's my host name, so Desktop 16 is my hostname. I don't know what….
For some reason, I do…. Desktop. I do like the model number, and then I do the year that I got it, or the year that it was made, created, or something. So this is a custom desktop, so I just called it desktop.
And it was built in 2016. I have another desktop that was built in 2022, and I have an X1 Carbon from 2018. So all my stuff is pretty….
Most of my stuff's pretty old. So, um, but anyway, so what this enables is I can do that hostname short.yaml, and it's gonna match to whichever….
Playbook I have here, and all of these playbooks, for the most part, have slightly different things, right? Like, this desktop 22.
This is my gaming machine, and so this playbook right here is going to have a bunch of stuff just for gaming.
Desktop 16 is, like, my… more like my workstation here, so this one's not gonna have any gaming stuff.
And this one's my laptop, so it's gonna… it might… yeah, I don't think it does right now, but I could… I could see a future where this has….
Laptop-specific packages on it, so you can make different playbooks for your different configurations like that.
Or you can make them all the same, you know, very flexible.
And if we go ahead and drill in here….
We can just look at one of these. So this is my….
Playbook, and if we remember from last time, a playbook. Is a list of plays, so here's the first play.
Configure desktop 16 as a workstation. It's probably the only play in this playbook.
But, whatever, still a list. It runs against local hosts.
Uh, I think this is optional to specify a local connection rather than an SSH connection.
And it runs as root. And then here, I have some variables.
Vars, and so my variable is… I'm specifying the primary user with the name Sean, the UID, and the group ID, okay?
This is useful because I typically run. Oh, Zoom fixed itself. I can see the chat.
I typically run these playbooks. Um, with a scheduled task, which we'll talk about later, that runs as root.
And so, the playbook is running as root. So I need a way to say, hey, yeah, but some of these configuration files are….
User-specific, right? Because some of them go in, like, my home directory, right? And so I need a way to specify my user, so that way it puts.
The configuration files and the right users' home directory. And so that's configurable right here.
And, you know, I could have just hard-coded my name everywhere, because I don't think anybody else is actually going to use this, but….
If you actually did want to use my playbook for some reason.
You could just come here and put your name in this section.
And it would probably work. So, there's that. Now, down here on line 13 is something we did not talk about earlier, roles.
Okay? And what a role is, is it's a package. Of reusable Ansible code, okay? There are a lot of ways to package.
A chunk of Ansible. Code to make it reusable.
Roles is probably the most basic one, I would say. Or at least it's the most common, maybe?
Um, but if you can think… so, you know when you're writing a bash script.
And you have this one… these few lines of code that you just seem to, like.
You're running in a few different places in your bash script, and so instead of copying and pasting them all over, you make a function, right? In your bash script, you make a function, and then you just call that function in all the different places.
That's essentially what a role is. A role is just like, hey, um, rather than copying this Ansible code here and here and here and whatever.
I'm just gonna make it a roll, and then in that role, I can call… I can call that role from all the different places. So here.
Um, we can look… I have, like, for example, this is a role that I called Nerd fonts, okay? So what this role does.
Is it installs all these different nerd fonts, like Iosevka. This is the… this is my terminal font.
So if you thought my terminal font was really fancy and you really liked it, this is the one to get, M+.
I kind of like it. I also kind of like Iosevka.
The thing with all of these fonts is they are very, uh, narrow. I like very narrow fonts, because then you can fit more….
Characters, uh, wide before you have to, like, scroll or word wrap or anything like that. So I like very narrow fonts, and all these fonts are very narrow.
The point is, this is like some reusable. And configurable Ansible code.
That I can put in all my different playbooks. So we see it here in my Desktop 16 playbook.
If we go back to, like, my desktop 22 playbook. You see that it has the same thing, right?
Um, so I'm using the same… I'm reusing this role in multiple playbooks.
Okay? So let's go ahead and look at this role. I hope this is a….
Simple one to look at. I didn't really think ahead. Uh, nerd faults.
Okay, so what does this role have? Well, it has…. Tasks and defaults.
So, defaults is variables. Right? So you saw….
Um, when I was declaring the role, I was passing in a bunch of fonts.
So I was overriding…. Why did that happen?
Oh, man, okay. Sorry, I was overriding this font's…. Default when I declared the role, and I said, okay, I only want these certain fonts.
If I didn't do that. This is what would be in… these are the fonts that it would do instead, okay?
Um, so the defaults file is like, hey, if you don't override these variables.
This is what you're going to have by default, okay? I think that's….
Hopefully straightforward. And then, also, we have some tasks. So, we have a main.yaml.
And what this is gonna do is it's gonna make sure the font config.
Package is installed. And then it's gonna make sure that I have some other, uh, required packages for decompressing the fonts.
Xc and unzip. And then what I'm gonna do is I'm going to include.
This other task file called download, extractFonts.yaml. And what I'm gonna do is I'm gonna include that task on a loop.
Okay, so basically what this is doing is this is looping over that list of fonts that we just saw in the defaults. It's loop… er, in the vars, either one.
It's looping over there, and for each font, it's performing. The actions in this task file, okay? So let's go ahead and look at that one.
And we can see here that it's creating some directory to store the font.
And then it's downloading and extracting the font. Into that directory.
And… the way that I make this item potent…. Is with this line right here, okay? So basically, this task.
Once it's been done one time, it will create. This, whatever, README file, okay? And I know it will do that.
So what I say is, this task creates this file, so what the unarchive.
Module knows is it looks, and it says, okay, if I see this README file.
Then I know this task has already been done. And I can just skip it. I can do OK. You know, instead of changed, I'll do OK or Skiped. I can't remember what it does, but….
But it won't… it won't download this again, because some of these fonts are, like, a couple hundred megabytes, so it can take a few seconds to download.
And it just slows down your playbook. So it's really good to try to maintain as much item potency as you can by using things like this creates.
Okay, is there any question… I know I kind of went over some advanced Ansible stuff right now, I didn't really plan to do that, that was kinda….
Off the cuff, but the important thing is the roles, being, like, reusable.
Does anybody have any questions about that part?
Sorry, yeah, I know I kind of went deep there. I probably shouldn't do that.
My brain hurts.
But it's… but it's recorded, so I can go back and try and understand it.
Better. Thank you.
Okay. So, let's see, I think I'm… let's see how far off I am from the….
It's always good to expand.
What I planned here. Okay, and so we could stop there, right? This could be a good place to stop, you know? For example, like.
Okay, so I have a new workstation, right? Let's say I just installed Fedora on my laptop.
And then I ran, you know, step one and step two.
And step two has, you know, it's ran this playbook to, like, install my fonts and do all this other stuff that I like to do when I first.
Set up a new workstation. Well, great, I could be done, right there. You know, you could just call it good, you know?
But, you know, I'm not gonna do that. You know, because I'm constantly, like, adding new packages, I'm constantly, like, tweaking my….
Config files and stuff. And whenever I do that kind of package tweaking or adding on one system, I typically like it to be kind of….
I try to keep all my workstations at least somewhat the same.
Uh, you know, and so if I add a package on this system, I'm going to want to see that package when I go up to my other system, or get on my laptop later, or whatever.
And so, what I do is I create a scheduled job.
Where, you know, every so often, it's gonna pull the latest.
Playbook down from GitHub, and it's going to run it on its local host.
And so this is a good, you know, people that might want to do this are, like, persistent tinkerers like me, people with multiple workstations.
And all you do here is you create a recurring job. In my case, it's a SystemDimer.
The system detimer is going to call Ansible pull, Ansible pull is going to go out to GitHub.
Get whatever the latest version is. Clone it down, and run it against itself to ensure that it's up-to-date with whatever the latest.
Configuration…. I've declared.
Um, so, let's talk about that a little bit more, right? So, if you remember, from these bootstrapping steps.
Nowhere in here am I doing a system detimer, right? So how is the schedule job.
Getting set up. Well, it's kind of recursive. But I'm setting up….
The schedule job using a role that I called Ansible Pull.
So when I run…. This command, this very first Ansible pull, when I run this manually with my hands by typing it in.
Um, it's going to…. Uh, set up….
The scheduled job right here. So when it runs this Ansible pull role.
It's gonna set up the scheduled job. So let's take a look at this.
Um…. And I have a nice README, uh, for it.
So, if you get confused…. This all looks to still be accurate, for the most part.
Uh, okay. So basically.
Let's see, do we need to go into depth on this?
Or we could just skip… oh, okay, let's just go over the names.
So, the first thing that matters is we're going to…. Template, the Ansible pull SystemD service. And what does template mean? Well, you see here that I'm using the Ansible.builtin.template.
Module, and what this is doing is this is, like. Okay.
Let's say that I want to copy a file. From my playbook.
To…. The, um, SystemD system directory.
On my host, but I don't just want to copy it verbatim, I need to make some tweaks. I need to, like.
You know, each… each host that I copy that file to needs, like, one little thing different in the file, or whatever.
That's what template is good for. So let's go ahead and look at this template.
For the Ansible Poll Service, that's what I named it. And you can see here that it has a bunch of this kind of syntax here, where it's, like, double curly braces.
Opening and closing. This is using what's called Jinja 2 syntax.
And these are variables, okay? And so, what this is gonna do is when.
The template module is copying this service onto. Into the SystemD system.
Folder, it's going to replace all of these double curly brace variables.
With actual values, okay? So, if we look up here, the easy one is this documentation.
And the documentation is inside the repo. The… my repo here on GitLab and the READMEs.
And so, what this is, says Home Lab, Ansible repo URL.
And so I imagine, if we go here to VARs…. Nope. If we go here to defaults.
We have…. Ansible repo URL, right here.
So, that variable…. As the file is copied into that directory, that curly brace variable is going to get substituted.
With this actual value right here, okay? And so, if we look at….
Um, this… let me copy this, and…. Um, do a less on this, open, grab them.
Less on this… okay. So here we can see the variable was substituted right here as it was copied.
And the same thing with all these other variables, right? Like, I make the….
You'll notice, if we go back to that, you'll notice that, like.
This right here is a variable, because if you install Ansible with your package manager.
It's gonna put Ansible Pull in one location. If you install it with pip, that's going to put it in another location.
And I didn't really want my playbook to be dependent on how you install Ansible Poll.
So instead, I made that a variable. That you can just set to whatever you want.
And then that's gonna, you know, be templated out. In the service.
Right here.
I…. I get why your, uh, Ansible pull path is a variable.
Oh, uh, Sean? Oh, go ahead, Grant.
But your Ansible, uh…. Repo URL.
Why modify that? In your template file.
Versus in your. The file you're looking at now.
Because to me, you're making. The same simple change, and it's a question of.
Why you would do it in one file versus the other.
What am I missing?
So, I mean, you know, it's preference. You know, like, it's all… it's, you know, it's like….
How many… so, you know, this is…. Somewhat similar to programming, right?
Well, right.
So, I put… what I noticed was I was putting the repo URL.
In a bunch of places. And I'm like, I am repeating myself a bunch here, so I extracted that into a variable.
Okay.
With the thought that if I change the repo URL, which I've already done once.
I only have to make that change in one place, and it'll propagate through the variable to all the different spots.
Okay, thank you.
Was there another question?
Yeah, Sean, I had a question. The, the, uh…. When you first described, okay, here in the double curly braces.
He used the term Jinja, too?
Yep, Jinja 2, you'll see this file has this J2, uh, suffix here.
And Jinja 2 is a very popular templating language for the… in the… that's typically used with Python programs.
Um…. And it's just kind of… and Jinja, too, is what specifies that double curly brace.
Syntax, and it's basically, like, the template…. Parser, or whatever, that Python uses. So, um, yeah, it's just a template language.
And I'll put the docs in the chat in case you want to read more.
Okay. Great, thank you.
So it kind of functions as what we used to call a pre-processor.
To more macroprocessor to fill some things in. And… that….
What comes out of that is placed in the files on the system.
And you'll see that this exec start command here is basically the same as that command I ran manually.
The only difference is I'm kind of like…. Um, teeing the output to a log file.
And if you… if we look at my tasks, I think that's what we'll see next, so….
So here, I'm templating that service file that we just talked about, and then below that, I'm templating the actual systemD timer.
That will call that service file. So if we look here….
Um, so here is the system detimer, and once again, here's the repo URL, right? This is what I was talking about, like, repeating myself over and over again.
It's in a lot of places in this, uh, role. And then you'll see here under the timer section that this timer should kick off.
Um, every day at 3 AM, right? But I just told you.
None of my…. Workstations are online at 3 AM, they're all asleep.
So, they never actually kick off at 3 AM. I don't, you know, never.
But, I have this persistent equals true here, okay? And when you put this in.
When my systems wake up, right, whenever I wake them up.
Systemd is going to realize, oh, the last time I ran this job.
Was, like, yesterday. I was supposed to run at 3 AM, and I didn't.
I should run now. Um…. And so, as long as you have this persistent equals true, system detimers are smart enough to, like.
Figure out, ooh, I missed a run, let me run now.
And then I have this randomized delay seconds here, which means the job is going to start anywhere from 0.
To 600 seconds after, um, the timer is triggered. And I just did that… it probably doesn't matter, but I just did that because sometimes when I'm, like, I'm first logging in, I don't want my system to be, like, bogged down or slow, because it's, like, running the playbook.
So just give it, you know, give me 5 minutes to get settled into whatever task I'm doing, and then.
Kick off the background process, you know? It's not… I probably doesn't matter, but….
That's just something I put there. Uh, okay, so after we template the timer, then I have some other stuff about, like, the log directory, and here I'm setting up log rotation.
And I'm enabling and starting the timer. And… oh, and….
Mostly because, you know, I was doing this with AI, obviously, and the AI wrote this, um….
Uh, management script for me, so I'm like, eh, whatever, I'll throw it on there. It's actually been super useful.
Uh, and…. You know, this is not normally something I would ever do, because I'm, like….
I just don't care enough. But I was…. I was easily able to have the AI generate me a bash completion.
Uh, for the script as well. So not only do I have this nice little management script that I called H.
But I also have a bash completion for it. So, if we look here, this is another Jinja 2 template.
And, um…. It just has a bunch of, like, helper commands.
Here, let me just demonstrate it, it'd be easier. So, um, if I do H….
Um, dash help, right? Yeah. So… so… just using the H command, and this doesn't really matter, this is….
Yeah, that's probably not that interesting, but…. There's two subcommands, A for automation and D for documentation.
So if I do HA, and this has tab completion, like I said, so if I do A tab.
It tab completes to automation. If I do D tab, it tab completes the documentation.
Uh, I can do dash dash help here, and this gives you all of the subcommands for HA, or Home Lab Automation.
And we can see that I can edit the config by opening the editor.
And the playbook directory here. I can commit… oh, this one has been so useful. Man, just… just having, like, a little thing that's just like, hey.
Just commit. Like, whatever changes are right now in there, just commit them and push them up, I don't care about making a commit message.
That one's nice. This one allows me to run, like, git diff, or any arbitrary git commands, as if I was in that directory.
Anyway, I don't want to… this is the one I use when I'm testing it, so I can run HAT.
After I make a change to my playbook, I just run HAT.
And it runs it. Anyway. And H-A-L will show me the logs.
So, when did this run? This ran at 7am this morning, that must have been when I powered on my workstation, or pretty close to it this morning.
Oh, actually, that was a while ago. Down here. 5.30 AM, that's when I logged in this morning. What were you doing at 5.30am? Okay, I was down here, Linux thing.
Huh, okay. Um…. All right, HA… am we done here?
Hat runs it. Anyway, it's not important.
Not so important. But, uh, yeah, the main reason I did that is because the AI did it, and I'm like, oh, cool, I'll put it in there, sure.
Any questions about… so this is. How I basically, you know, I run it once by hand.
And during that by hand run, it sets up this timer, which now runs it every day from now on.
Any questions about that?
Okay, last thing, because I think we're probably…. Yeah, oh yeah, we're finally… okay. Last thing….
Um…. Dot files. So you can manage your .files with Ansible, obviously, you can… you can manage files in general with Ansible.
Um, probably… I don't recommend this. Uh, there are a ton of dedic- there are plenty of dedicated tools that are great at managing .files.
The one that I've used for years, and I've given past talks on it is YATAM, yet another .file Manager.
Really still like that one. It's still very well maintained. Even to this day, so definitely recommend that one. Another one that I've heard about is GNU Stowe.
Another one, if you're, like, a Knicks… if you're a Nix OS or a Nix person, a home manager is kind of fun.
But, you know, I just wanted to… I'm already using Ansible to, like.
Configure my workstation, so I just wanted to… I wanted to do my .files.
With Ansible also. So let me show you how I did it. It's a little bit of a hack, right? But not… maybe not that much of a hack.
So let me show you. So if I do an ls-l on, like, my BashRC, okay.
What we're going to see is my BashRC. Is a SIM link.
2…. This location here.
So, if you remember, what Ansible Pool does, okay. One of the, um, arguments for Ansible pull is the directory.
You want the playbook to be downloaded to. And in my case, I chose slash opt slash home lab automation.
I just chose that arbitrarily, okay? And so, that's here.
And what I've done is I've added my .files. To that repo.
And so when I do that. As I'm running this Ansible pull business, that means that I'm automatically.
Cloning my .files to each one of my workstations. And keeping them up-to-date and in sync with Git.
Okay? And then, all I have to do is just write a little Ansible task.
To SIM link them. From my playbook location.
To where they're supposed to go. Like, in my home directory.
Okay? And the benefit of doing a SIM link, as opposed to, like, a copy or something like that.
Is I can modify…. You notice how I keep doing .vim? I really need to….
Hold on, let's do that right now. Um, alias…. Them equals… and VIM, is that how you do it?
Uh, oh.
Yeah, now if I do VIM, okay, good, I did it. Okay. So, notice how I've been doing that all night. I've been typing VIM and then having to correct it to NVIM, so I just did that.
And now, um, you notice how I did that, and it took effect immediately.
Right? Um…. And that's why I do the sim link.
Right? Because if I did, like, a copy or something like that, then….
I would have to make this change in my playbook directory, and then run my playbook, and it would copy the file.
To the BashRC location, right? And then I would see my change to test if it worked or not, right?
Which is slow and annoying. So, by doing the sim link.
I can just edit the file as you always would, and then when I'm ready to….
Committed, I would just commit my…. My playbook, like, if I go to that….
If I ran HAC… oh. Hold on, let's not do that right now. Let's do H-A-G….
We can see that it was already committed, dang it. Alright, whatever, I'll just commit it.
Okay, so I just committed that change to my playbook, so if we go….
Back to here, and we go to my .files, and we look at my bashRC, and we go to the bottom….
There it is. So that changed. So now. When I go, uh, when I fire up my laptop.
Uh, it's gonna run that…. Uh, you know, schedule a job, and it's gonna now have this alias on my….
On my laptop. Next time I boot it up. Which I think's pretty cool.
Um, yeah. Okay. I think I'm gonna stop there, because it's been pretty long and pretty late.
Uh, what… here, I will, um…. I don't know who's… I don't know if anybody's actually going to use this, but maybe you can steal some ideas from it.
So, I'm going to, um…. Put the repo in the chat.
And also, we can talk about this if anybody cares. But, um, you know, I've been teaching these REL courses at the community college, or at least I did last semester, and I'm hoping to continue it.
So, I did write a playbook. Um, for how to basically do an automated setup of a RHEL, like, lab environment for students or anybody to use.
Um, it uses Kickstart. So, the first thing it does is it, um, let's look at this….
So, the first thing that's gonna…. Do here….
Is it's going to install all of the virtualization stuff, that's what this is doing.
And, um…. Yeah, it's gonna install the virtualization stuff, so this is gonna install, like, KVM, QEMU, all that stuff.
Um, and it's gonna put your user and the libvert users group.
Um, whatever user you specify in here. And then, uh, it's gonna configure, like, a network and KVM.
And then it's going to, um, create the network. And make sure it's active, and it's… see, this… this libvert collection, in my opinion.
Not that great, right? You notice how I had to do, like.
I had to do, like, define…. Create active and auto start, all as, like, separate tasks.
That's because this module, in my opinion. Could use some help. I'll just say it that way. I don't want to talk bad about open source developers.
Uh, then I stage some Kickstart files. Um….
And then, I…. Create the workstation, and I pass the Kickstart file in here.
As an extra args. To the vert install command.
And it installs, and it runs the Kickstart. And then… I basically have it all set up.
And I do that for, like, a few different servers. And that way you can get a little lab environment going with a quick little playbook. So that's just some….
Something, if anybody's interested, I threw the link in chat.
Fantastic, Sean, thank you. Nice.
Okay, questions? Comments?
Um, I got one. I don't know if I….
Have a good mental list of the competitors to Ansible, but there's.
There's Puppet and Grafana, and uh…. In the sushi world, it's salt.
Grafana is something else, isn't it? I thought it was graphing.
Salt, yeah, uh…. Yeah, that's a monitoring tool.
Yeah. I'm used to, like, Ansible, Puppet, Chef, and Salt. But that is, uh, memorization from a decade-plus ago.
Yep. But in the back of my head, I've got a feeling that there's some of those which are.
Not considered, uh, uh…. Useful as a poll tool. You know, they only will do push.
Not… not poll. Do I have that right? Or, uh…. But somehow Ansible.
I think kind of made its mark as being able to do pulls rather than pushes.
I think… I think pull is sort of like an afterthought with Ansible. It's like a… it's like a… yeah, it can also do that, but I think that, you know, very much the documentation steers you into the more push.
Push-based method. What Ansible is famous for is being agentless. So you, you know, in the typical push-based.
Kind of thing. You install Ansible on, like, your control node, and then you don't need to worry about installing Ansible on.
You know, your entire fleet, whereas I think with Puppet. And maybe with salt as well, I'm not too familiar with that one.
You have to install the agent on every node.
Okay, another thought, kind of going back and looking at the big picture.
Uh, in fact, I think it's this coming October. Uh, like, 3 months from now.
Would be the 10th anniversary. Of Red Hat.
Buying Ansible. Um…. Any thoughts, comments on.
What it means for a for-profit. Corporation to buy an open source piece of software.
Was this a good thing?
Did Red Hat buy Ansible, or are you conflating IBM buying Red Hat?
No, uh…. Well, let me go find it in the, uh….
It's in our calendar, stand by.
Yeah.
Okay, October the 16th. Uh, Red Hat announced its acquisition.
Okay.
Of IT automation startup Ansible. Or either 100 or 150 billion.
What I realized, for some people, that's pocket change. In my world.
I, you know, wanted to know what I'm getting, or, you know, what.
If this is already open source software. October the 16, 1-6.
What date was that, Gary?
So, the technicalities, IBM taking care of the…. Answer, because IBM owns the Red Hat.
Yes. Yeah.
Uh, did IBM already own Red Hat in 2015? They did? Okay.
Anyway, I'm just trying to get a feel for…. You know, for that much money, what was the advantage?
To actually…. Acquiring it.
No.
What does it mean to acquire open source software?
Intellectual property, um, management guidance. Um….
Yeah, I think the guidance would be important. You'd get the developers to do things that would be beneficial to you.
Mm-hmm. I've got it, yeah.
I think that would be the big thing.
Has there been any…. Controversies arising from that?
Um…. Ibm bought Red Hat in 2019, so Red Hat.
Bought Ansible before IBM bought Red Hat.
Okay.
Yeah, it seems weird, right? It seems like you can't… you can't buy, really, open source software. I mean, so maybe it was one of those situations where there was, like, some company named Ansible.
And the software was named Ansible, and so, like, maybe it's just a….
Unfortunate naming thing, like…. Yeah, like, because if the company was called, like, you know.
You know, Galaxy Solutions, and they made Ansible, and we were saying… and, you know, they were, like, maybe the main contributors to a code base called Ansible.
Then we would be saying, oh, Red Hat bought Galaxy Solutions, the main contributor of Ansible, you know?
And I think that just wouldn't sound as weird as saying Red Hat bought Ansible, you know?
Mm-hmm.
Mm-hmm, mm-hmm.
Well, and it could be that Ansible was a software product.
That was open source. But you could purchase support contracts and request.
Development on…. From the company.
As a for-pay item.
Maybe they might be using for an open shift. They might want to….
Taken.
Yeah, I…. I mean, Ansible is very foundationally baked into a lot of Red Hat things now.
Yeah, I think… so what Red Hat… what I've seen Red Hat pushing is they have….
Um, these system roles is what they're called. And the idea being….
That, hey, you should write… you should use these system roles to configure your Red Hat systems, because.
We want to be able to make changes between, like, Red Hat 9 and, like, Red Hat 10.
Right? We want to be able to, like, change things around.
But we don't want to inconvenience our customers, so what we'll do, if you use these system roles, we'll make sure the system roles stay the same.
Between these versions. So the thought is, is that you. Right? You know, you configure your systems using the system roles, and then we will update.
The modules within those roles to still work the same as we change the underlying, you know, whatever about the operating system.
So I think that's one play that Red Hat is going for with.
With that, but also, like I said, the Ansible automation platform is huge business, I'm sure, for Red Hat, even to this day.
You know, I'm not… I don't… this is not sensitive information, this… there's, like, a huge press release about it, but….
The company I work for, Southwest Airlines, they bought a bunch of Ansible support last year, like some big.
Big contract, then… and do a bunch of Ansible stuff now. I'm not involved with any of it, but….
Somewhere in the company, a lot of that stuff's happening, so I know they made a lot of money just even from us.
Another…. Kind of related fallout question to that is… and then, as you said on the last one, or my last question, there's.
Other considerations, but…. I guess just this last spring.
Ibm, who, as we pointed out, there's Neva pointed out, now owns Red Hat.
Went out and bought AshiCorp, or maybe they just bought Terraform from HashiCorp, and I….
I'm not really good with Terraform, but I guess I've always kind of thought of it as a.
Something similar to…. Ansible, but like I said, I'm not good enough to really totally understand that.
Yeah, yeah, that is super interesting to me, and…. Uh, so I watched… so, uh, let me see, like….
During, um, Red Hat Summit. They also had, like, an Ansible day, or an Ansible keynote, I guess, at Red Hat Summit.
And they brought the, uh, one of the founders, uh, of….
Hashicorp up on stage. And they had basically nothing.
They just brought them up, and they say, oh, we're thinking… now that we, you know, now that we're all on the same team.
We have a bunch of really good ideas for how to integrate Terraform and Ansible.
And it's gonna be so incredible, but they had nothing to, like, no… nothing concrete.
There's just….
Both are different, uh. Infrastructure as a code, and just completely different things.
Yeah, a lot of people use them together, like, you'll use Terraform to, like, provision, like I was saying, provision the EC2 instances.
And then Ansible to configure them once they're up and running with, like, an IP address, an SSH key, and all that. So a lot of people do use them together.
And I… what they were hinting at on that onstage presentation is, like, well, we're gonna have Ansible be able to call Terraform.
So that way, you run your playbook, and first it does the Terraform part, and then it does the Ansible part. So, I mean, they're certainly working towards.
Uh, streamlining it, and I'm sure it'll be good for their bottom line if they were able to do so, but as of right now, I haven't seen anything.
Concrete.
Yeah, my brain is still processing.
I thought I smelled smoke.
There we go. Yeah, Gary's got smoke coming out of his ears.
Well, one thing I could say, I meant to show this off, but I forgot, but if you're a GNOME user.
There's actually a module, a DCOF module, so for those of you that know a little bit about GNOME.
On Linux. Dcomf is essentially like the Windows registry, but for known, kind of thing.
And so, whenever you're changing the settings, like in the Settings app of GNOME.
What it's doing behind the scenes is it's updating this DCOF registry.
And Ansible actually has a deconf module. And so, um, what I do is… I don't really change that much with GNOME, I pretty much just use it exactly how it comes out of the box.
But the few things I do change, like the screen timeout and stuff like that, I….
Figured out what those registry settings are in the DECOF. And I added that to my playbook.
And I… and I… so even my desktop environment is configured via Ansible.
Um, alongside of, like, my command line environment and all that kind of stuff.
I feel like that's code to write code to change settings.
Yeah. Yeah, it might be a bit overkill, but, you know, it does… a lot of times when you set up a new workstation, you do spend quite a few minutes going through all the settings, and.
I….
Setting up everything how you like. So it is nice to not have to do that, or just do it once, you know?
Yeah.
It comes down to…. Economies of scale. Do you get enough benefit.
From the automation. To make the effort.
To set up the automation worthwhile.
Could I call myself a software developer if I didn't spend, like, an hour automating something that takes 5 minutes?
Well, if you don't use Ansible, you don't learn it. You gotta use a tool in order to really learn it, to….
Yeah, very true.
Back yourself into a corner, and then. Figure out what you did wrong, and then make it work better.
And….
That's using your own dog food kind of deal. You gotta use it.
You gotta break something. I've always said you learn more with failure than.
With success. Because you learn….
Yep.
That what you did doesn't work. You learn the symptoms of what was done, you learn how to undo it.
And those first three things may happen multiple times. Plus, you ultimately learn what does achieve your goal.
Versus if you get lucky, you just learn what achieves your goal.
Mm-hmm.
You learn more with the failure.
That actually is one of the…. Things, which is discussed right now with the, uh.
Spacex, uh, Super Heavy Launcher, uh. I mean, I lost count. I think they've lost 4 of them now, uh, some in rather….
Dramatic explosions on the pad, or just off the pad. And, uh, yeah, it… it looks….
Impressive, it looks bad. But, as you said, you learn a lot.
When something fails. In a catastrophic way. If you've been paying attention and keeping good records and stuff, but uh….
And the thing that…. I guess the other side of the coin is.
And the members of United Launch Alliance, namely Boeing and Lockheed.
You know, were the traditional aerospace company just getting too conservative? I mean, it does cost money.
When stuff blows up on the pad, but as long as it's not a banned launch.
Um, it may be worth it.
Yeah, and if you test torpedoes and…. Out of the two, one works. Is that a good success rate?
Well.
There's a problem we had in World War II.
Mm-hmm. Yeah. Yep, yep. They deployed them out into the Pacific, and then found out that they just go boink into the hull of a ship, and they don't blow up. Oops.
Yep.
Yeah. When they tested him, one of them did, right?
That's why you fire, too. Um, I… that makes me think of when they were dealing with new missiles, and the….
Flight control computer on them. They started having weird errors where they were running out of memory.
And it was cheaper. To add memory.
To the system than to debug the code to find the memory leak.
I mean, it just had to make it to the target, and then the problematic code vaporized.
10-minute warning.
Yeah, they don't call them explosions. They're…. Unscheduled rapid disassembly.
Yeah. On Windows Weekly, they were saying today.
Or they were saying it…. Microsoft has renamed, uh.
Crashes now, they call them unscheduled…. Unscheduled, uh, vacation?
System or something like that.
Did my manager approve this vacation for me?
Yeah. I don't remember the exact name, but they don't call it a crash anymore, they call it….
An unscheduled, uh, situation or something.
The new Windows 11 feature.
Yeah, but they're doing…. They're doing it to say, we no longer have crashes, we solved crashes. No, you didn't.
Right.
That's a marketing maneuver.
Yeah, well, that's like all these, uh, companies that say, we don't have… we….
Uh, don't have any proof that we were hacked. Well…. That's because we didn't run any log files. We have no idea what the hell happened.
They never say that, right?
Right?
Well, I suggest we pull the plug. We're still recording.
I will broaden out for just a second and point out that we've been asking.
Questions or making comments. Specific to tonight's talk.
Uh, I did say that there'd be another opportunity for general Q&A.
Does anyone have any general questions, comments? Tell us what you've been working on, uh, before we close down tonight.
Anything anyone want to bring up?
I work on a VMware platform. As a platform engineer, as a virtual infrastructure.
I'm a VMware automation engineer.
Interesting.
Yeah. So. So we are doing migration from VMware to OpenShift.
Vmware to OpenShift.
Yes.
I've heard a lot of people are doing that. Every time I turned on any website, it was a Red Hat ad for OpenShift automation. They were pushing that so hard now that VMware has, uh….
Um, basically turned all of its customers into, uh, into hate, you know.
Turn on all this kind of stuff.
The VMware is, uh…. Technical is taken care by….
Broadcam, so…. The entire name.
Yep.
Is gone, and even the licenses are too expensive. Yeah.
Yeah. Um, Broadcom did more for advertisement for Red Hat's virtualization platform.
That heck could have ever dreamed for.
Yep.
Although I heard a little birdie chirping. That apparently something is changing with Broadcom that's supposed to help.
But I have no details about it yet.
Believe it when I see it. So far, it's just been story after story of them….
Clamping down and just exploiting, right? They're not trying to…. You know, develop new features, or do anything like that. They just want to exploit their existing customers for as much profit as they can.
And even if they turn the ship around a little bit, it's very clear what their intentions are. It's just to exploit, exploit, exploit, so….
You know, even if they completely turn the ship around. The amount of effort they're gonna have to.
Do to overcome. The bad will from the last year.
People are not…. Going to trust VMware or whomever owns them.
Under Broadcom. Probably ever again.
Yeah, people moving VMware to OpenShift and Nutanix. This is also one of the….
Hyper-converged infrastructure.
How's the migration been going?
It's good. So far, no issues. We are using, uh…. There is, uh, tools like, uh….
For Nutanix, we use a MOO, that is the tool. And for, uh….
Okay.
Oh, man.
Veeam replication is one of the tools. The use.
Are you migrating systems as they are? Um, or doing fresh installs and migrating workload over.
Because I've seen both happening. With what I'm exposed to.
Now, migration… some of the applications, they're not comfortable with OpenShift.
They want to be in an existing… going to the Nutanix?
Some of them are…. I'd like to move to OpenShift.
So we have it, like, around 4,000 Red Hat servers. And, uh, 100 AX servers.
And, uh, 2,000 Windows servers.
That's actually fewer Windows servers. Ratio-wise compared to.
Linux or AIX that I've…. Seen in other environments.
Like, you can put a zero behind the number of windows compared to the.
Linux or AIX.
Yeah.
There's a workstations. For servers or workstations?
Say again, Tron? Servers.
What the heck? That's incredible.
Yeah. Like, I've seen…. 10 times….
The Windows servers as Linux servers. And 10 times the Linux servers as AIX or other.
Legacy Unix. Has not been migrated to Linux yet.
See, these organizations are the ones that are, like, still stuck on window… like, in 2025.
To still have that many more Windows servers and Linux servers.
These are exactly the people that VMware is looking to exploit, right? The people… like, if you can't even move off Windows.
How you ever gonna move off VMware? You know, it ain't gonna happen?
Blue Lock VMware.
It's easier than you might think, it's just on a 3-8 year cycle.
Of, okay, what is the virtualization platform we're running Windows on next year?
You do fresh installs, and. Your new servers, and then as your server lifecycle happens, you take.
Instead of the old compact. Running an old version of Windows.
You run, um…. On a new Dell, running a new version of Windows, except instead of Dell and Compaq, it's VMware and, uh.
Kbm, or pick your virtualization platform, and it's… as the servers are upgraded.
That's how they… I've seen people exiting.
Yeah, but those Windows servers are good for 10 years. So….
You know, the support on, like, Windows 2019 until 2029.
Or, like, what….
Well, the OS versus hardware.
So, I think the biggest failure is the Windows since 2009.
Is completely… lot of issues occurred in 2019 version Windows Server.
So people not interested to set up on a 2019 template.
Uh, in our environment, they get rid of it, and everybody migrated to the updated version 2022 Windows.
And, um, yeah, their, like, their applications supporting on a SQL.
Some of them are, like.NET applications. Yeah, they're doing that, and this….
Technically, like, a few people, like, like to go with Unix, or some of them are… we are using CentOS.
Like, a fewer service, like a 50 servers on CentOS. And the rest of them are 3,000 on Red Hat.
Um, Sean, you were commenting on the numbers. How… I feel like you could probably liken.
Windows servers. The way I see them used.
Very similar to a server equals a container. And if you think about the number of containers running on Linux servers.
Your numbers are probably much closer. To the number of actual Windows servers.
Yeah, but that's the worst, because each Windows VM is at least 20 gigs, so….
No, no, no, I'm not… I'm talking about service isolation standpoint.
So, that's not at all like a container, right?
Yeah, no, I get what you're saying, but it's just, like, the least efficient thing you could do, really, because, I mean, like.
I mean, at least on Linux, even a Linux VM is, like, half the size of a Windows VM, just from….
You know, the OS installed just by itself, you know?
Right, but if you're leveraging. Ensures that hypervisors have.
Where deduplication is not…. The term I want, but it's what I'm going with. Um, shared memory pages and the likes. If you have the exact same version of.
100 Windows servers? They may only be consuming.
Memory on the host that's the aggregate of 20 of them.
And similar with disk…. Deduplication-type things.
Basically, you're really only storing. Small deltas for each of them.
Okay, well, that's pretty good. That's not bad, then.
Right, and VMware, if you have. The same versions on everything.
It can get a phenomenal number. Of VMs on the same host.
And now, you pay for that… that capability. You had it before, but now to keep it, you have to pay, what, double?
Um, I think in some places it was 3 to 4 times.
Wow.
I want to ask a completely different question, uh…. There's a few names.
Amongst the participants here. That, uh, uh….
I haven't seen in a long time, maybe a couple that I have never seen. Uh, so I'm just curious as to what brought you to the meeting tonight. Did you see us on Meetup?
Did somebody at work or some other associate of yours send you an email or a phone call and say, hey, they're gonna talk about Ansible tonight? Is it the topic that intrigued you, or….
How did you come tonight? If anyone. I don't want to embarrass anyone, you can answer it verbally if you like, put it in chat.
Uh, you can send it to everybody in chat, or just send it to….
To Gary Meyer personally, if you like, either way. I'm just curious.
So, DW, uh, you saw it on Meetup, and you decided to join, so does that mean.
The topic, um, drew your interest, or…. A Linux….
Unix group meetup.
Cool.
So, my side, I was part of St. Louis. Back in 20….
24… 2023, I was in the part… meeting up on this group.
I moved out of St. Louis, and recently, like, one year ago, one and a half year ago.
Um, to Houston. I brought a house here, and…. I'm remotely working to the client.
So, I used to be, uh, attend the Red Hat sections when you guys.
Conduct long back. Like, in a year or two years back.
So I was missing, so I was…. I lost my meetup group password. Somehow, I retired now, so….
I got… I saw the invitation, so I accept… I mean, I saw the Ansible is….
Event is going on, so that I attended. Session.
Cool. Well….
In, like, New Year's. Let me….
Thanks for coming back. Thank you for coming back. We appreciated all your comments tonight.
Same thing with DW. Thank you for coming tonight, too, so….
Our next meeting is in 8 days, Thursday of next week. It is the St. Louis Log, St. Louis Linux user group meeting.
Uh, and we do not yet have a, uh, confirmed topic or speaker.
Um, so if anybody wants to, uh. Offer any particular topic, uh, send a note to, uh.
Um, you can set it to SteerCom, S-T-E-E-R-C-O-M. At SLUV.org, and uh….
One of us will see your note and contact you. Yeah, does that work?
If you're not a member? Uh, yeah, okay, I believe so.
At the very least, it should be held from.
Well, maybe send it to editor at slug.org, I know that works. Editor at slug.org.
Uh, Gary, I suggest that you do a presentation on, uh, calendar maintenance.
Here we go. You're a good salesman. A very good salesman.
It couldn't hurt.
Yeah, you're right. Well, it could in that I don't know if I would make a decent presentation by Thursday on the topic, but….
Oh, come on, Lee and I have put more together and less.
Oh, yes, that's true, that is true. The thing is, is it would be embarrassing, because when you guys do that, it turns out wonderfully.
God, Lee, how much are you paying him to flatter us like that?
And then….
I haven't mentioned anything.
Gary's problem is that piece of crap computer he's got.
What computer? It's got a freaking Chromebook. That's not a computer.
Oh, it's a computer running a questionable distribution of an OS.
You haven't seen the… you haven't seen the hardware, Grant. Hey, I bought this from a guy named Chang, and Nanking, and he guarantees me that it's one of the original abacuses.
Well, here, I was gonna make a reference to one laptop per child.
And those were, like, Raspberry Pi A, or something like that, weren't they?
Oh, gosh.
Yeah, I would still like to get my hands on one.
Oh, God. Well, you don't have… you don't have any kids, do you?
No, but…. To me, the OLPC.
Is one of those milestones, kind of like the Raspberry Pi.
Was a milestone of…. Has gotten to a point.
Did it mass market usable?
Ah, he's building a museum. Hey, you oughta… I got about a dozen boxes of museum-quality stuff here, I'll give them to you.
Okay. I need to talk to you about 3D printers.
Okay? Anytime. All right, we ready to pull a plug, Gary? I guess so. This has been the, uh, general meeting of SLUG for the month of July 2025. Today's date, Wednesday the 9th of July, 2025.
Of our topic tonight, uh, our, uh, tutorial was Ansible 101.
Our main topic was Ansible Pull. And our speaker was Sean Tweehaus.
Thank you all for