Closed dixhuit closed 8 years ago
@danbohea I'm getting something very different from your results here. Centos 66 is broken for me, but not for a mirror issue - for the same python_selinux issue I patched in https://github.com/zxaos/vlad/commit/7d43ba353b5c2a0b0ee2784c2cd4d9cce267c805 . I hadn't realized it was an issue in 66 too! I wonder how long it's been broken?
FWIW, if I apply that commit, things seem to load better. Still not the same error you're getting. - I'm actually getting the same issue I had over in #308 (not the same drupal console error as #314 ) Maybe it was just a network bug for you?
Maybe it was just a network bug for you?
Hope so. Will try again now and post more info.
Yep, I still get the same error in the same place: TASK: [base | yum | yum update and ensure core packages are installed]
Time to compare settings files? This is the contents of my merged_user_settings.yml (this will include some defaults that I'm not explicitly setting):
---
webserver_hostname: nosferatu.local
webserver_hostname_aliases:
- www.nosferatu.local
boxipaddress: 192.168.100.100
boxname: nosferatu
vm_cpus: auto
vm_memory: auto
vm_chipset: ich9
vm_pae: 'on'
vm_acpi: 'on'
vm_ioapic: 'on'
host_synced_folder: ../docroot
aux_synced_folder: ../vlad_aux
synced_folder_type: nfs
ansible_verbosity: ''
vlad_os: centos66
vlad_custom_play: false
vlad_custom_play_path: ../vlad_custom/
vlad_custom_play_file: provision.yml
vlad_custom_base_box_name: ''
use_host_id: true
Can you share yours and I'll see if I get the same error.
The only thing different from example.vlad_settings.yml
is the vlad_os
part and an overridden box URL:
merged_user_settings.yml
:
---
webserver_hostname: drupal.local
webserver_hostname_aliases:
- www.drupal.local
boxipaddress: 192.168.100.183
boxname: vlad
vm_cpus: 2
vm_memory: 1024
vm_chipset: ich9
vm_pae: 'on'
vm_acpi: 'on'
vm_ioapic: 'on'
host_synced_folder: ./docroot
aux_synced_folder: ./vlad_aux
synced_folder_type: nfs
ansible_verbosity: ''
vlad_os: centos66
vlad_custom_play: false
vlad_custom_play_path: ../vlad_custom/
vlad_custom_play_file: provision.yml
vlad_custom_base_box_name: ''
adminer_install: false
apache_install: true
imagemagick_install: false
mailcatcher_install: false
memcached_install: false
munin_install: false
mysql_install: true
node_install: false
php_install: true
pimpmylog_install: false
redis_install: false
ruby_install: false
sendmail_install: false
solr_install: false
varnish_install: false
xhprof_install: false
http_port: 80
varnish_http_port: 80
Same error with your settings too. I'm kinda glad :)
Would you mind sharing your dependency versions?
echo "VirtualBox `VBoxManage --version`"; vagrant --version; ansible --version; vagrant plugin list
Gives me:
version; vagrant plugin list
VirtualBox 5.0.10r104061
Vagrant 1.7.4
ansible 1.9.4
configured module search path = None
vagrant-cachier (1.2.0)
vagrant-hostsupdater (0.0.11)
vagrant-share (1.1.4, system)
vagrant-triggers (0.5.0)
I'm running in VMWare Fusion 8.0.2 (3164312) instead of VirtualBox
-bash: VBoxManage: command not found
VirtualBox
Vagrant 1.7.4
ansible 1.9.4
configured module search path = None
vagrant-cachier (1.2.1)
vagrant-hostsupdater (1.0.1)
vagrant-share (1.1.4, system)
vagrant-triggers (0.5.2)
vagrant-vmware-fusion (4.0.2)
Updated my Vagrant plugins and retested but still the same error in the same place.
Huh.
Are we getting different mirror lists because of geographic region maybe?
Oh, alternative theory: It's because we're using different base boxes.
# Virtualbox provider settings
config.vm.provider "virtualbox" do |vb, o|
if vlad_custom_base_box_name != ""
# Add a previously built custom box
o.vm.box = vlad_custom_base_box_name
else
if vlad_os == "centos66"
# Add a CentOS 6 VirtualBox box
o.vm.box = "hansode/centos-6.6-x86_64"
vs
# VMWare provider settings. These tend to not have good alternatives on atlas, so specify URLS manually
config.vm.provider "vmware_fusion" do |vmw, o|
if vlad_custom_base_box_name != ""
# Add a previously built custom box
o.vm.box = vlad_custom_base_box_name
else
# Add VMWare box.
if vlad_os == "centos66"
o.vm.box = "opscode_centos-6.6"
o.vm.box_url = "http://opscode-vm-bento.s3.amazonaws.com/vagrant/vmware/opscode_centos-6.6_chef-provisionerless.box"
Edit: So try switching to that URL, or possibly bento/centos-6.7
(since that might be the one to use in the future if I can make it work so we can merge #308 )
Further edit: Right, that URL won't work for you because it's a vmware one. Here's the corresponding VirtualBox base box: http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.6_chef-provisionerless.box
I'm leaning towards the base box theory...
Confirmed. I just amended my Vagrantfile to point VirtualBox to bento/centos-6.7
and now Ansible pushes past the original error and instead now fails at:
TASK: [base | ssh config | add ssh config file] *******************************
failed: [192.168.100.100] => {"failed": true}
msg: Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!
Which appears to match up with the error you fixed at https://github.com/zxaos/vlad/commit/7d43ba353b5c2a0b0ee2784c2cd4d9cce267c805
Amending vladguts/playbooks/roles/base/tasks/python.yml as per your fork then seems to fix that error and Ansible is able to provision all the way up to Drupal f*cking Console_ ;)
I'm tempted to update dev to use bento/centos-6.7
for all providers so that CentOS is no longer borked - it'll be a short term, poor-man's version of your original PR from #308 but there will be nothing stopping us from revisiting that concept in the future. Also, I suggest we disable the drupal_console role for now as it clearly needs more attention and is holding up progress in other areas.
Thoughts? @philipnorton42, @zxaos
OK, maybe jumping to CentOS 6.7 is a bit extreme just to fix CentOS on VirtualBox. Perhaps we can look at using a different base box for 6.6 just for VirtualBox?
Drupal Console is disabled in dev
for now: https://github.com/hashbangcode/vlad/commit/8989a05c9802735f99f263ae2df3309ad7e559fc
Agreed, if Drupal console is causing issues then lets disable it for now. It's a useful tool but it's no good if the whole box doesn't provision correctly :)
@danbohea: Which version of DC is causing this issue?. We fixed Drupal-VM, issues on latest release and must be working now.
See #314.
Closing now that #317 ha been merged.
Nothing fancy in my settings file, OS specified in the usual way:
I'm actually just testing some changes I've made to the drush role as I never really use CentOS but I can recreate this on current
dev
just the same: