Method to integrate Powershell scripts with non-Windows workflow?

Question

I love the smell of new machines in the morning.

I'm automating a machine creation workflow that involves several separate systems across my infrastructure, some of which involve 15 year old perl scripts on Solaris hosts, PXE Booting Linux systems, and Powershell on Windows Server 2008.

I can script each of the individual parts, and integrating the Linux and Unix automation is fairly straightforward, but I'm at a loss as to how to reliably tie together the Powershell scripts to the rest of the processes.

I would prefer if the process began on a Linux host, since I imagine that it will end up as a web application living on an Apache server, but if it needs to begin on Windows, I am hesitantly okay with that.

I would ideally like something along the lines of psexec for Linux to run against Windows, but the answer in that direction appears to by Cygwin, and as much as I appreciate all of the hard work that they put in, it has never felt right, if you know what I mean. It's great for a desktop and gives a lot of functionality, but I feel like Windows servers should be treated like Windows servers and not bastardized Unix machines (which, incidentally, is my argument against OSX servers, too, and they're actually Unix). Anyway, I don't want to go with Cygwin unless that's the last and only option.

So I guess what I'm asking is if there is a way to execute jobs on Windows machines from Linux. Without Cygwin. I'm open to ideas and suggestions, including "Look idiot, everyone uses Cygwin, so suck it up and deal with it". Thanks in advance!

Solution 1

I've spent hours pounding on this very problem and it eventually came down to two viable options (there are a lot of non-viable options out there):

1. Build a Windows box with an IIS service hosting a WebAPI that is both domained and set up in such a way that WinRM sessions from it will work.
2. Cygwin

With the second option you're stuck fighting your way through the the GNU/Posix abstraction layer to get at the actual windows bits. Which does restrict what you're able to do with it.

The first option pretty much builds a web-based abstraction layer you write yourself on top of your full native-stack Windows install. If you're willing to put in the work, the Linux master-server only has to do a bunch of curl calls to do what needs doing. This works best when scripts are fire-and-forget though, as building a call-back system is a lot more effort.

Solution 2

I would use the Powershell Web Access feature introduced in Powershell v3.0. This allows you to use Powershell scripts from a Linux host.

Solution 3

You can also buy cross-platform scheduling or workflow automation software that can kick off native scripts on many hosts depending on previous actions, or even their returned results. Large enterprises use software like Tivoli, UC4, Espresso (CA dSeries, now) that does this, and I've used it at large enterprises that needed to do this sort of thing. FYI, these often have native support for things like Oracle jobs, to give you an idea of the pricetag you might be looking at.

(In my past job, they also used Cygwin anyway, so that they could use the same Perl scripts without modification when workloads moved between platforms. Lots of fun.)

You could also try to build your own, as @sysadmin1138 suggests; that would be a fun project, and might even end up robust enough to be usable and not get you paged at 2 AM when the financial exports fail on the first try.

Solution 4

On the topic of counter-intuitive hacks, have you considered abusing Continuous Integration software as a cross-platform orchestration tool?

Install the CI master wherever is most convenient, install the agent on your Windows box (either this or this), configure a job to execute your powershell script (either directly invoking it using the Windows Batch Command config, or using a plugin if you want to write/keep your script inside the CI app) on your Windows agent and trigger the job remotely via curl or similar.

Solution 5

You could use something like nrpe to remotely execute the powershell script on the windows host. You might want to modify your powershell scripts to return exit codes as expected by nrpe, but there's no reason you couldn't call check_nrpe from your scripts on your linux host.

View more solutions

Comments

[Matt Simmons]

I was afraid of that first option :-) There's a big shark tank full of issues there, just waiting to bite me if I do it wrong, too. Authentication, error parsing, general application security...etc etc etc. But thanks for the input. I'm glad I'm not the only person who got hung up on this.

[Matt Simmons]

Oh, if only it were that easy. I wasn't kidding about the 15 year old perl part. I've been here for 3 months, and I'm not aware of how all of the interconnections "work" yet, but I know that they are many and varied, with a subtlety that leads people who have been here for years to completely disregard documented features in existing tools developed in-house because no one is sure if/when/how debugged they are. It's hairy. It'll be a multi-year project to fix it all.

[MDMarra]

@MattSimmons I suppose I don't fully understand the requirements then :-) Why does the Linux server need to call the PowerShell script? In the past I've worked around this requirement by keeping machine provisioning info in a database (which can be updated by the *nix server) and then WinPE queries that database when determining which answer file to apply. Surely something similar can be adapted to almost any environment right? It's basically just rebuilding MDT from scratch by yourself heh

[Deb]

Bleh, their pricing is such that it's designed for deployment-server usage rather than 'deploy on everything that needs managing remotely'. Workable, just a different model than Linux.

[Matt Simmons]

There are things that (in some cases) need to happen on the Windows side whenever the new-machine script runs. I COULD start things from the Windows side, but I would need to build a new web application server for the front interface when that time comes, and I'm much more comfortable doing that with PHP on Linux than C# (or whatever) on Windows. But like I said, if I have to, I have to.

[Matt Simmons]

Fortunately I'm not passing around financial data anymore :-) This is automation for a college. Much lower pucker factor.

[Deb]

@MattSimmons I did something similar at $Job-1. IIS IP restrictions make a lot of this easier; if API calls can only come from one host, it reduces attack surface quite a bit.

[Matt Simmons]

That's deliciously counter-intuitive. I like it. It's a major hack, but still, creative! Thanks.

[laughingbovine]

I haven't used it, but from what I've read WinRM can run on its own (without IIS or a custom API). Use restrictive routing and kerberos authentication and it sounds (SOUNDS) like it could be pretty secure. Thoughts?

[Deb]

@laughingbovine The problem has always been WinRM support. The IIS method I propose allows fronting PowerShell with a REST API which is supported by just about everything. WinRM support is barely supported a few places. In the almost three years since I wrote this, that support has probably improved from the non-existent state it was in 2012.