Talk:MediaWiki-Vagrant

Labs dependencies?
Mostly just a note to self, things to research and add to the documentation: Adamw (talk) 03:43, 12 November 2013 (UTC)
 * First run does not seem to work for me, puppet never runs. After destroying that box, the next call to "vagrant up" succeeds.  Something to do with the order of linking or shared directories?
 * The redis-server puppet module specifies a "-wmf" package, thus will not work without setting up WMF apt sources.
 * Configuring a redis object cache might be a bit heavy for the default install?

that port 8080 appears to be taken on my machine ... where is the file to change the port?

Versioning, sigh
"vagrant up" fails for me, complaining that my version of VirtualBox is too new (it wants 4.0-4.2, and Debian unstable has 4.3.2). Sigh. Anomie (talk) 18:02, 23 January 2014 (UTC)

Time for first vagrant up
I've changed 10-15 min to about a hour, because 10-15 min is just the time for the download of the Ubuntu image on a 5? Mb/s connection. However, I think two hours would be more realistic: notice: Finished catalog run in 5756.80 seconds In my first "vagrant up", with most time spent after notice: /Stage[main]/Git/Package[git]/ensure: ensure changed 'purged' to 'latest' and before notice: /Stage[main]/Mediawiki/Git::Clone[mediawiki/core]/Exec[git clone mediawiki/core]/returns: executed successfully for a total of 129 minutes of CPU time. Nothing tragic, but had I known I would only have started it before going to bed. --Nemo 07:50, 22 February 2014 (UTC)
 * Just for reference, most of that Puppet time is the git clone. This should be addressed by 61060 (and related work). Superm401 - Talk 19:50, 3 March 2014 (UTC)
 * A fresh clone of core is long, but doesn't take that long on my machine usually. --Nemo 19:58, 3 March 2014 (UTC)

LOL, someone should have told me  would take thaaaat long eating a lot of my CPU power, btw. Otherise I wouldn't Ctrl+C'ed it before being complete and wondering why MediaWiki was always missing in my Vagrant setups. Why doesn't it just do a shallow clone? -- Rillke (talk) 14:22, 14 June 2014 (UTC)

Vagrant 1.6.1
Is MediaWiki-Vagrant supposed to work with Vagrant 1.6.1 (latest release) or is it a good idea to stick with 1.5.4? When I tried with 1.6.1, the default MediaWiki on 127.0.0.1:8080 worked as expected, but "vagrant list-roles" was not recognized, but showed the help of all commands instead. I had no problem with 1.5.4 on the same PC. whym (talk) 17:09, 10 May 2014 (UTC)
 * I just noticed that it was reported already: 65066. whym (talk) 21:45, 10 May 2014 (UTC)
 * 65066 is closed now and Vagrant 1.6.0+ is supported. Thanks for everyone's patience with this. --BDavis (WMF) (talk) 16:39, 11 July 2014 (UTC)

./setup.sh fails
On OS X 10.6.8, with up-to-date versions of Virtualbox (4.3.14), Vagrant (1.6.3) and Macports (2.3.1) installed:

$ ./setup.sh Installing plugin vagrant-vbguest - Installing the 'vagrant-vbguest' plugin. This can take a few minutes... - Bundler, the underlying system Vagrant uses to install plugins, - reported an error. The error is shown below. These errors are usually - caused by misconfigured plugin installations or transient network - issues. The error from Bundler is: - - An error occurred while installing nokogiri (1.6.3.1), and Bundler cannot continue. - Make sure that `gem install nokogiri -v '1.6.3.1'` succeeds before bundling. Failed to execute command `vagrant plugin install vagrant-vbguest` (pid 7505 exit 1)

Zazpot (talk) 23:30, 7 August 2014 (UTC)
 * Several workarounds for the upstream problem of installing the nokogiri gem on OSX are documented in and  --BDavis (WMF) (talk) 20:28, 4 October 2014 (UTC)

I've tried to install vagrant on a laptop and on a xen vps.

