Windows – Using Ansible, how can I take actions on each file in a specific location

ansibleansible-playbookwindows

I'm building playbooks to deploy a Windows application that requires some prerequisites (Visual C++ runtimes and dotNet framework) to be installed before the application itself.
These prerequisites are .EXE files and are all contained in a specific folder.

I want to build an Ansible playbook that would (amongst other things) execute each of the .EXE files in the preriquisites folder with the parameters "/install /passive"

I don't want to have to specify each filename in my playbook.

My idea was to first find the prerequisites setup files using the "win_file" module, assign the result to a variable and them iterate over the variable and run the "win_command" module for each file it contains.

Unfortunately, I cannot assign the win_find result to a variable using the register statement, it simply doesn't do anything.

Here is what I tried:

- hosts: "{{ target }}"

  tasks:

  - name: Find files in path
    win_find:
      register: myvar
      paths: E:\Temp\Prognosis_11.2\Prerequisites

  - name: debug
    debug:
      msg: "{{ myvar }}"

And the playbook's output when ran with -v (verbose mode):

TASK [Find files in path] **********************************************************************************************************************************************************

ok: [SMN001] => {"changed": false, "examined": 5, "files": [{"attributes": "Archive", "checksum": "3049a85843eaf65e89e2336d5fe6e85e416797be", "creationtime": 1550942958.6690862, "extension": ".exe", "filename": "NDP46-KB3045557-x86-x64-AllOS-ENU.exe", "isarchive": true, "isdir": false, "ishidden": false, "islnk": false, "isreadonly": false, "isshared": false, "lastaccesstime": 1550942958.6690862, "lastwritetime": 1459427148, "owner": "BUILTIN\Administrators", "path": "E:\Temp\Prognosis_11.2\Prerequisites\NDP46-KB3045557-x86-x64-AllOS-ENU.exe", "size": 65444688}, {"attributes": "Archive", "checksum": "8bf41ba9eef02d30635a10433817dbb6886da5a2", "creationtime": 1550942958.7627323, "extension": ".exe", "filename": "vcredist2013_x64.exe", "isarchive": true, "isdir": false, "ishidden": false, "islnk": false, "isreadonly": false, "isshared": false, "lastaccesstime": 1550942958.7627323, "lastwritetime": 1489501866, "owner": "BUILTIN\Administrators", "path": "E:\Temp\Prognosis_11.2\Prerequisites\vcredist2013_x64.exe", "size": 7194312}, {"attributes": "Archive", "checksum": "df7f0a73bfa077e483e51bfb97f5e2eceedfb6a3", "creationtime": 1550942958.7779777, "extension": ".exe", "filename": "vcredist2013_x86.exe", "isarchive": true, "isdir": false, "ishidden": false, "islnk": false, "isreadonly": false, "isshared": false, "lastaccesstime": 1550942958.7779777, "lastwritetime": 1489501866, "owner": "BUILTIN\Administrators", "path": "E:\Temp\Prognosis_11.2\Prerequisites\vcredist2013_x86.exe", "size": 6503984}, {"attributes": "Archive", "checksum": "007064d974a55940838f19cd0b0e3aaf27ca06a7", "creationtime": 1550942958.7939014, "extension": ".exe", "filename": "vcredist2017_x64.exe", "isarchive": true, "isdir": false, "ishidden": false, "islnk": false, "isreadonly": false, "isshared": false, "lastaccesstime": 1550942958.7939014, "lastwritetime": 1488965662, "owner": "BUILTIN\Administrators", "path": "E:\Temp\Prognosis_11.2\Prerequisites\vcredist2017_x64.exe", "size": 15261400}, {"attributes": "Archive", "checksum": "ba1f7e7cace62f7c55ab948cd3b29acc4e8e2329", "creationtime": 1550942958.8406758, "extension": ".exe", "filename": "vcredist2017_x86.exe", "isarchive": true, "isdir": false, "ishidden": false, "islnk": false, "isreadonly": false, "isshared": false, "lastaccesstime": 1550942958.8406758, "lastwritetime": 1488965662, "owner": "BUILTIN\Administrators", "path": "E:\Temp\Prognosis_11.2\Prerequisites\vcredist2017_x86.exe", "size": 14401656}], "matched": 5}

TASK [debug] ***********************************************************************************************************************************************************************

fatal: [SMN001]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'myvar' is undefined\n\nThe error appears to have been in '/etc/ansible/playbooks/test_find_files.yaml': line 18, column 5, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n – name: debug\n ^ here\n"}

