Switching Teams: From Linux to Windows and Windows to Linux

Trevor: [00:00:00] Would you agree with the— with learning being fun and exciting?

Matt: I would also agree with it being a struggle.

Trevor: It’s time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices, and operate your team and business for maximum DevOps awesomeness. I’m your host, Trevor Hess, @TrevorGHess on Twitter. Arrested DevOps is brought to you by 10th Magnitude, a cloud services company that figures if you’re listening to this podcast, you must be pretty cool. You can find out about joining their cloud services team at arresteddevops.com/10thmagnitude. This episode is also brought to you by Datadog, a monitoring tool that helps bridge the gap between operations and dev teams. Datadog brings together system metrics, changes, alerts, and events from over 70 common infrastructure tools such as Chef, Docker, and AWS so that dev and ops teams share their key data and alerts in a single place and collaborate on issues in real time. Datadog is available for a 14-day trial at arresteddevops.com/datadog. Tonight we’ll be talking about getting bounced out of our comfort zones, or in this case, OSes, going from Linux to Windows and the other way around. Our guest tonight is Matt Matthew Walt Walter, or Matt Walter for legal purposes. Matt, tell us about yourself.

Matt: [00:01:29] Hi Trevor, uh, my name is Matthew Walter and I’m a Linux sysadmin at a company called North American Power. It’s a deregulated energy marketer in Connecticut, and I’ve been working on transitioning, not completely, but from Linux to Windows over the last 6 months or so.

Trevor: Awesome. Thank you so much for joining us tonight.

Matt: Happy to be here.

Trevor: I guess me, it’s, uh, this is, this is one of our first, uh, one-on-ones. Thanks for, thanks for being my first one-on-one, Matt.

Matt: I’m happy to be here, Trevor.

Trevor: So as we get started, let’s briefly go over what we’re going to talk about tonight on the show. First of all, we’re going to talk about why do we switch? What makes us switch? Do we, is it, is it ever our own volition or no? We’re gonna talk about managing installations, OS philosophies, the different terminals, so Bash or command line or PowerShell or Z Shell, what have you. We’ll talk about Pythons and PowerShells, so how do we get to managing regex and doing kind of those sorts of things where we can get tripped up with line endings, the differences in file systems. We’re gonna talk a little bit about monitoring strategies, LDAP and Active Directory, And finally, we’re going to talk about actually utilizing Windows on Mac or utilizing Linux on Windows. So as we get started here, I had to say it’s odd getting running here because it’s— I’m so used to Matt and Bridget just running with everything. And so it’s exciting. And I’ll admit to being a little nervous.

Matt: [00:03:05] I think we’re both a little bit out of our comfort zone here.

Trevor: Outside of transitioning operating systems? All right, so let’s let’s get started. So Matt, you you mentioned briefly when you introduced yourself why you’re going through this transition because you’re you’re in the middle of you’re kind of in the middle of going through an organizational transformation. So you want to talk a little bit about how that felt and why like how you approach the situation?

Matt: Well, so I was told in February I think that our company was going to be starting a transition from a Linux LAMP stack with PHP over to a .NET stack for a new line of business app that’s running the majority of our backend sort of stuff. And as I’m actually the only ops person at North American Power right now, so being a Linux admin and being told that we’re transitioning over to a Windows stack, I was kind of— I was a little leery at first. But after looking into it a little bit, I found that there’s a lot that I was interested in and a lot of things that I could still leverage from what I knew. We run Ansible for our configuration management here for the Linux side. And just looking at the possible tools and what I could learn on Windows and how I could leverage that going forward, I decided to stay. And it was still kind of a scary thing though, going into like, I’m a Linux admin and I’m gonna try and learn Windows. It’s not something I ever thought I would do.

Trevor: [00:04:33] Yeah, it can be an interesting transition as we’ll, as we’ll explore tonight. So for me, I’ve lately, I’ve started having more and more clients pop up that are Linux. And so they’re kind of getting some, some Linux in my Windows and it’s been interesting. So, so full disclosure, I’ve been, I’ve been working with Matt a little bit the past couple of weeks. And so Matt can, Matt can testify firsthand as to how much I’ve been struggling with things like if statements in Bash. But it’s, it’s been a lot of fun getting, getting familiar with Linux. I personally have worked with Macs in the past, both as a failed graphic designer and as a— having worked a little bit with Ruby on Rails at my last company. So it’s been interesting getting more comfortable in Bash and finally opening up, you know, installing Zsh or these other, other tools. And, you know, it’s just something for me that it’s just that struggle to keep learning, which isn’t really a struggle. It’s more of a really exciting, fun thing to do. I don’t know, Matt, would you agree with learning being fun and exciting?

