Our wiki instances are running fedora 32 and an older version of mediawiki, we should move them to f34.
In staging I have already done this, but the database upgrade crashes out:
... Beginning migration of recentchanges.rc_user and recentchanges.rc_user_text to recentchanges.rc_actor Completed migration, updated 0 row(s) with 0 new actor(s), 0 error(s) Beginning migration of logging.log_user and logging.log_user_text to logging.log_actor ... log_id=600 Wikimedia\Rdbms\DBQueryError from line 1699 of /usr/share/mediawiki/includes/libs/rdbms/database/Database.php: Error 1062: Duplicate entry '' for key 'actor_name' (db03) Function: MigrateActors::addActorsForRows Query: INSERT INTO `en_actor` (actor_name) VALUES ('') #0 /usr/share/mediawiki/includes/libs/rdbms/database/Database.php(1683): Wikimedia\Rdbms\Database->getQueryException() #1 /usr/share/mediawiki/includes/libs/rdbms/database/Database.php(1658): Wikimedia\Rdbms\Database->getQueryExceptionAndLog() #2 /usr/share/mediawiki/includes/libs/rdbms/database/Database.php(1227): Wikimedia\Rdbms\Database->reportQueryError() #3 /usr/share/mediawiki/includes/libs/rdbms/database/Database.php(2343): Wikimedia\Rdbms\Database->query() #4 /usr/share/mediawiki/includes/libs/rdbms/database/Database.php(2323): Wikimedia\Rdbms\Database->doInsert() #5 /usr/share/mediawiki/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->insert() #6 /usr/share/mediawiki/includes/libs/rdbms/database/DBConnRef.php(369): Wikimedia\Rdbms\DBConnRef->__call() #7 /usr/share/mediawiki/maintenance/includes/MigrateActors.php(219): Wikimedia\Rdbms\DBConnRef->insert() #8 /usr/share/mediawiki/maintenance/includes/MigrateActors.php(305): MigrateActors->addActorsForRows() #9 /usr/share/mediawiki/maintenance/includes/MigrateActors.php(115): MigrateActors->migrate() #10 /usr/share/mediawiki/maintenance/includes/LoggedUpdateMaintenance.php(45): MigrateActors->doDBUpdates() #11 /usr/share/mediawiki/includes/installer/DatabaseUpdater.php(1385): LoggedUpdateMaintenance->execute() #12 /usr/share/mediawiki/includes/installer/DatabaseUpdater.php(554): DatabaseUpdater->migrateActors() #13 /usr/share/mediawiki/includes/installer/DatabaseUpdater.php(517): DatabaseUpdater->runUpdates() #14 /usr/share/mediawiki/maintenance/update.php(181): DatabaseUpdater->doUpdates() #15 /usr/share/mediawiki/maintenance/doMaintenance.php(107): UpdateMediaWiki->execute() #16 /usr/share/mediawiki/maintenance/update.php(253): require_once('/usr/share/medi...') #17 {main}
Somehow when it converts users to actors, it converts a '' one. ;(
select * from en_actor where actor_name = ''; +----------+------------+------------+ | actor_id | actor_user | actor_name | +----------+------------+------------+ | 235697 | NULL | | +----------+------------+------------+ 1 row in set (0.001 sec)
We need to finish staging and get it working, then do prod.
Metadata Update from @asaleh: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: medium-gain, medium-trouble, ops
ok, so I poked at the database and found the old logs that it didn't like (which were from 2008 when it was imported from moinmoin) and cleaned them up and got the upgrade to finish.
Now, auth isn't working. :(
@abompard might you be able to take a look? It's saying I need to sign the FPCA, but we fixed that in prod and it's copying that fix in... so I am not sure whats going on.
I'll have a look.
Oops, my mistake. The ipsilon install in staging was incomplete. I did downgrade the package to a version that did not have a specific field for the OTP token, but forgot to re-apply our fedora-specific patch afterwards, so Ipsilon was still using the old FAS information database, which failed, and thus did not find any groups for users.
Fixed now, sorry about that.
Ah ha. No worries. Probibly should get that patch into ansible?
So, it now logs me in, but it logged me in as a new 'kevin1' user. ;( Any ideas there?
I suppose that's because your regular username is already in the database from the prod instance. Unicity is username and OIDC issuer which is id.stg.fp.o on staging and id.fp.o on prod.
id.stg.fp.o
id.fp.o
The patch is already in ansible, it's just that I downgraded the rpm manually on the staging server.
It never used to be this way... I could dump the prod db, move it to staging and login as my user. ;( I suppose we could tweak the db when moving it... or is there some way to have id == id.stg for this purpose?
I didn't find an easy way to make the OpenIDC plugin accept id.stg as id but I've tested that by running a SQL query on the DB after the prod copy, login works. The SQL is just:
id.stg
id
UPDATE en_openid_connect SET oidc_issuer = 'https://id.stg.fedoraproject.org/openidc/' WHERE oidc_issuer = 'https://id.fedoraproject.org/openidc/';
Could this be added to the database copy playbook? I can do it but I haven't found it.
ok. Just odd that we have to do this now. ;(
@puiterwijk might know more...
Yeah I don't know why it worked before. But I think it's more correct to change the data on import to adapt it to staging rather than adding conditionals or configuration items to the software.
This is now complete in prod.
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.