Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question
add comment

8 Answers 8

up vote 4 down vote accepted

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.

share|improve this answer
    
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 Oct 15 '12 at 13:33
2  
@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. –  sysadmin1138 Oct 15 '12 at 13:57
add comment

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.

share|improve this answer
1  
Fortunately I'm not passing around financial data anymore :-) This is automation for a college. Much lower pucker factor. –  Matt Simmons Oct 15 '12 at 13:57
add comment

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

share|improve this answer
add comment

PowerShell server lets you SSH in to a Windows server and get a PowerShell console. I haven't used it beyond the free trial, but my informal use proved to me it was a fairly reliable product.

share|improve this answer
    
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. –  sysadmin1138 Oct 15 '12 at 13:51
add comment

How gross do you want to feel afterwards, because there's always telnet :)

Seriously though, why do you need the Linux server to call the PowerShell script? Can you redesign your workflow so that the Linux server simply delivers the correct boot.wim image via tftp to a PXE booted host? I've had good luck in the past keeping a Windows image with different answer files on a Windows file server and delivering a custom WinPE boot image using tftpd from a Linux host. Then, you can have the answer file call the correct PowerShell script and you don't have to deal with cross-platform yuckiness like Cygwin.

share|improve this answer
    
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. –  Matt Simmons Oct 15 '12 at 13:36
    
@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 –  MDMarra Oct 15 '12 at 13:40
    
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 Oct 15 '12 at 13:55
add comment

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.

share|improve this answer
1  
That's deliciously counter-intuitive. I like it. It's a major hack, but still, creative! Thanks. –  Matt Simmons Oct 15 '12 at 14:49
add comment

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.

share|improve this answer
add comment

I work in a large enterprise where this issue is common. For the processes we currently support our approach is to have the Unix systems make Web calls to an "admin" Windows server that's running ColdFusion on IIS. We have classes and functions that are triggered from GET requests which use the "cfexecute" directive to launch specific powershell scripts. It's ugly but it works. We're looking at the powershell v3 Web service features to migrate away from having ColdFusion acting as a middleman.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.