Last modified: 2014-08-04 00:43:45 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 T38363, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 36363 - Either undo php->php-1.xx symlink messiness, or automate archiving of old MediaWiki versions
Either undo php->php-1.xx symlink messiness, or automate archiving of old Med...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Deployment systems (Other open bugs)
wmf-deployment
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
incident-report
:
Depends on: 64748
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-01 01:29 UTC by Rob Lanphier
Modified: 2014-08-04 00:43 UTC (History)
6 users (show)

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


Attachments

Description Rob Lanphier 2012-05-01 01:29:36 UTC
In our current file structure in nfs and on the apaches, we have something to the effect of:
/home/wikipedia/common/php

...which is a symlink to:

/home/wikipedia/common/php-1.20wmf1

...as of this writing.  We managed to cause site problems today by nuking the old php-1.19 problem, and seem destined to cause the same problem nuking php-1.20wmf1.

Can we either eliminate the need for this symlink, or barring that, automate the archiving process for old MediaWiki source directories?
Comment 1 Sam Reed (reedy) 2012-05-01 10:21:58 UTC
(In reply to comment #0)
> In our current file structure in nfs and on the apaches, we have something to
> the effect of:
> /home/wikipedia/common/php
> 
> ...which is a symlink to:
> 
> /home/wikipedia/common/php-1.20wmf1
> 
> ...as of this writing.  We managed to cause site problems today by nuking the
> old php-1.19 problem, and seem destined to cause the same problem nuking
> php-1.20wmf1.
> 
> Can we either eliminate the need for this symlink, or barring that, automate
> the archiving process for old MediaWiki source directories?

If the symlink had been updated to point to php-1.20wmf1 (rather than php-1.19), and then pushed at the same point (or the symlink pushed first!), the issues won't have happened
Comment 2 p858snake 2012-05-03 20:46:28 UTC
Is there a easy way to find out what actually uses the end results of the php symlink? So it might be easier to kill it off (I know the wikipedia.org welcome mat for one…)
Comment 3 Sam Reed (reedy) 2013-06-18 21:25:59 UTC
(In reply to comment #2)
> Is there a easy way to find out what actually uses the end results of the php
> symlink? So it might be easier to kill it off (I know the wikipedia.org
> welcome
> mat for one…)

I think most of the usages would be more external - rather than stuff generally controlled by normal deployments etc


They might appear in the access logs..
Comment 4 Bryan Davis 2014-05-27 15:26:57 UTC
I think this can be closed once bug 64748 has been verified as fixed.
Comment 5 Andre Klapper 2014-08-04 00:43:45 UTC
(In reply to Bryan Davis from comment #4)
> I think this can be closed once bug 64748 has been verified as fixed.

You closed bug 64748 as FIXED, so I assume that this is also FIXED.

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


Navigation
Links