Event:

Presenter:
James Sweeny
Company:
Puppet Labs

Since Puppet grew up in the *nix world, there is a common misconception that it can't be used to effectively manage Windows. This talk hopes to dispel confusion on the matter and demonstrate that Windows can be managed effectively and easily with Puppet. Along with basic how-tos and tips on working with Windows systems using Puppet, Windows specific issues and caveats will be discussed with effective mitigations.

Presenter Bio:
Learn more:
  • Ready to dig in? The Learning Puppet VM provides you with a safe, convenient virtual environment to get started.
  • PuppetConf 2014 will be back in San Francisco. Developer Day will be held September 22, PuppetConf will be held September 23-24. Save the date!
Transcript:

James Sweeny: Okay, so like Gary said I'm a professional service engineer with Puppet Labs. That means that I do consulting and training. I think some of you are even in my training class this week recently. Hi guys.

So this talk is sort of meant to be very introductory. I'm going to go over some basic Puppet concepts for those of you who might be Windows admins who have never actually used Puppet before. However, I'm not going to teach you how to use Puppet, so those of you who are already bored don't have to leave right away.

We're going to quickly talk about how the Windows agent is set up and installed some of the things you need to be concerned about with that. I'm going to go over the Puppet resource model, how our catalogue works, and basics of types and providers at least for context. You can understand how this works on Windows.

And we'll talk about some of the comparisons between Linux and Windows. How is it really different between these two operating systems? And then some specific challenges on Windows that are kind of unique to Windows resources that just don't make sense in a UNIX environment. And some things about Windows that are really weird that would probably hurt you if you're not careful.

So Puppet on Windows has been around for a couple of years now. It's growing a lot. I've been to some companies where they use Windows exclusively and manage it with Puppet.

We support these platforms. Technically, you might find that it works on desktop OSs too although we don't really support Windows XP because Microsoft doesn't.

So to get it installed it's a really simple basic Window MSI installation. I think any Windows admin has seen the screen that looks almost exactly like this although the logo might not be as pretty.

We have just a simple MSI file you can double click it if that's your thing. It gives you a nice graphical interface with some basic questions that you can answer. Those of you who are more -- I don't want to say real admins -- have this option available where you can just run it from a command line.

And we provide three options. There maybe more than that right now, three different options for things that you can set. Basically, you can run this automatically during your Windows bootstrap process and make sure that your agent is up and can talk to your masters. You can also set the cert name, which I'd say is very important.

So once it's there, it runs a simple Windows service. The screenshot here is from the services.msc screen similar in the one in Linux where you'll be running in a script, Puppet and Windows you just run off the basic Window service.

So on the Windows installer the paths are slightly different, but you'll find that they're pretty similar to the Linux once when you get deeper down. These two up here in the program files directory under \Puppet Labs\Puppet we have a sys and a bin directory. I implore you to never mess with those unless you really, really know what you're doing there's a very good chance that it could bite you.

But be aware that they are there all of the executables and batch scripts that we use to launch a Ruby instance to run the Windows agent are located in here in some way. Again, please don't mess with them.

These ones on the other hand might be a little bit more flexible, depending on what version of Windows you're on you could be in C:\\Program Data\Puppet Labs, which is for versions 2008 and later. If you're on an older operating system like 2003, you'll find it in C:\\Documents and Settings\All Users\Application Data\Puppet Labs. So just be aware of that.

This is actually resolving the app data variable to find where those go. And within that directory we have a var directory and etc directory. This pretty much mirrors what you've got on a Linux machine. The cache data for instance, your cache catalogue, latest report that ran, you're going to find in the var directory as well as any plug-ins that get synced.

So in any Puppet ruv, if you have custom Ruby code it gets synched down to this plug ins directory -- so that's where you'll find that stuff. Generally speaking, you don't need to mess with that. It probably won't hurt too much stuff if you do the agent run will be able to replace it if you mess stuff up, I would call that one a read only if you want to poke around.

And then finally, the etc directory is where we have the actual configuration. Again, very similar to the Linux path it's just been sort of ported to a different base directory in Windows. Your Puppet.conf file, which you probably will want to edit it at some point or at least manage directly with Puppet. And we have the SSL data directory which is where your certificates go. If you ever run into a certificate issue, that's the directory that you want to delete to regen your certs.

Really quick how many people here are currently using Puppet on Windows? That's more than I thought. And how many people are using Windows, but not Puppet? Okay that's about what I expected all right. This is largely for you guys, I think.

So the way that Puppet basically works we have this process of sending data back and forth once or twice between the agent and the master. All of the actual processing where decisions are made about how your machine is supposed to look is done by the master where the agent only provides data about itself, and is responsible for actually applying those decisions.

So whenever you're working in Puppet always keep in mind that this is the flow that everything goes on. First the nodes sends information about itself the master complies a catalogue and sends it back to the agent, which is responsible for actually enforcing the configurations that you specified. Okay?

I would say that this right here is basically Puppet in a nutshell this is one of the most important things that you can understand about it. So for those of you who are new to Puppet if you learn nothing else, learn this.

And then we're actually applying these changes to the system we do this with something called resources, which is a special interface sort of an abstraction that Puppet uses to make it really easy to manage things. So the sort of abstraction layer provides a series of types, which are things like basic objects that you'd want to be managing on your system. For instance, the file type manages files, obviously. And the package type manages packages. You UNIX and Linux admins are probably very familiar with packages. Windows admins maybe not as much, but you probably should be. And of course, services and users and all that classic stuff.

Now, to actually make these changes -- Puppet types are pretty generic. They work pretty much the same on most systems in terms of how you define them. However, the providers the actual key aspect -- these things do all the work. They're written in Ruby and Puppet. If you're writing from Windows you'll probably use some sort of Windows APIs or call out to Windows programs. But these are responsible for checking the status of resources and updating them, okay.

So the providers are really the heavy lifting here and when you want to get Puppet to work on a brand new operating system that you haven't really used it on before, the providers are where you really need stuff to work. Okay that's the part where you might have something extra that needs to happen.

We've done a lot of the work for various Linux distribution we've done a lot of the work for Windows too.

If you guys are trying to get more advanced about this you want to look into writing your own custom providers.

Many of them hopefully for the Puppet native types although we've got those pretty well covered I think, you may want to write your own at some point for other things which we'll get to in a bit.

So the actual Puppet code looks like this. Here's a simple managing of a couple of resources in Linux. I think even if you've never seen Puppet, if you've never used Linux, if you're a Windows admin you can kind of figure out what this means. We want to make sure that a web server is running. And we want to make sure that a user that needs that service is also available.

So why is Windows special here? What really makes Windows different from Linux in this sense? Like we've got types, we've got providers. Windows has files. Windows has services. Windows has packages. And the answer that you find is it's really not that different in terms of how you conceptually manage your systems. How things are supposed to look? Or what sort of components are there? There are differences. But at least at a superficial level they really aren't that many.

For instance, take the host resource. This is one of our native resources that manages DNS hosts on a machine. On a Linux machine this will edit file this will edit lines in your \etc \hosts file. Whereas on Windows it just edits your C:\Windows\System32\drivers\etc\hosts file. The only problem with Windows here is that they have ridiculously long paths for some reason.

Service is the same, right. You want to have a service SSHD running to have remote access to your Linux system we enable a service like this.

If you want to have remote access to a Windows system -- the only thing that's really different is that you want to have the terminal service running, so that you can get RDP access.

So you Windows admin are probably really familiar with this screen this is what look like for terminal services, if you stop this that's equal than basically of a Linux admin stopping SSHD. This is how people will get graphical access into your system.

And as we can see from this slide it's really the same the same kind of way to manage them. Basically because we have these providers these great providers that are underneath that. You say “service” whether it's Linux or Windows and Puppet can figure it out okay.

So the Cron Resource. Linux admins are very familiar with this. This is how you run things periodically. So how do we run things periodically in Windows? What's our Cron equivalent?

I can't just run this on Windows because Windows doesn't have Cron. We start to see an actual difference here. So the schedule task resource in Windows is what allows us to do the same thing. Both of these slides one that managing this run job.batch file to have it periodically every month wake up and run it. This will work with this trigger there's a number of options here I implore you to check out docs.Puppetlabs.com to see more of them.

Those of you who are my training know that's my favorite website in the entire world. This here will run it monthly. Again and the same thing this job works on both Windows and Linux. But we start to see an important difference here and that there are some key Windows concepts that just don't translate and vice versa. So for these we need to have custom types or special modules that are able to do that.

Now, before I get into showing you some of these I just want to talk about some of the more difficult pieces that just windows has a completely alien concept that any POSIX-based operating system has. And that's the way files are handled.

And the two key ones here are the way that Windows does paths and the way that Windows does line endings. These are the kind of things that you always have to be aware of. And those of you who manage multiple operating systems both Windows and Linux have probably gotten bit by this before even without Puppet.

So the key here, if you remember the slide that I showed before where we were showing the cycle of how the Puppet catalogue is generated, where the master is making decisions about how things are supposed to look and the agent is applying them.

You need to think whenever you're dealing with a file:
* What is going to be managing this?
* What is evaluating this code that I have here?
* Is the master deciding what the exact text of the file should be?
* or is the agent deciding that?

Because on Puppet only the master can only run on Linux. So you got to have a Linux master that has got a Linux pass and Linux line and this and the master needs to look for things and manage them in that way. But the Windows machine has no concept of that, so always think about that.

So Puppet provides an easy way to translate that especially for things like paths. So take for instance Windows loves to do this backslash thing instead of forward slashes, which I think is weird, but they do it anyway. Any of these three options are going to work on a Windows machine.

Puppet will automatically translate forward slashes into back slashes if Puppet needs to handle that path. Okay?

Similarly if we use single quotes the backslashes will be disregarded they will be treated like a regular backslash instead of as an escape character.

And then finally if you are using double quotes, which allows for a thing called variable interpolation where escape characters will actually do something. You simply escape the backslash.

Now, all of these will basically work. You should probably try to use the forward slashes if you can, so that you avoid confusion with escape characters maybe your double backslash gets passed into something else that also want to escape backslashes and might treat your second backslashes and escape character or something like that. Its kind like writing a sequel injection exploit actually. So try to use forward slashes when you can except when that path is being read by a Windows machine. Okay?

So for instance here we have a scheduled task that we are setting up to run seejobsrunjob.exe. That string right there for the command is what's going to be passed to the scheduled task. Windows will try to execute that program and it will fail because it won't be able to find that path because that makes no sense to windows. Okay.

So line endings is the other one. Anybody who has ever copied a file from a Windows machine to a Linux machine has probably seen something like this and wondered – “Why does it do that to me it's really annoying?”

The problem here is that Windows uses a character turn a line feed in order to specify what character ends the line, whereas Linux uses just a simple line feed character. So that confusion there is what is possibly going to cause you problems, especially since the Puppet master is running on Linux and the Puppet master if it's generating strings with new lines -- like if you put a backslash ending your code -- that's going to end up creating a regular line feed as opposed to a character turn line feed.

So you need to be aware of how that might come back to bite you just keep in mind remember what I said before. Think about where this code is being evaluated: Is it the windows machine that is looking at this? Or is it your master that is looking at it?

Now a great way to get around this. You can't really use files dynamically this way, but the file resource in Puppet, which if you use the source property will copy everything down in binary.

So it doesn't matter what kind of line endings you have it doesn't even matter if your file is not ASCII text, the source essentially will copy it down perfectly. Content on the other hand, which generates these templates, if you have code that is generating actual multiple lines in there it will use Linux-style line endings not Windows ones.

Okay, so one possible way that you can get around this if you are not generating the code is to use the -- or even from the source -- is to use the UNIX-to-DOS utility on your machine, and that will convert the line endings to Windows style. Just keep in mind that you are going to need to keep separate files for your windows machines then you use for your Linux machines. So if you have services that use both and they aren't going to be aware of the line endings you need to be aware of that, okay.

The other part is file permissions. I like to write on windows a lot, a lot of people do I think, but Windows file permissions are actually way more versatile than Linux. You can do things like include groups within groups. The ACLs are much more obvious. You are really only dealing with NTFS, so you don't have like the different conflicts between what kind of file system you are running and how does it handle ACLs?

So in Puppet to specify these, you still use a UNIX style mode this is because the file type is what's aware of -- is what's specifying what that's going to be, not the provider. The provider doesn't check to see that you have a valid -- that doesn't check the validity of the mode or anything like that, the type is going to do it.

So you're still using a Unix style modern in Windows. And if you are going to specify any owner or group to own a file you need to specify that using that Unix style mode, which is actually not as bad as you'd think. This piece of code here sets the owner, administrator, and the group users on a given file with mode 644, which to you Windows people that means that the owner can read and write and then everybody else can read. And here is what that is basically is going to look like. We have the users group that is able to read and write okay.

So the last one is the permissions. Be very careful of the case of your files this one gets interesting because Windows is case-insensitive while as Puppet is case-sensitive. So if you define a file as having a certain case and it exists differently on your target system, Puppet will think that the file doesn't exist. And then when it tries to create it will be recreating that file. So watch out for case. Just try to keep it consistent. Pretend that Windows is a case sensitive file system when you are doing this it's going to make it a lot easier if you are just solid with that.

And then the other thing you can't set a SID on a file. Okay, you can set things by user name and Puppet will use the Windows tools to resolve that. But there isn't current a way to actually set the SID directly on the off-chance that you actually care about that. I really run in places where people actually do.

So the Exec Recourse. This is something that Windows admins will typically resort to, whenever they need to change something. You know the types and providers might not be enough the ones that ship with Puppet. I think generally they are great for a lot of things, but a lot people just say I need to run this command this is how I do things.

If I change my application host configuration on my Windows machine I need to restart my IIS server I need to run the IIS reset command. So here we have just a simple exec, notice that the path here is using forward slashes. Puppet is interpreting that path for where it's going to look up the file and that will run C:\WINDOWS\System32\ IISreset. Okay and this will happen anytime that that application host doc config file is updated. This will reload the configuration.

Now another important thing to note here is that Exec does not run with ncmd.exe. Okay it's not a regular -- it's not like invoking a shell and running its just running the command directly. So if you need to use shell built-ins you are going to need to do something like this say command/C and then run the dir command, which is not actually an executable, okay.

So along those lines, there is kind of a small problem I need to keep you aware of is 32-bit Redirection. So you may have run into this on your Windows systems without Puppet where you have a 32-bit program and you are trying to run a 64-bit executable with it. So Puppet runs in 32-bit on Windows, there is a problem to do with the way the Ruby works. So we have to run it on 32-bit on Windows, if you are running on a 64-bit system and you want to execute a 64-bit application, Windows will actually automatically remap -- because they are so nice to you -- They will remap that executable to point to the 32-bit location even though you want to run the 64-bit one.

And we are not talking about running the actual executable within Puppets name space, or within Ruby itself, we are talking about starting a separate shell to execute it. So Windows will see that it's a 32-bit app that's running it, and even though you are trying to run a 64-bit application it will try to look for the 32-bit one. And in many cases you are going to see that you got, you can't actually find that file. I have seen this bite a lot of people.

So the workaround for these Windows provides this Sysnative directory where if you call an executable directly from there it will avoid doing this file system redirection. So it will actually try to run the thing that you really do want to run instead of the one that it thinks that you probably want to run. So that's a really useful workaround I think to be aware of.

So Powershell is all the rage right now. I think it's like god's gift to Windows admins, it makes it a lot easier to do a lot of things and if Powershell gets a lot bigger its basically going to almost maybe possibly put Windows on par with Linux. The rest of you please don't throw thing at me. So here is one way that you would execute a Powershell command. Those of you who have been running them from a sell before know that you know you have to set the execution policy to remote signed, so that you don't have to actually see your script cryptographically signed before you execute it which I guess is just a pain.

So here we run Powershell.exe, we set the execution policy, we pass an argument of the file that we want around which contains our script, and we get the path of where the Windows -- where that actual script resides, or where that Powershell binary resides, okay. This is kind of a mouthful it's not really easy to look at a code like this.

Fortunately, Josh Cooper who's sitting right there in the third row who would like to answer questions about it by the way, we have a Powershell Exec Provider, which allows the Exec Resource and Puppet to natively run Powershell code. You don't need to put all that crap to say remote execution policy and all the full-path to the powershell.exe. We can just pass commands directly into the Exec.

So if you are writing execs in Windows and if you are writing execs in Windows you are probably using Powershell to do a lot of your execution. I urge you to check out this provider, it's awesome. It's going to make your life a lot easier, and it's going to make your code easier to read.

All you have to do is set provider Powershell in the Exec after you've installed the forge module.

And since I'm taking about forge modules, I think it's important to note here, just because something needs to be a module I don't consider that to be a flaw in Puppet.

It's a really good idea I think to have as many things modularized as possible in fact. I would argue that we have too many things in code Puppet and more of them should be modules. Especially when you are talking about esoteric platforms like Windows or AIX or something, you don't want to build that into core unless it's something that really applies to every operating system. So when you have Windows specific things that you want to manage that don't make sense anywhere else, you should probably write that as a separate module and not try like actually edit core Puppet or something like that. Okay?

So those of you who don't know about it, I hope that nobody doesn't know about it at this point because this is PuppetConf. Check out forge.puppetlabs.com. Or use the Puppet module tool to search for modules and then install them. There is a lot of really great Windows modules out there.

For instance, this one Puppet Labs registry. So next to Execs this is probably the most common way I have seen people try to manage things in Windows now it's just using these registry key. Thank god I haven't seen too many people running execs to manage the registry. This registry type and provider allows you to set keys like here HKEY Local Machine, system test key we make sure that that registry key exists or we make sure that it has a specific string value because the string value is very important to have on our systems right now.

Simplified to that there is a defined type called registry value that sort of does the whole thing and you can make sure that this whole specific registry path actually exists there. Commonly, I find on Linux machines you want to do everything with files right, all your configs are in files, in windows I won't say all, but many of them are in the registry.

And, so instead of going package files services you're on a Linux machine you'll often find yourself going package registry service on a windows machine. Okay?

And it's just simple registry key those of you who don't know what I'm talking about when I say registry you probably know what I'm talking about right now. It's that big messy thing that's really disorganized in windows, but somehow make everything break. So this here will just set that registry key like this.

So another really cool one is this adenning/winntp module on the forge.

This is really simple just sets what your NTP server is supposed to be. This is what I think the interface to managing things in windows should look like. You grab a forge module and you just say I want this winntp class and I want it to have these settings. I'm done. You don't need to think about any of this. I don't need to tell you that under the hood in this module is actually editing the registry to set that value. How many of you really want to dig into the registry anyway to try and find where something is supposed to be set? It just makes it a lot easier.

This one here from simondean sets up a package -- sorry a share on a Windows machine. So this will share the p:\\ drive outs, so that in this example to have repositories available.

And you will see why it is really important to set up some sort of external share in Puppet that might hold packages when we talk about how windows handles actual package installation.

Another really good one, this one came out just recently from Tom Linkin, one of our PSEs to handle domain membership on a Windows system. It's an unavoidable fact that when you are trying to manage domain membership, you need a service account and you need to somewhere expose that password in your automation. So that's what we have out here.

I would suggest that you use something like an encrypted backend like Hiera or something to actually manage that password, but here we just set what the domain membership of our machine is supposed to be.

We're going to have -- our machine must be a member of example.com and we are going to use this service account to do it.

There is a couple of extra really neat features of this that will allow you to do things like change the computer password. I don't know if any of you have ever had to do that on windows, I know that I have and that's a pain. But some cool things like that. So also a good one to check out.

Many more of these modules are available, there is no time to talk about them all. In fact I think since yesterday when I last checked my slides a whole bunch of new modules have been added. Actually this opentable/iis one was just been added today when I talked to the guy who wrote it and told him hey you should put this on the forge. Paul Stack by the way, a really smart guy.

We have a SQL server module that manages SQL server. Adenning also made of Windows facts module. This one is great for managing actual facts, particularly on desktop machines. You will get things like what kind of monitor is attached and how the video card works and interesting things like that that are really useful for a windows desktop.

And also this MSUAC class that does the first thing that any Windows admin ever does is disable UAC. Linux guys who have ever troubleshot SE Linux now are also laughing at this because they know the exact same pattern.

Search for windows on forge.puppetlabs.com. I bet you that by the time my talk is finished there will even be more modules up there. People are constantly working more and more on windows and the more you guys contribute to it the better it gets for everybody.

If you are lucky, people will contribute back to your modules and it will make everybody's life a lot easier.

So really quickly I want to talk about packages. This is kind of a weak spot for windows generally. We have -- I call it the MSI Package Provide, because prior to Puppet 3.0 this was the way that you could manage packages. We say that we want MySQL installed and we give a source MSI file to grab the installation from.

You can also specify specific install directories or arguments using the install options type. That's one of the few things that are Windows only.

As of Puppet 3.0 we have a special built in Windows package provider. It's selected automatically, you don't need to tell it to use it and it can natively support exe and msi.

A backport is also available on the forge, so that you can use this Windows type in provider on Puppet 2.7, okay. So please don't use the MSI provider anymore. If you are on Puppet 3 or older, the Windows one is much better.

Unfortunately, it still kind off give us a problem right. Linux is really easy to manage packages, you don't need to pass RPMs and debs around to get your stuff installed. You have yum, you have apt-get, you have zypper or whatever things like that. These are versionable, they are upgradable, it's easy to change between versions.

Windows finally has something very similar written by Rob Reynolds, who is sitting over there and would also love to talk to you is a tool called Chocolatey that is basically apt-get for Windows. And you can use Chocolatey to actually directly install these. Kind of unrelated to puppet.

Rob by the way is going to have a couple of talks later. He will have a hands-on demo I think at 3:20 tomorrow where you can go and check and play around with Chocolatey.

Now, Rich Seagull over at the International Securities Exchange where they are using Windows very heavily is actually written a provider and Puppet for Chocolatey.

So this right here just as easy as installing a package on Linux, you have a way to install packages on Windows. This makes sure that sysinternals is installed and any Windows admin should have that installed.

Okay, now really quickly I want to talk about this DISM thing, I think I'm running a little bit low on time, this is essentially the roles and features that is in Windows 2008 and later. The puppetlabs, DISM module will help you manage that. Do things like install DHCP Servers or DNS servers. Really simple like this, here we are installing dot net, DISM NetFx3 ensure present, piece of cake right?

The DISM, the underpinnings of this are probably going away pretty soon. Microsoft is going heavily on power shell towards this. So I suggest you also check out the opentable namespace on the forge. Just last night Paul Stack released a Windows feature module that does all of this using native power shell.

So the one last thing that I want to talk about real quick is rebooting, which is a thing that is kind of pinpoint that is kind of unique to Windows users, where you have to reboot after every single freaking thing.

Here we have just a simple exec that calls shutdown.exe; and has a machine power off in five minutes. Or has a machine restart rather in five minutes. This can be a problem for instance, if your catalogue is still running while that happens, you are also kind of guessing and hoping that the restart is going to happen at the right time. There could be different dependencies that could force you to restart in the middle of your process. Say for instance, you are installing SQL server, it wants to reboot and then you need to do something else after that. How do you handle not trying to manage those resources later in the catalogue? This is actually not going to cut it.

So some people argue that actually rebooting is actually an orchestration problem and even if it is necessary to do tons of reboots in Windows for configuration, you should not have to have something automatically restarting your system.

I often agree with these people, so a typical approach to this is to have a simple exec that really doesn't do anything. That just says we have a reboot pending, have that set to be refresh only and no op true.

That means this exec will only ever find its way into the catalogue where it actually needs to run. If something else before it has changed in this case say a driver update came through we need to reboot the system.

Now I say noop true because this exactly doesn't run anything. And instead gives us a little option, the report to say there is a pending change on the system. And we can see this part if you are using the puppet enterprise console or a puppet dashboard and I think Foreman does something similar – that will show you that oh this machine needs you to do something and when you look at the report you will see it needs a reboot.

Probably still not the best way and, so Josh Cooper again saving the day has given us this Windows Reboot Resource. This will actually call the shut-down command, but before it does, it will abort applying the Puppet catalogue. So any resources that have not yet been managed, Puppet will just give up on them, it will exit the catalogue run. It will submit its report, and then the machine will reboot at a certain time. We can start this to be interactive, so that people can stop the reboot if they are using the system at that time that it comes up too.

We are really looking for feedback on this. So if anybody has reboot problems please tell Josh, please tell anyone at Puppet Labs. There are tickets on projects that you can update. We want to know what the best workflow for you is for how you are supposed to do this kind of reboot. I think everybody has a different opinion on the best way to do this.

So some more great resources that are out there if you go to docs.puppetlabs.com/windows that's all the documentation or most of the documentation that we have right now for Windows in the core type.

You will find that I probably plagiarized most of my talk off of that web page, so it's a really good one to check out.

Also check out our type reference. This explains how the Puppet core types work on both Windows and Linux, but all the details that you need to know about the Windows providers are often there as well.

There is a great blog post. I think there is a couple of blog posts and some web casts that we have on our web page if you want to see more about that information.

And not related directly to Windows, but I suggest you also check out the Puppet Types and Providers book by Dan Bode and Nan Liu. Nan is actually going to be here tomorrow doing a workshop in types and providers, so you might want to check that out. What Windows really needs is more providers.

So you guys know how you are supposed to manage your systems, you got to write the like people rating those providers will make the ecosystem better for everybody. So definitely worth checking out.

And that's it for now, I hope to field some questions.

There is a mic over there if anybody wants to step up and ask me something or if you want not to ask questions, so we can leave early. Just step up to the mic please if you have a question. Sorry I'm making you walk.

Male speaker: So you talked about ACLs and that they are not particularly handled, there are some cases where you do need to handle more complex ACLs. I wonder -- Do you see that being better implemented with the new type or some sort of complex implementation of the same -- of a provider for the file type?

James Sweeny: Are you reading my mind, yes. I think that a new type is probably the best way to do that. I haven't seen anyone do that. Complex ACL's is kind of a tricky situation in Linux as well where we don't have a way to sort of need if we manage these. So how do you extend those types. It's my personal opinion that a separate type would be the way to do that and if you're writing the type to have an auto requires on a file that you're actually managing. I think that that would be the best way to do that it just doesn't exist right now right. Thank you for that question.

Male Speaker: Are you able to run both Linux clients and Windows clients from either the same tree or different environments in that tree?

James Sweeny: Yeah, absolutely. I mean the puppet master is what is making these catalogue accomplish decisions. We just want to make sure the code that will only apply successfully on Windows doesn't end up your Linux machines.

There's all kinds of conditional logic and stuff of their woe for that. I've never seen somebody who actually has a separate Windows-only puppet master versus their Linux-only puppet master thank you.

Male Speaker: I have to admit I'm a Windows admin.

James Sweeny: I'm Sorry.

Male Speaker: Yeah I know. I get that a lot. I have some problems with Puppet in that I have to manage -- or replicate in Puppet with classes and groups the same thing that I do in the Active directory where I really like a puppet to be able to read what I've already got set up in Active Directory for maybe groups the computer belongs to is there some sort of way that I can use that to factor into my modules that I'm writing to say alright if you're a member of that group do this.

James Sweeny: So really quick what do you mean by groups on the systems? You're talking about like you have certain groups that need to have certain configurations settings applied for them?

Male Speaker: Not local groups no.

James Sweeny: What's that?

Male Speaker: I'm saying active directory security groups if I put it.

James Sweeny: With the all the computer.

Male Speaker: A lump of servers that are part of an App tier okay, I want that to mean something in a puppet rather than me have to do it in the AD and then do it in the puppet council.

James Sweeny: So you're talking about oh for classification okay yeah. There is I believe a Hiera LDAP back end, and there may be maybe not if there isn't one could be easily written. But what you want to do is to have Puppet talk to LDAP and get that information out. And I think that's certainly doable although I haven't seen a direct example of it I would off the talk my head say that's the best way to approach that though.

Male Speaker: Okay, thank you. [inaudible] there's going to be support services for any modules out there the two things I came across is one for the users resource they use the UID to be the SID, but what if you're using active directory for a shared environment, so that the Linux is configured to be the paired module going to the adapt covers environment and, so suddenly your SID you actually have a UID for the Linux and you also have the SID, but it's called the UID?

James Sweeny: Actually yeah, so you don't want to, what you probably want to do is try to not set that like have a condition and your puppet codes what's undef on the windows machine and then leave it that way on the Linux machine, a puppet on Windows will not actually connect to active directory to make changes to the user accounts, it just changes the users as they already exist on the system and in fact there are user resource here also only manages the local system users. Now, it can use like active directory users to apply changes to a file or something like that, but it can't actually make any changes in the active directory on the manage note.

Male Speaker: And then another thing too I was wondering if there's going to be a future support of this or if there's a module out there and the community is as for their Windows services, there's unlimited number of what they call that entities for the service type. And one of the things that is very important to me is, for example, we have rabbitMQ on a Windows box we have insert and install like SPM for that and for the service and configure that and then there's other things because we actually have to configure the ACLS on the services and that's just required for like you know it's not where the services ASP. Net stack.

James Sweeny: Yeah I believe there is I believe there is a feature request out right now on that I'm not sure what the actual road map for providing support for that is, but I would agree with you that that's pretty important.

Male Speaker: Okay and then there is one last question for Cooper.

James Sweeny: Yeah that's definitely one for Cooper I think he easily likes dream stop time for talking.

Male Speaker: For that power show I saw that it was really awesome and I was wondering in our environment we have a requirement to set the dot net run time environment explicitly for which power show executes under. And so that's different as in Windows they have there not forward, backwards compatible you have all these .Nets lying around and, so we have to specify particular dot net environment for the power show execution environment?

James Sweeny: Alright there was one that.

Male Speaker: And I was wondering if we could configure that?

James Sweeny: There's a command line argument to powershow.exe when you do that?

Male Speaker: No it's actually really nasty you have to set up an XML file inside the directory and then put some XML definite.

James Sweeny: That does sound a broke arm, I don't know the answer to that I'm sorry, but I'll look into that.

Male Speaker: It will be like a feature request, it was not there for that module?

James Sweeny: Yeah, yeah I think definitely I mean projects offer thelabs.com you guys can file any feature request on this stuff and then we'll definitely look at them our community is. Again this largely Linux and Unix, so always looking for feedback from people who live in trenches and windows like I fortunately got out of that life a long time ago right.

Male Speaker: Does puppet apply work on Windows and if it does it alter how templates work with line endings?

James Sweeny: I'm not sure about the templates actually I haven't tried that, but Puppet apply definitely does work in Windows. I would give it a shot that's the easiest way to find out.

Male Speaker: And I actually have a new Windows machines work you know just [Inaudible] [0:35:41] -

James Sweeny: No I thought you were one exactly anymore?

Male Speaker: I think is more of a future request, but currently there is no way to install the Windows agent with the cloud provider?

James Sweeny: With the yeah, yeah.

Male Speaker: That's my use case.

James Sweeny: I'm not sure it that's something on projects at thelabs.com for that right now, but that should be added.

Male Speaker: There is a ticket.

James Sweeny: There is okay yeah cool, so I.

Male Speaker: [Inaudible] [0:36:17].

James Sweeny: Okay yeah, so Josh say's there is one I would log on and add a plus one to that if you're very interested. I think we're still trying to gauge what interest lies on cloud provisioner and what people want what really want out of it.

Male Speaker: Thanks.

James Sweeny: Okay, so there's my contact information up there if you guys have many questions feel free to email me, if you're like James you're just a client-facing person I don't want to talk to you for me and the Josh I would be happy to do that too and you blow up his inbox.

You can yeah you're very welcome you can find me on irc as supercow or you can hit me up on twitter. I'd love to talk to anybody or answer anything more about this after and of course I will be walking around feel free to get me.

Paul Stack by the way is doing a talk later on his actual like in-the-trenches experience implementing lots of stuff with windows and power shell. Rob the author of Chocolatey now pop at labs he's going to have two talks later and I'm sure that Josh as well anybody would love to talk to you more about us, so feel free to grab me or them or anything like that if you'd like to know more. So thanks everybody.

[0:37:23]

[Audio Ends]