Sign in problem after gerrit migration

[Y. Li]

Hi,

I migrate gerrit server with ldap authentication to a new gerrit-2.14 server. Ldap server address is also changed. Mysql data is restored and git repository is rsynced.  And gerrit is started using "java -jar gerrit-2.14.war init -d /xxxx/gerrit" at the first time.

Gerrit starts ok.

When I login gerrit with an exist username, it prompt "invalide username and password".

In LDAP server log,  "op=2 SEARCH RESULT tag=101 err=0 nentries=0 text="

In gerrit error_log, "INFO  com.google.gerrit.httpd.auth.ldap.LdapLoginServlet : 'xxxx' failed to sign in: Cannot assign external ID "gerrit:xxxx" to account 360; external ID already in use."

It seems that gerrit takes it as a new account.

All usernames are lower case, so it is not a case sensitive problem. 

Any suggestion? Thanks!

[Edwin Kempin]

Thanks for the report. Wikimedia reported the same issue but so far it's not clear what is causing this.

You are right that this error message means that Gerrit tries to create a new account [1], so the question is why it did not find the existing account? To find an existing accounts it retrieves the account from the account index [2,3]. One possibility is that the account is not found because it's missing/stale in the account index. Can you please try to reindex the affected account 360 by using the

  POST /accounts/360/index

REST endpoint and let us know whether this fixed the issue? It might not, since Wikimedia claims that reindexing doesn't help in this case, but I would like to confirm this.

By the way your account IDs look weird, normally they should have 7 digits.

[1] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.14/gerrit-server/src/main/java/com/google/gerrit/server/account/AccountManager.java#214

[2] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.14/gerrit-server/src/main/java/com/google/gerrit/server/account/AccountManager.java#114

[3] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.14/gerrit-server/src/main/java/com/google/gerrit/server/account/AccountManager.java#136

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Edwin Kempin

Software Engineer

eke...@google.com

+16502534437

Google Germany GmbH

Dienerstraße 12

80331 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank.

      

This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

[Edwin Kempin]

On Thu, Jun 22, 2017 at 9:30 AM, Edwin Kempin <eke...@google.com> wrote:

Thanks for the report. Wikimedia reported the same issue but so far it's not clear what is causing this.

You are right that this error message means that Gerrit tries to create a new account [1], so the question is why it did not find the existing account? To find an existing accounts it retrieves the account from the account index [2,3]. One possibility is that the account is not found because it's missing/stale in the account index. Can you please try to reindex the affected account 360 by using the

  POST /accounts/360/index

REST endpoint and let us know whether this fixed the issue? It might not, since Wikimedia claims that reindexing doesn't help in this case, but I would like to confirm this.

By the way your account IDs look weird, normally they should have 7 digits.

[1] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.14/gerrit-server/src/main/java/com/google/gerrit/server/account/AccountManager.java#214

[2] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.14/gerrit-server/src/main/java/com/google/gerrit/server/account/AccountManager.java#114

[3] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.14/gerrit-server/src/main/java/com/google/gerrit/server/account/AccountManager.java#136

On Thu, Jun 22, 2017 at 4:26 AM, Y. Li <ly6...@sohu.com> wrote:

Hi,

I migrate gerrit server with ldap authentication to a new gerrit-2.14 server. Ldap server address is also changed. Mysql data is restored and git repository is rsynced.  And gerrit is started using "java -jar gerrit-2.14.war init -d /xxxx/gerrit" at the first time.

Gerrit starts ok.

When I login gerrit with an exist username, it prompt "invalide username and password".

In LDAP server log,  "op=2 SEARCH RESULT tag=101 err=0 nentries=0 text="

In gerrit error_log, "INFO  com.google.gerrit.httpd.auth.ldap.LdapLoginServlet : 'xxxx' failed to sign in: Cannot assign external ID "gerrit:xxxx" to account 360; external ID already in use."

Can you also please say how 'xxxx' looks like? I don't need the concrete value, but please say if it is all lowercase or not?

[Edwin Kempin]

Change [1] may fix this, but even if not it should still be an improvement since it eliminates the account index in this code path.

[1] https://gerrit-review.googlesource.com/110992

[Y. Li]

Thanks for you reply.

I have tried "java -jar gerrit-2.14.war reindex -d /xxxx/gerrit". After reindex and restart gerrit, It seems OK after now.

