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?


 * Try . That will update the .settings.yaml config file for you to set an alternate HTTP port. --BDavis (WMF) (talk) 21:12, 6 March 2015 (UTC)

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)
 * Trying to follow the initial convert-everything instructions seems to result in a failure to make the initial mediawiki clone, which cascades into the entire provisioning failing.  followed by manually running that command works, but then it fails on the next extension, and so on. I'd hypothesize that the puppet user isn't set up properly to use ssh? DLynch (WMF) (talk) 19:58, 6 October 2015 (UTC)

Latest VirtualBox from Oracle isn't necessary on recent Ubuntu
The page says
 * Get the latest VirtualBox

and as of December 29 2014 Oracle provides VirtualBox 4.3.20 for download at that link. But when I do a plain on Ubuntu 14.04 it installs 4.3.10-dfsg-1 from trusty/multiverse virtualbox amd64, surely that's new enough.

( apt show vagrant suggests sudo apt-get install virtualbox on Ubuntu 14.04 will install Vagrant 1.4.3-1, which is several versions behind the 1.7.1 on the Vagrant download page.)

-- SPage (WMF) (talk) 02:25, 30 December 2014 (UTC)

Monitoring tools (network)
Recently I had to monitor bandwidth usage (because I wanted to know why provisioning was hanging for 3 hours): It turned out git download speed was ~70 KiB/s. -- Rillke (talk) 16:54, 13 February 2015 (UTC)

Network throttling
Recently I had to debug some uploading code and was looking for a software being capable to simulate limited bandwidth and connection losses between host machine and guest (like an airport WiFi connection). Finally I did it client side (Chrome developer tools) but that's something that'd be cool to have documentation on. -- Rillke (talk) 16:58, 13 February 2015 (UTC)


 * I spent a fair amount of time trying to figure that out a year ago or so; Chrome devtools is by far your best option if you don't need to test with arbitrary browsers. Server-side IIRC trickle was one the least user-unfriendly option but not 100% reliable due to the hacky method it uses to simulate throttling. The next least bad option was proxying through the Mono port of Fiddler. --Tgr (WMF) (talk) 23:00, 3 January 2016 (UTC)

ERROR: Error installing ruby-libvirt: ERROR: Failed to build gem native extension.
I've tried to follow. I upgraded to fedora 21, reinstalled docker (another docker application is running happily) and installed vagrant-lxc. Packages cgroup-lite, nfs-kernel-server and build-essential are not available, so I skipped for now; I skipped apparmor because it doesn't apply and the installation from deb because I already installed from the package. I cloned mediawiki-vagrant and submodules.

Both  and   make /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/cc1 work for a while but eventually fail with ERROR:  Error installing ruby-libvirt: ERROR: Failed to build gem native extension.; I'm not able to follow the suggestion: : it doesn't succeed and I don't know why. I have Linux 3.19.7-200.fc21.x86_64, $ which ruby ~/.rvm/rubies/ruby-2.1.0/bin/ruby I know this is probably not an issue specific to MediaWiki-Vagrant but I'm leaving a note here just for the sake of documentation. I won't have time to debug the issue till June... --Nemo 17:20, 18 May 2015 (UTC)

Fails to vagrant up
I'm just simply trying to run ./setup.sh && vagrant up, but it fails (reproducable) with this error:

==> default: Error: composer install --optimize-autoloader --prefer-dist returned 1 instead of one of [0]

==> default: Error: /Stage[main]/Mediawiki/Php::Composer::Install[/vagrant/mediawiki]/Exec[composer-install--vagrant-mediawiki]/returns: change from notrun to 0 failed: composer install --optimize-autoloader --prefer-dist returned 1 instead of one of [0]


 * Please enter the VM with  and run   manually to see the error it reports. - Jan Zerebecki 13:19, 7 July 2015 (UTC)

"Undefined index: wiki in /var/www/w/MWMultiVersion.php"
I have a problem launching a VM with  set to   and   set to 4444. fails with:

The resulting VM returns HTTP requests to http://127.0.0.1:4444/ with the error "No wiki found; Sorry, we were not able to work out what wiki you were trying to view. Please specify a valid Host header."

I have filed T116500 for this failure; I'd appreciate any comments how it should work or how to debug and if someone can(not) reproduce the error. --Tim&#160;Landscheidt 20:44, 26 October 2015 (UTC)


 * This was caused by the directory on the host machine having the permissions 700, probably due to its origin as a temporary directory created by .    fixed this.  --Tim&#160;Landscheidt 00:35, 28 October 2015 (UTC)

Testing old Internet Explorer compatibility with MediaWiki-Vagrant
Probably not common enough to add to the already bloated tutorial, but in case it is needed by someone, here it is:
 * install modern.ie (easiest way is probably to use the Atlas boxes, except for IE6) and start the IE VM
 * run  for your normal vagrant box
 * you can now use the displayed URL in IE

The more straightforward approach of running the two machines on the same host-only network does not seem to work, as Vagrant seems to be unable to set the network for Windows VMs properly. --Tgr (WMF) (talk) 22:48, 3 January 2016 (UTC)

There was an error while executing `VBoxManage`
When I enter  in Git Bash, it says Bringing machine 'default' up with 'virtualbox' provider... ==> default: Clearing any previously set network interfaces... There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below.

Command: ["hostonlyif", "create"]

Stderr: 0%... Progress state: E_FAIL VBoxManage.exe: error: Failed to create the host-only adapter VBoxManage.exe: error: Code E_FAIL (0x80004005) - Unspecified error (extended in                                                                                                                      fo not available) VBoxManage.exe: error: Context: "int __cdecl handleCreate(struct HandlerArg *,in                                                                                                                      t,int *)" at line 66 of file VBoxManageHostonly.cpp What do I need to do to fix this? Nirmos (talk) 20:10, 22 July 2016 (UTC)
 * This looks to be very similar to an upstream bug report with VirtualBox affecting Windows 10 and VirtualBox <5.0.2. Have you tried updating to the latest versions of Vagrant and VirtualBox? It is certainly some VirtualBox issue and not directly a problem with MediaWiki-Vagrant. --BDavis (WMF) (talk) 21:10, 22 July 2016 (UTC)
 * BDavis (WMF): I uninstalled the old versions of Vagrant and VirtualBox and downloaded new ones. Now it says the following when entering :

Bringing machine 'default' up with 'virtualbox' provider... ==> default: Clearing any previously set network interfaces... There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below.

Command: ["hostonlyif", "create"]

Stderr: 0%... Progress state: E_INVALIDARG VBoxManage.exe: error: Failed to create the host-only adapter VBoxManage.exe: error: Assertion failed: [!aInterfaceName.isEmpty] at 'F:\tinderbox\win-rel\src\VBox\Main\src-server\HostNetworkInterfaceImpl.cpp' (74) in long __cdecl HostNetworkInterface::init(class com::Bstr,class com::Bstr,class com::Guid,enum __MIDL___MIDL_itf_VirtualBox_0000_0000_0038). VBoxManage.exe: error: Please contact the product vendor! VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component HostNetworkInterfaceWrap, interface IHostNetworkInterface VBoxManage.exe: error: Context: "enum RTEXITCODE __cdecl handleCreate(structHandlerArg *)" at line 71 of file VBoxManageHostonly.cpp
 * Nirmos (talk) 16:54, 23 July 2016 (UTC)
 * This looks to still be the same error; only the line number in VBoxManageHostonly.cpp has changed. There are some reports upstream with Vagrant of success by running VirtualBox in Windows8 compatibility mode. Others report Virtualbox 5.0.2 working. A linked blog post proposed yet another workaround of manually configuring an IP address in VirtualBox itself. The default IP used by MediaWiki-Vagrant is 10.11.12.13 if you try to use that blog's method. Sorry I can't be of more help, but do read through both the VirtualBox bug report and the Vagrant issue to get ideas of how to get past this issue on your host computer. --BDavis (WMF) (talk) 00:09, 25 July 2016 (UTC)

Jessie?
Is there any way (or plan) to migrate to Debian Jessie (used in Production/Labs/..) instead of old images like Ubuntu Trusty? --KartikMistry (talk) 07:21, 3 November 2016 (UTC)
 * There is a desire and a phabricator task. At this point I don't think any real work has been done which is at least partially my fault. --BDavis (WMF) (talk) 14:57, 3 November 2016 (UTC)

