Error with Ansible Playbook Inventory files being marked executable about docker-swarm

[vfarcic]

I don't have Windows on any of my machines so I can not fix/test this issue. Could you try to fix it and make a pull request?

[r4j4h]

Most certainly. =)

[r4j4h]

Okay, so I tried chmodding the root folder and a few other things and none of those worked satisfactorily.

Here's the approaches I've identified and some information about them and whether or not I've tried them and what my results were. They all come or seem to come irritatingly close to working, but all with side effects:

1. Change Vagrantfile to mark not executable

config.vm.synced_folder ".", "/vagrant", :mount_options => ["dmode=...","fmode=..."]

I dotted out the numbers because as you'll learn below I am unable to recreate the same near-success case as I did on the first try and did not copy the error as I can't select text in this console and did not expect to run into the trouble getting back to this point that I did.

Got past the executable error, but ansible gave a different error having trouble with something else I believe relating to consul as it could not find the IP it was expecting. Might be from everything now being marked non-executable? It feels a bit dirty, although perhaps still potentially functional.

2. Change Vagrantfile to use non Virtual Box Share type

config.vm.synced_folder ".", "/vagrant", :type => "smb"

Rsync is available for a one time transfer and might be sufficient for all systems, with the caveat that it only happens when the vagrant box is provisioned/reloaded.

For normal sync support there are options for each configuration but I do not know of a way to let one configuration dynamically switch synced_folder types based on the operating system. I'd like to figure that out for this route as having OS-specific Vagrantfiles or branches or something does not sound fun.

Assuming we can, Samba should work for Windows. VBoxshare should work for others as it currently is, but there's also NFS, which could potentially serve as another alternate to Vboxshare or rsync for Non-Windows.

So far with Samba I'm getting some errors, but this could be related to my hasty testing method which I'll describe below. Unrelated to my hasty testing method, I am having issues deleting the samba share that vagrant created, and it angrily failed itself when it was unable to delete those samba shares. I'm also not confident with how it requires admin rights, which may deter some users.

I do still want to try the rsync method though.

3. Change the .ini into a dynamic inventory file

The linked Stack Overflow question thread contains examples in a bash script and a ruby script. The Vagrantfile in the repo uses ruby script for its configuration so this might be a good route to stay consistent. However, the resulting file is less clear than the .ini form.

Also it should be noted the inverse happens and this file MUST be executable, but perhaps that is an easier problem for non-Windows systems to solve.

I have not tried this route yet, but it definitely seems the most promising.

4. Use VirtualBox manually to run something like Ubuntu and then do everything from there

I did something like this for docker way back when and it worked well, so perhaps something similar could work.

The big problem with this one is now for the user to access things we need to forward IP's/ports which can get really confusing really quick and isn't great for new users. I doubt many people will be running these examples in parallel so it shouldn't be too horrible to hardcode some of that so the user does not have to deal with it in most cases.

There's also the cost of VM-in-a-VM.

I also have not tried this route yet either.

---

Was using vagrant provision instead of cleanly destroying/upping in the hopes of saving time quickly trying a few things, but this probably ultimately only antagonized my efforts. My co

My biggest slow down was Samba. Well my run with Samba actually almost worked, but I had left in the mount_options from approach 1 and before I could tell if this was going to be an issue I went to stop and fix it. Then I ran into a snag trying to re-provision as the samba share is still there. There is this note under Limitations in the Vagrant docs about how we have to manually remove Samba shares. When using the syntax in their documents instead of deleting the share it just provided me its help message, which included instructions very similar to theirs but with /delete in caps. Even then it still just outputted the help message and didn't affect the share. Trying to run vagrant destroy or re-provisioning at this point began to throw funky errors relating to the share and some other vagrant-y things.

Unfortunately at this point I must get on with my night but I'm sure I'm just missing something simple to my net share command.

I've waded through all the errors and destroyed the machines and am now upping vagrant with the permissions approach again to re-verify my first test results since I tried the samba after not wanting to re-type the result message because of its length and being so confident samba would work.

Ugh, as it were I apparently can't find the right combination of chmod entries to let things work again. I keep running into ERROR: the playbook ... infra.yml .. could not be found because of not having read/execute permissions on the folder. Tried like 4 combinations and none worked although I know one did before. >_<

So of those here's what I'd like to try later:

• Try mount_options approach again
• Try rsync
• Try converting hosts/prod to ruby script
• Following the article from my Ubuntu VB image

[r4j4h]

So, inspired by some comments on the blog, and having reinstalled Windows 8.1, I gave this another shot and after the mount_options it all worked! :)