Commit c45b9155 authored by Suzanne Selhorn's avatar Suzanne Selhorn

Merge branch 'master' into 'master'

Change of future tense to present

See merge request gitlab-org/gitlab!60225
parents 66096840 c23f4fce
......@@ -27,7 +27,7 @@ Could not authenticate you from Ldapmain because "Connection timed out - user sp
```
If your configured LDAP provider and/or endpoint is offline or otherwise
unreachable by GitLab, no LDAP user will be able to authenticate and sign-in.
unreachable by GitLab, no LDAP user is able to authenticate and sign-in.
GitLab does not cache or store credentials for LDAP users to provide authentication
during an LDAP outage.
......@@ -181,14 +181,13 @@ user = User.find_by_any_email('email@example.com')
user.username
```
This will show you which user has this email address. One of two steps will
have to be taken here:
This shows you which user has this email address. One of two steps must be taken here:
- To create a new GitLab user/username for this user when signing in with LDAP,
remove the secondary email to remove the conflict.
- To use an existing GitLab user/username for this user to use with LDAP,
remove this email as a secondary email and make it a primary one so GitLab
will associate this profile to the LDAP identity.
associates this profile to the LDAP identity.
The user can do either of these steps [in their
profile](../../../user/profile/index.md#access-your-user-profile) or an administrator can do it.
......@@ -227,7 +226,7 @@ output](#example-console-output-after-a-user-sync).
##### Example console output after a user sync **(PREMIUM SELF)**
The output from a [manual user sync](#sync-all-users) will be very verbose, and a
The output from a [manual user sync](#sync-all-users) is very verbose, and a
single user's successful sync can look like this:
```shell
......@@ -255,8 +254,8 @@ uid: John
There's a lot here, so let's go over what could be helpful when debugging.
First, GitLab will look for all users that have previously
signed in with LDAP and iterate on them. Each user's sync will start with
First, GitLab looks for all users that have previously
signed in with LDAP and iterate on them. Each user's sync starts with
the following line that contains the user's username and email, as they
exist in GitLab now:
......@@ -274,7 +273,7 @@ link between this user and the configured LDAP provider(s):
Identity Load (0.9ms) SELECT "identities".* FROM "identities" WHERE "identities"."user_id" = 20 AND (provider LIKE 'ldap%') LIMIT 1
```
The identity object will have the DN that GitLab will use to look for the user
The identity object has the DN that GitLab uses to look for the user
in LDAP. If the DN isn't found, the email is used instead. We can see that
this user is found in LDAP:
......@@ -294,18 +293,18 @@ following message instead:
LDAP search error: No Such Object
```
...in which case the user will be blocked:
...in which case the user is blocked:
```shell
User Update (0.4ms) UPDATE "users" SET "state" = $1, "updated_at" = $2 WHERE "users"."id" = $3 [["state", "ldap_blocked"], ["updated_at", "2019-10-18 15:46:22.902177"], ["id", 20]]
```
Once the user is found in LDAP the rest of the output will update the GitLab
Once the user is found in LDAP, the rest of the output updates the GitLab
database with any changes.
#### Query a user in LDAP
This will test that GitLab can reach out to LDAP and read a particular user.
This tests that GitLab can reach out to LDAP and read a particular user.
It can expose potential errors connecting to and/or querying LDAP
that may seem to fail silently in the GitLab UI.
......
......@@ -24,7 +24,7 @@ integrated [Container Registry](../../packages/container_registry.md#use-object-
You can enable a storage-agnostic replication so it
can be used for cloud or local storage. Whenever a new image is pushed to the
**primary** site, each **secondary** site will pull it to its own container
**primary** site, each **secondary** site pulls it to its own container
repository.
To configure Docker Registry replication:
......@@ -70,12 +70,12 @@ We need to make Docker Registry send notification events to the
NOTE:
If you use an external Registry (not the one integrated with GitLab), you must add
these settings to its configuration yourself. In this case, you will also have to specify
these settings to its configuration yourself. In this case, you also have to specify
notification secret in `registry.notification_secret` section of
`/etc/gitlab/gitlab.rb` file.
NOTE:
If you use GitLab HA, you will also have to specify
If you use GitLab HA, you also have to specify
the notification secret in `registry.notification_secret` section of
`/etc/gitlab/gitlab.rb` file for every web node.
......@@ -95,7 +95,7 @@ expecting to see the Docker images replicated.
Because we need to allow the **secondary** site to communicate securely with
the **primary** site Container Registry, we need to have a single key
pair for all the sites. The **secondary** site will use this key to
pair for all the sites. The **secondary** site uses this key to
generate a short-lived JWT that is pull-only-capable to access the
**primary** site Container Registry.
......@@ -126,5 +126,5 @@ For each application and Sidekiq node on the **secondary** site:
To verify Container Registry replication is working, go to **Admin Area > Geo**
(`/admin/geo/nodes`) on the **secondary** site.
The initial replication, or "backfill", will probably still be in progress.
The initial replication, or "backfill", is probably still in progress.
You can monitor the synchronization process on each Geo site from the **primary** site's **Geo Nodes** dashboard in your browser.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment