Re: [ansible-project] Running on Windows

[Michael DeHaan]

I honestly don't know.

I'm open to patches to make this possible where it makes sense unless
it starts looking ugly.

-c ssh may work ok out of the box, I would think it might.

There is a bit on the internet about paramiko.

We do some things with files that are probably not using os.path.join
everywhere but IIRC python is generally cool about wrong-way-slashes.

--Michael



On Wed, Sep 26, 2012 at 4:44 PM, giulianob <gbar...@aotaonline.com> wrote:
> Is it possible to run Ansibel from Windows? Either natively or even with
> Cygwin would be fine.
>
> Regards

[Darren Chamberlain]

I tried this a few days ago:

C:\Users\darren>python \ansible\bin\ansible
Traceback (most recent call last):
File "\ansible\bin\ansible", line 25, in <module>
from ansible.runner import Runner
File "c:\ansible\lib\ansible\runner\__init__.py", line 21, in <module>
import pwd
ImportError: No module named pwd

pwd is a unix-only module, so it fails immediately. This can be
wrapped in a try/except block, but I haven't looked into what the
ramifications will be. And of course sshd on windows is whole other
story.

* Michael DeHaan <michael.dehaan at gmail.com> [2012/09/26 18:24]:

--
Darren Chamberlain <dar...@boston.com>

[Michael DeHaan]

On Wed, Sep 26, 2012 at 9:49 PM, Darren Chamberlain <dar...@boston.com> wrote:
> I tried this a few days ago:
>
> C:\Users\darren>python \ansible\bin\ansible
> Traceback (most recent call last):
> File "\ansible\bin\ansible", line 25, in <module>
> from ansible.runner import Runner
> File "c:\ansible\lib\ansible\runner\__init__.py", line 21, in <module>
> import pwd
> ImportError: No module named pwd

try/excepting this is totally reasonable.

I think it's going to be a matter of peeling the onion and seeing what
happens along the way. multiprocessing fortunately claims to work on
Windows :)

[giulianob]

I'll try it with Cygwin and see if it works.

Regards

[Michael DeHaan]

On Thu, Sep 27, 2012 at 8:09 AM, giulianob <gbar...@aotaonline.com> wrote:
> I'll try it with Cygwin and see if it works.

Thanks!

I'm pretty sure it won't do something right, what's going to be
interesting is fixing things until it does.

I suspect there may be a handfull of things.

I'd also be interested to see if it ran under ActivePython, and how
many changes that might take.

[giulianob]

Just installed it on Cygwin and a basic ping command works fine. Haven't tried anything more complex. Would be nice if it worked natively but this isn't bad :)

[Michael DeHaan]

On Thu, Sep 27, 2012 at 3:43 PM, giulianob <gbar...@aotaonline.com> wrote:
> Just installed it on Cygwin and a basic ping command works fine. Haven't
> tried anything more complex. Would be nice if it worked natively but this
> isn't bad :)
>

Outstanding.

[giulianob]

I have an SSH daemon on Windows using CopSSH and was trying to run some simple commands from Ansible. It was able to connect and create the /home/user/.ansible folder but couldn't send the file over with the command. I didn't try with plain SSH but I am curious as to what mechanism Ansible w/ Paramiko uses to transfer files?

Regards

On Wednesday, September 26, 2012 6:24:09 PM UTC-4, Michael DeHaan wrote:

[Michael DeHaan]

On Fri, Sep 28, 2012 at 1:55 PM, giulianob <gbar...@aotaonline.com> wrote:
> I have an SSH daemon on Windows using CopSSH and was trying to run some
> simple commands from Ansible. It was able to connect and create the
> /home/user/.ansible folder but couldn't send the file over with the command.
> I didn't try with plain SSH but I am curious as to what mechanism Ansible w/
> Paramiko uses to transfer files?

It uses sftp.

[Michael DeHaan]

I don't have the resources to look into this right *now*, but I'd be
VERY curious if a native WMI transport was possible to add. I'm sure
it is.

We don't really have a lot of modules for managing OS X, so I can't
assume Windows would be an immediate thing, but some basic control
seems like it would be super easy to do, and we could probably retain
our ability to not require any (non-native) daemons if done correctly.

