2.15.3 Instance Moving to Different Domain Using Same Auth Type

[Michelle Pogado]

Hi, 

We have a Gerrit 2.15.3 instance using LDAP authentication.
We now need to move to a new domain and need to migrate into machines in that new domain by early next year.

We need to keep everything as is, except for the ldap server and domain.

We are now trying to move the instance to the new domain and realized that we will be registered as a new accounts.
The biggest problem now is that no one is part of the administrator group since the admins are of the old-domain accounts.

Question:

How will we  be able to administer our instance?
Or any steps we can take beforehand so that at least 1 new account can adminstrate?

[Luca Milanesio]

Hi Michelle,

> On 25 Oct 2024, at 11:18, Michelle Pogado <michell...@gmail.com> wrote:
>
> Hi,
>
> We have a Gerrit 2.15.3 instance using LDAP authentication.
> We now need to move to a new domain and need to migrate into machines in that new domain by early next year.
> We need to keep everything as is, except for the ldap server and domain.

Is there any reason for not upgrading? Your Gerrit is EOL and completely unsupported, see [1].
Also, bear in mind that you may be missing *a lot* of security fixes; therefore you should also give more reasons to your top management for upgrading :-)

> We are now trying to move the instance to the new domain and realized that we will be registered as a new accounts.

You don’t need to register new accounts in Gerrit; you can keep the same accounts.

> The biggest problem now is that no one is part of the administrator group since the admins are of the old-domain accounts.

How come? Who has installed Gerrit? Has he left the company without delegating his role to anyone?

>
> Question:
> How will we be able to administer our instance?
> Or any steps we can take beforehand so that at least 1 new account can adminstrate?

In that case, I typically suggest to enable the auth “DEVELOPMENT_BECOME_ANY_ACCOUNT” in gerrit.config, impersonate the Admin that left the company (or is unavailable) and add another user to the Admin group.

HTH

Luca.

[1] https://www.gerritcodereview.com/2019-11-15-gerrit-2.15-eol.html

[Matthias Sohn]

Alternatively you can configure capability.administrateServer to some group to define who is an administrator.

See https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#capability.administrateServer

 

HTH

Luca.

[1] https://www.gerritcodereview.com/2019-11-15-gerrit-2.15-eol.html

--
--
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.
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/E2738BBE-1CEB-425F-9A2E-2839CFDA65FE%40gmail.com.

[Michelle Pogado]

Is there any reason for not upgrading? Your Gerrit is EOL and completely unsupported, see [1].
Also, bear in mind that you may be missing *a lot* of security fixes; therefore you should also give more reasons to your top management for upgrading :-)

 

We are upgrading to latest version :), but since our version is quite old, and doing the version-by-version upgrade would be quite tedious, we decided to just have a mirror of the old instance (2.15 version) running on one server but set to read only.

Then, we will setup a new instance (latest 3.x version) running on another server containing only the repos that are actively used.

 

> We are now trying to move the instance to the new domain and realized that we will be registered as a new accounts.

You don’t need to register new accounts in Gerrit; you can keep the same accounts.

Umm, in our new domain (ldap, AD, etc), the username scheme was modified like below
Old domain = firstname.lastname
New domain = firstname

I've watched the video of Matthias regarding their migration but what I understand was that there was a mapping of user accounts going on via external ids.
However, some users really had to be registered as new accounts...
Or maybe I did not understand it fully...

 

> The biggest problem now is that no one is part of the administrator group since the admins are of the old-domain accounts.

How come? Who has installed Gerrit? Has he left the company without delegating his role to anyone?

 

 Due to the username scheme of the new domain's ldap server.

 

> Question:
> How will we be able to administer our instance?
> Or any steps we can take beforehand so that at least 1 new account can adminstrate?

In that case, I typically suggest to enable the auth “DEVELOPMENT_BECOME_ANY_ACCOUNT” in gerrit.config, impersonate the Admin that left the company (or is unavailable) and add another user to the Admin group.

HTH

Worked like a charm!

I just impersonated my own old account and problem solved!

Just for fun, I also tried Matthias' suggestion and it also served our purpose.

Thank you so much for these advice!

 

[Fabio Ponciroli]

Hi Michelle,

On Mon, 28 Oct 2024 at 06:13, Michelle Pogado <michell...@gmail.com> wrote:

Is there any reason for not upgrading? Your Gerrit is EOL and completely unsupported, see [1].
Also, bear in mind that you may be missing *a lot* of security fixes; therefore you should also give more reasons to your top management for upgrading :-)

 

We are upgrading to latest version :), but since our version is quite old, and doing the version-by-version upgrade would be quite tedious, we decided to just have a mirror of the old instance (2.15 version) running on one server but set to read only.

I recently gave a talk [1] at the last Gerrit User Summit, about migrating on a project-by-project base for a situation similar to yours.

Hopefully, the talk will be published soon. It might be an alternative way you might want to consider when facing your migration.

[1]: https://gerrit.googlesource.com/summit/2024/+/master/sessions/migrating-from-2.13-to-3.9.md

Then, we will setup a new instance (latest 3.x version) running on another server containing only the repos that are actively used.

 

> We are now trying to move the instance to the new domain and realized that we will be registered as a new accounts.

You don’t need to register new accounts in Gerrit; you can keep the same accounts.

Umm, in our new domain (ldap, AD, etc), the username scheme was modified like below
Old domain = firstname.lastname
New domain = firstname

I've watched the video of Matthias regarding their migration but what I understand was that there was a mapping of user accounts going on via external ids.
However, some users really had to be registered as new accounts...
Or maybe I did not understand it fully...

 

> The biggest problem now is that no one is part of the administrator group since the admins are of the old-domain accounts.

How come? Who has installed Gerrit? Has he left the company without delegating his role to anyone?

 

 Due to the username scheme of the new domain's ldap server.

 

> Question:
> How will we be able to administer our instance?
> Or any steps we can take beforehand so that at least 1 new account can adminstrate?

In that case, I typically suggest to enable the auth “DEVELOPMENT_BECOME_ANY_ACCOUNT” in gerrit.config, impersonate the Admin that left the company (or is unavailable) and add another user to the Admin group.

HTH

Worked like a charm!

I just impersonated my own old account and problem solved!

Just for fun, I also tried Matthias' suggestion and it also served our purpose.

Thank you so much for these advice!

 

--

--
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.

To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/3abadb5f-da91-475e-99a1-2f833a7bc0d8n%40googlegroups.com.