Closes #99 and #100

[antitoxic]

No description provided.

[morty]

This seems to be the parent to the 1.9.5 commit.

See voxpupuli/puppet-python@eb52429

[antitoxic]

You're right. WIll fix that. e92de3dee9c55d5 however is definitely out of the history.

[antitoxic]

@morty I've fixed the commit reference.

[rossjones]

@morty if you get a chance this week, could you try a rebuild and see if this causes an issue. I'm not sure how common this setup is - I've certainly never encountered it when running vbox with either direct sharing or over NFS.

[morty]

I've just spun up another instance and it all worked fine. I cannot reproduce this issue.

@antitoxic can you tell us a little more about your setup? What version of Vagrant/Virtualbox are you using?

This line should make creating symbolic links possible: https://github.com/datagovuk/dgu-vagrant-puppet/blob/master/Vagrantfile#L38

[antitoxic]

My host machine is Arch linux, I used the latest virtualbox (5) and latest vagrant at the time I reported this issue. I didn't proceed further with my tests after that.

I'm pretty uncertain what VBoxInternal2/SharedFoldersEnableSymlinksCreate do behind the scenes. Do any of you know? My previous experience with filesystems and network drives is that symlinks and locking are pretty bad on network drives and I'm surprised that VirtualBox has an option that solves that thoroughly.

[rossjones]

I don't know why I'm not seeing this, probably because I'm on a Mac.

Rather than it being a symlink issue, is it possible that it's actually this issue https://www.virtualbox.org/ticket/14563 ? Can you manually create a symlink without .. in it and have it succeed?

I'm just wary of breaking symlinks for binaries as it is likely to break things (like grunt).

Another option, seeing as we're presumably in a VM solely for CKAN - can-we/is-it-safe-to install the node stuff globally?

[antitoxic]

I did some more tests (only now I have access to my dgu test machine).

It seems the problem is due to permissions. I can create symlinks as root (or sudo).

I also noticed that the guest additions installed on the vagrant box are older version than the virtualbox itself:

==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default: 
    default: Guest Additions Version: 4.2.0
    default: VirtualBox Version: 5.0

Some questions:

1. Could the whole symlink be related to guestaddtions versions?
2. Is the older version due to the basebox being ubuntu precise that has older guest additions?

[davidread]

This is a very common message you get when you upgrade your virtualbox version and you carry on using a vm created before. I've never seen it cause a problem like this.