Cause git repository files are processed, I wonder whether it will affect user's repository sync...

As to account id, all ids in my system are not 7 digits. They are from 1 to 2xx , and will increase after every new user logon.

 
在 2017年6月22日星期四 UTC+8下午3:31:22，Edwin Kempin写道：

Thanks for the report. Wikimedia reported the same issue but so far it's not clear what is causing this.

You are right that this error message means that Gerrit tries to create a new account [1], so the question is why it did not find the existing account? To find an existing accounts it retrieves the account from the account index [2,3]. One possibility is that the account is not found because it's missing/stale in the account index. Can you please try to reindex the affected account 360 by using the

  POST /accounts/360/index

REST endpoint and let us know whether this fixed the issue? It might not, since Wikimedia claims that reindexing doesn't help in this case, but I would like to confirm this.

By the way your account IDs look weird, normally they should have 7 digits.

[1] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.14/gerrit-server/src/main/java/com/google/gerrit/server/account/AccountManager.java#214

[2] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.14/gerrit-server/src/main/java/com/google/gerrit/server/account/AccountManager.java#114

[3] https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.14/gerrit-server/src/main/java/com/google/gerrit/server/account/AccountManager.java#136

On Thu, Jun 22, 2017 at 4:26 AM, Y. Li <ly6...@sohu.com> wrote:

Hi,

I migrate gerrit server with ldap authentication to a new gerrit-2.14 server. Ldap server address is also changed. Mysql data is restored and git repository is rsynced.  And gerrit is started using "java -jar gerrit-2.14.war init -d /xxxx/gerrit" at the first time.

Gerrit starts ok.

When I login gerrit with an exist username, it prompt "invalide username and password".

In LDAP server log,  "op=2 SEARCH RESULT tag=101 err=0 nentries=0 text="

In gerrit error_log, "INFO  com.google.gerrit.httpd.auth.ldap.LdapLoginServlet : 'xxxx' failed to sign in: Cannot assign external ID "gerrit:xxxx" to account 360; external ID already in use."

It seems that gerrit takes it as a new account.

All usernames are lower case, so it is not a case sensitive problem. 

Any suggestion? Thanks!

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Luca Milanesio]

Was it then just an account index misalignment?

Did you do a full off-line reindex after upgrading to 2.14 before?

If not, I thought Gerrit 2.14 was refusing to start if the accounts index wasn't ready.

Luca.

[thomasmu...@yahoo.com]

Ah, he did a full reindex, wmf didnt do the full reindex so i wonder why the full reindex worked but online reindex did not. I would say that is a bug. wmf carn't do a full reindex due to the time it takes to do it. We only do it for majour upgrades, ie 2.12 -> 2.13.

[Luca Milanesio]

Interesting, I did not consider the on-line reindex for accounts: let me check in the code if it is actually implemented or not.

Luca.

[thomasmu...@yahoo.com]

It seems it was implemented since 2.13.8.


https://www.gerritcodereview.com/releases/2.13.md#2.13.8

https://gerrit-review.googlesource.com/#/c/104370/

[Luca Milanesio]

That isn't a reference to the online reindexer, it is just about an extra event and extension point for aligning indexes across nodes.

Luca.

[Luca Milanesio]

The account index definition was introduced in d1969dec3296aee166a3b727f4f2fae6b277ab56  and is contained in the following releases:

$ git tag --contains d1969dec3296aee166a3b727f4f2fae6b277ab56
v2.13
v2.13-rc0
v2.13-rc1
v2.13.1
v2.13.2
v2.13.3
v2.13.4
v2.13.5
v2.13.6
v2.13.7
v2.13.8
v2.14
v2.14-rc0
v2.14-rc1
v2.14.1

Any upgrade to v2.13 *requires* an off-line indexing, because the account index just did not existed before that release.

Upgrading from v2.13.x to v2.14 would upgrade the account index automatically.

There is somehow a corner case where Gerrit 2.13 starts even without an account index and *then* the problem happens, because accounts are there *BUT* are not indexed yet.

Can anyone identify the corner case? I haven't yet :-(

Luca.

[thomasmu...@yahoo.com]

Aha, i belive reindexing offline was faster for us when we did 2.12 -> 2.13. So i guess it must be that. I have created.

Thanks so much for finding the course.

