Last modified: 2014-11-12 10:59:35 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 T65396, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63396 - Beta cluster centralauth accounts points to no longer existing wikis
Beta cluster centralauth accounts points to no longer existing wikis
Status: NEW
Product: Wikimedia Labs
Classification: Unclassified
deployment-prep (beta) (Other open bugs)
unspecified
All All
: Unprioritized normal
: ---
Assigned To: Nobody - You can work on this!
:
: 66401 72773 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-01 22:55 UTC by Alex Monk
Modified: 2014-11-12 10:59 UTC (History)
9 users (show)

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


Attachments

Description Alex Monk 2014-04-01 22:55:51 UTC
"Sorry! This site is experiencing technical difficulties." with a title that hasn't been parsed for {{SITENAME}} and the error "Cannot contact the database server: Unknown database 'cswiki' (10.68.16.193)"

(tested on en.wikipedia.beta.wmflabs.org)
Comment 1 Alex Monk 2014-04-18 18:12:48 UTC
Fixed it by querying the wikis I was attached on, comparing it to all.dblist-labs and killing the localuser entries for those which don't exist:

sudo -u apache mwscript eval.php --wiki=enwiki

CentralAuthUser::getCentralDB()->delete( 'localuser', array( 'lu_name' => 'Krenair', 'lu_wiki' => array( 'cswiki', 'cswikibooks', 'cswikinews', 'cswikisource', 'dewikinews', 'frwiki', 'incubatorwiki' ) ) );

Other people probably have similar issues though.
Comment 2 Alex Monk 2014-04-18 18:26:36 UTC
sigh, still get it on logging in for some reason...
Comment 3 Alex Monk 2014-04-18 18:36:49 UTC
$db = CentralAuthUser::getCentralDB();
$wikiList = CentralAuthUser::getWikiList();
$db->delete( 'localuser', array( 'lu_name' => 'Krenair', 'lu_wiki NOT IN (' . $db->makeList( $wikiList ) . ')' ) );
$db->delete( 'localnames', array( 'ln_name' => 'Krenair', 'ln_wiki NOT IN (' . $db->makeList( $wikiList ) . ')' ) );

I can log in now
Comment 4 Antoine "hashar" Musso (WMF) 2014-10-24 14:30:26 UTC
*** Bug 66401 has been marked as a duplicate of this bug. ***
Comment 5 Antoine "hashar" Musso (WMF) 2014-10-24 14:30:51 UTC
Reusing topic of duplicate bug 66401
Comment 6 Alex Monk 2014-10-24 16:25:23 UTC
There's some slightly weird cases around the code I posted. Some quotes from IRC so they aren't missed.

<Krenair> on deployment-prep, if I run this query:
<Krenair> show databases where `Database` not in ('arwiki','cawiki','commonswiki','deploymentwiki','dewiki','ee_prototypewiki','en_rtlwiki','enwiki','enwikibooks','enwikinews','enwikiquote','enwikisource','enwikiversity','enwiktionary','eowiki','eswiki','fawiki','hewiki','hiwiki','jawiki','kowiki','loginwiki','metawiki','ruwiki','simplewiki','sqwiki','testwiki','ukwiki','wikidatawiki','zhwiki');
<Krenair> (that list of wiki DBs is from CentralAuthUser::getWikiList())
<Krenair> I get some entries back which should be listed by CentralAuthUser::getWikiList()....
<Krenair> At least aawiki, not sure about others
<Krenair> these look like wiki dbs: auth, dewikinews, dewikivoyage, enwikivoyage, labswiki
<Krenair> no idea what/where auth or labswiki are supposed to be. dewikinews/dewikivoyage/enwikivoyage return "No wiki found" at the normal hostnames.
Comment 7 Alex Monk 2014-10-24 16:25:58 UTC
(Additionally, centralauth.localnames/localusers seems to have a ton of references to wikis that AFAIK have never been in deployment-prep?)
Comment 8 Alex Monk 2014-10-30 19:10:44 UTC
*** Bug 72773 has been marked as a duplicate of this bug. ***
Comment 9 Antoine "hashar" Musso (WMF) 2014-11-12 10:59:35 UTC
From a mail Bryan Davis sent me a while ago:

When folks reported not being able to log in to deployment.beta and
Chad and I both realized "wiki rename" at the same time here's what I
did to try and fix:

Using this script:

$ cat betasql
#!/bin/sh

USER=`php -r 'include("/a/common/wmf-config/PrivateSettings.php");
print $wgDBuser;'`
PASS=`php -r 'include("/a/common/wmf-config/PrivateSettings.php");
print $wgDBpassword;'`
HOST="deployment-db1"
mysql -u $USER -p$PASS -h $HOST


> use centralauth
> update localuser set lu_wiki = 'deploymentwiki' where lu_wiki = 'labswiki';
Query OK, 940 rows affected (0.39 sec)
Rows matched: 940  Changed: 940  Warnings: 0

> update localnames set ln_wiki = 'deploymentwiki' where ln_wiki = 'labswiki';
Query OK, 943 rows affected (0.54 sec)
Rows matched: 943  Changed: 943  Warnings: 0

> update globaluser set gu_home_db = 'deploymentwiki' where gu_home_db = 'labswiki';
Query OK, 84 rows affected (0.49 sec)
Rows matched: 84  Changed: 84  Warnings: 0

I also looked at wikiset.ws_wikis and renameuser_status.ru_wiki but
neither of them mentioned the old labswiki name.

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


Navigation
Links