Initial provision failed to create temporary content file: timed out

[kynetiv]

I'm running into this error on my clean copy of drupal-vm:

TASK [geerlingguy.solr : Download Solr.] ***************************************
fatal: [collegescorecard]: FAILED! => {"changed": false, "failed": true, "msg": "failed to create temporary content file: timed out"}

I tried running vagrant provision again a few times but appear to be getting the same error.

My config.yml isn't too far from the example config, other than uncommenting solr from installed_extras, using Drupal 7 and not installing the site or running the make file on provision.

[geerlingguy]

I'm not able to reproduce this issue on VMware Fusion or VirtualBox; it sounds like there could be an issue with one of the following:

• Version of Ansible (see [Bug Report] uri module fails to create file with certain binary files ansible/ansible#7606) - are you on 2.0.1?
• Connectivity with the server from where Solr is downloaded (http://archive.apache.org/dist); either the site was down temporarily (it's working for me now), or it's blocked from your location.

If it's the latter issue, you may be able to work around it by using a different Solr mirror (solr_mirror in config.yml). See: http://www.apache.org/dyn/closer.lua/lucene/solr/5.5.0

[kynetiv]

I am running 2.0.1 of ansible
I've tried different mirrors, my connection over wifi, ethernet, with and without vpn. still no go for me.

I think I did notice a typo in tasks/main.yml (note the quote placements)

"solr_filename=solr-{{ solr_version }}"
should be
solr_filename="solr-{{ solr_version }}"

...although still I tried installing the 3.x version which doesn't have the typo and it fails me. For now i think I'll try and put it there manually but I'll update this thread if I figure out why for me it doesn't download. Thanks for the suggestions!

[geerlingguy]

Hmm... that typo could lead to an issue depending on the version installed. I was using 4.x.

[geerlingguy]

The role has been rearchitected a bit, and the filename should be set correctly in all cases now—I'm making sure to add tests for 3.x, 4.x, and 5.x (more to come, on different platforms as well). Thanks for reporting the issue, hopefully it doesn't come up again!