On the laptop with VirtualBox 4.3.10, Ubuntu 14.04, Vagrant 1.4.3,
 * 1) `vagrant up` gives 'this machine is in poweroff state bla bla' error and suggests to run virtualbox gui to see a more useful error message. This approach is crappy; it should pick up the error message from virtualbox in the first place -- some people may want to run vagrant on a server, for instance.
 * 2) On the laptop, when I start virtualbox and try to run the machine, I get a "VT-x is disabled in the BIOS. (VERR_VMX_MSR_VMXON_DISABLED)" option. I spent a few minutes browsing my BIOS settings. I don't have this option in BIOS. Who, and why, made it a default instead of writing a note explaining how to check whether BIOS supports this, and how to enabled this on opt-in basis? And even if it's desirable, why is there no note explaining how to check, and how to opt-out?
 * 3) I went into virtualbox gui and disabled virtualisation, and tried to boot again. It gave the same error message. Turned out that the settings dialog of a machine allows me to click "OK" and closes silently when my settings are incorrect. VirtualBox is a pile of crap.
 * 4) Turns out that which settings are incorrect is displayed using small icons at the dialog bottom, not even a statusbar widget for this. VirtualBox is a pile of crap, again. (I'll deliver both of these two messages to them.)
 * 5) After fixing relevant settings and disabling VT-X in the machine, I clicked 'run' in the virtualbox gui. The machine started and opened a black screen and gave no error. Thought an Ubuntu OS inside a VM would've given a shell prompt. Weird.
 * 6) I powered off the machine and returned to terminal, and typed 'vagrant up' there. It complained about the machine being in poweroff state again. -- I went to the gui, tried to run it, it complained about VT-X being disabled again. All my changes to the virtual machine settings were undone; apparently 'vagrant up' forces VT-X to be on. This is unbelieably stupid.

On the xen vps, Vagrant 1.0.3, VirtualBox 4.1.18, Debian GNU/Linux 7 (wheezy), ~/dev/vagrant$ ./setup.sh /home/user/dev/vagrant/Vagrantfile:40:in `': The mediawiki-vagrant plugin hasn't been installed yet. Please run `setup.sh`. (RuntimeError) from /usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:115:in `load' from /usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:115:in `block in procs_for_source' from /usr/lib/ruby/vendor_ruby/vagrant/config.rb:41:in `block in capture_configures' from :10:in `synchronize' from /usr/lib/ruby/vendor_ruby/vagrant/config.rb:36:in `capture_configures' from /usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:114:in `procs_for_source' from /usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:51:in `block in set' from /usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:45:in `each' from /usr/lib/ruby/vendor_ruby/vagrant/config/loader.rb:45:in `set' from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:377:in `block in load_config!' from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:392:in `call' from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:392:in `load_config!' from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:327:in `load!' from /usr/bin/vagrant:40:in ` ' Failed to execute command `vagrant plugin list` (pid 31819 exit 1) ~/dev/vagrant$
 * 1) I tried to follow the same instructions. On step 4, when running setup.sh, I got this error message:

Therefore I am unable to complete the install of Vagrant with MediaWiki. Please identify bugs involved in the above and also share hints how I can possibly complete the install on any of the two machines. --Gryllida 09:47, 25 August 2014 (UTC)


 * For me, it was also not easy to set up Vagrant. It looks like it is targeted only to people who has enough skills. VT-X will not work on a laptop if the processor does not support this, as well it will not work in XEN, since virtualization is already in use. And without VT-X, you can not run a 64 bit system in Vagrant. I do not know exactly where you are coming and I could be wrong, but I think in your case, you should try to run the 32 bit system in Vagrant with VT-X is disabled. --Pastakhov (talk) 10:42, 25 August 2014 (UTC)
 * What 32-bit system are you referring to? MediaWiki-Vagrant is using a 64-bit guest. Superm401 - Talk 18:03, 25 August 2014 (UTC)
 * So I was wrong, it seemed to me there is a choice --Pastakhov (talk) 03:02, 26 August 2014 (UTC)

Pastakhov, people suggested I try a later version of "Vagrant" software itself. Note the instructions say "latest" in bold. I would like that to be replaced by a "X.Y.Z+", though - would make things much easier for people whose operating system is using a package manager (where the concept of 'latest' is ambiguous). It is taking a while to download 'Vagrant' from their own website and I will leave a message here after a few hours. --Gryllida 11:19, 25 August 2014 (UTC)

