Native windows support

Archives Ansible Developer
1

I have ported ansible to run under Windows, code available at https://github.com/zart/ansible/commits/native-windows-support
Port consists mostly in removing unconditional dependency on unix-only modules like pwd, grp, fcntl, termios.
Module library is mostly untouched.

Requirements to run it on Windows:

  • python 2.x, obviously
  • pywin32
  • paramiko <=1.10.2, due to https://github.com/paramiko/paramiko/issues/193
  • pyyaml and jinja2
  • switch transport to paramiko
  • disable colors
  • you have to invoke python bin\ansible and the like to run extensionless scripts
    I tested ansible, ansible-doc, ansible-playbook. Didn’t test ansible-pull yet. Basic stuff seems to work.

What doesn’t work:

  • running as proper binary/script
    This requires either switch to setuptools (which are able to generate proper .exe/.pya stubs on windows) or renaming ansible scripts to *.py (which is not that pretty)
    And renaming bin\ansible to bin\ansible.py is problematic since import ansible will import script itself instead of the package.

  • colored output.
    Right now it just appends some hard-coded ANSI sequences. Can be fixed by doing proper curses calls on Unix and using ctypes/win32console calls on Windows.

  • ssh/ssh_alt transports
    They’re using hard-coded ssh -tt command-line and lots of openssh-specific options. It either has to be reworked to allow other ssh implementations or new transport has to be written for alternative ssh implementations, like putty, ssh.com, etc.

  • local transport (and local_action)

This defaults to /bin/sh. Should be possible to replace it with $SHELL/%COMSPEC% instead. sudo support can be implemented via runas.
Still, most of the modules probably won’t work on Windows as-is.

  • cows

Haven’t looked if there is a Windows port of cowsay ;D

This also opens opportunity to write custom wmi transport (or module) for configuring windows boxes natively. Cross-platform support is still problematic.

2

That’s not too complicated! Nice.

So I’m somewhat open to entertaining this.

Upon initial review, there is some untyped try/except logic that should be more like HAS_TERMIOS=True / False and then key off that.

https://github.com/zart/ansible/commit/d6bbda7ce1ef4d7cfff21e5a94337b9592decf6e

I would also like to see the os logic moved inside the functions in here, but approve of abstracting the locking code:

https://github.com/zart/ansible/commit/e07480bc4df2ccca443449b5c4d9e9a2756e1b83

Similarly, the same HAS_PWD type import logic should be done here, rather than conditional imports, so imports can remain at the top of the file (as this has some performance disadvantages anyway, not to mention not being as skimmable)

https://github.com/zart/ansible/commit/a581840da51d9efc0f1fd8028aae971c93197f11

example:

HAS_FOO=False
try:
import foo
HAS_FOO=True
except ImportError:
import alternative_foo

I’m not sure about https://github.com/zart/ansible/commit/f8d4276ba0f6e60a0b576ccb368566a222aba49d because I don’t quite understand why this was done, but seems it might cause problems?

In any event, if you are willing to tweak this some, I’m willing to entertain it and test it, though we may need patches from time to time to maintain it, as I’m not quite wanting to say it’s going to be something we test often – I’m much more interested in a management solution for Windows remotes, long term, but i understand this is quite valuable to Windows based vagrant users, so yeah, this could be a good thing.

We should probably add some code where Windows picks paramiko if the connection type is “smart”.

3

That’s not too complicated! Nice.

So I’m somewhat open to entertaining this.

Upon initial review, there is some untyped try/except logic that should be more like HAS_TERMIOS=True / False and then key off that.

https://github.com/zart/ansible/commit/d6bbda7ce1ef4d7cfff21e5a94337b9592decf6e

I would also like to see the os logic moved inside the functions in here, but approve of abstracting the locking code:

https://github.com/zart/ansible/commit/e07480bc4df2ccca443449b5c4d9e9a2756e1b83

Similarly, the same HAS_PWD type import logic should be done here, rather than conditional imports, so imports can remain at the top of the file (as this has some performance disadvantages anyway, not to mention not being as skimmable)

https://github.com/zart/ansible/commit/a581840da51d9efc0f1fd8028aae971c93197f11

example:

HAS_FOO=False
try:
import foo
HAS_FOO=True
except ImportError:
import alternative_foo

Ok, I’ll rework those parts.

I’m not sure about https://github.com/zart/ansible/commit/f8d4276ba0f6e60a0b576ccb368566a222aba49d because I don’t quite understand why this was done, but seems it might cause problems?

I’m testing the code in the virtualenv with ansible checkout. When ansible is installed this way while having {‘ansible’: ‘lib/ansible’} line in setup.py sys.path contains path to ansible’s root directory which break ansible imports.
With the change to {‘’: ‘lib’} sys.path contains correct path to ‘lib’ subdirectory, making gross sys.path.insert(0, os.path.abspath(‘lib’)) hack irrelevant.

In any event, if you are willing to tweak this some, I’m willing to entertain it and test it, though we may need patches from time to time to maintain it, as I’m not quite wanting to say it’s going to be something we test often – I’m much more interested in a management solution for Windows remotes, long term, but i understand this is quite valuable to Windows based vagrant users, so yeah, this could be a good thing.

I’ll try to polish this, but some changes might be pretty intrusive, I think.

We should probably add some code where Windows picks paramiko if the connection type is “smart”.

I’d rather fix ssh/ssh_alt or write another transport to enable the use of plink/putty, but having paramiko fallback on windows should be fine too.