The file modes for vboxsf, smb shares are fixed. If you’re running ansible in a Vagrant VM, depending on mode to determine whether an inventory is dynamic or not is unreliable. Are there other acceptable solutions to identify executables? extensions (.py, .bash, .sh, etc) and parsing out the #! to get the interpreter?
Any other people running into this or have ideas for solutions?
Given that’s all virtualbox, I would be very confused if you couldn’t keep chmod +x files on the filesystem.
Now, what you do say about the shared storage dirs are a thing, so it seems the solution is to not share /etc, or if you do share /etc, keep these files off those volumes?
But sharing “/” is probably not going to be a thing.
You can’t chmod +x a file on or on a mounted smb share from linux.
My use case, and I’m fairly sure it’s a common one…
I have a project I want to use ansible on. We store the whole project in git, we use vagrant so everyone has a matching dev environment.
My project repository looks like…
/Vagrantfile
/ansible/inventory/dev/hosts
/ansible/inventory/dev/doinv.py
/ansible/provision.yml
/ansible/configure.yml
/ansible/deploy.yml
/client/**
/server/**
We have vagrant boxes with ansible pre-installed.
My team mates check out the project, runs vagrant up. The git repository is share as /vagrant inside the guest.
The default virtual box file permissions are 777.
if I run ansible-playbook -i /vagrant/ansible/inventory/dev/hosts it tries to interpret it as a script. I cannot chmod -x the file as vboxfs has a fixed mode for all files defined when mounted.
Currently we work around this with a script that copies the inventory to ~/ansible/** and sets the permissions. There are occasional annoyances like files being out of sync or removed files not being removed. It would be nice if we could work out of the canonical git repo that is shared with both the guest and the host. This probably affects everyone who tries to work with ansible from within vagrant on a windows host.
Right, that was exactly my point - you can’t do that 
I was suggesting you not share the entire VM directory, so you can use proper Linux permissions.
or I should say, not share the place you put your inventory script.
And how would I use Ansible without an inventory? As a windows user I can’t run it on my host system. Would you be open to changing how dynamic and static inventories are identified to improve the ansible experience on vagrant vms?
Didn’t say use it without an inventory, I was suggesting to share less of “/” with Windows.
That’s an option, isn’t it?
It seems if chmod +x didn’t work everywhere Linux wouldn’t really work (/usr/bin, etc). So it seems your inventory path is just in a path that’s currently shared and shouldn’t be?
I’m not sharing / with windows. I’m sharing c:\Users\me\src\repository with the vagrant vm. it is mounted at /vagrant in the vm. Are you saying my inventory shouldn’t be in my git repository?
Your inventory script if it needs to be marked executable needs to be marked executable.
I feel we would get dinged for security issues if we started executing non-executable files.
Darrel, is the goal to provide a .vmdk with ansible already provisioned with your company-ansible-deployment git project included?
Does it have to burned into the vmdk/vagrant box? If not, my workaround would be to just put a
run: “always” in the Vagrantfile’s vm.provision section as described on the Vagrant provisioning pages.
That provisioning section would pull in the latest company-ansible-git project. Even for decent sized projects, that should only be a few seconds.
Developers could comment out the - run: “always” - section if they needed to pin to a particular commit.
If you have lots of binaries in the git repo, you could always have a version of the git repo burned in at .vmdk Vagrant package time and then run a “git pull” to update to the latest.
As for me, I’ve found some issues with /vagrant sharing because of symlinks not working. Do you have a fix for that? The symlinks show up as broken in the vagrant box rather than sharing the linked file with vagrant.
I had originally hoped that Vagrant’s file sharing would allow a sort of distributed etc between all vagrant projects but i’m finding that’s not very practical for reasons like yours and the symlinking issue i hit.
kesten
Our goal is to have our developers check out the git repository on their host system regardless of OS (some are windows, some linux, some OS X). Run vagrant up to launch the VM. Then execute and run the project inside the VM while being able to edit files and manage git with the tools they’re most comfortable with on the host operating system.
We’re a consulting practice, we have about 15 projects in development or or maintenance with various stacks of varying complexity that we need to work on.
We have vagrant boxes with smb and ansible pre-installed, but we don’t bake in the git repositories and we don’t manage git from inside the vagrant. The vagrant is primarily an execution environment for the project.
Our windows users use the vagrant to run ansible as well. We currently have a script that copies the inventory around and then runs ansible with an alternative inventory path. It’s a little hacky, but I can live with it, It would be nicer if the x bit wasn’t how a dynamic inventory is detected.
If you’re on OS X/Linux use NFS to resolve the link issues. On windows use SMB and remember to check the values for follow links and wide links in the smb conf.
Are there security issues with running python setup.py. If it’s clearly documented that files ending with specific extensions, .bash, .py, .php, js, will be interpreted. I don’t see how it would be any more dangerous, especially if you have it sand boxed to a specific folder. Unless there is some hidden permission elevation risk that wouldn’t be present with a chmod +x.
So the short answer, before we spend any more time on the subject, is that you won’t consider alternate approaches to identifying dynamic inventory files?
“Are there security issues with running python setup.py”
That’s not the issue.
The question is whether we’ll get people who don’t know any better filing CVE’s that we have no good way to respond to.
This is the first time this has come up. Turn off the problematic fileshare, store the inventory script in a different directory, use VMware, something.
This won’t be changing to execute non-executable scripts by finding their interpreter lines and pretending to be a shell. That’s just not a good idea.
(In fact, technically, there’s nothing saying a dynamic inventory script couldn’t be a C program, where this doesn’t help - though unlikely, it’s another example of why executable bits are important)
Since vagrant always sees the inventory as executable for Windows, you
could make your hosts file an executable that returns JSON, which would
work for all platforms. If you prefer to keep the INI format for
developers to edit, drop an executable alongside it that reads it and
outputs JSON in the format Ansible expects (e.g.
https://gist.github.com/cchurch/6203028e8c46c42a9aa2).
In a southern aristocratic accent, laced with whiskey and cigars;
Why, Chris my dear man, you’re absolutely brilliant!
Actually, I take that smb/links comment back. I just spun up one of our node.js projects, and realized we’re using --no-bin-links since we weren’t able to get links to work on the share with either smb or vmware, except from our unix/smb based NAS. NFS though, seems to work like a charm on linux and os x.
I ran into some string parsing issues, so I modified @cchurch’s gist to use ansible.inventory.ini.InventoryParser to parse the inventory file.