BTW I already tried "to run the 32 bit system in Vagrant with VT-X is disabled" and 'vagrant up' undid my changes. (Step 6). --Gryllida 11:20, 25 August 2014 (UTC)


 * Please be constructive. We are not the developers of either Vagrant or VirtualBox.  Also, the people who work on MediaWiki-Vagrant do so as one of their many tasks.


 * Gryllida,  does usually show the error in the console, but sometimes it is unable to figure it out.  As you know, this is not optimal.  It's not a problem in MediaWiki-Vagrant, but rather the interaction between VirtualBox and Vagrant.  If you want, there are other options.  E.g. it is supposed to work with VMWare, though I have not personally tried that or Xen.


 * The main issue is VT-x. As indicated by Pastakhov and the documentation (I've made the wiki docs clearer this is a hard requirement), for the features MediaWiki-Vagrant needs, hardware virtualization is required.  It is not an optimal optimization feature.  Hardware virtualization (VT-x, or AMD's equivalent, AMD-V) is required by VirtualBox for 64-bit guests, and MediaWiki-Vagrant uses a 64-bit guest.  If you post your laptop's specifications, someone may be able to check if it supports it.  There is a note about this in both the README and this wiki page.


 * I've updated the version info here to match the README. Superm401 - Talk 18:03, 25 August 2014 (UTC)
 * Well yes, writing out the complete thing helped me to analyse the situation and get there to step 6, which got documentation updated. You're adorable, thanks for updating it. Hooray.
 * As I did mention above, I will pass relevant parts of that picture, and the software communication problem, to the relevant people. --Gryllida 04:04, 26 August 2014 (UTC)

Resolved by enabling CPU virtualisation in BIOS settings. --Gryllida ( Please don't ping me, I have Echo turned off. ) 06:01, 6 September 2014 (UTC)

The networking pain
«vagrant up» says that connection timed out:

user@localhost:~/dev/vagrant$ vagrant up Bringing machine 'default' up with 'virtualbox' provider... ==> default: Clearing any previously set forwarded ports... ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat default: Adapter 2: hostonly ==> default: Forwarding ports... default: 80 => 8080 (adapter 1) default: 22 => 2222 (adapter 1) ==> default: Running 'pre-boot' VM customizations... ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2222 default: SSH username: vagrant default: SSH auth method: private key default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying...   default: Warning: Connection timeout. Retrying... Timed out while waiting for the machine to boot. This means that Vagrant was unable to communicate with the guest machine within the configured ("config.vm.boot_timeout" value) time period. If you look above, you should be able to see the error(s) that Vagrant had when attempting to connect to the machine. These errors are usually good hints as to what may be wrong. If you're using a custom box, '''make sure that networking is properly '''working and you're able to connect to the machine. It is a common''' problem that networking isn't setup properly in these boxes. Verify that authentication configurations are also setup properly, as well. If the box appears to be booting properly, you may want to increase the timeout ("config.vm.boot_timeout") value. user@localhost:~/dev/vagrant$

I selected some part of this in bold, which appears to be actionable meaningful part of the message:


 * 1) Make sure that networking is properly working and you're able to connect to the machine. It is a common problem that networking isn't setup properly in these boxes.
 * 2) Verify that authentication configurations are also setup properly, as well.

Then I added one more network adapter to the machine and ran "vagrant up". It removed it. I made other changes to the virtual machine configuration in Virtual Box. "vagrant up" reset them again. How would you like me to "set up" networking and authentication here?

README.md of the vagrant gives this quote:

For information about settings, see settings.d/README.
 * 1) Settings

settings.d/README contains this:

_                    //       .-""""-.    ;(_\      /        \   /\_/     |    .---./  /  /                    ,                   /)      \ C'  '>'| /  /       _    _ _/__/_   __   _   _       _(/       ';   - / /  /       /_)__(/_(__(___(_/ (_(_/_/_)_ o  (_(_       __)---;/`  /      - .-/ _.-' \`"""`| /                            (_/ .'    _/      \/ \  -;'|       |  This directory is mounted as '/vagrant/settings.d' in the  '-._/-.      |  guest environment. MediaWiki will automatically load any PHP      \(-\     |  files in this directory in lexical order.       |---|       |    J  |  As an alternative to managing all MediaWiki settings in a       |    |  |  single large file, consider grouping your configurations by       |    ;  |  component or theme, and creating a separate PHP file for       |   /|  \  each group. This makes it quite easy to keep your settings       | _/ T  /  organized, to temporarily disable specific configurations,       |  | |  |  and to share settings with others.       |  | |__|_       |__| '-.__)  Because the files are loaded in lexical order, you can  jgs  \__)        control the order in which your configurations are set by            adopting the habit of adding a two-digit prefix to each file name. For example:

settings.d/       ├── 10-RunFirst.php ├── 20-SomeExtension.php └── 99-RunLast.php The file '00-debug.php-example' in this directory is included as an example. It contains settings that are useful for debugging and development work. To use it, simply copy '00-debug.php-example' to '00-debug.php', ommiting the '-example' suffix. Note that the settings files in settings.d/puppet-managed are automatically created and destroyed by Puppet in response to your Puppet configuration. Don't put your custom settings there, because Puppet will erase or override them. Keep your custom settings files in this directory instead. Settings files in this directory will load *after* any Puppet-managed files, so you can override any unwanted settings that are set by Puppet.

All of the above is illegible, not actionable, without clear explanation to me as to what Puppet is, what specifically in the settings I should look at, and specifically how to resolve the two «common» problems mentioned in the "vagrant up" output — if they're common, it should be much much more clear as to where to go to edit these settings.

Please suggest how to proceed. --Gryllida ( Please don't ping me, I have Echo turned off. ) 06:01, 6 September 2014 (UTC)

SSH for default clone link?
Do we want to change the first clone command to use SSH instead of HTTPS? This caused me quite a few headaches when starting out when I tried to use git-review later. I know https is a bit easier if the user is just going to clone and not edit, but since this link is used in conjunction with the Gerrit Tutorial, it might be worth considering.

--Jhobs (talk) 19:51, 30 September 2014 (UTC)
 * Not sure (never used vagrant), but is this the reason behind bug bugzilla:62844? If yes, then we definitely should change that. « Saper // talk »  11:52, 4 October 2014 (UTC)
 * Yes, please. Helder 12:25, 4 October 2014 (UTC)

Using ssh git origin URLs
Making the clones managed by MediaWiki-Vagrant use ssh by default requires forwarding an ssh-agent with an active key for gerrit access into the virtual machine. This is necessary because the git clones are actually created and managed via Puppet configuration from inside the virtual machine rather than from the host operating system. We are not currently able to ensure that this can be done on all host platforms (eg Windows) so we default to https origin URLs. There is a (poorly documented) means to configure your local MediaWiki-Vagrant install to use ssh origin URLs instead: $ vagrant config forward_agent yes $ vagrant hiera git::urlformat ssh://USER@gerrit.wikimedia.org:29418/%s.git $ vagrant up Replace USER in the second command with your gerrit user name. These changes will only affect new git clones, so it must be done before the initial vagrant up command is run on a brand new MediaWiki-Vagrant install to affect the initial mediawiki git clone.

If you would like to convert an existing install, the easiest way to do it would be to destroy the existing vm, delete the mediawiki git clone, and create a new vm. $ vagrant destroy -f $ rm -rf mediawiki $ vagrant config forward_agent yes $ vagrant hiera git::urlformat ssh://USER@gerrit.wikimedia.org:29418/%s.git $ vagrant up

It is also possible to convert an existing git clone to use an ssh origin URL manually using the git remote set-url command: $ cd mediawiki $ git remote set-url origin ssh://USER@gerrit.wikimedia.org:29418/mediawiki/core.git $ git fetch $ git rebase origin/master This would need to be repeated for each skin and extension as well with appropriate modifications to the git URL.

There have been several attempts at making this process easier and we haven't given up yet. I'm personally hoping that the migration from gerrit to phabricator will continue to progress and allow us to get rid of this problem with submitting patches all together. --BDavis (WMF) (talk) 20:18, 4 October 2014 (UTC)


 * Thanks for excellent explanation, BDavis (WMF)! Maybe we should just publish the last solution as a work around? Personally I've never had major issues with SSH agent and  under Windows (but I am using   and   for consistency), but this is kind of required for MediaWiki development to get it running, sooner or later.  « Saper // talk »  21:20, 4 October 2014 (UTC)
 * I'm all for someone moving the documentation I gave into the main page somewhere. There should be a warning for Windows users about the closed and unfixed upstream bug impacting ssh agent forwarding. --BDavis (WMF) (talk) 04:58, 6 October 2014 (UTC)