Most modules in core use python, obviously, but there's nothing saying
there couldn't be some powershell daemons on the side with a "win_foo"
prefix.

--Michael

[Michael DeHaan]

On Fri, Sep 28, 2012 at 2:12 PM, Michael DeHaan

Correction -- I don't mean "daemons" here, I mean modules.

>
> --Michael

[giulianob]

Do you know of any resources about how to remotely run commands from linux -> win?

I see this here that seems easy to use: http://mpov.timmorgan.org/winexe-on-ubuntu

Regards

On Wednesday, September 26, 2012 6:24:09 PM UTC-4, Michael DeHaan wrote:

[giulianob]

Got a basic ping/pong command to work by doing an openssh install with Cygwin instead of using the prepackaged ssh servers for Windows. Very neat.

On Wednesday, September 26, 2012 6:24:09 PM UTC-4, Michael DeHaan wrote:

[Giuliano Barberi]

I used the python install from Cygwin and not the one from Windows. 

On Tue, Nov 20, 2012 at 6:28 PM, Peder Jakobsen <pjak...@gmail.com> wrote:

Hi, I'm also trying to get this going on windows,  I would love to know how you got rid of the error:

 

File "c:\ansible\lib\ansible\runner\__init__.py", line 21, in <module>
>       import pwd
>   ImportError: No module named pwd

 

Did you install some dependencies to make pwd work, or did you comment out code in a .py module

--
 
 

--
Giuliano Barberi

[Peder Jakobsen]

On Tuesday, November 20, 2012 9:32:02 PM UTC-5, giulianob wrote:

I used the python install from Cygwin and not the one from Windows. 

 

Thanks, works great now. 

 

For the sake of the project gaining more traction, it would be good to be able to easily install Ansible on Windows

[Michael DeHaan]

>
> Thanks, works great now.
>
> For the sake of the project gaining more traction, it would be good to be
> able to easily install Ansible on Windows

I would love to lose some traction :)

[Peder Jakobsen | gmail]

LOL. Does this mean that you have a regular day job and are just rolling this on the side for fun?

--

[Michael DeHaan]

>
>
> LOL. Does this mean that you have a regular day job and are just rolling
> this on the side for fun?

Not entirely for fun (I really needed a more manageable Func and a
simpler Linux CMS, and wanted to solve deployment problems for future
use), but it's not a business. I do use many pieces of Ansible, but
not as much as many folks on this list -- but yes, we've achieved so
much growth that I wouldn't mind accelerating a bit less! Thankfully
I think the core is *mostly* done and most of our future activity is
going to revolve around modules and keeping up with the distros.