I've setup a task https://phabricator.wikimedia.org/T168670 to do a full reindex offline to see if it works :).

[thomasmu...@yahoo.com]

I tryed gerrit 2.12 to 2.13 upgrade without reindex and got

[2017-06-22 21:06:37,936] [main] ERROR com.google.gerrit.pgm.Daemon : Unable to start daemon

com.google.inject.ProvisionException: Unable to provision, see the following errors:

1) No index versions ready; run java -jar /var/www/html/test/bin/gerrit.war reindex

1 error

at com.google.gerrit.lucene.LuceneVersionManager.initIndex(LuceneVersionManager.java:146)

On Thursday, June 22, 2017 at 7:03:36 AM UTC+1, Y. Li wrote:

[Luca Milanesio]

Exactly what I was expecting to see :-)

On-line reindex makes sense only for *upgrading* an index: that means that when people migrated to 2.13, they *HAD TO* run reindex.

It is unclear to me how some of the people manage to start Gerrit 2.13 *without* an off-line reindex first, and then got the problem of the account index out of sync with the DBMS.

Luca.

[thomasmu...@yahoo.com]

We did an offline reindex (wmf) we doint do any online reindex when we did 2.12 -> 2.13. But we found the reindex to be faster then normal.

[thomasmu...@yahoo.com]

Chad has now reindex accounts with the following command

https://phabricator.wikimedia.org/T168670#3373154

java -jar bin/gerrit.war reindex --index accounts

On Thursday, June 22, 2017 at 7:03:36 AM UTC+1, Y. Li wrote:

[thomasmu...@yahoo.com]

It seems reindex offline broke some accounts for us now. See https://phabricator.wikimedia.org/T168707

Cannot assign user name "maurelio" to account 5000; name already in use.

(previously was account 4997, and after each try, it increased the account number by one unit)

[Edwin Kempin]

Looks to me like this is just the same error that you had before the offline reindex.

I don't see any evidence that offline reindex broke anything, but it rather didn't fix this problem.

 

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[Edwin Kempin]

On Fri, Jun 23, 2017 at 12:55 PM, Edwin Kempin <eke...@google.com> wrote:

On Fri, Jun 23, 2017 at 12:07 PM, thomasmulhall410 via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

It seems reindex offline broke some accounts for us now. See https://phabricator.wikimedia.org/T168707

Cannot assign user name "maurelio" to account 5000; name already in use.

To investigate this further can you please do the following:

1. Clone the All-Users repository

2. Fetch and checkout the refs/meta/external-ids branch

3. grep -r -i 'maurelio'

In addition to the output of this grep command, please say how you have set the following parameters in your gerrit.config:

- auth.userNameToLowerCase

- ldap.accountSshUserName

- ldap.localUsernameToLowerCase

[thomasmu...@yahoo.com]

Hi, here's our gerrit.config https://github.com/wikimedia/puppet/blob/production/modules/gerrit/templates/gerrit.config.erb

[Edwin Kempin]

On Fri, Jun 23, 2017 at 1:57 PM, thomasmulhall410 via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

Hi, here's our gerrit.config https://github.com/wikimedia/puppet/blob/production/modules/gerrit/templates/gerrit.config.erb

Thanks, but it's not useful without the other information I have asked for.

[thomasmu...@yahoo.com]

It seems that after we reindexed last night it broke there account.

Though there account is a couple of years old though.

I will need to ask chad if he backported https://gerrit-review.googlesource.com/?polygerrit=0#/c/92830/ when he rebuilt from stable-2.13 but I think he did otherwise we would have got externalid error instead of name error.

I will have a look in the All-User branch later when near pc.

[Edwin Kempin]

OK, please also say which database you are using?

[thomasmu...@yahoo.com]

We haven't set userNameToLowerCase in auto though. But have set it for ldap. Could that be why?

[thomasmu...@yahoo.com]

We are using the mysql connector (mysql db).

[thomasmu...@yahoo.com]

Will try to get the additional info today (sorry for the delay, not sure if my normal access can get the external id from branch, so may need chad to get that)

[thomasmu...@yahoo.com]

auto = auth

[Edwin Kempin]

On Fri, Jun 23, 2017 at 2:05 PM, thomasmulhall410 via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

We haven't set userNameToLowerCase in auto though. But have set it for ldap. Could that be why?

