I accidentally overwrote replica.my.cnf for toolsbeta.admin. Please restore it.
To resolve this task:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • madhuvishy | T135931 Tool Labs users missing replica.my.cnf (tracking) | |||
| Declined | None | T109807 Restore replica.my.cnf for toolsbeta.admin |
The process for (re-)generating replica.my.cnf is described at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Admin#Regenerate_replica.my.cnf.
Hmm, so the code currently only writes new replica.my.cnf files for tools accounts and not for other projects... I am not entirely sure what's the best way to fix this - easiest is probably to just create a tool account and copy its credentials, better way is to probably make it generate credentials for toolsbeta as well.
Where is create-dbusers restricted to Toolforge accounts? Why should /usr/local/sbin/create-dbusers --config /etc/create-dbusers.yaml --once --project toolsbeta not work?
The short answer is: despite the presence of a "project" option there is no multi-tenancy thinking at all. I made some notes on this mechanism here but if we were to do toolsbeta it would be a race to finish for any accounts with any other project. One account (u$ID), and one replica file, would be created once for one project and never again for any other. The project option is a ruse at the moment. We can do this for toolsbeta for a particular test tool account or some such if that's helpful but actually using create-dbusers across projects that are not Tools in any serious manner is not viable for the moment.
Perhaps I'm missing something here. I did not ask for create-dbusers to run continuously to create replica.my.cnf for any new service group in the Toolsbeta project. I asked:
Why should /usr/local/sbin/create-dbusers --config /etc/create-dbusers.yaml --once --project toolsbeta not work?
Why should that be a "race to finish" and cause "accounts to never again be created for any other projects"?
Ah, okay, you removed --once in 7a9a70c541f2a1d44c23d2e7086b540b5224cce4. "* Interval defaults to 0 instead of a --once option" probably means then --interval 0 or something like that.
When an account for u1234 is created it sets up the DB user, grants, and dumps to replica file. It has no project awareness in any of those places even though users span projects. So if two projects have their credential files managed by this mechanism it would create in the first case, and in the second it would see a user in the db already and bail out. That's as intended at the moment . So it's a race for which project is seen and acted upon first.
I'm trying to respond to the general --project option in play here. It's not a thing that can be used generally. For a single one-off account in toolsbeta we don't expect to be used anywhere else we could figure something out. Otherwise, it's not to be used for now as its use was never actually thought through.
@chasemp: Thanks for the explanation. Running maintain-dbusers for several projects in parallel would indeed be problematic for user accounts.
I don't want to see this issue blocked on coming up with a will-work-for-eternity solution to the underlying issues; if the password for s51594 (toolsbeta.admin) needs to be queried manually one time (or the account in MySQL created manually), I'm fine with that as I don't intend to delete replica.my.cnf again :-).
So please get or set a password for s51594 once and write it in the project toolsbeta to the file /data/project/admin/replica.my.cnf. Thanks.
@scfc your home directory on tools should now have a replica file with credentials for your user (not tool) - you could use these credentials for admin purposes on other projects, given we don't actually create tool specific mysql accounts for projects outside tools. Would that work for you?