Matt: [00:05:44] I would also agree with it being a struggle. It’s drinking from the fire hose most days.

Trevor: Yes, but much like being a child and seeing an open fire hydrant, it’s hard not to play with the fire hose. Oh, that’s true. All right, so let’s talk about the differences in kind of the approach we have when we go from Windows to Linux or vice versa. Let’s just talk about the different things that we know about these operating systems that we think might kind of trip each other up. So, you know, the first thing we kind of listed out here to talk about is managing installations. You know, I come from a world where As we all know, I’ve got my developer background, so I largely come from a world where installing something means downloading an .exe or an .msi, double-clicking it, and going through an InstallShield wizard. But that’s not really how things work on Linux, is it?

Matt: No, it’s more like as long as you know or can find the package name for what you want, you can probably do it through your favorite package manager. And that way you always know that it will always be there through a secure or reasonably secure source. And if you don’t, there’s other people’s packages, other repositories. Like, for instance, on RHEL, there’s the EPEL repo that somebody’s maintaining that through the fantastic goodness of their hearts and providing us with a great thing.

Trevor: [00:07:10] So, I just want to back up a second there. So, you said packages. So, for me, you know, obviously now I know what a package is, but let’s pretend I didn’t know what a package is. What is a package? What is a package manager?

Matt: So with a Linux package manager, it’s the code that you want to install. And when you actually create one, there’s a series of scripts that run. It comes with an install script, an uninstall script, a here’s the things that need to be done before you actually install the package itself, which is usually either the binary that you’re installing or, you know, you can compile the source code and all this, that sort of thing. But what they come with is a key that says it came from a reputable source, it’s signed, and you’re able to just reach out and grab them using whatever, whichever your distribution tool is, whether it’s apt-get or yum. And you can get metadata about those packages, when they were updated, what the updates consisted of, that sort of thing. Very, very convenient in your, your current shell. It’s not like you have to go to a foreign website and download something from places like SourceForge, etc.

Trevor: [00:08:18] Oh, you mean malware.com? Malware Central. And so now we also are starting to see that appear in Windows space too, though. So we’re starting to see package managers come up. I mean, so I think for a few years now, a lot of folks in the Windows space have been familiar with Chocolatey, which is a Windows package manager that, you know, uses— utilizes— I believe it uses PowerShell as its backend to manage the installation of our typical EXEs or however you’ve scripted for these things, your package to install. But again, it goes into a package repository where these things are maintained and kind of pruned for goodness. And also, as Windows 10 rolled out, we saw the emergence of OneGet for Windows as well. So have you had the opportunity to see Chocolatey or OneGet yet?

Matt: So I’ve seen Chocolatey in action, and it’s very cool. It definitely gives the same feel as a Linux package manager. I’ve heard a few things. I haven’t checked recently. I know there was a thing about it not actually being like signed packages or secure. So it’s not something I would run in production. But if that changes, then it’s something that I’m very interested in seeing. Plus the Microsoft implementation, was it OneGet? I think it’s actually still using mostly Chocolatey on the backend.

Trevor: [00:09:37] I think so. So I think Chocolatey is the package source for OneGet or one of them.

Matt: Yeah. So if it was actually like a curated and secure repository of signed packages, that would be fantastic. And I would love to use it. Because when I did try it, it was very simple and it just, everything just kind of worked, which is exactly what I’m looking for.

Trevor: Yeah. So I believe the answer is they are, it is curated. What I’m not sure about is, well, rather, I actually, I don’t think they are signed. In fact, I have seen situations before where the PowerShell script that runs is actually pulling an executable or MSI down from the release area of whatever company site it is.

Matt: Yeah.

Trevor: And I’ve actually run into situations, I think I was installing Notepad++, and it so happened that that day Notepad++ decided that was the day that they were going to change their package directory structure. And so all of a sudden my cookbooks were not converging because they— what the Chocolatey package that was trying to run wasn’t being— wasn’t able to pull down a file because it didn’t exist anymore. So I think, I think you’re right. I think it’s kind of— it’s in its infancy still, and we should look to it for greatness, but might not be quite ready for everyone yet.

Matt: [00:10:56] The other cool thing that Linux package managers do is you can— it manages your dependencies for you, but it also— you can mirror the whole repository. I think last time I tried for Ubuntu 12.04 it was something like 80 gigs, which is large but not unreasonable. So you could still mirror the entirety of the Ubuntu package repository locally to do package management and make sure that you’re not sending crazy updates out to your servers.

Trevor: That’s awesome. So let’s kind of talk about the OS philosophies next. So, I mean, kind of what I’m thinking here is just some of the basic tenets that we see in our operating systems. So when Matt and I were discussing this topic, before we decided to turn it into a podcast, one of the first things that we talked about was, was the concept of in Linux being able to interact with everything as a file, whereas in Windows everything is an API or registry key. And this topic came up a little bit in our first Microsofty episode where we had Jessica DeVita and Jeffrey Snover on, and Snover sort of said the same thing, and that was one of the reasons why he said that kind of doing some of the, as I recall, some of doing some of the kind of infrastructure as code and configuration management pieces is challenging in Windows because everything isn’t a file.

Matt: [00:12:20] Yeah, we’ve definitely run across that one. So I mean, so on the Linux side, it’s, it’s everything is a file, but it’s also everything has one job. So all the tools are created, the Unix philosophy of small atomic things and then being able to chain them together to get whatever result you want. Provides very flexible tools. But I mean, things like everything down to like the sockets for the network stuff, or if you want to actually change your running system going into— there’s a file directory that tracks everything that’s happening in your system, and you can go look at it. It’s an interesting— everything is accessible. There’s nothing that’s hidden away. It makes it very handy.

Trevor: Yeah, I mean, that’s definitely one of my frustrations every time I open up a Windows operating system, and one of the first things I have to do is I have to go into folder I have to make sure that we’re not hiding things from me. You know, I mean, obviously when we’re looking actually in PowerShell or CMD, I can actually list all the files, no problem, as long as I’m an administrator. It drives me crazy whenever I go into the file system, like into Explorer on a system, and I’m looking for a .file and I can’t find it because it’s not showing to me, or the extension for a file is hidden. That just irks me. But yeah, absolutely. And that’s one of the things that can be challenging about Windows. I mean, like you said, you can interact with anything live in the system in Linux. And, you know, that’s why you can change just about anything without having to reboot, whereas in Windows you change anything and you almost always have to reboot. Although that’s changing too.

Matt: [00:13:53] We can only hope. So as far as the Windows operating system philosophies, that’s been changing a lot. I’m still getting a handle on exactly what’s going on in the Windows world. I would not call myself experienced in Windows at this point by any means. So how— where’s that going?

Trevor: So it’s interesting because it seems like there’s— in the conversations I’ve had with folks from Microsoft, it seems like there’s a genuine interest to kind of close the gap and alleviate these issues that folks run into because they are frustrating for everybody, especially as we move into this world where everything needs to be repeatable, everything’s in the cloud, everything needs to be smaller, everything is compartmentalized and containerized. And all of our favorite cadre of buzzwords. And it really seems like Microsoft is trying to work towards that. And so I’ve been told that, you know, there’s, you still have to do the occasional reboot in Nano, but it’s not nearly as often as it was on any of the previous versions of Windows Server, which is fantastic because you can manage those configuration changes without having to worry about, okay, my system’s now going to be down for you know, 2 minutes, 3 minutes, 20 minutes, depending on how complicated your system is.

Matt: [00:15:15] So in terms of Windows philosophy though, like the Unix philosophy has always been, you know, the small atomic things that make everything accessible. But is there really a driving Windows philosophy or management philosophy or anything like that?

Trevor: I think the answer is yes. I’m not sure how I would best phrase it. I think what I would say is, like, you know, like we mentioned, it’s, it’s kind of that, that pattern where we’re talking about everything has kind of a handle. And, you know, in the .NET Framework, everything has, has a library that you can point at, and you can, you can interact with things in a kind of a consistent way, for the most part. But generally, kind of opposite of what you were saying, having the idea of having one tool to do everything is, is much more common, as opposed to in Linux, where it’s the smallest possible thing to do a job. It’s these kind of heavyweight pieces that accomplish a lot, but maybe not as well as if it was broken out.

Matt: [00:16:16] I definitely, um, upon looking when I, when I did my research, is, you know, is Windows something that I’m interested in moving into at all? What I found was that the previous characterization that I would have said for Microsoft was that everything should be clicky and, and explain itself so that somebody who doesn’t know what they’re doing can do it. It definitely has been changing more too with the advent of PowerShell and especially like DSC and moving toward Nano. It’s been changing into more of you need to know what you’re doing and they’re providing the powerful tools in order to do that. So absolutely, you know, I don’t necessarily want to look down on anyone, but in a lot of cases there was a stereotype of the Windows admin was unskilled because all they ever did was click buttons. And I definitely think that that’s changing a lot.

Trevor: Yeah, I mean, every— like, with tools like Chef and Puppet, you wind up— everybody’s trying to figure out how you can interact with a lot of these tools without having to be in that interface. And like you said, DSC provides a lot of functionality to get at that. But, you know, like, trying to automate SQL Server can be like pulling teeth because You know, the SQL Server installer is a big bulky multi-step wizard and it doesn’t have a super friendly command line.

Matt: [00:17:35] Totally fucking beast.

Trevor: At least, you know, it’s not like installing a package on Linux where you just add the flags and everything’s there and then you can edit the config files. You know, when you’re working against something like SQL, you’ve got to go find the right registry files. You’ve then got to figure out what the special command line tool is for SQL to get into to make sure that your logins and everything are configured correctly. You know, there’s, there’s, there’s so many moving pieces so that you can use this big giant tool that’s very powerful but not necessarily as straightforward as some of the smaller pieces. Cool. Now that you have— now you have the opportunity to make fun of my, my Bash skills because we’re gonna talk about bash versus Z shell versus command line versus PowerShell.

Matt: So making fun of your bash skills, as, as funny as it was to watch that, I think that’s actually a fantastic example because so with bash there’s a lot of you have to go look up syntax and you had to figure out what those, those loop structures would look like and all of the occasionally difficult to like bash is pretty well documented, but you’ve got to go find what you’re looking for. So the struggles that you had with that versus being able to just pick up PowerShell and get it. So when I first started touching PowerShell, figuring out the syntax of verb, noun, and then the couple— hang on a second, I’ve got a train. So if you want to pick that up for a second.

Trevor: [00:19:06] Yeah. So I was able to kind of figure out how to do some of the Bash stuff, but as I started looking at like I was so I was trying to do an if statement, which in PowerShell is pretty straightforward. Trying to accomplish the same thing in Bash was driving me crazy. I mean, it was very interesting that the space meant something. And when spaces mean things, I get kind of irate because it drives me insane.

Matt: You were definitely— the mix between whitespace being significant in a test structure and then trying to figure out what you were doing with that. It got kinda hairy there. But when I was picking up PowerShell, it was— it’s all very well documented. It follows the same patterns through everything. It’s— for me, it’s pretty confusing just for the— the commands don’t follow a pattern other than they relate to what you’re trying to do in some way. So, but after I learned a few things like the Get-Command cmdlet and things like that, it went pretty quick. Whereas I can definitely see picking up Bash for the first time and trying to do anything really reasonably complex with it could be a hairy experience.

Trevor: [00:20:14] Yeah, I mean, it’s just, it’s very different. You know, it’s, I can, I can express my intent in PowerShell, whereas in Bash, I need to know my intent, I think is one way of describing it. And, you know, it’s a lot easier to base things off of what you want to do as opposed to necessarily having to know what you need to do. Which, so, if you have any established paradigm in place, you can kind of build off of that. Whereas, if you are unfamiliar with, you know, how it works, it’s hard to know what to look for. You know, that’s one of the things I struggle with sometimes is, what do I Google for to solve this problem?

Matt: It’s half Google-fu.

Trevor: So, it’s funny, we kind of skipped right over command line and went straight to Bash. Bash to PowerShell. I mean, I mean, command line’s not super useful.

Matt: I mean, at this point I wish it was removed. It would simplify things.

Trevor: It really would. I mean, there’s, there’s nothing— I mean, I’m sure that’s not true. I’m sure there’s something that I don’t know about that you need, you need command line around for some, some old, old executable that it can only run in command line. I, I don’t know. If you know what that is, tweet at me and let me know. Or at us, I should say. I’m sure it’d be an interesting read.

Matt: [00:21:33] From what I saw, it was mostly for, um, because Microsoft has always been supportive of legacy and everything that they’ve done before, trying not to break backwards compatibility, which is fantastic. Um, so I think it’s more just keeping that going.

Trevor: But I think you’re not alone in wanting it to go away.

Matt: Definitely. When I— I was going to say that, uh, picking up PowerShell for the first time, as you know, I I live and breathe in Bash and, you know, pop out to Python or something like else if I’m looking for regex or trying to do anything that’s more complex than a one-liner really. But picking up PowerShell for the first time and being able to— I was trying to stand up virtual machine in Azure and run some things against it, and I was able to pipe a Get-AzureVM cmdlet which returned an object of that VM’s attributes into the next command. That blew my mind. Being able to do that in my shell was really, really cool to me.

Trevor: Yeah, that’s super. It’s like, that’s, that’s so powerful. I mean, in fact, for me, going the opposite direction, not being able to— so for me, I was trying to get something to, to evaluate to true. It took me like a minute or 2 to realize, oh, I can’t do that. This isn’t PowerShell. There’s, there’s— I can give an exit code, but I can’t necessarily do truthiness.

Matt: [00:22:52] Yeah, even, um, adding and doing math in Bash is kind of, uh, there’s a weird syntax for that one.

Trevor: Yeah, equality is, is unusual for me, and even in PowerShell, because I’m used to .NET and, and, and kind of C-based programming languages or JavaScript where it’s, you know, equals equals or equals equals equals or you know, bang equals and having that mean something, not -eq meaning equality and, and all the different matchers that you get to evaluate in PowerShell and Bash.

Matt: I think we’re on the same line to Pythons and PowerShells, talking about regex and just parsing data in between the 2 shells. The thing that I noticed about PowerShell was that you can It actually almost reminded me of the AWS CLI in that you were able to specify your outputs. And because I interacted with that much more than I had PowerShell at the point, being able to drop anything that you want into a table. Whereas if you try to do that in Bash, you end up with, you know, long chain of pipes and sed and awk trying to make that look the way that you want and get exactly what you want. And you’re often better off just going to something like Python.

Trevor: [00:24:02] Yeah. I don’t even know what half those words were just now.

Matt: Sed and awk processing.

Trevor: Oh, okay. I do know both of those words. I just didn’t know them as one word. Yeah, I mean, it’s awesome how you can manage objects like that in PowerShell. You have to be careful though, because I’ve actually seen libraries published by some pretty big companies that misuse— maybe misuse isn’t right, but they don’t send back objects in PowerShell. They actually send back the evaluated data. So for example, instead of, instead of providing you with the output of a command as data, it provides you the output of the command as a formatted table, which does not have the same interactability as the raw data. So you wind up with this table that you can, you as, you as human with eyes can read and understand, but you as person who wants computer to manage data have no use for.

Matt: [00:25:03] It’s probably a Linux admin doing that.

Trevor: That’s possible. So I mean, being able to interact with things as an object, I mean, it’s partly a scripting language. It’s great. I mean, you have access to the whole .NET framework. But so it sounds like as I go into Linux more, I need to learn more about Python. So you want to talk a little bit about how you manage, how you can kind of pipe commands into Python and manage.

Matt: So there’s a lot of people, I believe, that will write command line parsers in Python and then use those like right in line with the rest of their Bash. So trying to get the, the right output that they’re looking for. But there’s a lot of other things as far as like regex and making sure that when you’re looking through a particular log file that you’re going to get the data out that you’re looking for. You know what string you’re looking for, so you can move that into another file and then populated in another way. Because if you’re looking to get that, that pretty table that PowerShell will give you, you have to figure out how to create it yourself with the requisite fields. There’s a lot of stuff, especially with Python, where if you want any library like CSV or something like that to put something out to any other format than what you would get just standard in, standard out, you need to go somewhere else. Because Bash can do it, it’s just you’re likely to pull your hair out versus using an actual programming language.

Trevor: [00:26:27] I think that makes sense given, given what we’ve talked about with Bash. It’s just, it’s, it’s different to me now that I’ve gotten used to working with PowerShell first to kind of lose that ability. For you, it’s like this cool enhancement, I think. But for me, it’s like I’ve lost something.

Matt: For that, Python is kind of ubiquitous only because it’s on pretty much every Linux box. You could use Ruby or whatever other language you’re comfortable with as well. And a lot of people have been doing new things with Go, just because it’s portable and pretty awesome.

Trevor: Portable and pretty awesome. I think I like that. But, yeah, I’ve actually— I have worked a little bit, and when I was doing more Rails work, I worked with Ruby as a console, and I found that that was pretty useful, being able to kind of create those rake tasks and utilize those things. It could be kind of fun, and you get to do more complex and interesting things. So, as we talk a little bit about code, why don’t we talk a little bit about line endings briefly at this point? So you— I know you understand this way better than I do, so I’m gonna let you explain line ending, the difference in line endings between—

Matt: [00:27:38] I think I’ve seen the results of this, but I think it’s something like the—

Trevor: that’s where I’m at too.

Matt: It’s like Windows ends things with a specific type of carriage return and Linux ends them with another. But the major thing is that when you try and open a file from Linux on a Windows box, it looks more or less like one line or garbled, or you’ll see an invisible line ending somewhere that one operating system or the other won’t handle. I’m at the point now where those—

Trevor: yeah, wonderful boxes.

Matt: I’m at the point now where I’m just trying to— I’m gonna see if I can let Git handle all of my line endings and just never worry about it again. But it’s one of those things that will blow up in your face if you don’t think about it correctly. What was that other issue we had? The, um, different encoding? UTF-8?

Trevor: Oh yeah, yeah, yeah, that’s, that’s an entirely different issue. Making sure that your, your command line tools or your Bash tools can actually interpret the file types you’re giving them, or not the file types but the encoding types. So that’s, that’s a whole nother can of worms. So then let’s talk a little bit about file systems. We got, we got a few more topics we want to hit here and not a whole lot of time left. So let’s, uh, let’s kind of rapid-fire this, I think, a little bit. So let’s, let’s talk about our differences in file systems and, and how, uh, so for me coming into, coming into Linux and seeing all the, the permissions and kind of the first time I saw somebody chown 777, And having no idea what that meant, I thought it was some sort of like leet speak nonsense that was going on. Like, what are you, what are you weird Linux person doing? I don’t understand. And I’ll be honest to say, I still don’t know the full permissions model. But it’s interesting to see the kind of that representation when you do ls -lf and see all of the, all the file folder permissions to specify whether it’s a file or a folder and how it’s all just properties.

Matt: [00:29:38] To me, it was always more simple and kind of elegant. The way that Linux does it, just because you have, you have user, you have group, and then you have everyone else, the others, and you can specify whether they can read, write, or execute. So you manage your users, whoever owns the file, you manage what groups anyone else has access to, and then you manage the rest of the world. They also introduced file ACLs and things like that that kind of mimic what Windows does, but Windows gives you that full role-based access control and everything that you can, you can do basically anything with, uh, from, from the outset. So it being able to, to look at something as a series of 3 numbers and say it’s good to go or not has always been pretty simple to me.

Trevor: Yeah, I mean, actually hearing you say that makes a lot of things click in my head that were like disjointed pieces. Also thinking about it, I’ve never actually managed Windows file permissions I haven’t either.

Matt: You know, that’s something we’re gonna have to check out.

Trevor: So I, like, I know you can set the user-based and group-based roles and permissions granularly, but I’ve never tried to do it in a group basis outside of a GUI. That’s, uh, that’s something interesting. I’ll have to, I’ll have to dig into that and maybe tweet about it.

Matt: [00:30:53] Windows also has the concept of an owner for a file or something like that, but most people don’t ever change it. They just, you just deal with the users and groups that have access to the file.

Trevor: I don’t think I’ve ever— I think outside of like sideloading an old hard drive, I don’t think I’ve ever changed owners. So let’s talk a little bit about monitoring. So obviously we’ve got a couple different ways to look at things here. So I know in the Windows space, monitoring is handled largely by the Event Viewer. And that’s where you get a lot of the system details and see when, like, when services started, when users logged into the system, when bad things happen, et cetera. I’ve actually never looked to see this. Where does—

Matt: log usually. And underneath that there’s both the system logs and then usually any other application logs. But Event Viewer puts that all in that nice little GUI for you. But with the directory, it’s just a series of files that our log items are appended to. It actually can be surprisingly simple because things like— as they’re written item by item, so you can grab each of those items. And for something like Logstash or whatnot, you can ship that single entry over, and, uh, it makes it— it only grows one line at a time, or, you know, I guess a stack trace at a time.

Trevor: [00:32:09] Yeah, interesting. So that’s the— these are the things we, we all wrap up and ship into Splunk or what have you.

Matt: One thing I noticed about Windows monitoring was that everything I found there, other than, you know, finding the tools that people have written recently, everything was a product, and, uh, everything around that was all you have to, you have to buy it, you have to pay money, and then you have to talk to a bunch of closed source developers who are not gonna be there for you all the time. You have to go through the, you know, like the company’s support teams instead of, hey, I have a fix for this sort of thing. That goes back to like the closed source versus open source thing.

Trevor: But yeah, I mean, that can be— I find for me, I find that to be both frustrating, and I find it frustrating on both ends because On one end, you have a dedicated set of people that you can pay to fix something. On the other hand, you’ve got somebody who’s doing this probably in their spare time, or a group of people doing this in their spare time. And you, in some cases, not all cases, but in some cases, you’re almost better off fixing it yourself than waiting for it to be fixed by the owner. So I can see it frustrating in both ways. I love when an open source project is responsive, but it’s not always the case. And oftentimes I find that I can fix the problem faster and then send it back and offer that to them.

Matt: [00:33:30] For definitely when, uh, we first started this transition here, people kept coming in and saying, hey, do we have a support contract with, with such and such? And I, I’d be like, well, we— it’s open source. We don’t— and there’s no company that’s supporting that. We don’t have a support contract with anyone. I, I don’t understand where that came from. But then realizing that they, they worked in a completely different world where If something’s broken, we call someone, and that’s kind of the opposite of where I’ve been living.

Trevor: Yeah, man, it’s interesting because as I was a .NET developer, almost, I think, once or twice did I ever actually reach out to Microsoft or some of my vendors for help. Everything else, we were either working with open source or whatever, and it was just, okay, okay, patch it and make it work. You’re not paying for that support contract.

Matt: That was actually— that was one of the first things that, uh, our new Windows sysadmin asked me. He’s like, do we have a Microsoft Service Agreement? And I said, I don’t know.

Trevor: Yeah, those are expensive. All right, so let’s talk quickly about LDAP and Active Directory. So I will say immediately that I actually have no idea how LDAP works. I just— I know the word, and I have no idea how that is used to manage users in Linux, it’s a little bit more—

Matt: [00:34:51] it doesn’t work as well out of the box as Active Directory does, which is, I think, in this— if we were talking about a Linux versus Windows sort of thing, Active Directory wins hands down. Most of the Linux LDAP solutions are people that are bolting things on to try and emulate Active Directory, and it’s still— I tried setting up some of the open source ones a while back, and I got it working, but it was definitely not a fun experience.

Trevor: Yeah, I mean, it’s interesting now. I’ve heard both horror stories and great success stories in getting Active Directory set up too. And it’s incredible how much quicker it seems things are going now that it’s in Azure. So my only experience personally with setting up Active Directory has been setting it up in my own Azure subscription, but I’ve just, I’ve seen so many problems with people trying to figure out the forest for the trees in their Active Directory setups that it’s— it just seems like it’s one of those things that you, you, if you don’t maintain it, it’s going to grow out of control.

Matt: [00:35:56] That was—

Trevor: you know, the puns, the puns are an important part of a conversation.

Matt: But no, um, as far as, uh, like for instance, our, our Linux boxes here, we do not actually have any sort of LDAP connected to them. Just because they exist and they do a job and we shouldn’t be connecting to them other than with a specific key that most of our automation users— like, excuse me, the automation client is using. So Ansible connects with a key and that’s the only one that should be on the box. We don’t— no users are logging into most of our Linux nodes.

Trevor: That’s awesome. I like hands-off.

Matt: The goal.

Trevor: Absolutely. Well, one of the goals. The goal is making— is to get the money. All right. So finally, let’s, let’s cover quickly. How do we, how do we use Windows on a Mac and how do we use Linux on Windows? So obviously, you know, out of the box, your Mac comes with Boot Camp, right? But Boot Camp is not always the easiest way to run a system, especially if you’re not super comfortable diving into Windows. And even if you are, it does some weird things.

Matt: [00:37:04] Definitely without VirtualBox and Test Kitchen, life would be much, much worse.

Trevor: Yes, I mean, in terms of testing our infrastructure, but in terms of, like, in terms of using it for— so, so one of the things that we talked about was you’ve got VirtualBox with a machine that you have set up to run some of your Microsoft utilities that you don’t want— you don’t want to abandon your Mac for, right?

Matt: Just, just in order to get a PowerShell terminal without having to spin another box up. So I use it if I want to connect to our domain and query the rings and anything that I want to use PowerShell for, even if it’s just to get names of services and things like that.

Trevor: Yeah, and so that’s super handy. It’s really cool how you can just use— you can set up VirtualBox, doesn’t matter if you’re on what computer you’re on, and you can just emulate the operating system you use. Because that’s the same thing I use to use Linux on Windows is I spin up VirtualBox. Typically it’s like you said, using Test Kitchen with Chef, and then I can just SSH into it and do what I need to do. Or on the rare occasion I need a GUI in Linux, I can spin up an Ubuntu server with— or Ubuntu desktop with the GUI on it and futz around in that and wind up back in Bash anyway.

Matt: [00:38:21] So the only other thing that I think we should definitely talk about was that consistent management tools. So without things like Chef and test kitchen and being able to use those same tools between Linux and Windows. The fact that the Windows support for those has dramatically improved over the last couple years really was the only reason that I thought that even potentially working in this space was going to be possible for me. Because this way I’m still working on concepts, I’m learning general things that can apply to both Linux and Windows using the same support paradigms, configuration management, and continuous integration and infrastructure as code, and using those things applied to the Windows stack with some modifications and, and making it work as we go. That’s really the only way that made Linux to Windows even an option for me.

Trevor: Yeah, I mean, for me too, that’s being able to use those tools to kind of wrap my understanding around without having to bash against bash to, to teach myself how to do that, it’s been, it’s been awesome because I can just take these, these expectations that I have and futz around with them until they align without getting lost in the, the nitty-gritty of, of how things work. That’s not to say that the nitty-gritty isn’t important and understanding those concepts is important, but it’s, it’s great to be able to get started without Yeah, definitely.

Matt: [00:39:51] You’re able to take, this is what I know this should look like, and figuring out how to make it look like that versus I have no idea where I’m going and now I need to figure out how to do something in a whole different paradigm.

Trevor: Absolutely. Well, thank you so much, Matt. Uh, let’s, let’s roll into checkouts real quick.

Matt: Uh, I don’t know if you, if you had the opportunity to check out, but, uh, if you want to go first, you know, I could probably come up with something.

Trevor: So I’m gonna, I’m gonna recommend this, uh, this new microphone that Matt got me, which I will cut in the actual name of. When I remember what it’s called. I think it’s the Blue Yeti, and it’s worked a lot better for me than the mic I had before, which is awesome because now I don’t have to have Matt Stratton telling me that I broke his fancy microphone. And outside of that, there was a— I watched a cool movie last night on Netflix called The Machine, and I’d recommend that as well.

Matt: So I actually just moved onto a sailboat, so heated blankets are fantastic. Just, you know, put that out there for those of us going into winter in very cold places. Also, I’ve been reading a book by Brandon Sanderson, the Mistborn series, which is not new, but I’m picking it up, and I really enjoy his writing. Excuse me. It’s fantasy sci-fi in some cases, but It’s really all I have right now.

Trevor: [00:41:15] Cool. We have a newsletter, arresteddevops.com/bananastand. It’s the best way to know about upcoming podcast episodes and cool news with DevOps. We also have an iPhone app if you dig that kind of thing. You can download it for free at arresteddevops.com/iphone. Thanks again to our sponsors. Be sure to visit them at arresteddevops.com/tenthmagnitude and arresteddevops.com/datadog. Thanks to Matthew Walter for joining us tonight. And loyal listeners, if you enjoy Arrested DevOps, we would appreciate it if you would visit arresteddevops.com/itunes and leave us a review in the iTunes Store. We’d love to know what you thought of the episode tonight. Please leave us comments at arresteddevops.com/osswitching. Be sure to check us out at arresteddevops.com or @ArrestedDevOps on Twitter. We’re always happy to get your input, ideas, or feedback at shows@arresteddevops.com. Please let us know if you have any ideas for future episodes. I’m Trevor, @TrevorGHess. We’re Arrested DevOps, and remember, there’s always DevOps in the banana stand.