As you can see, the files are properly found, but the "myvar" variable doesn't exist even though it should have been assigned.

According to this page, this logic does seem to work on Linux hosts: http://www.mydailytutorials.com/using-ansible-find-module-search-filesfolder/ (ref "Storing the file names in a register" at the bottom of the page).

Could it be an issue with the win_find module itself?
Any thoughts?

Thanks!

Best Answer

It's just a typo, your register: is too far indented.

It should appear as:

  - name: Find files in path
    win_find:
      paths: E:\Temp\Prognosis_11.2\Prerequisites
    register: myvar

Related Solutions

Security – How to implement ansible with per-host passwords, securely

You've certainly done your research...

From all of my experience with ansible what you're looking to accomplish, isn't supported. As you mentioned, ansible states that it does not require passwordless sudo, and you are correct, it does not. But I have yet to see any method of using multiple sudo passwords within ansible, without of course running multiple configs.

So, I can't offer the exact solution you are looking for, but you did ask...

"So... how are people using Ansible in situations like these? Setting NOPASSWD in /etc/sudoers, reusing password across hosts or enabling root SSH login all seem rather drastic reductions in security."

I can give you one view on that. My use case is 1k nodes in multiple data centers supporting a global SaaS firm in which I have to design/implement some insanely tight security controls due to the nature of our business. Security is always balancing act, more usability less security, this process is no different if you are running 10 servers or 1,000 or 100,000.

You are absolutely correct not to use root logins either via password or ssh keys. In fact, root login should be disabled entirely if the servers have a network cable plugged into them.

Lets talk about password reuse, in a large enterprise, is it reasonable to ask sysadmins to have different passwords on each node? for a couple nodes, perhaps, but my admins/engineers would mutiny if they had to have different passwords on 1000 nodes. Implementing that would be near impossible as well, each user would have to store there own passwords somewhere, hopefully a keypass, not a spreadsheet. And every time you put a password in a location where it can be pulled out in plain text, you have greatly decreased your security. I would much rather them know, by heart, one or two really strong passwords than have to consult a keypass file every time they needed to log into or invoke sudo on a machine.

So password resuse and standardization is something that is completely acceptable and standard even in a secure environment. Otherwise ldap, keystone, and other directory services wouldn't need to exist.

When we move to automated users, ssh keys work great to get you in, but you still need to get through sudo. Your choices are a standardized password for the automated user (which is acceptable in many cases) or to enable NOPASSWD as you've pointed out. Most automated users only execute a few commands, so it's quite possible and certainly desirable to enable NOPASSWD, but only for pre-approved commands. I'd suggest using your configuration management (ansible in this case) to manage your sudoers file so that you can easily update the password-less commands list.

Now, there are some steps you can take once you start scaling to further isolate risk. While we have 1000 or so nodes, not all of them are 'production' servers, some are test environments, etc. Not all admins can access production servers, those than can though use their same SSO user/pass|key as they would elsewhere. But automated users are a bit more secure, for instance an automated tool that non-production admins can access has a user & credentials that cannot be used in production. If you want to launch ansible on all nodes, you'd have to do it in two batches, once for non-production and once for production.

We also use puppet though, since it's an enforcing configuration management tool, so most changes to all environments would get pushed out through it.

Obviously, if that feature request you cited gets reopened/completed, what you're looking to do would be entirely supported. Even then though, security is a process of risk assessment and compromise. If you only have a few nodes that you can remember the passwords for without resorting to a post-it note, separate passwords would be slightly more secure. But for most of us, it's not a feasible option.

How to notify a remote service using Ansible

(listen is a 2.2 new feature which is not released as of writing, so I won't use it)

A notify is just like a regular tasks (or so) except it is triggered by an event, so basically you could do something like that, this is kind of ugly (and insecure as the machine should have ssh access to the remote servers) but should work.

handlers:
    - name: restart my remote service
      command: ssh user@myserver -- service restart myservice

But Ansible has a more elegant manner to handle this with delegate_to

handlers:
    - name: restart my remote service
      service: name=myserver state=restarted
      delegate_to: myserver

What it does, it the handler task will be executed on the server(s) you've have delegate the task. and then plug-in to your task as you told in the question.

Best Answer

Related Solutions

Security – How to implement ansible with per-host passwords, securely

How to notify a remote service using Ansible

Related Topic