Page MenuHomePhabricator

Cannot assign user name "XXX" to account ####; name already in use.
Closed, ResolvedPublic

Description

Hi, it seems that @Kipcool and @Albert221 are also affected by the same issue as in T197083

Cannot assign user name "kipcool" to account 6839; name already in use.
Cannot assign user name "albert221" to account 6851; name already in use.

@Kipcool has not logged in for several months, so maybe there is something new to do that I don't know, or maybe my account has been buggy for quite some time. Have tried "kipcool" or "Kipcool", same result.

@Albert221 has not logged in since Feb 2018 which predate the Gerrit upgrade that caused T197083

I can log in fine at wikitech. Only gerrit won't let me in.

$ grep -i kipcool error_log.2019-02-19 |grep -v Incorrect|cut -d\  -f1,2,4-
[2019-02-19 19:18:36,865] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6816; name already in use.
[2019-02-19 19:19:28,273] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6817; name already in use.
[2019-02-19 19:35:51,112] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6818; name already in use.
[2019-02-19 19:36:11,966] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6819; name already in use.
[2019-02-19 19:36:43,478] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6820; name already in use.
[2019-02-19 19:39:12,391] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6821; name already in use.
[2019-02-19 19:39:19,321] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6822; name already in use.
[2019-02-19 19:39:22,095] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6823; name already in use.
[2019-02-19 19:41:13,055] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6824; name already in use.
[2019-02-19 19:42:47,006] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6825; name already in use.
[2019-02-19 19:47:19,276] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6826; name already in use.
[2019-02-19 19:47:27,160] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6827; name already in use.
[2019-02-19 19:47:36,346] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6828; name already in use.
[2019-02-19 19:54:48,080] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6829; name already in use.
[2019-02-19 19:54:50,202] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6830; name already in use.
[2019-02-19 19:54:54,228] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6831; name already in use.
[2019-02-19 19:54:57,225] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6832; name already in use.
[2019-02-19 19:54:59,382] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6833; name already in use.
[2019-02-19 19:55:01,239] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6834; name already in use.
[2019-02-19 19:55:02,561] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6835; name already in use.
[2019-02-19 19:55:08,604] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6836; name already in use.
[2019-02-19 19:58:03,026] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6837; name already in use.
[2019-02-19 20:07:00,467] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6838; name already in use.
[2019-02-19 20:07:02,078] ERROR com.google.gerrit.server.account.AccountManager : Cannot assign user name "kipcool" to account 6839; name already in use.

