Talk:MediaWiki-Vagrant

Labs dependencies?

Mostly just a note to self, things to research and add to the documentation:

• 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?

Adamw (talk) 03:43, 12 November 2013 (UTC)

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

Try vagrant config http_port <PORT>. 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 bugzilla: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 notice: /Stage[main]/Git/Package[git]/ensure: ensure changed 'purged' to 'latest' 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: bugzilla:65066. whym (talk) 21:45, 10 May 2014 (UTC)

bugzilla: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 bug 69052 and bug 68453 --BDavis (WMF) (talk) 20:28, 4 October 2014 (UTC)

<censored>

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),

1. I tried to follow the same instructions. On step 4, when running setup.sh, I got this error message:

~/dev/vagrant$ ./setup.sh
/home/user/dev/vagrant/Vagrantfile:40:in `<top (required)>': 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 <internal:prelude>: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 `<main>'
Failed to execute command `vagrant plugin list` (pid 31819 exit 1)
~/dev/vagrant$

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, vagrant 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:

## Settings

For information about settings, see settings.d/README.

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 git under Windows (but I am using pageant.exe and plink.exe 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 (==> default: Error: /usr/bin/git clone --recurse-submodules ssh://kemayo@gerrit.wikimedia.org:29418/mediawiki/core.git /vagrant/mediawiki returned 128 instead of one of [0]), which cascades into the entire provisioning failing. vagrant ssh 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

 $ sudo apt-get install virtualbox

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):

$ vagrant ssh
$ # ... unicorn appears ...
$ sudo apt-get install nethogs
$ sudo nethogs

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)

@Rillke: 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 [1]. 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 vagrant plugin install vagrant-lxc and ./setup.sh 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:Make sure that `gem install ruby-libvirt -v '0.5.2'` succeeds before bundling: 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 vagrant ssh and run composer install --optimize-autoloader --prefer-dist 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 nfs_shares set to false and http_port set to 4444. vagrant up fails with:

==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: PHP Notice:  Undefined index: wiki in /var/www/w/MWMultiVersion.php on line 146
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: PHP Stack trace:
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: PHP   1. {main}() /var/www/w/MWScript.php:0
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: PHP   2. getMWScriptWithArgs() /var/www/w/MWScript.php:89
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: PHP   3. getMediaWikiCli() /var/www/w/MWScript.php:79
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: PHP   4. MWMultiVersion->getMediawikiRoot() /var/www/w/MWVersion.php:61
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: 
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: Notice: Undefined index: wiki in /var/www/w/MWMultiVersion.php on line 146
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: 
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: Call Stack:
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns:     0.0007     235472   1. {main}() /var/www/w/MWScript.php:0
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns:     0.0008     235648   2. getMWScriptWithArgs() /var/www/w/MWScript.php:89
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns:     0.0034     248792   3. getMediaWikiCli() /var/www/w/MWScript.php:79
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns:     0.0047     283272   4. MWMultiVersion->getMediawikiRoot() /var/www/w/MWVersion.php:61
==> default: Notice: /Stage[main]/Mediawiki/Mediawiki::Import::Text[Template:Main_Page]/Exec[add page devwiki/Template:Main_Page]/returns: 
[…]

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 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 mktemp -d. chmod g+rwx fixed this. --Tim 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 vagrant share --http `vagrant config --get http_port` --https `vagrant config --get https_port` 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 vagrant up 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 vagrant up:

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)

Tracked in Phabricator
Task T136429

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 vagrant import-dump command to load pages from a dump file and the mediawiki::import::dump Puppet define. --BDavis (WMF) (talk) 21:36, 2 December 2016 (UTC)

Cloning MediaWiki fails during first setup

Tracked in Phabricator
Task T152801

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/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/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. —Mainframe98 _talk 11:08, 11 December 2016 (UTC)

This same error has been reported in Phabricator by Tgr (WMF). Let's keep the discussion and examination there. --BDavis (WMF) (talk) 17:32, 11 December 2016 (UTC)

Subscribed. Thanks. —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

@EddieGP: Moved this from the page:

• If an ssh-agent with a key loaded is running on your host, vagrant may run into trouble with vagrant up and vagrant halt 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 find -name "private_key" and with the path specified run ssh-add ~/vagrant/.vagrant/machines/default/virtualbox/private_key (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 phab: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 <modulename> 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

# sudo echo 'deb http://packages.dotdeb.org jessie all' >> /etc/apt/sources.list
# sudo echo 'deb-src http://packages.dotdeb.org jessie all' >> /etc/apt/sources.list
# wget https://www.dotdeb.org/dotdeb.gpg
# sudo apt-key add dotdeb.gpg
# rm dotdeb.gpg
# sudo apt-get update
# sudo apt-get install php7.0-xml php7.0-curl php7.0-zip php7.0-mbstring php7.0-redis
# 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 top I noticed that there was a php process running periodically. I managed to catch the whole command by hammering ps 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#Troubleshooting_startup 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. — Preceding unsigned comment added by Sebastian Berlin (WMSE) (talk • contribs) 08:17, 14 June 2017‎

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)

— Preceding unsigned comment added by OlePedia (talk • contribs)

Stupid me those can't be reached from Windows of course. — Preceding unsigned comment added by OlePedia (talk • contribs)

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.

— Preceding unsigned comment added by Ommmmid (talk • contribs)

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 $wgResourceLoaderStorageEnabled = false; --Tgr (WMF) (talk) 03:06, 7 October 2017 (UTC)

Simplify the install process?

Hello ,

Could you please publish a debian distribution .iso file in which Mediawiki Vagrant is installed by following the instructions? Such an image would require updates each time a new version of Vagrant or VirtualBox is added, and each time there is a new commit to the https://gerrit.wikimedia.org/r/mediawiki/vagrant repository (or daily, or weekly). Not sure whether this would work well for VPS users or the standard debian iso image needs to be customised for each VPS provider?

