Last modified: 2014-08-04 00:43:45 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?
(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
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…)
(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..
I think this can be closed once bug 64748 has been verified as fixed.
(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.