Closed richierampage closed 8 years ago
Everything does look correct. Can you access the site from within the VM?
vagrant ssh
...
curl http://examplevm.dev
One thing that comes to mind as you're using an existing codebase. Do you use any redirects within Drupal/htaccess, eg to https or www.
?
Good call about trying within the vm with curl will try that and post results. To rule out code issues I tried a vanilla d7 clone from d.o. with same results. Thanks for replying :-) On 5 May 2016 6:12 p.m., "Oskar Schöldström" notifications@github.com wrote:
Everything does look correct. Can you access the site from within the VM?
vagrant ssh ... curl http://examplevm.dev
One thing that comes to mind as you're using an existing codebase. Do you use any redirects within Drupal/htaccess, eg to https or www.?
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/geerlingguy/drupal-vm/issues/592#issuecomment-217213612
Some other things you could do to help debugging (unless someone else chimes in):
apache2
and php5-fpm
.No idea what the problem could be but the more info the better. More eyes looking at things and maybe we can spot what's wrong.
I can successfully request urls via curl from within the vm. Can't see it being a vhost issue but here it is anyway. :-)
<VirtualHost *:80>
ServerName examplevm.dev
DocumentRoot /var/www/drupalvm
<Directory "/var/www/drupalvm">
AllowOverride All
Options -Indexes +FollowSymLinks
Require all granted
</Directory>
ProxyPassMatch ^/(.*\.php(/.*)?)$ "fcgi://127.0.0.1:9000/var/www/drupalvm"
</VirtualHost>
All other vhosts are working fine externally to vm (adminer etc.), it's just drupal that's timing out. Here's adminer's vhost settings that is working fine.
<VirtualHost *:80>
ServerName adminer.examplevm.dev
DocumentRoot /opt/adminer
<Directory "/opt/adminer">
AllowOverride All
Options -Indexes +FollowSymLinks
Require all granted
</Directory>
ProxyPassMatch ^/(.*\.php(/.*)?)$ "fcgi://127.0.0.1:9000/opt/adminer"
</VirtualHost>
@richierampage - Can you try setting the host to www.examplevm.dev
instead? Maybe the bare domain is doing something funny... Since Google bought .dev
, I've noticed strange things sometimes when using certain bare .dev domains.
Also, if you ping examplevm.dev
on your host, what do you get?
@geerlingguy I can confirm that the issue is with bate .dev domains.
www.examplevm.dev works fine, as does examplevm.local
Thanks for the pointer, I would never have considered that a specific tld defined in /etc/hosts could be treated differently than others!
@richierampage - Thanks for the confirmation! Yeah, .dev
worked splendid for a long time, until Google Alphabet had the gumption to go buy the TLD and break domains in weird ways.
How rude! Should we consider switching the example host to something else? I see others are having that discussion as well https://github.com/Varying-Vagrant-Vagrants/VVV/issues/583
Yeah... the problem is, what? I don't like .local
because it has weird issues on both Mac OS X and Windows because of zeroconf... and something like .com
would be problematic just like .dev
:/
I could maybe purchase the .drupalvm
TLD if someone wants to front the money :)
As per the discussion in the issue I referenced, it seems the only options are:
.localhost
.test
drupalvm.localhost
, people wouldn't even understand that's a hostname... So maybe not :/
How about prepending the drupal site url with www. the same as adminer etc? That worked ok for me with .dev but not sure if there are other issues with .dev due to the Alphabet ownership you mentioned?
We could do a www., but that's still not too obvious. I'm leaning slightly towards .test
... but that implies that the site is a 'test' site, not dev, prod, etc., and that could also throw people off. Though .dev
has similar semantic issues.
The main thing is to find something that won't blow up someday. Naming things--
All the other sites within drupalvm have a prefix (dashboard, adminer, pimpmylog) so how about we set a default for the drupal site that can be overridden in config?
The default value might be 'www' or whatever. This could then be overridden, in this way there would always is always a prefix and we could still use .dev. as when used with a subdomain e.g. drupal.examplevm.dev it seems to work fine.
site_prefix: drupal
Not considered multisite, haven't tried that yet within Drupalvm but should work I guess.
Hi,
tl;dr
Box provisions and install d7 but times out when trying to access vm, other installed apps such as adminer and dashboard work fine.
Detail
I've just started playing with drupal-vm although pretty familiar with vagrant/drupal/ansible. First impressions great!
What I am trying to do is automatically build a vm and then install Drupal from a project repo on bitbucket (I appreciate the benefits of make driven development but this is how we roll for smaller projects!).
I can not see an automated way out of the box to do this so I am trying cloning code repo on my host machine (mac running vmware fusion) into a dir called docroot that is at root of drupalvm project (as opposed to say ~/Sites/). Need to restructure things for version control but ok for now.
When I vagrant up, vm is built & site installed using my existing, pre-cloned codebase (
install_site: true
). I can ssh onto vm and successfully run drush status command which shows site installed. I can also get to dashboard, adminer and pimpmylog apps.What I can't do is access site, it times out. :-(
Apache vhost configs look fine but there are no requests or errors in log files for my vm (other_vhosts log file). I do see entries for adminer etc. though so requests to vm don't seem to be getting to apache.
I can ping examplevm.dev and it resolves correctly. (using hostupdater for local/etc./hosts file updates).
Although it seems to be apache related to rule out my codebase I have cloned Drupal core and still the same.
My config.yml file is below. Pretty standard except I have changed boxname, ip and removed /drupal from synced directory.
Any ideas on what to try next would be much appreciated. :-)
Thanks
Rich
config.yml