If you want it to work well as a client program on Windows, the best
way to do that is figure out how and make it happen. I don't think
we'll ever
be managing Windows machines in the core code, that seems very
round-peg, square-hole, and would detract from the core mission.
Though if
there's a patch here and there to make Cygwin happier, or a line or
two to put into the docs (docsite/rst/*.rst in the main project) that
would be good
to have.

[Brian Coca]

Soo no integration with the MMC anytime soon?

--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001

[Peder Jakobsen | gmail]

On Wed, Nov 21, 2012 at 9:37 AM, Michael DeHaan <michael...@gmail.com> wrote:

>
>
> LOL. Does this mean that you have a regular day job and are just rolling
> this on the side for fun?

the best way to do that is figure out how and make it happen.  

 

Ofcourse!  It's obnoxious to expect an open source project to just give and give without giving anything back.  :)

 

I'm working on a large project with people from around the world (CKAN.org).  It is a pylons based web app + SOLR (java) which is gaining traction quickly, and we have just started assessing Ansible as our main devops tool.   Hopefully we can colloborate to give the communcity something useful in return, but in due time because we have many other fish to fry.

 

[Brian Coca]

It doesn't hurt to ask, but expect to receive at the mercy of the author + contributors. 

Unless many windows admin contributors appear I don't see windows support in the near future. The majority of ansible users (and contributors) are running Linux, mostly RHEL and derivatives. 

Support for other distros/platforms depends on demand among contributors, expertise, the ability to make patches that don't break other platforms and are able to meet with the approval of the original author.  

The code is generally easy to expand for different platforms, with current efforts to make it even easier, but most platforms are unix like, windows is a big departure and might not be that easy to integrate.

[Michael DeHaan]

>
> Unless many windows admin contributors appear I don't see windows support in
> the near future. The majority of ansible users (and contributors) are
> running Linux, mostly RHEL and derivatives.

It may not be a majority, but it's a large group.

We have a pretty large amount of Debian/*BSD folks now, and some
amount of Solaris.

We definitely don't have many people managing OS X though.

[Peder Jakobsen | gmail]

Let me clarify.  I'm not interested in managing windows servers, I merely want to administer my remote *nix servers from Cygwin or some other console. 

If I can make it work, I'll contribute a recipe.

--
 
 

[Michael DeHaan]

Hi,

This is nice.

My suggestion would be rather than creating the ansible-win, we try
and get these changes encapsulated in utils and other functions, using
try/except ImportError and so forth as neccessary.

This will prevent the need to dual maintain these in the future.

Can you make this happen? If so, that would be outstanding.

ansible and ansible-win do not look that different, in other words,
and you've got most everything abstracted elsewhere.

Obviously we'd want ansible-playbook, and hopefully ansible-doc, too

Thanks!

--Michael

On Thu, Jan 24, 2013 at 10:11 PM, Shlomo Zippel <shlomo...@gmail.com> wrote:
> Hey guys,
>
> I just checked in an initial version of the client running natively on
> windows (Without Cygwin or ActivePython):
> https://github.com/shlomozippel/ansible/tree/windows
>
> I only sanity tested the ping command, and I had to rename ansible to
> ansible-win.py (the script needs .py extension in windows for
> multiprocessing module to find it, and it can't be called ansible.py because
> then 'import ansible' finds the script instead of the package).
>
> I will spend some more time on this in the next few days/weeks but just
> wanted to let you know about it.
>
> - Shlomo

> --
>
>

[Giuliano Barberi]

That's awesome I will try it later. We will probably need to create commands that play nice with ms install too

On Jan 25, 2013 7:47 AM, "Shlomo Zippel" <shlomo...@gmail.com> wrote:

Hey guys,

I just checked in an initial version of the client running natively on windows (Without Cygwin or ActivePython):

https://github.com/shlomozippel/ansible/tree/windows

I only sanity tested the ping command, and I had to rename ansible to ansible-win.py (the script needs .py extension in windows for multiprocessing module to find it, and it can't be called ansible.py because then 'import ansible' finds the script instead of the package).

I will spend some more time on this in the next few days/weeks but just wanted to let you know about it.

- Shlomo

On Wednesday, November 21, 2012 8:42:41 AM UTC-8, Peder Jakobsen wrote:

--
 
 

[Michael DeHaan]

On Fri, Jan 25, 2013 at 7:58 AM, Giuliano Barberi
<gbar...@aotaonline.com> wrote:
> That's awesome I will try it later. We will probably need to create commands
> that play nice with ms install too

If you're talking about managing windows from ansible, that's another
animal entirely, and would theoretically require something like a WMI
transport type to maintain the 'no bootstrapping' philosophy.

I am not entirely convinced Windows admins really want this, or that
various attempts of traditional Unix tools to fit in that space are
accepted by Windows admin teams.

This is why we don't do it.


--Michael

[Giuliano Barberi]

I have both windows and Linux servers. I love ansible and find the windows management environments overkill for most things. I would definitely like to use ansible to manage windows if possible.

[giulianob]

Sorry got confused though that this was running ansible from windows to manage linux not windows management :)

[Shlomo Zippel]

On Fri, Jan 25, 2013 at 4:47 AM, Michael DeHaan <michael...@gmail.com> wrote:

Hi,

This is nice.

My suggestion would be rather than creating the ansible-win, we try
and get these changes encapsulated in utils and other functions, using
try/except ImportError and so forth as neccessary.

Just to clarify: ansible-win.py is identical to ansible. I had to rename it for 2 reasons:

- windows requires a .py extension, otherwise imp.find_module will not find the script when forking (multiprocessing module does this)

- if the script is renamed to ansible.py, attempting to import ansible from within the script causes the script itself to be imported (ansible.py) instead of the package (ansible/__init.py__)

So I renamed it to ansible-win.py. This is obviously the wrong way to do it, I will try getting setup.py to rename the ansible script when installing in windows.

  

This will prevent the need to dual maintain these in the future.

Can you make this happen?  If so, that would be outstanding.

ansible and ansible-win do not look that different, in other words,
and you've got most everything abstracted elsewhere.

Obviously we'd want ansible-playbook, and hopefully ansible-doc, too

I will be looking at these later today. Hopefully I'll be running full playbooks from windows soon :)

 

--

[Brian Coca]

ansible.bat or ansible.cmd as an additional file that invokes
"python.exe ansible" should also work and avoid the rename.

There might be new nicer ways, but I haven't touched windows in about 10yrs

--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001

Pedo mellon a minno

[Michael DeHaan]

On Fri, Jan 25, 2013 at 4:17 PM, Brian Coca <bria...@gmail.com> wrote:
> ansible.bat or ansible.cmd as an additional file that invokes
> "python.exe ansible" should also work and avoid the rename.

+1 to that.

like "python.exe ansible.cmd $*"

Replacing "$*" with whatever it is windows means all arguments given
to the program in Windows, lest that be $1 $2 $3 $4 ... etc

it's been a while for me too :)

[Shlomo Zippel]

Windows progress:

- removed the duplicate script

- parallel exec working

- ansible-playbook & ansible-doc both working

- setup only installs windows specific scripts on windows

--

[Michael DeHaan]

On Sat, Jan 26, 2013 at 5:02 PM, Shlomo Zippel <shlomo...@gmail.com> wrote:
> Windows progress:
> - removed the duplicate script
> - parallel exec working
> - ansible-playbook & ansible-doc both working
> - setup only installs windows specific scripts on windows

This sounds great!

[Michael DeHaan]

> I've never really done much python reading, but this looks like the ssh
> transport; looks like a class with 5 public methods (I assume a method
> starting with _ is not public...?), of which fetch_file and put_file of
> which WinRM cannot readily support (I gather there are hoops to jump through
> to get or put files to windows boxes - this guy explains it better than me,
> search for "share"). That might be a reasonable thing to create a winrm.py
> equivalent, or am I missing something fundamental?
>

I think there are probably going to be reasonable simple ways to ship
Powershell to a remote box and execute them.

Trick is doing it nicely, in a way that does not require installing a
Ruby (or other daemon) on the box -- and just using, say, the .NET
framework.

--Michael

[Peter Mounce]

That's just it, though, without ****ing around with network shares, I don't think there are ways to send scripts (as in, script files, which is how I read your reply) to the victim boxes to run.

However, to run just commands, one doesn't need ruby etc on the box, just to have winrm active and listening, which one can do via winrm quickconfig (in its most basic form) or active directory group policy so it happens when a server joins the AD (assuming there is one).  winrm commands can then be anything; cmd invocations, powershell cmdlets, whatever - but from what I gather, that part is up to the ansible playbooks, which get written bespoke anyhow. (?)

[Brian Coca]

I haven't done windows admin in a while, but if you are a admin on the
target machine you used to have a share to C: (actually all drives).
So it would be easy to copy scripts over netbios.

Another roundabout way is by setting a policy that downloads the
scripts from a netlogon share.

--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001

Pedo mellon a minno

[Peter Mounce]

Yes, the administrative shares exist, but that requires that port 135 be open for netbios traffic.  Opening netbios on public facing boxes involves living with some security vulnerabilites (not least of which the fact that windows LAN manager still doesn't store passwords securely).  WinRM requires either 5985 (default http) or 5986 (default https) to be open (or whatever non-default one might choose).

Powershell's Invoke-Command cmdlet allows a script to exist locally, and be transformed into a scriptblock to run remotely on the list of victim computers, however: https://blogs.technet.com/b/heyscriptingguy/archive/2012/07/25/an-introduction-to-powershell-remoting-part-three-interactive-and-fan-out-remoting.aspx

[Brian Coca]

Aside from restricting port access to specific IPs the only other
thing I can think of to help you with this is installing an ssh server
on windows. There is even a openssh version IIRC.

[Peter Mounce]

The issue with that is because I (currently) work in a Microsoft environment, some colleagues knee-jerk forbid non-MS methods for doing things when there is an MS-way.  It's ... frustrating, but also difficult to circumvent.

[Dave Cottlehuber]

On 3 May 2013 22:26, Steve Irvine <stephen...@gmail.com> wrote:

Hi,

I know this is a bit old but it's an interesting subject for me.

I managed to cobble together an extremely hacky windows config management tool using powershell. I avoided the need for administrative shares by creating an object which contained the text of the script I wanted to create (by appending together different fragments), then I could use invoke-command in powershell and pass the entire object as an argument to create a new script file on the server. Which I could then execute. Combine it with some modules for different tasks and a for loop and you're away.

It's nasty and I'm not proud, but happy to stick it on github if anyone's interested. Perhaps there's something there that could help make a windows-native andible command path. 

In all honesty my experience trying to do devops on Windows just made me want to work with Linux more. The lack of dependency-aware package managers, the fact that configuration data can live in so many different entities (files, databases, the registry) and the lack of a decent ssh analog (powershell remoting has some funny limitations) make the whole process a lot harder than it needs to be.

Steve

Please post it, yes. And yes, devops on Windows is like trying to brush your teeth using a tiger's tail.

[Romeo Theriault]

On Tue, May 7, 2013 at 1:44 AM, Dave Cottlehuber <d...@jsonified.com> wrote:

Please post it, yes. And yes, devops on Windows is like trying to brush your teeth using a tiger's tail.

Funny. I'd love to have some sort of ansible support on windows though, even if it was just ansible-pull.  One of my last major reasons to need to keep some other  'thou shall not be named' CF management tool around around is for the windows support.

--

Romeo

[Michael DeHaan]

Yeah I think any starting point may be useful for inspiration, I'd be interested in seeing what you had.

Though I do think it needs to not be pull based, nor require ansible installation.. and we need to figure out how to make that work.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Steve Irvine]

Hi Michael,

Ansible is great by the way, I am loving using it.

OK, having cleaned out (hopefully) all incriminating evidence, here it is. There's not much to it but it pretty much follows the no-bootstrap philosophy of ansible.

It is push, not pull based and doesn't need any new software installed, although powershell remoting isn't enabled by default for security reasons so there is still some work to do before it's enabled.

 

https://github.com/stephenjirvine/windevops

Please be kind, I am not much of a developer :). Still it works and is a hell of a lot better than RDPing into 20 windows boxes one after another, waiting for the gui, start->run->powershell etc etc

It would appear that Powershell 3's workflow constructs use a similar philosophy but I didn't know about them when I wrote this (Powershell 3 wasn't out).

When I used it we combined it with a library of powershell modules, but these were very specific to the company I worked for and not much use outside so I've excluded them.

Steve 

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/17YZIgArn2g/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

[Frederik Haesbrouck]

Michael,

I am quite new to Ansible (did some try-outs on Ubuntu before) but thought of using it at my new job: 

They asked me to make a script to install a bunch of tools on Windows computers, as a replacement for some BAT-scripting...

Although I was under the impression that Windows was also supported, I now get the impression (from reading this thread) that it is still 'experimental'...

Did you had the time to evaluate Shlomo's effort?

Could I use the same playbook syntax?

Regards,

Frederik

[Michael DeHaan]

There's no Windows support.

Will let you know when there might be.

All the previous thread comments still apply :)

--

[Sébastien Simard]

Frederik,

I'm not sure what your exact needs are, but FWIW you might want to have a look at http://chocolatey.org or http://coapp.org

- seb

2013/7/3 Michael DeHaan <michael...@gmail.com>

[Brian Coca]

ansible doesn't support windows, some stuff CAN be made to work with cygwin but I don't recommend it as an option.

[Brian Coca]

1 note, with cygwin you CAN use windows as a 'master' and most stuff just works. Windows being a configuration target is what doesn't work well at all.

[Lorin Hochstein]

One of the main blockers is that there is currently no remote PowerShell client library that run on non-Windows machines. I believe it's technically possible to build one, since the spec is documented, but nobody's done it. 

Lorijn

Lorin Hochstein

Lead Architect - Cloud Services

Nimbis Services, Inc.

www.nimbisservices.com

[Greg Zapp]

There are winrm clients for multiple languages.  That should do the trick.

[Michael DeHaan]

Hi all,

We are quite aware of many options to do this.

No need to respond on this very old thread and stay tuned as this is something we want to address this year.