No setting auth.userNameToLowerCase to true is not required if ldap.localUsernameToLowerCase is set to true.

But I suspect that you have set auth.localUsernameToLowerCase to true without running the LocalUsernamesToLowerCase program as documented in [1]. Please note that you must run offline reindex for all accounts again after running this program.

[1] https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#ldap.localUsernameToLowerCase

[thomasmu...@yahoo.com]

We ran that programme that converted usernames to lowercase. We setup a maint date and did it.

Also per the link I gave, we did not set auth.localUsernameToLowerCase since puppet will revert any changes done on the machine. So anything in that repo is how we setup the gerrit.

[thomasmu...@yahoo.com]

See https://phabricator.wikimedia.org/T168707#3374249 they said they tried capital and lower case which did not work

[thomasmu...@yahoo.com]

https://phabricator.wikimedia.org/T168707#3374273

[Edwin Kempin]

On Fri, Jun 23, 2017 at 2:18 PM, thomasmulhall410 via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

We ran that programme that converted usernames to lowercase. We setup a maint date and did it.

Okay, then this should be confirmed by the data from the refs/meta/external-ids branch.

Maybe there is also a bug in this program and it didn't do the conversion correctly.

Anyway no value speculating before we have that data from your refs/meta/external-ids branch.

 

Also per the link I gave, we did not set auth.localUsernameToLowerCase since puppet will revert any changes done on the machine. So anything in that repo is how we setup the gerrit.

[thomasmu...@yahoo.com]

Hi, we doint have that branch

~/All-Users$ git checkout refs/meta/external-ids

error: pathspec 'refs/meta/external-ids' did not match any file(s) known to git

unless it needs admin permission to view it.

On Friday, June 23, 2017 at 1:32:25 PM UTC+1, Edwin Kempin wrote:

On Fri, Jun 23, 2017 at 2:18 PM, thomasmulhall410 via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

We ran that programme that converted usernames to lowercase. We setup a maint date and did it.

Okay, then this should be confirmed by the data from the refs/meta/external-ids branch.

Maybe there is also a bug in this program and it didn't do the conversion correctly.

Anyway no value speculating before we have that data from your refs/meta/external-ids branch.

 

Also per the link I gave, we did not set auth.localUsernameToLowerCase since puppet will revert any changes done on the machine. So anything in that repo is how we setup the gerrit.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

[thomasmu...@yahoo.com]

That branch only exists in gerrit 2.14 not 2.13.8. https://github.com/GerritCodeReview/gerrit/commit/744d2b896719e2058539db98443c80eb9368fd77

[thomasmu...@yahoo.com]

But using a gerrit 2.14 test install, i carn't find that branch either.

[Edwin Kempin]

On Fri, Jun 23, 2017 at 4:46 PM, thomasmulhall410 via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

That branch only exists in gerrit 2.14 not 2.13.8. https://github.com/GerritCodeReview/gerrit/commit/744d2b896719e2058539db98443c80eb9368fd77

I thought we talking about a problem that occurs after the upgrade to 2.14?

If the problem is with 2.13.8 then please check which external IDs exist for maurelio in the ACCOUNT_EXTENRAL_IDS table in ReviewDb.

 

On Thursday, June 22, 2017 at 7:03:36 AM UTC+1, Y. Li wrote:

Hi,

I migrate gerrit server with ldap authentication to a new gerrit-2.14 server. Ldap server address is also changed. Mysql data is restored and git repository is rsynced.  And gerrit is started using "java -jar gerrit-2.14.war init -d /xxxx/gerrit" at the first time.

Gerrit starts ok.

When I login gerrit with an exist username, it prompt "invalide username and password".

In LDAP server log,  "op=2 SEARCH RESULT tag=101 err=0 nentries=0 text="

In gerrit error_log, "INFO  com.google.gerrit.httpd.auth.ldap.LdapLoginServlet : 'xxxx' failed to sign in: Cannot assign external ID "gerrit:xxxx" to account 360; external ID already in use."

It seems that gerrit takes it as a new account.

All usernames are lower case, so it is not a case sensitive problem. 

Any suggestion? Thanks!

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[Edwin Kempin]

On Fri, Jun 23, 2017 at 4:50 PM, thomasmulhall410 via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

But using a gerrit 2.14 test install, i carn't find that branch either.

