Last modified: 2014-09-22 17:37:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T73093, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 71093 - labs-vagrant provision fails on existing instance
labs-vagrant provision fails on existing instance
Status: RESOLVED DUPLICATE of bug 70959
Product: MediaWiki-Vagrant
Classification: Unclassified
labs-vagrant (Other open bugs)
unspecified
All All
: High normal
: ---
Assigned To: Bryan Davis
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-20 19:44 UTC by Yuri Astrakhan
Modified: 2014-09-22 17:37 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Yuri Astrakhan 2014-09-20 19:44:18 UTC
vagrant 9c2935d7b656473b77825a1effd2e45b51a5f6b1 when running labs provision on an existing instance:

See http://pastebin.com/PMz7JVum

Error: mwscript importDump.php --wiki=wiki /vagrant/puppet/modules/labs/files/labs_privacy_policy.xml returned 1 instead of one of [0]
Error: /Stage[main]/Role::Labs_initial_content/Mediawiki::Import_dump[labs_privacy]/Exec[import_dump_labs_privacy]/returns: change from notrun to 0 failed: mwscript importDump.php --wiki=wiki /vagrant/puppet/modules/labs/files/labs_privacy_policy.xml returned 1 instead of one of [0]

Following 

Notice: /Stage[main]/Role::Labs_initial_content/Mediawiki::Import_dump[labs_privacy]/Exec[import_dump_labs_privacy]/returns: PHP Warning:  chdir(): Permission denied (errno 13) in /var/www/w/MWVersion.php on line 62
Comment 1 Yuri Astrakhan 2014-09-21 01:13:35 UTC
Updated info: just built a new instance: created instance, added vagrant-labs role, waited until it was done, and did a labs-vagrant provision. The first provision succeeded, but re-running provisioning without any modifications caused an error:

Error: mwscript importDump.php --wiki=wiki /vagrant/puppet/modules/labs/files/labs_privacy_policy.xml returned 1 instead of one of [0]
Error: /Stage[main]/Role::Labs_initial_content/Mediawiki::Import_dump[labs_priva                                                                                                             cy]/Exec[import_dump_labs_privacy]/returns: change from notrun to 0 failed: mwscript importDump.php --wiki=wiki /vagrant/puppet/modules/labs/files/labs_privacy_policy.xml returned 1 instead of one of [0]

The website reports:

[2b2994d1] / Exception from line 1302 of /srv/vagrant/mediawiki/includes/cache/LocalisationCache.php: Unable to open CDB file "/vagrant/mediawiki/cache/l10n_cache-en.cdb.tmp.934868137" for write.
Comment 2 Bryan Davis 2014-09-22 15:27:38 UTC
The permissions on the git clone of the mediawiki-vagrant repository are incorrect. The files are disk end up being readable only by the vagrant user and members of the wikidev group. This is obviously not what we want. Caused by I3eea91a5933af31457a3ac24624e0fda82d61849.
Comment 3 Bryan Davis 2014-09-22 15:41:08 UTC
The git clone permissions problem may only affect my test box? I kind of skipped over Yuri's analysis when I saw the same top level error message from puppet. For me, the base directory at /srv/vagrant has the desired permissions (2775) but the mediawiki clone at /srv/vagrant/mediawiki ended up with 2770 permissions. I fixed with `sudo chmod -R o+rX /srv/vagrant/mediawiki` which gets me past that particular problem.

Once I had cleared the code readability hurdle, I hit the same issue that Yuri reported. I think this issue is caused by I86b110b6ac2e92f4796b94f82f8ffb59d2ae23e2 which switched the default l10n cache behavior to use cdb files. In a VM-based MediaWiki-Vagrant deploy the /vagrant directory would be mounted in such a way as to ignore the file permissions and allow www-data to write to /vagrant/mediawiki/cache. On a Labs instance this is not the case. There are a couple of ways this could be fixed, but the easiest is probably to follow the lead of the logging permissions fix introduced in I194d788d1254c1e05ea53937b4663faaed537b62 and grant www-data write permissions to the /vagrant/mediawiki/cache directory.
Comment 4 Bryan Davis 2014-09-22 15:45:03 UTC
(In reply to Bryan Davis from comment #3)
> There are a couple of ways this could be
> fixed, but the easiest is probably to follow the lead of the logging
> permissions fix introduced in I194d788d1254c1e05ea53937b4663faaed537b62 and
> grant www-data write permissions to the /vagrant/mediawiki/cache directory.

Actually this is not likely to be the best fix in this particular instance as the /vagrant/mediawiki is managed by the puppet code from mediawiki-vagrant and not the puppet code from operations/puppet. Maybe the best thing to do here is adjust the default cache directory within mediawiki-vagrant itself. If we put the cache in a location that is not exported from the host os when using Vagrant proper we will probably get better performance there as a happy side effect.
Comment 5 Bryan Davis 2014-09-22 15:54:28 UTC
(In reply to Bryan Davis from comment #4)
> (In reply to Bryan Davis from comment #3)
> > There are a couple of ways this could be
> > fixed, but the easiest is probably to follow the lead of the logging
> > permissions fix introduced in I194d788d1254c1e05ea53937b4663faaed537b62 and
> > grant www-data write permissions to the /vagrant/mediawiki/cache directory.
> 
> Actually this is not likely to be the best fix in this particular instance
> as the /vagrant/mediawiki is managed by the puppet code from
> mediawiki-vagrant and not the puppet code from operations/puppet. Maybe the
> best thing to do here is adjust the default cache directory within
> mediawiki-vagrant itself. If we put the cache in a location that is not
> exported from the host os when using Vagrant proper we will probably get
> better performance there as a happy side effect.

The ::mediawiki class already provisions a directory explicitly for caching content (https://github.com/wikimedia/mediawiki-vagrant/blob/master/puppet/modules/mediawiki/manifests/init.pp#L94-L99). There however is apparently no LocalSettings configuration that tells MW to use this directory. When I86b110b6ac2e92f4796b94f82f8ffb59d2ae23e2 introduced using $IP/cache for this it was doing a good thing, but possibly in the wrong way.
Comment 6 Dan Duvall 2014-09-22 17:36:25 UTC
I believe this is a duplicate of bug 70959 for which a patch has been submitted (I45def381a30c5c0719ab38ca627c7c91df91c5e3).
Comment 7 Dan Duvall 2014-09-22 17:37:56 UTC

*** This bug has been marked as a duplicate of bug 70959 ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links