Adding templates automatically
What's the typical way to add common templates in use on English Wikipedia? I'm doing this manually now by copying the source from Template:Div_col, Template:Div_col_end, ... and then finding the right roles to enable. Is there a better way to get kind of a development version of Wikipedia locally? For example, Nearby has a feature that will fallback to using production Wikipedia for results. Is there something equivalent for templates? Thanks! Niedzielski (talk) 21:01, 2 December 2016 (UTC)
 * There's an RfC about figuring out how to do something like this, but no functionality yet in MediaWiki. For mw-vagrant, there is the  command to load pages from a dump file and the   Puppet define. --BDavis (WMF) (talk) 21:36, 2 December 2016 (UTC)

Cloning MediaWiki fails during first setup
I'm trying to set up MediaWiki-Vagrant on a Windows machine and it consistently fails to clone MediaWiki from gerrit every time. ==> default: Notice: /Stage[main]/Mediawiki/Git::Clone[mediawiki/core]/Exec[git_clone_mediawiki/core]/returns: Cloning into '/vagrant/mediawiki'... ==> default: Notice: /Stage[main]/Mediawiki/Git::Clone[mediawiki/core]/Exec[git_clone_mediawiki/core]/returns: error: RPC failed; result=56, HTTP code = 200 ==> default: Notice: /Stage[main]/Mediawiki/Git::Clone[mediawiki/core]/Exec[git_clone_mediawiki/core]/returns: fatal: The remote end hung up unexpectedly ==> default: Notice: /Stage[main]/Mediawiki/Git::Clone[mediawiki/core]/Exec[git_clone_mediawiki/core]/returns: fatal: early EOF ==> default: Notice: /Stage[main]/Mediawiki/Git::Clone[mediawiki/core]/Exec[git_clone_mediawiki/core]/returns: fatal: index-pack failed ==> default: Error: /usr/bin/git clone --recurse-submodules --branch 'REL1_27' https://gerrit.wikimedia.org/r/p/mediawiki/core.git /vagrant/mediawiki returned 128 instead of one of [0] ==> default: Error: /Stage[main]/Mediawiki/Git::Clone[mediawiki/core]/Exec[git_clone_mediawiki/core]/returns: change from notrun to 0 failed: /usr/bin/git clone --recurse-submodules --branch 'REL1_27' https://gerrit.wikimedia.org/r/p/mediawiki/core.git /vagrant/mediawiki returned 128 instead of one of [0] ==> default: Notice: /Stage[main]/Mediawiki/Php::Composer::Install[/vagrant/mediawiki]/Exec[composer-install--vagrant-mediawiki]: Dependency Exec[git_clone_mediawiki/core] has failures: true The installation succeeds, but attempting to browse to 127.0.0.1:8080 results in a "No wiki found" error page, with the only suggestion being devwiki, which links to http://dev.wiki.local.wmftest.net:8080/, which doesn't work either. info.php does work, and displays the correct information. The virtual machine is accessible through ssh and displays the correct start up screen, but attempting to run the listed commands like mysql, mwrepl or mwscript fail because there's no database configured. The MediaWiki distribution is missing from /vagrant/mediawiki, as well as from C:\Vagrant\vagrant\MediaWiki, as indicated by the error earlier. I'm running Vagrant 1.9.1, VirtualBox 5.1.10 on Windows 10. &mdash; Mainframe98 talk 11:08, 11 December 2016 (UTC)
 * This same error has been reported in Phabricator by . Let's keep the discussion and examination there. --BDavis (WMF) (talk) 17:32, 11 December 2016 (UTC)
 * Subscribed. Thanks. &mdash; Mainframe98 talk 17:51, 11 December 2016 (UTC)

vagrant 1.8.5
Is vagrant 1.8.5 supposed to be supported? I can't tell whether "download the latest vagrant" (currently 1.9.1) is an advice that applies to my case. --Nemo 13:14, 28 January 2017 (UTC)

its extensions are not built. Try: gem pristine
During ./setup .sh I got Ignoring ffi-1.9.8 because its extensions are not built. Try: gem pristine ffi --version 1.9.8 Ignoring hitimes-1.2.2 because its extensions are not built. Try: gem pristine hitimes --version 1.2.2 Ignoring json-1.8.2 because its extensions are not built. Try: gem pristine json --version 1.8.2 Ignoring unf_ext-0.0.7.1 because its extensions are not built. Try: gem pristine unf_ext --version 0.0.7.1 Ignoring ffi-1.9.8 because its extensions are not built. Try: gem pristine ffi --version 1.9.8 Ignoring hitimes-1.2.2 because its extensions are not built. Try: gem pristine hitimes --version 1.2.2 Ignoring json-1.8.2 because its extensions are not built. Try: gem pristine json --version 1.8.2 Ignoring unf_ext-0.0.7.1 because its extensions are not built. Try: gem pristine unf_ext --version 0.0.7.1 Installing additional development packages didn't help. $ ruby --version ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-linux] $ gem --version 2.5.2 --Nemo 13:24, 28 January 2017 (UTC)

vagrant ssh problems
Moved this from the page:


 * If an ssh-agent with a key loaded is running on your host, vagrant may run into trouble with  and   as it selects the key loaded in ssh-agent to connect to the guest (which fails). One solution to this is to add the vagrant private key to the ssh-agent of your host.

To do this, go to your vagrant directory in a shell, run  and with the path specified run   (replace the path with the one you found before).

SSH agents work fine with Vagrant (which sort of disables them anyway, by setting IdentitiesOnly). I think I have run into this issue once at T158258 (and still have no idea what exactly happened) but usually using an agent work fine. --Tgr (WMF) (talk) 19:02, 2 March 2017 (UTC)


 * Well at least this was the solution for me. Vagrant wouldn't do vagrant halt gracefully but always force the machine down and kept stuck with "default: Warning: Connection timeout. Retrying..." before aborting (the error messages were the same as in the "the networking pain" section above) but with a second shell I could vagrant ssh into the machine just a few seconds before the first connection timeout warning. After I detected that killing my ssh-agent process let me do vagrant up and vagrant halt gracefully I tested around and found this as the solution. Really crazy. EddieGP (talk) 19:18, 2 March 2017 (UTC)
 * PS: After I've read your task: I'm completely new to this, so I've followed the installation guide here step by step. My machine has never seen vagrant before, though it has seen virtualbox (which I wiped off before reinstalling the latest version as mentioned in the guide). I've got the latest vagrant version (1.9.1, and fyi vagrant has those as deb on their page) and latest virtualbox (from virtualbox repo). So it can't be a problem with your version. I'm currently running Ubuntu 16.10. EddieGP (talk) 19:18, 2 March 2017 (UTC)

Networking issues
Hey, does anyone know how I could speed up vagrant? It's taking me 10 seconds (at miniminum) to load a page, running login is somewhere between 30~40 sec. Can't be because of resources, vagrant is allowed to use 4GB of memory & all 4 CPUs. System information shows that it's not even near to using all of this. So I guess it's some networking issue, either with http connection between browser and vagrant or with the nfs share of the mediawiki directory. I'm running Ubuntu 16.10 with vb 5.1.14 & vagrant 1.9.2 (which both are the latest), the /-partition (where vb (/usr/bin/) and vagrant (/opt) are) is an ssd and the /home-partition (where the files for the vm are) is a spinning device. I've already tried using the repository releases instead of the latest ones and booting with all combinations of nfs shares options in 'vagrant config' command (disable nfs, use nfs with cache, force nfs_v3), I've also destroyed and re-up-ed after the initial up as suggested somewhere. Even clicked through all available network adapters in vb gui. Nothing helped, only effect was some did make it worse (didn't boot any more at all with force_v3, page load time > 1 min when disabling nfs etc.). Anybody knows what I could try from here? So far on IRC nobody was able to help ...EddieGP (talk) 16:53, 6 March 2017 (UTC)

Vagrant provision error
Hi all,

I try to install MediaWiki Vagrant.

I'm on a very new Ubuntu 16.04 installation and I've got this error message :

https://paste.fedoraproject.org/paste/DZ6k7mceyh2DSmzMoZtHLV5M1UNdIGYhyRLivL9gydE=

As you see at the end, I haven't a "maintenance" folder in my "mediawiki" folder...

What can I do ?

Many thanks by advanced for your answers !

--Cywil (talk) 17:55, 25 April 2017 (UTC)


 * new try : https://paste.fedoraproject.org/paste/h7OYb~YL6ntoVKTS7kUufV5M1UNdIGYhyRLivL9gydE=
 * error known here : https://phabricator.wikimedia.org/T152801

Adding puppet modules
What's the recommended way to install modules from puppet forge? So far the only way I've managed is by running sudo puppet module install --modulepath /vagrant/puppet/modules --hiera_config /vagrant/puppet/hiera.yaml --verbose  from within vagrant. --Quantum7 (talk) 09:11, 5 May 2017 (UTC)

PHP 7
When I try to install an extension that depends on a PHP 7+ package with the latest version of MW Vagrant I get:

This package requires php >=7.0 but your HHVM version does not satisfy that requirement.

What is the recommended way to run PHP 7+ code on MW Vagrant? And when will this be possible by default?

-- Jeroen De Dauw (talk) 00:50, 6 June 2017 (UTC)

I got something to work with


 * 1) sudo echo 'deb http://packages.dotdeb.org jessie all' >> /etc/apt/sources.list
 * 2) sudo echo 'deb-src http://packages.dotdeb.org jessie all' >> /etc/apt/sources.list
 * 3) wget https://www.dotdeb.org/dotdeb.gpg
 * 4) sudo apt-key add dotdeb.gpg
 * 5) rm dotdeb.gpg
 * 6) sudo apt-get update
 * 7) sudo apt-get install php7.0-xml php7.0-curl php7.0-zip php7.0-mbstring php7.0-redis
 * 8) php7.0 /usr/local/bin/composer update

This allows me to run composer and PHPUnit tests fine. More config is needed to have the webserver use the PHP 7 though.

-- Jeroen De Dauw (talk) 01:09, 6 June 2017 (UTC)

Hidden error when mwscript is run
I had a problem with starting MediaWiki, which wasn't hard to solve in itself, but there was no obvious error message. Vagrant started fine, but when I tried to access the wiki I got server error 503. I could access info.php, so I knew that something was running. When I ran  I noticed that there was a   process running periodically. I managed to catch the whole command by hammering  and when I ran it manually I got an error message (my extension.json was invalid, as I said not hard to solve).

It would be good if this error was presented to the user in some way or if there at least was something under MediaWiki-Vagrant about this. It's possible that you can find it in some log somewhere, but I couldn't; did a search in /vagrant/logs/ for the error. For command and log, see: https://phabricator.wikimedia.org/P5576.

Filed as T177735 --Tgr (WMF) (talk) 06:44, 9 October 2017 (UTC)

How is http://dev.wiki.local.wmftest.net:8080 different?
I've setup of vagrant (on a windows box) and successfully accessed the wiki using 127.0.0.1:8080 and later switched it to 127.0.0.13:8080. After enabling the VisualEditor role, the VisualEditor throws a 'Cannot connect to server' error. I see that the vagrant wiki says: If you have enabled VisualEditor, you will need to browse http://dev.wiki.local.wmftest.net:8080/ instead. but I can't access dev.wiki.local.wmftest.net:8080. Chrome tells me   dev.wiki.local.wmftest.net refused to connect.

Why do I need dev.wiki.local.wmftest.net and how can I rectify the situation?

Thanks

Where are xdebug.ini and php.ini in my Windows host?
I am trying to set up debugging a MediaWiki-Vagrant installation with NetBeans on a Window Server 2008 R2 host. Advices on the net tells me to edit xdebug.ini. I can't find it on my host. info.php tells me that there is something /etc/php5/apache2/conf.d/20-xdebug.ini but I can't find that either.

MediaWiki: MediaWiki 1.30.0-alpha (4530424) PHP:      5.6.30-0+deb8u1 (apache2handler)

Stupid me those can't be reached from Windows of course.

Is there a way to disable caching of pages during development? i.e. auto-purge
I'm new to mediawiki development and I spent a good amount of debugging time until someone told me I need to purge the page manually before I see the changes.

Anyway to automate it by defualt during development?

update: talking about the one that needs adding wiki/PageName?action=purge to purge it manually.

Configuration options; MediaWiki has many caches so depends on which one you mean. One I have found particularly annoying during frontend development is the ResourceLoader localStorage cache (delays the effect of any Javascript code changes by 5 minutes) which can be disabled with  --Tgr (WMF) (talk) 03:06, 7 October 2017 (UTC)