Yes, it's only created by the schema migration that is contained in [1] and this change isn't part of 2.14. Sorry about the confusion. Then we need the data from the database.

[1] https://gerrit-review.googlesource.com/93470

 

--

[Joshua Olson]

Hi,

We've run into this issue and if you setup LDAP (or other external account validations like OAUTH) on gerrit then existing accounts and/or accounts created via the REST API will not be able to login via LDAP because the login validation code expects externally validated account to have an existing row in the the ACCOUNT_EXTERNAL_IDS table (or in All-Users.git if external ids have been migrated there) having the external_id value "gerrit:{username}".  If gerrit doesn't find this row it attempts to create a new account.  Gerrit expects all externally validated accounts to be created upon first login and thus only inserts the "gerrit:{username}" row at that time.

You can solve this by running this on the DB for any account you expect to login using external auth.  I believe the email address is optional in this insert.

   `insert into account_external_ids (account_id, email_address, external_id) values ({account_id}, '{username}@{domain}', 'gerrit:{username}');`

You will also need to reindex accounts after inserting this row directly into the DB.

Cheers,

Josh

[Luca Milanesio]

Actually I have found a problem as well over the week-end because of exactly that behaviour.

I've submitted a fix on 2.14 to allow a "special skip" of that logic when you do Git/HTTP authentication, but the same could be done for REST-API.

If you have been authenticated *and* the account is active, does not make sense anymore to try to register a new user when the external id cannot be found.

That logic is meant to be used for the WebUX GUI and not for command line or non direct invocation, isn't it?

We have at the moment in Gerrit 2.14 a situation where the accounts are half on the DBMS (accounts table) and half on NoteDb (All-Users for the external ids) and additionally we have the Lucene index for searching them.

If *one of them* is not up-to-date with the others, you can get into trouble :-(

Luca.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

[Edwin Kempin]

On Mon, Jun 26, 2017 at 9:58 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Actually I have found a problem as well over the week-end because of exactly that behaviour.

I've submitted a fix on 2.14 to allow a "special skip" of that logic when you do Git/HTTP authentication, but the same could be done for REST-API.

If you have been authenticated *and* the account is active, does not make sense anymore to try to register a new user when the external id cannot be found.

That logic is meant to be used for the WebUX GUI and not for command line or non direct invocation, isn't it?

We have at the moment in Gerrit 2.14 a situation where the accounts are half on the DBMS (accounts table) and half on NoteDb (All-Users for the external ids)

This is actually not true. With 2.14 accounts and external IDs are still both in ReviewDb. 

The schema migration that migrates external IDs from ReviewDb to NoteDb is only part of [1] which is not included in 2.14.

I was confused about this because 2.14 already writes new external IDs to NoteDb, but reading is always

done from ReviewDb (or the account index). Hence [2] must be reverted: [3]

[1] https://gerrit-review.googlesource.com/93470

[2] https://gerrit-review.googlesource.com/110992

[3] https://gerrit-review.googlesource.com/111095

 

and additionally we have the Lucene index for searching them.

If *one of them* is not up-to-date with the others, you can get into trouble :-(

Luca.

On 25 Jun 2017, at 03:34, Joshua Olson <joshua...@gmail.com> wrote:

Hi,

We've run into this issue and if you setup LDAP (or other external account validations like OAUTH) on gerrit then existing accounts and/or accounts created via the REST API will not be able to login via LDAP because the login validation code expects externally validated account to have an existing row in the the ACCOUNT_EXTERNAL_IDS table (or in All-Users.git if external ids have been migrated there) having the external_id value "gerrit:{username}".  If gerrit doesn't find this row it attempts to create a new account.  Gerrit expects all externally validated accounts to be created upon first login and thus only inserts the "gerrit:{username}" row at that time.

You can solve this by running this on the DB for any account you expect to login using external auth.  I believe the email address is optional in this insert.

   `insert into account_external_ids (account_id, email_address, external_id) values ({account_id}, '{username}@{domain}', 'gerrit:{username}');`

You will also need to reindex accounts after inserting this row directly into the DB.

Cheers,

Josh

On Wednesday, June 21, 2017 at 11:03:36 PM UTC-7, Y. Li wrote:

Hi,

I migrate gerrit server with ldap authentication to a new gerrit-2.14 server. Ldap server address is also changed. Mysql data is restored and git repository is rsynced.  And gerrit is started using "java -jar gerrit-2.14.war init -d /xxxx/gerrit" at the first time.

Gerrit starts ok.

When I login gerrit with an exist username, it prompt "invalide username and password".

In LDAP server log,  "op=2 SEARCH RESULT tag=101 err=0 nentries=0 text="

In gerrit error_log, "INFO  com.google.gerrit.httpd.auth.ldap.LdapLoginServlet : 'xxxx' failed to sign in: Cannot assign external ID "gerrit:xxxx" to account 360; external ID already in use."

It seems that gerrit takes it as a new account.

All usernames are lower case, so it is not a case sensitive problem. 

Any suggestion? Thanks!

--
--

To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[Luca Milanesio]

On 26 Jun 2017, at 10:52, Edwin Kempin <eke...@google.com> wrote:

On Mon, Jun 26, 2017 at 9:58 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Actually I have found a problem as well over the week-end because of exactly that behaviour.

I've submitted a fix on 2.14 to allow a "special skip" of that logic when you do Git/HTTP authentication, but the same could be done for REST-API.

If you have been authenticated *and* the account is active, does not make sense anymore to try to register a new user when the external id cannot be found.

That logic is meant to be used for the WebUX GUI and not for command line or non direct invocation, isn't it?

We have at the moment in Gerrit 2.14 a situation where the accounts are half on the DBMS (accounts table) and half on NoteDb (All-Users for the external ids)

This is actually not true. With 2.14 accounts and external IDs are still both in ReviewDb. 

The schema migration that migrates external IDs from ReviewDb to NoteDb is only part of [1] which is not included in 2.14.

Ah, I got confused as well as I've noticed that the new accounts were in NoteDb :-)

That explains why the old accounts weren't migrated either.

I was confused about this because 2.14 already writes new external IDs to NoteDb, but reading is always

done from ReviewDb (or the account index). Hence [2] must be reverted: [3]

[1] https://gerrit-review.googlesource.com/93470

[2] https://gerrit-review.googlesource.com/110992

[3] https://gerrit-review.googlesource.com/111095

Yes, but it is not enough :-(

Using a Lucene Index lookup on slaves wouldn't work, as Gerrit Slaves have no Lucene index at all :-(

Luca.

[Edwin Kempin]

On Mon, Jun 26, 2017 at 12:03 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:

On 26 Jun 2017, at 10:52, Edwin Kempin <eke...@google.com> wrote:

On Mon, Jun 26, 2017 at 9:58 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Actually I have found a problem as well over the week-end because of exactly that behaviour.

I've submitted a fix on 2.14 to allow a "special skip" of that logic when you do Git/HTTP authentication, but the same could be done for REST-API.

If you have been authenticated *and* the account is active, does not make sense anymore to try to register a new user when the external id cannot be found.

That logic is meant to be used for the WebUX GUI and not for command line or non direct invocation, isn't it?

We have at the moment in Gerrit 2.14 a situation where the accounts are half on the DBMS (accounts table) and half on NoteDb (All-Users for the external ids)

This is actually not true. With 2.14 accounts and external IDs are still both in ReviewDb. 

The schema migration that migrates external IDs from ReviewDb to NoteDb is only part of [1] which is not included in 2.14.

Ah, I got confused as well as I've noticed that the new accounts were in NoteDb :-)

That explains why the old accounts weren't migrated either.

I was confused about this because 2.14 already writes new external IDs to NoteDb, but reading is always

done from ReviewDb (or the account index). Hence [2] must be reverted: [3]

[1] https://gerrit-review.googlesource.com/93470

[2] https://gerrit-review.googlesource.com/110992

[3] https://gerrit-review.googlesource.com/111095

Yes, but it is not enough :-(

Using a Lucene Index lookup on slaves wouldn't work, as Gerrit Slaves have no Lucene index at all :-(

OK, let us fix this in stable-2.14 by reading from ReviewDb then.

[Edwin Kempin]

On Mon, Jun 26, 2017 at 12:05 PM, Edwin Kempin <eke...@google.com> wrote:

On Mon, Jun 26, 2017 at 12:03 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:

On 26 Jun 2017, at 10:52, Edwin Kempin <eke...@google.com> wrote:

On Mon, Jun 26, 2017 at 9:58 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Actually I have found a problem as well over the week-end because of exactly that behaviour.

I've submitted a fix on 2.14 to allow a "special skip" of that logic when you do Git/HTTP authentication, but the same could be done for REST-API.

If you have been authenticated *and* the account is active, does not make sense anymore to try to register a new user when the external id cannot be found.

That logic is meant to be used for the WebUX GUI and not for command line or non direct invocation, isn't it?

We have at the moment in Gerrit 2.14 a situation where the accounts are half on the DBMS (accounts table) and half on NoteDb (All-Users for the external ids)

This is actually not true. With 2.14 accounts and external IDs are still both in ReviewDb. 

The schema migration that migrates external IDs from ReviewDb to NoteDb is only part of [1] which is not included in 2.14.

Ah, I got confused as well as I've noticed that the new accounts were in NoteDb :-)

That explains why the old accounts weren't migrated either.

I was confused about this because 2.14 already writes new external IDs to NoteDb, but reading is always

done from ReviewDb (or the account index). Hence [2] must be reverted: [3]

[1] https://gerrit-review.googlesource.com/93470

[2] https://gerrit-review.googlesource.com/110992

[3] https://gerrit-review.googlesource.com/111095

Yes, but it is not enough :-(

Using a Lucene Index lookup on slaves wouldn't work, as Gerrit Slaves have no Lucene index at all :-(

OK, let us fix this in stable-2.14 by reading from ReviewDb then.

https://gerrit-review.googlesource.com/111097 

[Luca Milanesio]

On 26 Jun 2017, at 11:05, Edwin Kempin <eke...@google.com> wrote:

On Mon, Jun 26, 2017 at 12:03 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:

On 26 Jun 2017, at 10:52, Edwin Kempin <eke...@google.com> wrote:

On Mon, Jun 26, 2017 at 9:58 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Actually I have found a problem as well over the week-end because of exactly that behaviour.

I've submitted a fix on 2.14 to allow a "special skip" of that logic when you do Git/HTTP authentication, but the same could be done for REST-API.

If you have been authenticated *and* the account is active, does not make sense anymore to try to register a new user when the external id cannot be found.

That logic is meant to be used for the WebUX GUI and not for command line or non direct invocation, isn't it?

We have at the moment in Gerrit 2.14 a situation where the accounts are half on the DBMS (accounts table) and half on NoteDb (All-Users for the external ids)

This is actually not true. With 2.14 accounts and external IDs are still both in ReviewDb. 

The schema migration that migrates external IDs from ReviewDb to NoteDb is only part of [1] which is not included in 2.14.

Ah, I got confused as well as I've noticed that the new accounts were in NoteDb :-)

That explains why the old accounts weren't migrated either.

I was confused about this because 2.14 already writes new external IDs to NoteDb, but reading is always

done from ReviewDb (or the account index). Hence [2] must be reverted: [3]

[1] https://gerrit-review.googlesource.com/93470

[2] https://gerrit-review.googlesource.com/110992

[3] https://gerrit-review.googlesource.com/111095

Yes, but it is not enough :-(

Using a Lucene Index lookup on slaves wouldn't work, as Gerrit Slaves have no Lucene index at all :-(

OK, let us fix this in stable-2.14 by reading from ReviewDb then.

Yes, for stable-2.14 is definitely the best option.

Slaves have access to the DB, it should then work fine.

[thomasmu...@yahoo.com]

@ekempin hi, Chad shared this

gerrit> select * from accounts where full_name = 'MarcoAurelio';
 registered_on         | full_name    | preferred_email    | inactive | account_id
 ----------------------+--------------+--------------------+----------+-----------
 2016-07-25 01:42:27.0 | MarcoAurelio | stri...@gmail.com | N        | 787
(1 row; 8 ms)

gerrit> select * from account_external_ids where account_id = 787;
 account_id | email_address | password | external_id
 -----------+---------------+----------+------------------
 787        | NULL          | NULL     | username:maurelio
(1 row; 1 ms)

He says we are having the same problem as before where it is missing an entry.

[Edwin Kempin]

Thanks for sharing this info. Looks like this user is missing an external ID with the "gerrit:" scheme?

Do other users have external IDs for the "gerrit:" scheme?

--

[Luca Milanesio]

Hold on ... but the exception says "cannot assign external id gerrit:xxx" because it is in use ... but from the query the external id with gerrit prefix is the one missing.

Are we following a different problem / scenario?

@Paladox: how many users have only the username external id without the gerrit one?

Luca.

To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

[Edwin Kempin]

On Wed, Jun 28, 2017 at 9:31 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Hold on ... but the exception says "cannot assign external id gerrit:xxx" because it is in use ... but from the query the external id with gerrit prefix is the one missing.

Don't get confused.

The error from Y. Li was:

  'xxxx' failed to sign in: Cannot assign external ID "gerrit:xxxx" to account 360; external ID already in use."

But the error from Paladox none was:

  Cannot assign user name "maurelio" to account 5000; name already in use.

So they are different.

The error from Paladox none really means that Gerrit didn't find a 'gerrit:' ID for maurelio and hence it wants to create a new account. But the account creation fails on assigning the username to this new account (because this username is already used by the existing account).

 

Are we following a different problem / scenario?

They are different :) (see above)

 

@Paladox: how many users have only the username external id without the gerrit one?

Good question.

[Luca Milanesio]

On 28 Jun 2017, at 08:41, Edwin Kempin <eke...@google.com> wrote:

On Wed, Jun 28, 2017 at 9:31 AM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Hold on ... but the exception says "cannot assign external id gerrit:xxx" because it is in use ... but from the query the external id with gerrit prefix is the one missing.

Don't get confused.

The error from Y. Li was:

  'xxxx' failed to sign in: Cannot assign external ID "gerrit:xxxx" to account 360; external ID already in use."

But the error from Paladox none was:

  Cannot assign user name "maurelio" to account 5000; name already in use.

So they are different.

The error from Paladox none really means that Gerrit didn't find a 'gerrit:' ID for maurelio and hence it wants to create a new account. But the account creation fails on assigning the username to this new account (because this username is already used by the existing account).

 

Are we following a different problem / scenario?

They are different :) (see above)

OK, now it makes sense.

@Paladox your problem has nothing to do with a Gerrit 2.14 migration, can you please avoid posting further comments to this thread?

In *every* Gerrit release an account authenticated against LDAP that is missing the 'gerrit:' external id would have caused problems.

Your problem is more related to some DB data issues created "some time" in the past. The only way to resolve your issues is to fix the DB and add the missing external ids.

Luca.

[thomasmu...@yahoo.com]

> To unsubscribe, email repo-discuss...@googlegroups.com

>
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
>
>
> ---
>
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
>
>
> --
>
> --
>

> To unsubscribe, email repo-discuss...@googlegroups.com

>
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
>
>
> ---
>
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

Ok I’ve created this thread https://groups.google.com/forum/?nomobile=true#!topic/repo-discuss/1ZYXalK8iG4

[Vishnu Vardhan Rajmohan]

Hi,

I encountered something similar to this issue, so maybe its better to post it in the same thread.

I setup a new gerrit-2.14 server with ldap authentication, upon first login it fails and if I try again with same credentials, login is successful.

When the gerrit server is up there were no entries in the database and it happens only with the first user. The following are DB entries,

SELECT * FROM ACCOUNTS;
REGISTERED_ON   FULL_NAME   PREFERRED_EMAIL   INACTIVE   STATUS   ACCOUNT_ID 
2017-08-22 14:17:33.711 johndoe joh...@mail.com N null 1000264
2017-08-22 14:17:33.711 johndoe joh...@mail.com N null 1000265

SELECT * FROM ACCOUNT_EXTERNAL_IDS;
ACCOUNT_ID   EMAIL_ADDRESS   PASSWORD   EXTERNAL_ID 
1000265 us...@mail.com null gerrit:johndoe
1000265 null null username:johndoe

From error_log,

INFO  com.google.gerrit.httpd.auth.ldap.LdapLoginServlet : 'johndoe' failed to sign in: Authentication error

I noticed another thing, if the first user is a functional user_id there are no issues during login. The only difference is the functional user_id do not have an email address. I tested quite a lot of time and it looks to be consistent.

Please let me know if further clarification is needed.

Thanks,

Vishnu

[Luca Milanesio]

I've noticed you have the same user with multiple account ids: which 2.14.x have you upgraded to?

There were known issues with 2.14 and 2.14.1 with regards to external ids, fixed then with 2.14.2.

Luca.