Seems like on every login account, Gerrit attempts to create a new user :(

In All-Users.git we can find the commit that created the account.config file in NoteDB:

commit e3e003247bca2554fdbef03fb365805f2ea4fef9
Author:     Gerrit Code Review <gerrit@wikimedia.org>
AuthorDate: Fri Jun 8 17:17:03 2018 +0000
Commit:     Gerrit Code Review <gerrit@wikimedia.org>
CommitDate: Fri Jun 8 17:17:03 2018 +0000

    Update account

diff --git a/account.config b/account.config
new file mode 100644
index 00000000..2319f43e
--- /dev/null
+++ b/account.config
@@ -0,0 +1,3 @@
+[account]
+       fullName = Kipcool
+       preferredEmail = kipmaster@gmail.com

Which points to user id 609:

$ git for-each-ref --contains e3e003247bca2554fdbef03fb365805f2ea4fef9
e3e003247bca2554fdbef03fb365805f2ea4fef9 commit	refs/remotes/origin/users/09/609
$ git ls-tree origin/users/09/609
100644 blob 2319f43e33fd1099477ecbfbd1ded06bc0f57375	account.config
100644 blob f5cdd3c6790d7c22bc4bf6266eae3053bf71bb64	authorized_keys
100644 blob 0502821edc0cf51309b58471fd8402507a71b297	preferences.config
100644 blob cd0b5f97808f0701fb6bccdda28831994f3f12a7	watch.config
$ git show origin/users/09/609:account.config 
[account]
        fullName = Kipcool
        preferredEmail = kipmaster@gmail.com

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 20 2019, 11:31 AM
hashar updated the task description. (Show Details)Feb 20 2019, 12:32 PM
gerrit> select * from account_external_ids where external_id LIKE '%ipcool%';
 account_id | email_address       | password | external_id
 -----------+---------------------+----------+-----------------
 609        | kipmaster@gmail.com | NULL     | gerrit:Kipcool
 609        | NULL                | NULL     | username:kipcool
(2 rows; 16 ms)

@mmodell and @thcipriani previously dealt with a similar issue in T197083. They would probably know what needs to be done.

His account is missing a external id. Also this is no longer stored in the db, the db will be out dated now. It’s all stored in All-Users under refs/external* or (similar)

Indeed sorry, the accounts external ids are stored as git notes in refs/meta/external-ids:

$ git fetch origin refs/meta/external-ids
$ git checkout -b meta/external-ids FETCH_HEAD
$ git grep -i kipcool
6c/84cc1cfca1fbbc7f405b7a9f5c6510a7d6ad82:[externalId "username:kipcool"]
c2/18e23df72c4871cc4089f0979df44c00cc4cd8:[externalId "gerrit:Kipcool"]

The file is the sha1 sum of the id (eg: username:kipcool or gerrit:Kipcool). I guess the issue is due to the mismatching case. It is easy to change, just edit the file, get the sha1sum of the new key and git move the file. Then one with Database access right can push the notes to refs/meta/external-ids.

Then, I am not sure whether we need to use the all lower case account (kipcool) or the camel case one (Kipcool).


From T197083 , we also have another case mismatch:

aa/5f73819965682d225b8cc56df028b2c626ddea:[externalId "username:Kaldari"]
b3/d4b7a688fcf1202457de9031d4bbe36eeb707d:[externalId "gerrit:kaldari"]
ba/4d5d08c2e71dfa36b36ae06f3a6f8ac90d81ff:[externalId "username:kaldari"]
hashar renamed this task from Cannot assign user name "kipcool" to account 6839; name already in use. to Cannot assign user name "XXX" to account ####; name already in use..Feb 20 2019, 4:21 PM
hashar triaged this task as High priority.
hashar updated the task description. (Show Details)
hashar updated the task description. (Show Details)
hashar added a subscriber: Albert221.

@Albert221 has a similar issue:

All-Users$ git fetch origin refs/meta/externals-id
All-Users$ git grep -i albert221
80/e6adae5c49fadbb97697d11da542868c34d532:[externalId "username:albert221"]
af/f9df51330719d69bc40004cb18815156b8ab52:[externalId "gerrit:Albert221"]

The external ids mismatch :(

hashar added a comment.EditedFeb 20 2019, 4:57 PM

We can not fix accounts one by one. Gerrit enforces a validation when pushing to refs/meta/external-ids. I gave it a try using:

git clone All-Users.git
git fetch origin refs/meta/external-ids
git checkout -b meta/external-ids FETCH_HEAD
git touch foo && git commit -a -m 'dummy commit'
git push origin HEAD:refs/for/refs/meta/external-ids

Gerrit then complains with lot of accounts having duplicate emails. Since I don't know whether those emails are public, I pasted the output to a private/restricted task T216632.

Maybe a git push --force would bypass the validation, but I would rather not try that against the production Gerrit.

If we can find a reliable fix (eg normalize to all lower case?), we can write a quick script that fix all entries, push the result and we will be set.

sbassett set Security to Software security bug.Feb 20 2019, 6:59 PM
sbassett added a project: Security.
sbassett changed the visibility from "Public (No Login Required)" to "Custom Policy".
sbassett added a subscriber: sbassett.

Protecting this for now, since user emails are exposed, which we typically don't want in public Phab tasks.

Protecting this for now, since user emails are exposed, which we typically don't want in public Phab tasks.

Though the emails are already publicly available. They are used by git/gerrit :)

Though the emails are already publicly available. They are used by git/gerrit :)

