Articles from December 2016 on PowerShell.org - Welcome Automaters!

UPDATE / Tug: The Open-Source DSC Pull Server

Mon, 19 Dec 2016 17:25:49 +0000

If you haven’t taken a look atTug, now’s a great time. Eugene Bekker has been doing a ton of heavy lifting, taking my .NET Core proof-of-concept code and turning it into a formal ASP.NET MVC project.

Tug is nominally cross-platform. Basically, it’s n ASP.NET Core application that can run under any Web server that supports ASP.NET Core, which includes Windows, Windows Nano Server, and even Linux. Tug knows the DSC protocol, so it receives requests from Local Configuration Managers (LCMs) on DSC target nodes.
Tug has no “brains” to deal with those request, though. Instead, it implements a provider layer, and calls upon a provider to deal with requests. A very simple provider is currently implemented, which runs PowerShell commands in response to LCM requests. So, short story, if you can write a PowerShell advance function, you can make your pull server behave in whatever way you want. Store data in SQL Server, if you like, for example.
Because of some hitches in .NET Core 1.0, that run-PowerShell-commands trick doesn’t work well. so to do that you really have to target full .NET, which limits you to running Pull server on Windows Server or Windows Server Core. That should be fine for most folks.
But you can also write Tug providers in full .NET - meaning you can use (say) EF Framework to manipulate target node data.
Presently, Tug doesn’t implement the Report Server functionality - it’s stubbed out, and that’s coming next. And if you’re thinking, “will Tug be able to ____,” the answer is, “yes - if you write a provider layer that lets it do ____, which can include writing PowerShell commands (functions) that do ____.” Tug isn’t intended to lock you into one operational mode. Do you want to store client data in SQL Server, and assemble MOFs on-the-fly? You can program Tug to do that. Do you want to store everything in XML files? You an program Tug to do that. Want to use client certificate authentication for nodes? You can program Tug to do that. Because everyone wants something a little different from their Pull server, Tug’s designed to let you code up whatever model you prefer.
Tug’s an open-source project on GitHub, licensed under MIT, which means you can use it for whatever you want. We’ve got abrainstorming document with ideas, and if you’d like to contribute, that’s a place to start. **And please, contribute. **If you can’t, but you follow someone in the community who might be able to, please draw their attention to the project.

]]>

The Key to Understanding PowerShell – on Windows or Linux

Thu, 15 Dec 2016 15:22:12 +0000

I’ve listened to a few of my Windows-friendly compatriots attempting to explain PowerShell to their Linux colleagues, and it hasn’t always gone well. The problem, I think, is that a lot of Windows folks don’t actually know why PowerShell exists in the first place. Let me explain.

PowerShell _does not exist to automate administrative tasks. _Re-read that a few times until it really sinks in. You see, you start going at the Linux guys with this “automation” argument, and they’re all like, “yeah, man, we’ve had that for always.” The existence of PowerShell on Linux makes no sense if the point of PowerShell is simply automation. In fact, PowerShell as an automation mechanism also _makes no sense on Windows. _Keep in mind that all PowerShell does is built on WMI/CIM and .NET Framework; there was nothing stopping you from using those things in the first place. You didn’t need PowerShell.
The point of PowerShell is that .NET Framework is a terrible surface for systems administrators. Getting anything done correctly in .NET requires you to write an application of some size, compile it, and run it. .NET wasn’t designed with ad-hoc, system-level “scripting” in mind; it’s an application development framework. An empty .NET project starts with dozens of lines of code and configuration; that’s the bare minimum to even start writing code. For admins, it’s too much. Heck, it’s sometimes too much for _developers, _which is why some of them like PowerShell as a “.NET immediate window” so much - they can just bang out a one-liner, hit Enter, and get results.
I’ll argue that all operating systems rely on APIs for command-and-control. If you want to tell Windows to shut down, you need an API to do it. In modern times, that API comes via WMI/CIM or .NET, for the most part. In Linux, if you want to configure Apache to listen to a different port, you need an API. That API comes in the form of a text file. I’ll also argue that, from a systems administration perspective, all APIs suck. In Windows, you’re forced to learn this vast and complex .NET Framework, which is only marginally consistent within itself, and which requires a (relative) ton of code to make do anything. In Linux, you’re forced to learn regular expressions and text parsing, along with a bunch of poorly-interconnected command-line tools that have improbable names invented by Dungeons & Dragons geeks in the 1960s and 1970s. “Grep,” as an API for systems administration, was never a good idea - it’s just what got the job done when your main configuration surface was a bunch of text files.
The entire point of PowerShell is nothing more, nor less, than to wrap a more-consistent, administrator-friendly API around those other sucky APIs. PowerShell is an abstraction layer, and that’s it. Do you know how to conquer up a ServiceController reference in .NET, and ask it to restart a surface? Me neither, nor do I care to learn - I’ll just run Restart-Service, which does all that under the hood. Do you know how to pull a daemon list on Linux, retrieve just the httpd daemon, and restart it? You might, but I don’t, and I don’t care to learn that either - I’ll run Restart-Daemon (which will exist someday, I swear it).
On Windows, PowerShell doesn’t replace .NET. We all know that. It makes .NET easier for an admin to use in the context of administration. On Linux, PowerShell doesn’t replace grepsedawk and all the text files - it simply makes them easier, and more consistent, to use for administration. The point of PowerShell is that it allows us to deal in deterministic data structures (objects) without having to be text-parsing experts. It wraps poorly designed underlying APIs into something with a consistent, admin-focused surface. That’s it.
PowerShell does not posit that, on Linux, grepsedawk is a bad idea. PowerShell simply suggests that those tools, and their friends, are a lot harder to learn and use than they should be. PowerShell’s value-add is not automation - you can do that without PowerShell. PowerShell’s value-add is _better productivity as you automate, _and that’s something anyone should be able to wrap their minds around.

]]>

PowerShell Gotchas

Mon, 05 Dec 2016 00:28:59 +0000

You can certainly find a number of articles around that present PowerShell pitfalls that can easily trip you up if you are not careful. I took a different approach in my three-part series, A Plethora of PowerShell Pitfalls.
The first two parts are presented in quiz format, together covering the top 10 “gotchas”. They will help you test your awareness to see if you even realized the danger and did not know you’ve been skirting those traps for awhile. After you’ve had an opportunity to consider the conundrums presented, I then go into detailed explanations for why they happen and how to fix them.
The third and final part is a compendium of all the common “gotchas” that I put together after reviewing all the other lists out there. The more than 35 entries in the list cover, I believe, a good 98% of the issues you would likely encounter. Yes, there are more esoteric pitfalls as well, but I ran out of web page… 🙂
Part 1: Pesky Parameter Problems
Part 2: A Portion of Potential Puzzles
Part 3: The Compendium