I am trying to use Laravel homestead on a windows PC with Vagrant behind a proxy. I am using 'vagrant-proxyconf' and have updated my vagrantfile with the proxy details
Vagrant.configure("2") do |config|
if Vagrant.has_plugin?("vagrant-proxyconf")
config.proxy.http = "http://$my_account:$my_password#yproxyserver.com.au:8080"
config.proxy.https = "http://$my_account:$my_password#myproxyserver.com.au:8080"
config.proxy.no_proxy = "localhost,127.0.0.1"
end
end
However, whenever I try to 'vagrant up'I get the error:
The "https://getcomposer.org/version" file could not be downloaded:
failed to open stream: Cannot connect to HTTPS server through proxy
I have also tried making the proxy https, with no improvement.
config.proxy.https = "https://$my_account:$my_password#myproxyserver.com.au:8080"
config.proxy.no_proxy = "localhost,127.0.0.1"
Can anyone tell what I am doing wrong?
Are there things I can try to narrow down where the issue is? e.g. is it possible to test connection to proxy, test proxy user authentication... using the Vagrantfile
FYI: I am using GIT Bash command-line on windows 7 64-bit
Setting this variables via the Windows GUI made it possible for me to connect through our proxy (Right click on Computer > Properties > Advanced System Configuration > Advanced options tab > Environment Variables).
http_proxy=http://proxy:1234
https_proxy=http://proxy:1234
I spent the whole day on this. It didn't work for me setting it through CMD with the set command, through Git Bash with export nor writing it in the Vagrantfile.
I know this is an old post but I encountered this 2 days ago still.
Setting proxy didn't work for me because there is nothing in homestead that sets the proxy before the composer self-update command is run. So it always fails just after:
homestead: Running: script: Update Composer
So I had to go into scripts/homestead.rb and remove
composer self-update --no-progress
From the file in the "Updating composer" section (look for where it echos this out)
Everything worked fine for me then. Just use vagrant-proxyconf in the Vagrantfile as normal to get proxy settings into the VM and then do a composer self-update after everything is setup if you want/need.
Hope that helps someone out. I lost 2 days wondering what was going wrong with proxyconf when it was nothing to do with that
Related
Have spent over a day trying to get PhpStorm to debug a Drupal site inside a Vagrant virtual machine running Xdebug and I feel I'm close - but just not quite there yet.
Currently, in PhpStorm when debugging I have an error:
Waiting for incoming connection with ide key 'PHPSTORM'
In the Xdebug log in the VM (at /tmp/xdebug.log)
[2094] I: Checking remote connect back address.
[2094] I: Checking header 'HTTP_X_FORWARDED_FOR'.
[2094] I: Checking header 'REMOTE_ADDR'.
[2094] I: Remote address found, connecting to 192.168.88.1:9000.
[2161] E: Time-out connecting to client (Waited: 200 ms). :-(
[2161] Log closed at 2020-12-15 04:25:32
I tried setting up the Zero-configuration debugging without any luck.
For the debugging configuration, I have a PHP Remote Debug that validates correctly although it always defaults to the 'Local Web Server or Shared Folder' rather than the 'Remote Web Server' option.
When I started the project I set it up as a local web server option and I'm worried that I haven't changed the correct settings to now make this a remote web server. The connection type for the deployment is now 'Local or mounted folder' but originally this was 'In-place'.
Under Languages & Frameworks --> PHP --> Servers, I set this up on port 80, using Xdebug and without path mappings. I tried changing the port etc but then it doesn't validate so I'm confident that the server settings are correct and that PhpStorm is talking to the virtual machine correctly.
I changed the /etc/php/7.4/cli/php.ini file but phpinfo() says the configuration is coming from /etc/php/7.4/fpm/php.ini. The changes I made in the php.ini file are active though. phpinfo() is showing:
xdebug.idekey: PHPSTORM
xdebug.remote_host: 10.0.2.2
xdebug.remote_port: 9000
xdebug.remote_autostart: Off
xdebug.remote_connect_back: On
Really at a loss now as to what to try next. It is incredibly frustrating so hope someone can shed some light.
EDIT --- As per comment here is the screenshots of the setup:
Deployment: Local or mounted folder
PHP settings
The server setup
Debug settings
Validate the debugger from the remote server
Run Chrome with the debug addon running
The error message
The Run debug configuration settings
Start of the phpinfo with the config file showing where the xdebug settings need to be edited.
The Xdebug settings of phpinfo()
Some of the tests as per the comments:
After logging in to 'vagrant SSH' it shows the IP address to be used (10.0.2.2). The local computer is also IP 10.1.1.150 a telnet test of both of these works.
A 'sudo nano' of the Xdebug ini file
NOTE: Changing the remote connect back to 0 fixed the connection:
xdebug.remote_connect_back=0
And then the path mapping needed to be turned on in the Server settings and then everything was working correctly.
Big thanks to LazyOne for his helpful and thorough comments. :)
1) Check if there are separate php.ini files used by web server, -- you need to edit the right php.ini file.
Run phpinfo() and check to see if there is an ini file for Xdebug. In my case this was at /etc/php/7.4/fpm/conf.d/20-xdebug.ini
2) What's your Xdebug version?
Version 2 and 3 of Xdebug have slightly different parameters. In my case I was running Xdebug 2.9.5
3) What is the IP address of your Host OS as seen from the inside the VM? That's where Xdebug should connect (as it's Xdebug that connects to IDE and NOT other way around).
When you first log in to the SSH there will be an IP address shown. This is what the IP should be for Xdebug. In my example, this was 10.0.2.2
4) xdebug.remote_connect_back: On -- try set it off and ensure that you have correct xdebug.remote_host (as Xdebug v2 may not fallback to remote_host value when autodetected IP fails.
This fixed my connection!
sudo nano /etc/php/7.4/fpm/conf.d/20-xdebug.ini
Then change:
xdebug.remote_connect_back=1
To:
xdebug.remote_connect_back=0
Save, and then restart the server.
Test the connection again. After this step I had a connection between the host and remote server but I also had to turn on path mapping in PhpStorm to get the debugger working 100%.
5) Ensure that PhpStorm is the one that listens on Xdebug port when "phone handle" icon is enabled (use netstat or alike to confirm) and is allowed in firewall.
6) If you know the correct IP and sure that PhpStorm is listening -- you can just use telnet from inside the VM and try to connect to IDE on Xdebug port -- if connected then IP, port and firewall is most likely set up correctly.
Even with the error messages, the telnet check was working. So it pointed to the issue being with the Xdebug setup rather than the handshaking between the host and remote server.
Thanks to LazyOne's comments for finding the answer and for presenting a great workflow to help identify the problem.
I was experiencing something very similar to what you described.
I was able to start a debug session from the xdebug cli tool (dbgpClient) which proved to me that it was an issue with phpStorm.
My project is using a legacy version of xdebug. (2.2.7)
Downgrading to phpStorm 2020.2.4 resolved my issue.
(It's one-click in the jetbrains toolbox to downgrade)
Thanks for the answers in this issue. It took me half a day to find out that xdebug 2.2.7 with php5.3.10 doesn't work on Phpstorm 2020.3. So I downgraded to 2020.2.4 and it works again.
I'm trying to setup PhpStorm to debug correctly within a Vagrant Homestead environment. Xdebug is correctly installed and I'm running PHP 7.1
After setting a breakpoint in my app the script passes through any breakpoints and I get this message:
debug session was finished without being paused
It may be caused by path mappings misconfiguration or not synchronized local and remote projects.
To figure out the problem check path mappings configuration for 'wedleague.loc' server at PHP|Servers or enable Break at first line in PHP scripts option (from Run menu).
I've checked the mappings and have this set up for the root of the project:
local path remote path
file://C:/vagrant/projects/wedleague /home/vagrant/code/wedleague
If I set to debug at first breakpoint I can work through the debug session.
Tried loads of answers here but nothing seems to work.
What can I try to get the debug session to work correctly?
Update:
I've also tried this mapping (as suggested)
file://C:/vagrant/projects/wedleague/public /home/vagrant/code/wedleague/public
Still not working with this configuration either :(
Step 1
Install PHPStorm 2017.X
Install Xdebug helper for chrome
Step 2
Via ssh (choose a tool like putty, WinSCP, MobaXterm etc.)
Install xdebug, in your case laravel gets Ubuntu 16.04 by default with Nginx so we need to follow these instructions
The values I used are
; Enable xdebug extension module
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.remote_connect_back=1
xdebug.remote_host=10.0.2.2
in /etc/php.d/xdebug.ini
But note that I use my own vagrant installation (homestead is based on Vagrant) with CentOS and apache instead. Restart your virtual machine after config changes.
vagrant / homestead halt
and start again
vagrant / homestead up
Step 3
Config Xdebug helper extension in chrome by right clicking the symbol > options and set your IDE key to PHPStorm in the dropdown menu.
Configure PHPStorm, like a lot
hint: Settings has the shortcut ctrl + alt + s
Check the following settings. Don't forget to add both http and https in the Servers Setting and most important, don't read over the path mappings part.
And last but not least click these buttons, the first button with the phone horn actually has reversed icons in my opinion: when debugging it should have the little green part, altough logically red would mean stop, now it means start.
button 2 starts your url with a session var in the query string!
P.s. from your question: I think you need to go 1 level up root of laravel instead of public folders
edit: I just installed homestead at home and it comes with xdebug installed:
I setup Laravel Homestead. I then configured both homestead xdebug.ini and PHPStorm to make the debugging work.
Here is my xdebug.ini inside homestead
zend_extension=xdebug.so
xdebug.remote_autostart = on
xdebug.remote_enable = on
xdebug.remote_connect_back = on
xdebug.remote_port = 9000
xdebug.idekey = "vagrant"
To start a debugging session the steps I follow are
In PHPStorm --> Start Listening for connections
In PHPStorm set a breakpoint
In my browser --> Use XDebug Chrome Helper OR add to my URL ?XDEBUG_SESSION_START=
Load the page
This works perfectly. My problem is when I'm inside homestead command line and I run a php artisan command then I can't get it to hit my breakpoints.
What I've tried
XDEBUG_CONFIG="idekey=PHPSTORM" PHP_IDE_CONFIG="serverName=server_name" php -dxdebug.remote_host="127.0.0.1" artisan mycommand
php -d xdebug.profiler_enable=On artisan mycommand
I also tried to set xdebug.remote_autostart=On then sudo service php5-fpm restart but still my breakpoints never get hit in PHPStorm
Two things are important:
remote_connect_back can not work in the CLI case because Xdebug can not detect the remote IP when you are in the console
When using homestead / VirtualBox in the NAT network configuration, your development machine (which is running PHPStorm) does not have the IP 127.0.0.1 seen from inside the VM. Instead, it has usually an IP like 10.0.2.2. To find out the correct IP, have a look at your Apache's access.log,
The following worked for me:
php -dxdebug.remote_autostart=on -dxdebug.remote_connect_back=off
-dxdebug.remote_host=10.0.2.2 artisan
edit If your breakpoints are not hit, you have to set up the folder mappings correctly (as your path in the IDE is different from what the web server sees:
Do export PHP_IDE_CONFIG="serverName=yourservername" in your VM, where yourservername is what you configured in the screenshot under "name"
Add a Php Remote Debug Configuration with an IDE key and the server configured above
And add your IDE key and the remote_host to the VM's XDEBUG-CONFIG
export XDEBUG_CONFIG="idekey=artisan remote_host=10.0.2.2"
References: http://randyfay.com/content/remote-command-line-debugging-phpstorm-phpdrupal-including-drush
Or, if that all is just too complicated or not working - you can trigger your artisan command via a url (route) using
Artisan::call('whatever:command');
In most recent versions of Homestead you can do xphp artisan whatever and phpstorm will popup a windows automatically.
https://laravel.com/docs/8.x/homestead#debugging-cli-applications
My company's network is using proxy. So when I use vagrant up, it showed me a 401 permission error.
How can I do some setting to use vagrant?
Install proxyconf:
vagrant plugin install vagrant-proxyconf
Configure your Vagrantfile:
config.proxy.http = "http://yourproxy:8080"
config.proxy.https = "http://yourproxy:8080"
config.proxy.no_proxy = "localhost,127.0.0.1"
If your proxy requires authentication it is better to set the environment variable rather than storing your password in the Vagrantfile.
Also your Vagrantfile can be used by others easily who are not behind a proxy.
For Mac/Linux (in Bash)
export http_proxy="http://user:password#host:port"
export https_proxy="http://user:password#host:port"
vagrant plugin install vagrant-proxyconf
then
export VAGRANT_HTTP_PROXY=${http_proxy}
export VAGRANT_HTTPS_PROXY=${https_proxy}
export VAGRANT_NO_PROXY="127.0.0.1"
vagrant up
For Windows use set instead of export.
set http_proxy=http://user:password#host:port
set https_proxy=https://user:password#host:port
vagrant plugin install vagrant-proxyconf
then
set VAGRANT_HTTP_PROXY=%http_proxy%
set VAGRANT_HTTPS_PROXY=%https_proxy%
set VAGRANT_NO_PROXY="127.0.0.1"
vagrant up
Installing proxyconf will solve this, but behind a proxy you can't install a plugin simply using the command vagrant plugin install, Bundler will raise an error.
set your proxy in your environment if you're using a unix like system
export http_proxy=http://user:password#host:port
or get a more detailed answer here: How to use bundler behind a proxy?
after this set up proxyconf
Auto detect your proxy settings and inject them in all your vagrant VM
install the proxy plugin
vagrant plugin install vagrant-proxyconf
add this conf to you private/user VagrantFile (it will be executed for all your projects) :
vi $HOME/.vagrant.d/Vagrantfile
Vagrant.configure("2") do |config|
puts "proxyconf..."
if Vagrant.has_plugin?("vagrant-proxyconf")
puts "find proxyconf plugin !"
if ENV["http_proxy"]
puts "http_proxy: " + ENV["http_proxy"]
config.proxy.http = ENV["http_proxy"]
end
if ENV["https_proxy"]
puts "https_proxy: " + ENV["https_proxy"]
config.proxy.https = ENV["https_proxy"]
end
if ENV["no_proxy"]
config.proxy.no_proxy = ENV["no_proxy"]
end
end
end
now up your VM !
On a Windows host
open a CMD prompt;
set HTTP_PROXY=http://proxy.yourcorp.com:80
set HTTPS_PROXY=https://proxy.yourcorp.com:443
Substitute the address and port in the above snippets to whatever is appropriate for your situation. The above will remain set until you close the CMD prompt. If it works for you, consider adding them permanently to your environment variables so that you won't have to set them every time you open a new CMD prompt.
On windows, you must set a variable to specify proxy settings, download the vagrant-proxyconf plugin: (replace {PROXY_SCHEME}(http:// or https://), {PROXY_IP} and {PROXY_PORT} by the right values)
set http_proxy={PROXY_SCHEME}{PROXY_IP}:{PROXY_PORT}
set https_proxy={PROXY_SCHEME}{PROXY_IP}:{PROXY_PORT}
After that, you can add the plugin to hardcode your proxy settings in the vagrant file
vagrant plugin install vagrant-proxyconf --plugin-source http://rubygems.org
and then you can provide config.proxy.xxx settings in your Vagrantfile to be independent against environment settings variables
You will want to install the plugin proxyconf since this makes configuring the proxy for the guest machines pretty straight forward in the VagrantFile
config.proxy.http = "http://proxy:8888"
config.proxy.https = "http://proxy:8883"
config.proxy.no_proxy = "localhost,127.0.0.1"
However, there's quite a few things that could still go wrong.
Firstly, you probably can't install vagrant plugins when behind the proxy. If that's the case you should download the source e.g. from rubygems.org and install from source
$ vagrant plugin install vagrant-proxyconf --plugin-source file://fully/qualified/path/vagrant-proxyconf-1.x.0.gem
If you solve that problem you might have the fortune of being behind an NTLM proxy, which means that if you are using *nix on your guest machines then you still have some way to go, because NTLM authentication is not supported natively
There are many ways of solving that. I've used CNTLM to solve tht part of the puzzle. It acts as glue between standard authorization protocols and NTLM
For a complete walk through, have a look at this blog entry about setting vagrant up behind a corporate proxy
The question does not mention the VM Provider but in my case, I use Virtual Box under the same environment. There is an option in the Virtual Box GUI that I needed to enable in order to make it work. Is located in the Virtual Box app preferences: File >> Preferences... >> Proxy. Once I configured this, I was able to work without problems. Hope this tip can also help you guys.
If you actually do want your proxy configurations and plugin installations to be in your Vagrantfile, for example if you're making a Vagrantfile just for your corporate environment and can't have users editing environment variables, this was the answer for me:
ENV['http_proxy'] = 'http://proxyhost:proxyport'
ENV['https_proxy'] = 'http://proxyhost:proxyport'
# Plugin installation procedure from http://stackoverflow.com/a/28801317
required_plugins = %w(vagrant-proxyconf)
plugins_to_install = required_plugins.select { |plugin| not Vagrant.has_plugin? plugin }
if not plugins_to_install.empty?
puts "Installing plugins: #{plugins_to_install.join(' ')}"
if system "vagrant plugin install #{plugins_to_install.join(' ')}"
exec "vagrant #{ARGV.join(' ')}"
else
abort "Installation of one or more plugins has failed. Aborting."
end
end
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.proxy.http = "#{ENV['http_proxy']}"
config.proxy.https = "#{ENV['https_proxy']}"
config.proxy.no_proxy = "localhost,127.0.0.1"
# and so on
(If you don't, just set them as environment variables like the other answers say and refer to them from env in config.proxy.http(s) directives.)
Some Special characters in the password create problem in proxy. Either escape them or avoid having special characters in password.
In PowerShell, you could set the http_proxy and https_proxy environment variables like so:
$env:http_proxy="http://proxy:3128"
$env:https_proxy="http://proxy:3128"
In MS Windows this works for us:
set http_proxy=< proxy_url >
set https_proxy=< proxy_url >
And the equivalent for *nix:
export http_proxy=< proxy_url >
export https_proxy=< proxy_url >
I have a Vagrant VM standard issue lucid32.box running. What would the complete instructions be to set up LAMP on this?
I have looked at knife (part of chef) and attempted:
vagrant#lucid32:~$ knife cookbook site install apache2
but got
WARNING: No knife configuration file found
How do I set up a knife configuration file and what should I have in it?
I've been doing a lot of searching online for answers but am overwhelmed by partial solutions that don't explain their starting point/pre-requisites.
Update
I will aim to answer this myself as no-one else seems to want to. Here is my current understanding - I aim to address my unknowns/questions in red later.
OK, I've decided to answer this fully for myself as the original question poster. (Thanks to everyone who contributed prior.)
End-to-end setup of LAMP VM on a Windows 64-bit host using Vagrant and Oracle VirtualBox
I asked this question originally because although there are plenty of instructions and guides on the web, what they don’t seem to do is:
Clearly define a starting point and what the prerequisites are
Give instructions for those, like me, in corporate environments that have a capable Windows machine to host the VM. Instead they assume a Linux-based host machine.
Be clear on where the files being set up are: On the host? On the guest OS? (This is especially difficult to determine if both the host and guest OS are both Linux or Unix-based - the command line snippets shown don’t give clues obviously as they all look the same.)
State which version of Vagrant is used. There are two (2) main versions: API version 1 which is all releases before (but NOT including) v1.1.0. The other is API version 2 - which is releases from v1.1.0 onwards. So the versioning convention is similar to Java. This API version is important as, for example, v1 API scripts simply won't work on API v2 of the Vagrant software unless a clause is put at the beginning of the script to state which version to use.
Personally I think the Vagrant versioning convention could be simpler. NOTE: This guide here is for Vagrant 1. I am told that version 1 has a wide established installed base, while Vagrant 2 was still in draft mid 2013. I therefore like to call version 1 - V1 LTS - Long Term Support - like Ubuntu to show that this is going to be around for a long time yet.
Here is a picture to clarify which API is on which version of the Vagrant software:
For my example setup of using Vagrant here, I would suggest using pre-V1.1.0 (i.e. Vagrant API 1 from the downloads on vagrantup.com) however you ought to be able to use Vagrant 2 API version of the Vagrant software as mentioned above but you'll need to add a 'directive' at the beginning of your scripts to tell Vagrant that they are for Vagrant 1 otherwise the scripts will fail with an error message. TODO: I'll try to get that directive and put it here to help.
(Mitchell Hashimoto, Vagrant creator - please take note of the above for any future editions of your O'Reilly book: Vagrant: Up and Running: http://shop.oreilly.com/product/0636920026358.do)
What these instructions in this answer should do:
Get you a 32-bit Ubuntu Linux OS with a LAMP (Linux OS, Apache web server, MySQL database, PHP) stack running as a Virtual Machine using Oracle VirtualBox on your Windows 7 64-bit machine (or a Mac or Linux machine, but primarily tested on Windows but should work fine on Mac and this solution is meant to be platform-independent). I have tested PHP OK (via standard phpinfo.php file and see that MySQL is running but haven't tested this yet).
Other ways to set up a LAMP stack running on a Vagrant VM
Note: An alternative pretty much out-of-the-box solution for those (like me) who want a LAMP stack with the Drupal open-source content management framework is here: http://drupal.org/project/vagrant
You should be able to follow just my prerequisites below and then download the .zip from the above URL and follow the instructions on there and run vagrant up from the command line to start the VM and wait as it builds and starts (some of this is one-off the first time as once you have the image set up subsequent boots should be faster). You get a lot of other developer stuff 'for free' (i.e. to save you the effort installing them) - like git, drush (I think), and performance profiling tools. Afterwards go to [server address]/install.php to install Drupal. This seems to work well without issue - I've tried it out but not tested it extensively. You might need to disable the install of xhprof if you get an error message - see http://drupal.org/node/1940668 for details.
Another option is to use this configuration tool: https://puphpet.com/
- It's a visual point-and-click method for configuring your Vagrant setup. This works on Vagrant 2 (I think, Update yes, it does, on Vagrant 1.2.2 at least). Update: In fact, I've got this working successfully and based a setup for running Drupal on it locally - see my guide here: https://drupal.org/node/2055947
Update
Here are some other out-of-the-box Vagrant setups that I've found to work well - on Mac and Windows:
https://github.com/mikebell/drupaldev-apache
https://github.com/mikebell/drupaldev-nginx
If you want the Solr search engine locally in your VM as part of your LAMP stack, you may want to look at:
https://github.com/computerminds/parrot
Even though these alternatives are great, my instructions are still of value to help you understand the workings of such setups or if you want a simpler more basic LAMP stack.
Small extras that you need to find out how to do (will try to include them here)
Logging into the machine once set up - this is done via the standard SSH-based login. You will need the free tools putty.exe and puttygen.exe.
At the moment I have not provided how to log in with SSH here but will try to do so in future. You will find references at the end of this answer.
Note that the login will be with the user vagrant.
(After you have followed the setup instructions below) to use the root user you need to 'unlock' the account to be able to reset the password:
Unlock the root account:
vagrant#lucid32:~$ sudo passwd -u root
passwd: password expiry information changed.
Then change the root password:
vagrant#lucid32:~$ sudo passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
(The password is not shown as you type.)
Test the new password by logging into root with it:
vagrant#lucid32:~$ su root
Password:
root#lucid32:/home/vagrant#
Credit: https://scottlinux.com/2011/07/22/reset-or-change-user-password-in-linux/
(Article: "Reset or Change User Password in Linux" - This helped me work out how to do it.)
Any errors?
Give it a try - add comments to the answer if you have problems and I will try to fix. See also the troubleshooting at the end.
Future tasks
Currently using Puppet. Do it with Chef instead of Puppet, just to widen the ways of working. Both of these are contenders but have different approaches so I believe: With Puppet I am told that you say what you want and Puppet may make some arbitrary decisions to get you there. Whereas with Chef I believe you define the precise sequence of steps. Again - comment here and correct me if necessary,
Prerequisites for these instructions:
Windows 7 64-bit
Installed VirtualBox
Installed Vagrant
Separate installs of Ruby and Puppet are not required as these appear to come with Vagrant. To be honest, I did install these to fix some problems but found out those problems were something else. So I uninstalled Ruby and Puppet and re-ran (vagrant up etc) and it still works so I assume these extra, separate installs of Ruby and Puppet are not required.
Suggested Vagrant and VirtualBox version combination to use: VirtualBox version 4.2.12 and pre-Vagrant 1.2 (as previously discussed). Certain other combinations could work but I haven't tested those, so am sticking with this combination unless I can see clear benefit of using later versions. One top clear benefit would be speed of provisioning. The combination I state here works for the puphpet.com route to setting up a VM at least which is quite complex, and I would therefore assume should work on my simple setup documented here.
(Credit: These instructions are based on:
http://ox86.tumblr.com/post/23734821654/painless-development-environments-with-virtualbox
...but not an exact copy as they did not work for me.)
The instructions
(Ensure you have the prerequisites above.)
The host setup work is done on your host machine in your Windows user folder, for example for me this is C:\Users\rdavis
mkdir lamp-project
cd lamp-project
mkdir configs
cd ..
cd lamp-project
mkdir manifests
(following from: http://docs.vagrantup.com/v1/docs/getting-started/index.html)
Download the distro install image, in this case Ubuntu Lucid (10.04). This image is effectively equivalent to the install disk (CD or DVD) that you would traditionally use to install an OS on a machine.
C:\Users\rdavis\lamp-project>vagrant box add lucid32 http://files.vagrantup.com/lucid32.box
(By the way, there are several other popular distros on vagrantup.com, but if you want to generate the .box file from a distro .ISO then there is a tool called VeeWee to do that: https://github.com/jedi4ever/veewee)
Initialise it:
C:\Users\rdavis\lamp-project>vagrant init lucid32
(Note, I just used vagrant init when writing up these instructions because I had already initialised lucid32, but for the first time, you will have to do the above command.)
C:\Users\rdavis\lamp-project>vagrant init
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
C:\Users\rdavis\lamp-project>
Edit C:\Users\rdavis\lamp-project\Vagrantfile
- insert the following directly after Vagrant::Config.run do |config|
config.vm.box = "lucid32"
config.vm.provision :puppet do |puppet|
puppet.manifests_path = File.expand_path("../manifests", __FILE__)
end
config.vm.forward_port 80, 8080
config.vm.share_folder "configs", "/configs", File.expand_path("../configs", __FILE__)
So your Vagrantfile should look like:
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant::Config.run do |config|
config.vm.box = "lucid32"
config.vm.provision :puppet do |puppet|
puppet.manifests_path = File.expand_path("../manifests", __FILE__)
end
config.vm.forward_port 80, 8080
config.vm.share_folder "configs", "/configs", File.expand_path("../configs", __FILE__)
# All Vagrant configuration is done here. The most common configuration
# options are documented and commented below. For a complete reference,
# please see the online documentation at vagrantup.com.
# Every Vagrant virtual environment requires a box to build off of.
# config.vm.box = "lucid32"
# (this is already done above, but if you have a box called 'base' which is an Ubuntu lucid32 then you can use: config.vm.box = "base". This info may be helpful if you get error: "The box 'base' could not be found.")
# The url from where the 'config.vm.box' box will be fetched if it
# doesn't already exist on the user's system.
# config.vm.box_url = "http://example.com/path/to/above.box"
# Boot with a GUI so you can see the screen. (Default is headless)
# config.vm.boot_mode = :gui
# Assign this VM to a host-only network IP, allowing you to access it
# via the IP. Host-only networks can talk to the host machine as well as
# any other machines on the same network, but cannot be accessed (through this
# network interface) by any external networks.
# config.vm.network :hostonly, "192.168.33.10"
# Assign this VM to a bridged network, allowing you to connect directly to a
# network using the host's network device. This makes the VM appear as another
# physical device on your network.
# config.vm.network :bridged
# Forward a port from the guest to the host, which allows for outside
# computers to access the VM, whereas host only networking does not.
# config.vm.forward_port 80, 8080
# Share an additional folder to the guest VM. The first argument is
# an identifier, the second is the path on the guest to mount the
# folder, and the third is the path on the host to the actual folder.
# config.vm.share_folder "v-data", "/vagrant_data", "../data"
# Enable provisioning with Puppet stand alone. Puppet manifests
# are contained in a directory path relative to this Vagrantfile.
# You will need to create the manifests directory and a manifest in
# the file base.pp in the manifests_path directory.
#
# An example Puppet manifest to provision the message of the day:
#
# # group { "puppet":
# # ensure => "present",
# # }
# #
# # File { owner => 0, group => 0, mode => 0644 }
# #
# # file { '/etc/motd':
# # content => "Welcome to your Vagrant-built virtual machine!
# # Managed by Puppet.\n"
# # }
#
# config.vm.provision :puppet do |puppet|
# puppet.manifests_path = "manifests"
# puppet.manifest_file = "base.pp"
# end
# Enable provisioning with chef solo, specifying a cookbooks path, roles
# path, and data_bags path (all relative to this Vagrantfile), and adding
# some recipes and/or roles.
#
# config.vm.provision :chef_solo do |chef|
# chef.cookbooks_path = "../my-recipes/cookbooks"
# chef.roles_path = "../my-recipes/roles"
# chef.data_bags_path = "../my-recipes/data_bags"
# chef.add_recipe "mysql"
# chef.add_role "web"
#
# # You may also specify custom JSON attributes:
# chef.json = { :mysql_password => "foo" }
# end
# Enable provisioning with chef server, specifying the chef server URL,
# and the path to the validation key (relative to this Vagrantfile).
#
# The Opscode Platform uses HTTPS. Substitute your organization for
# ORGNAME in the URL and validation key.
#
# If you have your own Chef Server, use the appropriate URL, which may be
# HTTP instead of HTTPS depending on your configuration. Also change the
# validation key to validation.pem.
#
# config.vm.provision :chef_client do |chef|
# chef.chef_server_url = "https://api.opscode.com/organizations/ORGNAME"
# chef.validation_key_path = "ORGNAME-validator.pem"
# end
#
# If you're using the Opscode platform, your validator client is
# ORGNAME-validator, replacing ORGNAME with your organization name.
#
# IF you have your own Chef Server, the default validation client name is
# chef-validator, unless you changed the configuration.
#
# chef.validation_client_name = "ORGNAME-validator"
end
Then, in C:\Users\rdavis\lamp-project\manifests create file default.pp and put in it:
$config_path = "/configs"
$vagrant_base_path = "/vagrant"
Exec { path => "/bin:/usr/bin:/usr/local/bin" }
group { "puppet": ensure => present }
exec { "apt-get update": command => "apt-get update" }
class apache {
exec { "enable-mod_rewrite":
require => Package["apache2"],
before => Service["apache2"],
command => "/usr/sbin/a2enmod rewrite"
}
package { "apache2":
ensure => present
}
service { "apache2":
ensure => running,
require => Package["apache2"]
}
}
class php {
package { "libapache2-mod-php5": ensure => present }
package { "php5": ensure => present }
package { "php5-cli": ensure => present }
package { "php5-dev": ensure => present }
package { "php5-mysql": ensure => present }
package { "php-pear": ensure => present }
exec { "pear upgrade":
command => "/usr/bin/pear upgrade",
require => Package["php-pear"],
}
}
class mysql {
package { "mysql-server":
require => Exec["apt-get update"],
ensure => present,
}
service { "mysql":
enable => true,
ensure => running,
require => Package["mysql-server"],
}
exec { "Set MySQL server root password":
require => Package["mysql-server"],
unless => "/usr/bin/mysqladmin -uroot -proot status",
command => "/usr/bin/mysqladmin -uroot password root",
}
}
include apache
include php
include mysql
(Helpful note (optional), my above versions of Vagrantfile and default.pp (and other Vagrant ancilliary files and folder structure) are available from my GitHub repository, VagrantVMSetups, at: https://github.com/therobyouknow/VagrantVMSetups
- See the justlamp folder - this is the same as the contents of lamp-project used in this answer.)
Then run Vagrant:
C:\Users\rdavis\lamp-project>vagrant up
Note that this can take a while (5-15 minutes) - but bear with it. It should now successfully run a LAMP VM. Then you have finished with the VM in your current work task. If you then keep the VM for use at a later time but shut it down using vagrant halt (rather than vagrant destroy to delete the VM image) then I would expect this delay to be a one-off initial setup time. Subsequent startups of the VM (using vagrant up) should be faster I would think.
Troubleshooting:
Troubleshooting Problem 1: Bad/illegal quotes used - error message seen on host machine after running vagrant up
Background: this happened to me because I pasted in the code snippets from the web page where the instructions came from. The code snippet had open-and-close quotes - which aren’t interpreted as proper quotes by the interpreter/parser that Vagrant uses (or indeed by most script interpreters and compilers I would think.)
Symptom:
output like this:
There is a syntax error in the following Vagrantfile. The syntax error
message is reproduced below for convenience:
C:/Users/rdavis/lamp-project/Vagrantfile:6: invalid multibyte char (US-ASCII)
C:/Users/rdavis/lamp-project/Vagrantfile:6: syntax error, unexpected $end
Or this:
Could not parse for environment production: Could not match ?/configs? at /tmp/vagrant-puppet/manifests/default.pp:1 on node lucid32.hsd1.ca.comcast.net.
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
Or this:
There was an error executing the following command with VBoxManage:
["list", "hostonlyifs"]
Remedy: use proper double quotes “. Don’t use open-and-closing quotes.
Troubleshooting Problem 2: Following error message on host machine after running vagrant up
←[1;35merr: /Stage[main]/Apache/File[/etc/apache2/sites-enabled/000-default]: Could not evaluate: Could not retrieve information from environment production source(s) file:/configs/000-default at /tmp
/vagrant-puppet/manifests/default.pp:11←[0m
Remedy: you shouldn’t see this - the original script used contained references to a path containing 000-default. I just removed all lines and constructs referring to it.
Troubleshooting Problem 3: PHP files are treated as downloads (download of file occurs in browser) rather than being executed and displayed.
PHP needs enabling on the guest VM machine.
Remedy: you may or may not need to do this.
This tip worked: (to enable PHP and stop the file being seen as a download):
https://serverfault.com/questions/243435/getting-php-to-work-with-apache-to-run-php-files-through-browser
vagrant#lucid32:/etc/php5/cli$ a2enmod php5
Module php5 already enabled
vagrant#lucid32:/etc/php5/cli$ sudo apache2ctl restart
Another tip:
PHP needs enabling, suggestion in:
http://galleryproject.org/node/55011
is:
edit php.ini
These are shared extensions (.so files). You need to enable them in php.ini and then restart PHP.
Myself, I didn’t need to edit php.ini after all. By the way, this is at: /etc/php5/cli/php.ini for this lucid32 VM.
Troubleshooting Problem 4: Addressing the VirtualBox additions warning message about version mismatch
[default] The guest additions on this VM do not match the install version of
VirtualBox! This may cause things such as forwarded ports, shared
folders, and more to not work properly. If any of those things fail on
this machine, please update the guest additions and repackage the
box.
Guest Additions Version: 4.2.0
VirtualBox Version: 4.2.4
Not a problem it seems (it doesn’t stop the VM from running successfully), but if you wish to address it:
http://automation.binarysage.net/?p=1198
https://unix.stackexchange.com/questions/58216/automate-installation-of-virtualbox-guest-additio
ns-via-command-line
https://serverfault.com/questions/243435/getting-php-to-work-with-apache-to-run-php-files-through-browser
(for Linux-like users: http://www.pauloamgomes.net/blog/installing-vagrant)
Troubleshooting problem 5: The box 'base' could not be found." error message seen after running vagrant up.
Remedy? Check the line containing the statement config.vm.box = etc. in your Vagrantfile (see my example Vagrantfile above) to ensure that it is referring to a Vagrant box (the OS install image) that actually exists on your system - issue command vagrant box list to see what boxes you have.
If you have followed my instructions then you should have the lucid32 box. Make sure that there are no extraneous config.vm.box = etc. statements in your Vagrantfile. Confession: there was an extraneous config.vm.box = "base" in my Vagrantfile when actually a few lines above, config.vm.box = "lucid32" was already done. I have now corrected this.
FAQ
Q: What is a Vagrant box? A: Can be considered equivalent to an OS install disk in that it is the basis, the starting point for a VM - it’s the OS. It’s a binary file.
Q: What is a Vagrant package? A: A snapshot of the VM plus the configuration that Vagrant has performed from the VagrantFile provides a self-contained means to distribute the setup to other people.
References:
General Vagrant resources:
What exactly do the Vagrant commands do?
- nice description
http://community.opscode.com/questions/81
http://deanstrezovski.com/setting-up-a-cagrant-lamp-stack/
http://www.jasongrimes.org/2012/06/managing-lamp-environments-with-chef-vagrant-and-ec2-1-of-3/
How do I associate a Vagrant project directory with an existing VirtualBox VM?
http://docs.vagrantup.com/v1/docs/getting-started/index.html
More on Vagrant Boxes:
http://docs.vagrantup.com/v1/docs/boxes.html
Where is Vagrant saving changes to the VM?
SSH key-based logins (logging into the VM box externally - i.e. from the host machine or from another machine):
http://www.howtoforge.com/ssh_key_based_logins_putty_p2
http://docs.vagrantup.com/v1/docs/getting-started/ssh.html
http://en.wikipedia.org/wiki/Ssh-agent
For Windows SSH-based login to the VM:
PuTTY: a free telnet/ssh client
www.chiark.greenend.org.uk/~sgtatham/putty/
puttygen:
www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Version history/updates of this answer
Signposting and headings clean-up
Added running vagrant up and that it can take a while
Added how to set the root password in the VM
Added missing step to download and init the lucid32 box (equivalent to the install disk)
Added link to my https://github.com/therobyouknow/VagrantVMSetups GitHub repo that contains the Vagrant config setup for this answer - for convenience.
Altered Vagrantfile to remove the extraneous config.vm.box = "base" when actually a few lines above, config.vm.box = "lucid32" was already done. This will help if you encounter the error The box 'base' could not be found." Also added a new troubleshooting item explaining the same.
Added alternative out-of-the-box solution for those wanting a Drupal-based LAMP VM: http://drupal.org/project/vagrant see more notes above on this.
2013-07-10: slight grammar adjustment to reasons for writing this guide. Updated that the Vagrant book from O'Reilly is now published. Added link to https://puphpet.com/ - online Vagrant configurator script generator (very nice!). Added link to VeeWee tool which is used to generate a Vagrant .box file from any .ISO Linux distribution (standard install disc)
2013-10-14 Updated "what they don't seem to do" bullets with points on which Version of Vagrant - this guide uses Vagrant 1 (and why). Stated Vagrant 2 used with puphpet.com also link to my documentation using puphpet.com to set up a Vagrant VM for Drupal.
2013-10-21 Updated to state combination of VirtualBox version and Vagrant to use: VirtualBox version 4.2.12 and Vagrant 1.2.2. Certain other combinations could work but I haven't test those, so am sticking with this combination unless I can see clear benefit of using later versions. One top clear benefit would be speed of provisioning. Put heading on other approaches to Vagrant VM section. Updated to say this and other solutions are platform independent and should work on PC, Mac or Linux.
2013-10-23 updates on what Vagrant version to use for this guide (i.e. pre v1.2 (that's pre Vagrant 2)) and for another approach, puphpet.com (v1.2.2 - which by contrast is a Vagrant 2 release.)
2013-12-03 corrected notes of Vagrant API versioning and what API version is in which Vagrant software version. Added some more alternative, comprehensive Vagrant setups.
In your VM, you need to run:
$knife configure
Accept all the defaults.
After you have run this, there will be a configuration file in your ~/.chef/knife.rb.
As for your diagram:
The vagrant folder contains the Vagrantfile for that project. The actual .ovf and .vmdk files, along with another Vagranfile, exists in /%USERPROFILE%/.vagrant.d/
The Vagranfile is the configuration file for Vagrant and exists in multiple places with a set order of precedence. The Vagranfile in your project folder takes precedence: Vagrantfile documentation.
Everything can be from localhost, including setting up a more complex Vagrant project with multiple VMs, as such.
EDIT: to make it clear that the 'knife configure' cmd should be run in the VM and to remove a spurrious Windows path reference.