Fair enough, just being paranoid.

Our Gerrit instance has ldap.localUsernameToLowerCase = true. Reading the doc at https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#ldap.localUsernameToLowerCase :

ldap.localUsernameToLowerCase
Converts the local username, that is used to login into the Gerrit Web UI, to lower case before doing the LDAP authentication. By setting this parameter to true, a case insensitive login to the Gerrit Web UI can be achieved.
If set, it must be ensured that the local usernames for all existing accounts are converted to lower case, otherwise a user that has a local username that contains upper case characters will not be able to login anymore.
The local usernames for the existing accounts can be converted to lower case by running the server program LocalUsernamesToLowerCase. Please be aware that the conversion of the local usernames to lower case can’t be undone. For newly created accounts the local username will be directly stored in lower case.

I then head to the doc for the program LocalUsernamesToLowerCase at https://gerrit-review.googlesource.com/Documentation/pgm-LocalUsernamesToLowerCase.html

Converts the local username for every account to lower case. The local username is the username that is used to login into the Gerrit Web UI. The local username is stored a external ID with scheme gerrit.

IMPORTANT: This program does not modify usernames in the username scheme.

So if I understand it properly all local ids use the scheme gerrit and they should all have a lower case name (for example: gerrit:hashar). In the username scheme it seems acceptable to have mixed case (for example: username:Hashar).

In All-Users.git we have lot of local accounts having upper case letters:

$ git grep 'gerrit:.*[A-Z].*'|wc -l
1519

Which includes Kipcool and Albert211.


@thcipriani and @mmodell looks to me we want to shutdown Gerrit (to prevent user changes), make a backup of All-Users.git and run that conversion script. Knowing it can not be undone (hence the backup).

From the doc:

After all usernames have been migrated, the reindex program is automatically invoked to reindex all accounts.
This task cannot run in the background concurrently to the server; it must be run by itself.

I dont quite understand that last sentence. I seem to parse it as "must shutdown the actual server before running the program".

Though the emails are already publicly available. They are used by git/gerrit :)

Fair enough, just being paranoid.

No worries :)

@thcipriani and @mmodell looks to me we want to shutdown Gerrit (to prevent user changes), make a backup of All-Users.git and run that conversion script. Knowing it can not be undone (hence the backup).

This was done once previously: T155766: Gerrit: Schedule downtime to migrate all users username to lowercase

Although in an upstream discussion I had recently it's notable that one of the maintainers said:

The expectation would have been that running the LocalUsernamesToLower would have converted the existing "gerrit:Kxxxxxx" external ID to "gerrit:kxxxxxx". However from the ReviewDb data that you have provided above we can see that it was still "gerrit:Kxxxxxx" in ReviewDb before the migration to NoteDb. So either this program wasn't run or it did not work correctly.

So it seems like you're right, we need to run it again.

I was able to recreate this in my test instance by adding a user "UppercaseThcipriani", logging in, then enabling ldap.localUsernameToLowerCase (as we have set in production), logging out, and then logging in yielded, Cannot assign user name "UpperThcipriani" to account 1000006; name already in use. Meanwhile the All-Accounts DB flailed like:

commit 355f2c932995ebd1a8bb995593174a0bc6d232e4
Author: Gerrit Code Review <gerrit@capella.tylercipriani.com>
Date:   Wed Feb 27 15:42:13 2019 +0000

    Update external IDs

diff --git a/21932e70862b3be5786420faa38b5013005e59a2 b/21932e70862b3be5786420faa38b5013005e59a2
deleted file mode 100644
index bf8e689..0000000
--- a/21932e70862b3be5786420faa38b5013005e59a2
+++ /dev/null
@@ -1,2 +0,0 @@
-[externalId "gerrit:upperthcipriani"]
-       accountId = 1000006

commit 57dee0e55bb46cf88bcf36e9bd8ede6c6e25947b
Author: Gerrit Code Review <gerrit@capella.tylercipriani.com>
Date:   Wed Feb 27 15:42:13 2019 +0000

    Update external IDs