Or an installation bash script may be created which installs the required items step by step and checks that they installed correctly before proceeding to the next step.

Regards,
Gryllida 10:32, 30 June 2018 (UTC)

NovaProxy

09/24/2018 14:39 — In the How do I...? section there is a reference to NovaProxy.

Setup a custom hostname?

Go to Special:NovaProxy, click . . .

The link leads to a dead page. There are pages related to establishing a proxy server, such as, Phabricator (09/24/2018 14:30) and proxy help page, but they are not mentioned here.

What is the updated procedure? Or, should this reference simply be removed? --Tabecket (talk)

@Tabecket: pretty much everything with Nova in its name has been replaced with Horizon (uses the same credentials as Wikitech). --Tgr (WMF) (talk) 21:03, 24 September 2018 (UTC)

How to turn off Virtual environment after having done the work?

Hi, I am running Vagrant on Windows 10. Please help me with how to turn off virtual developer environment? Actually, it makes my laptop a little bit slower, and I wish to turn it off after having my work completed.

Any help will be appreciable :) Thanks. — Preceding unsigned comment added by MaroonPixel (talk • contribs) 10:01, 4 October 2018 (UTC)

vagrant halt will shut down the virtual machine. Then vagrant up can be used at some point in the future to start the VM again. vagrant destroy will remove the virtual machine entirely which should recover some disk space. After a destroy then an up will create a new virtual machine image, start it, and run the Puppet code to setup the new virtual machine entirely. --BDavis (WMF) (talk) 14:51, 4 October 2018 (UTC)

More space for HDD

Hello everyone, I need more space on the HDD because the dump i am trying to import is bigger than the 10 GB the VM has. MediaWiki-Vagrant#Additional storage space only give the answer how to add and mount another storage. Is there a way to extend the space before the VM is set up? --Aschroet (talk) 09:49, 3 May 2019 (UTC)

The base image size depends on the virtual server software you are using with MediaWiki-Vagrant. If you are using VirtualBox (the default) then you could try following instructions like the ones at https://tuhrig.de/resizing-vagrant-box-disk-space/ to resize the base VM. --BDavis (WMF) (talk) 18:04, 14 May 2019 (UTC)

Apache2 Debian Default Page

I'm the only one who just get the "Apache2 Debian Default Page"?

Moreover:

vagrant ssh

vagrant@vagrant:/etc/apache2/sites-available$ ls -l
total 0

Is this situation OK?

During provision, this was the only error:

==> default: Error: Unable to set ownership to puppet:puppet for log file: /vagrant/logs/puppet/puppet.9d43e244b.log

I'm somehow confused. --Valerio Bozzolan (talk) 10:34, 23 June 2021 (UTC)

@Valerio Bozzolan the expected output is something like

vagrant@vagrant:~$ ls -l /etc/apache2/sites-available
total 16
-r--r--r-- 1 root root 149 Jul 16  2020 50-devwiki.conf

The log error is expected and unrelated. Tgr (WMF) (talk) 12:23, 24 June 2021 (UTC)

Error during `vagrant provision`: `/usr/local/bin/composer install --optimize-autoloader --prefer-dist` failes

I had some trouble when running vagrant provision after a clean install. The following error occured:

==> default: Error: /usr/local/bin/composer install --optimize-autoloader --prefer-dist returned 255 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: /usr/local/bin/composer install --optimize-autoloader --prefer-dist returned 255 instead of one of [0]

Running the command in Vagrant ssh gave the following error:

$ /usr/local/bin/composer install --optimize-autoloader --prefer-dist
Composer could not find a composer.json file in /home/vagrant
To initialize a project, please create a composer.json file. See https://getcomposer.org/basic-usage

Which is correct, there's no composer.json in the home directory. There is however one in /vagrant/mediawiki/, so I ran the command there, which worked. Then running vagrant provision also worked.

Not sure if this is something anyone else experienced (I had some VirtualBox trouble at first), but it's worth a shot if you do. Sebastian Berlin (WMSE) (talk) 13:44, 30 March 2022 (UTC)

Public access via Internet

I installed MediaWiki-Vagrant on a VPS server, it works well but I could not open the website on <public_ip>:8080 - it is only accessible via 127.0.0.1 on that remote server. I currently have to use some SSH tunnel like ssh -N -L 8080:127.0.0.1:8080 <username>@<public_ip_of_remote_server> to connect. Is there some method to expose that port publicly? Thanks. Stang 17:32, 18 June 2022 (UTC)

NVM, vagrant config host_ip 0.0.0.0 works well. Problem solved/ Stang 18:05, 18 June 2022 (UTC)

Vagrant vs Docker

What should I prefer in 2024 (for development): MediaWiki-Vagrant or mwcli? 95.104.189.110 21:27, 8 July 2024 (UTC)

MediaWiki-Vagrant is dear to my heart, but technical and political changes have made it a niche project in the modern era. MediaWiki-Vagrant supports provisioning some complex environments that will require manual steps to reproduce in other development environments. MediaWiki-Docker or mwcli are more likely to have active users that can help you if you run into problems today. -- BDavis (WMF) (talk) 21:42, 8 July 2024 (UTC)

Thank you for the reply. I was uncertain about which option to choose because, despite the prevalence of containers approach in modern software development, it felt like there was far more effort put into MediaWiki-Vagrant compared to dockerized solutions (at least from documentation perspective), and as I see it still receives commits and page edits. However your last statement outweights this, so probably there's not too much field to actually make a choice. 95.104.184.37 09:57, 11 July 2024 (UTC)