diff --git a/21932e70862b3be5786420faa38b5013005e59a2 b/21932e70862b3be5786420faa38b5013005e59a2
new file mode 100644
index 0000000..bf8e689
--- /dev/null
+++ b/21932e70862b3be5786420faa38b5013005e59a2
@@ -0,0 +1,2 @@
+[externalId "gerrit:upperthcipriani"]
+       accountId = 1000006

Unfortunately, I wasn't able to test LocalUsernamesToLowerCase -- it failed with errors about injectors. Manually adding the gerrit:upperthcipriani externalId with the correct accountId using git on the local machine worked fine. i.e.:

git clone ~/gerrit_reviewsite/git/All-Users.git ~/All-Users-$(date -I)
cd ~/All-Users-$(date -I)
git fetch refs/meta/external-ids:refs/meta/external-ids
git checkout FETCH_HEAD
printf '[externalId "username:upperthcipriani"]\n\taccountId = 1000004\n' > \
    $(printf 'username:upperthcipriani' | shasum -a 1 | awk '{print $1}')
git add .
git commit -m 'thcipriani: fix accountId for UpperThcipriani'
git push origin HEAD:refs/meta/external-ids

This is roughly equivalent to what we did in the case of T197083 and should work fine for one-offs, but if this is a bigger problem, we should schedule some downtime (since it needs an offline reindex to run) the LocalUsernamesToLowercase script...again.

Maybe a git push --force would bypass the validation, but I would rather not try that against the production Gerrit.

Nope. This is filed upstream as: https://bugs.chromium.org/p/gerrit/issues/detail?id=9318

If we can find a reliable fix (eg normalize to all lower case?), we can write a quick script that fix all entries, push the result and we will be set.

This is effectively what LocalUsernamesToLowercase does, i.e., all externalId "gerrit:Xxxx" -> externalId "gerrit:xxxx"

Good thanks Tyler for confirming my assumption!

Given LocalUsernamesToLowercase failed on your local Gerrit -which I assume is the same version as prod-, I guess we are a bit blocked there aren't we? :-/

That's fixed with the 2.16 (from my testing using the prod puppet class).

I think this commit https://github.com/GerritCodeReview/gerrit/commit/c9cb9a8bd5163cdd249e6abd3e399d8b40d4d9e6 fixed it but cannot be backported.

Good thanks Tyler for confirming my assumption!
Given LocalUsernamesToLowercase failed on your local Gerrit -which I assume is the same version as prod-, I guess we are a bit blocked there aren't we? :-/

I attempted some manual git-ref surgery this morning for the 2 users listed on this task. @Kipcool and @Albert221 -- could you try logging into gerrit again when you get a chance?

That's fixed with the 2.16 (from my testing using the prod puppet class).
I think this commit https://github.com/GerritCodeReview/gerrit/commit/c9cb9a8bd5163cdd249e6abd3e399d8b40d4d9e6 fixed it but cannot be backported.

Bummer that it can't be backported. Does that mean we'll have to wait for the 2.16 upgrade to attempt this? I'd rather not try the upgrade and the rename all at once :\

@thcipriani : It worked for me, I can now log into gerrit. Thanks!

Stryn added a subscriber: Stryn.Mar 13 2019, 4:35 PM

I tried to use Gerrit but can't.

Cannot assign user name "stryn" to account 6932; name already in use.

@dschwen is also affected. I tried pushing an update to the external-ids and got this from gerrit:

remote: error: commit 38a1a1b: email address gerrit@wikimedia.org is not registered in your account, and you lack 'forge committer' permission.

I'm not sure why it's trying to set the committer to gerrit@wikimedia.org. How were we able to update these before? Any ideas @thcipriani?

hashar added a comment.EditedMar 26 2019, 6:31 PM

@dschwen is also affected. I tried pushing an update to the external-ids and got this from gerrit:

remote: error: commit 38a1a1b: email address gerrit@wikimedia.org is not registered in your account, and you lack 'forge committer' permission.

I'm not sure why it's trying to set the committer to gerrit@wikimedia.org. How were we able to update these before? Any ideas @thcipriani?

That is unrelated to this task. The git commit has Commit: XXXXX <gerrit@wikimedia.org> which is not a user registered in Gerrit and the end user does not have the permission to bypass that validation. See https://gerrit.wikimedia.org/r/Documentation/access-control.html#category_forge_committer When people send patches, they are usually the committer, an exception is when uploading third party patches eg when importing a repository (which also requires push rights).

There is also https://gerrit.wikimedia.org/r/Documentation/access-control.html#category_forge_author which lets one set the Author field, but there it also need to be a registered user in our instance.

TLDR: the commit author is wrong. We can fill another task and mention and the person should check the output of git config --get user.email.

@dschwen is also affected. I tried pushing an update to the external-ids and got this from gerrit:

remote: error: commit 38a1a1b: email address gerrit@wikimedia.org is not registered in your account, and you lack 'forge committer' permission.

I'm not sure why it's trying to set the committer to gerrit@wikimedia.org. How were we able to update these before? Any ideas @thcipriani?

recall last time we did this we ran into not only this problem, but also: https://bugs.chromium.org/p/gerrit/issues/detail?id=9318

What I've been doing, is creating my patch as the user on the server and pushing directly with cGit rather than passing through gerrit and jGit.

After pushing you need to reindex accounts which is a pretty painless process (https://www.gerritcodereview.com/cmd-index-start.html)

ssh -p 29418 gerrit.wikimedia.org -- gerrit index start accounts --force

I completely missed that it is @mmodell who was pushing to external-ids :-( Sorry!

Would it be because Gerrit generates the commit itself (hence committer being gerrit@wikimedia.org) and Mukunda lacks Administrative right to external-ids / Forge committer. Thus Gerrit ends up rejecting a commit it crafted itself since it uses Mukunda permissions.

I bet a member of the Administrator group would not face the same error. Or it is something entirely different.

Kipcool removed a subscriber: Kipcool.Mar 27 2019, 1:54 PM

@hashar: I had forgotten that there are multiple other things blocking me from pushing to that repo, so it would be futile even if I got past the permissions problem.

So we fixed @dschwen and @thcipriani made a nice script along the way. @thcipriani: did you post your gerrit-usernametoupper shell script somewhere?

Albert221 removed a subscriber: Albert221.Mar 29 2019, 12:49 PM

A couple more:

I guess we can keep renaming affected users manually?

And probably want to add Gerrit 2.16 upgrade as a blocker for the magic script LocalUsernamesToLowercase.

So we fixed @dschwen and @thcipriani made a nice script along the way. @thcipriani: did you post your gerrit-usernametoupper shell script somewhere?

https://gist.github.com/thcipriani/a46c63c5baa76a876b3b499df6690f6e

Hi, after several weeks, I have already been able to log in to Gerrit.

Hey, can this be done for these three users? Specially since the bash script is already there.

The last one needs it for the hackathon and I doubt 2.16 will be deployed by then.

Hey, can this be done for these three users? Specially since the bash script is already there.

The last one needs it for the hackathon and I doubt 2.16 will be deployed by then.

Thanks for amalgamating these. I did fixed all of these accounts just now (I hope).

Dzahn added a subscriber: Dzahn.May 8 2019, 2:37 PM

Is there something in this ticket that can't be public? We have/had several individual user tickets that are public and for the same problem and normally i would just send them here.

hashar added a comment.May 8 2019, 4:22 PM

It has been converted to a security/private task via T216605#4969481 due to user emails being disclosed. Then those emails are already publicly available via the Gerrit web interface. One might want to have a close look at all the content of this task, but my guess is that it can be made public again.

@hashar @Dzahn - this task should be fine to be made public in regards to PII exposure, I was just being overly-paranoid before re: gerrit account emails. And as long as there aren't any outstanding security issues being actively discussed or worked on here, that should be fine as well.

I've done some digging and have found that over 1512 users account are broken! (they contain caps).

See {P8523}

mmodell changed the visibility from "Custom Policy" to "Public (No Login Required)".May 30 2019, 5:09 PM
Mhurd added a subscriber: Mhurd.May 30 2019, 5:13 PM

Happening to me too:

Happening to me too:

Fixed this one up last week.

I've done some digging and have found that over 1512 users account are broken! (they contain caps).

Some of those users, weirdly, have lowercase versions of their uppercase username; i.e., gerrit:UpperCase and gerrit:uppercase both tied to the same account.

I wrote a small script to update All-Users, skipping those accounts that already have lowercase versions. It also does the sha1 file renaming needed for the strange structure of this repo:

1#!/usr/bin/env bash
2#
3# Gerrit Username To Lowercase
4# =====================
5#
6# Script for converting gerrit:-scheme usernames to lowercase directly
7# in a checkout of refs/meta/external-ids of the All-Users git repo.
8#
9# Copyright: Tyler Cipriani <tcipriani@wikimedia.org> 2019
10# License: GPLv3+
11
12# Utility logging methods
13info() {
14 printf '[INFO] %s' "$@"
15}
16println() {
17 printf '%s\n' "$@"
18}
19
20# Convert username with gerrit: schema to lowercase
21#
22# accepts a username as a mixed case string without a schema by:
23#
24# 1. Convert username mixed case to username lowercase
25# 2. Compute sha1sum of lowercase schema for use as new file name
26# 3. Find the old file name using git grep
27# 4. Git move the old file to the new file path (computed with sha1sum)
28# 5. Replace the username mixed-case in the new file with username lowercase
29#
30# param username: string, mixed case
31usernameToLower() {
32 local username username_lower shasum new_file old_file
33
34 username="$1"
35 username_lower="${username,,}"
36
37 shasum=$(printf "gerrit:%s" "${username_lower}" | shasum -a 1)
38
39 new_file=$(printf '%s/%s\n' "${shasum:0:2}" "${shasum:2:38}")
40 old_file=$(git grep --full-name --files-with-matches "\"gerrit:${username}\"")
41
42 if [ -f "$new_file" ]; then
43 println "The new file '${new_file}' exists!!!! for '${username}'. Aborting!"
44 exit 1
45 fi
46
47 git mv "$old_file" "$new_file"
48
49 # Change username to lowercase in new file
50 sed -i "s/gerrit:${username}/gerrit:${username_lower}/" "$new_file"
51}
52
53# Find any gerrit:-schema users with capital letters
54# Look to see if there is a lowercase version
55# If not, convert user to lowercase
56main() {
57 while read -r user; do
58 # Grep for lowercase user
59 if git grep "\\[externalId \"gerrit:${user,,}\"\\]" &>/dev/null; then
60 continue
61 fi
62 info "Converting ${user}..."
63 usernameToLower "$user"
64 println "DONE!"
65 done < <(git grep -P 'gerrit:.*[A-Z]+.*' | sed -e 's/.*:\[externalId "gerrit:\(.*\)"]/\1/')
66}
67
68main "$@"

This found 1305 accounts that had mixed/uppercase only usernames. This does essentially the same thing as the upstream usernameToLowercase script afaict.

Since logins are case-insensitive (and, seemingly, ldap login through the GUI is case insensitive, i.e., I can login with tHcIPrIani) -- this should be safe to run and apply, correct?

If so, we can apply the generated patch, reindex user accounts and resolve this ticket -- trying to think of any other implications of this that I missed here.

If so, we can apply the generated patch, reindex user accounts and resolve this ticket -- trying to think of any other implications of this that I missed here.

I say do it!

I concur with ^^.

Thanks for the enthusiasm :)

Could I get someone who is up-to-date on our LDAP setup (either @akosiaris or @bd808, I'm guessing) to review my assertions above? In particular:

Since logins are case-insensitive (and, seemingly, ldap login through the GUI is case insensitive, i.e., I can login with tHcIPrIani) -- this should be safe to run and apply, correct?

And

If so, we can apply the generated patch, reindex user accounts and resolve this ticket -- trying to think of any other implications of this that I missed here.

A conceptual +1 that I'm not about to shoot myself in the foot somehow would be nice assurance :)

Thanks for the enthusiasm :)
Could I get someone who is up-to-date on our LDAP setup (either @akosiaris or @bd808, I'm guessing) to review my assertions above? In particular:

Since logins are case-insensitive (and, seemingly, ldap login through the GUI is case insensitive, i.e., I can login with tHcIPrIani) --

This assertion is correct. All logins in LDAP are case-insensitive (have always been FWIW). This has led to other issues in the past and major effort to solve. You can have a look at T170150 (for my own past pain story) and T165795 (for bd808's pain story). The latter is a bit more involved and also proposes a solution to make the login case sensitive, albeit at a performance cost (see the task for numbers as it may or may not be a solution in this case).

this should be safe to run and apply, correct?

Well...

  • what's stopping people from making the same case mistakes and causing the issue again? Won't new accounts face that same problem? Or do we expect LocalUsernamesToLowerCase to mitigate that?
  • Are there perhaps people that have actually relied on the uppercase form (for reason not guessable by me currently)? Maybe they should be contacted and asked beforehand?

And

If so, we can apply the generated patch, reindex user accounts and resolve this ticket -- trying to think of any other implications of this that I missed here.

A conceptual +1 that I'm not about to shoot myself in the foot somehow would be nice assurance :)

Aside from my questions above, I don't see an issue with that.

Mess added a subscriber: Mess.EditedSat, Jun 29, 9:13 PM

I've tried to log in into Gerrit (my last access was 2 years ago) with my Wikitech account (which works fine), but I'm affected by the same issue (as portraited in the image below:

@thcipriani, could you please fix also my account (or at least explain how to solve it on my own, if possible)? Thank you.

  • what's stopping people from making the same case mistakes and causing the issue again? Won't new accounts face that same problem? Or do we expect LocalUsernamesToLowerCase to mitigate that?

The setting in our gerrit.config ldap.localUsernamesToLowercase = true means that new folks who login will have their username stored in the gerrit "database" (read:All-Users) as lowercase.

  • Are there perhaps people that have actually relied on the uppercase form (for reason not guessable by me currently)? Maybe they should be contacted and asked beforehand?

The local user scheme (gerrit: usernames in All-Users) are only used for UI login. Your account.fullName and your shell access should be stored in different places. My understanding is that folks with mixed-case usernames in the gerrit schema can no longer login (after 2.15.8). Prior to the ldap change mentioned above, a script was run that was intended to do what my shell script does; however, there must have been some bug. In short, I do not think that anyone relies on this and I think the remaining mixed case gerrit: usernames are a mistake.

Aside from my questions above, I don't see an issue with that.

I have a local patch, I plan to apply it tomorrow so that I can be around to ensure there is no other fallout.

I've tried to log in into Gerrit (my last access was 2 years ago) with my Wikitech account (which works fine), but I'm affected by the same issue (as portraited in the image above:


@thcipriani, could you please fix also my account (or at least explain how to solve it on my own, if possible)? Thank you.

@Mess you are part of my local patch. I will update this task tomorrow after a reindex.

ΟΚ, LGTM then.

thcipriani closed this task as Resolved.Tue, Jul 2, 6:06 PM
thcipriani claimed this task.

Applied patch and reindexed accounts 2019-07-02 17:53 UTC.

@Mess your problem should be resolved.

Mess added a comment.Tue, Jul 2, 6:47 PM

Applied patch and reindexed accounts 2019-07-02 17:53 UTC.
@Mess your problem should be resolved.

@thcipriani I confirm you my problem was fixed with your patch. Thank you so much for your kindness!

hashar added a comment.Wed, Jul 3, 8:38 AM

Congratulations @thcipriani !