Merge branch 'docs-code-block-style-2' into 'master'
Docs: Fix whitespace in administration docs See merge request gitlab-org/gitlab-ce!30554
This commit is contained in:
commit
ecffca5d92
|
@ -9,6 +9,7 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t
|
|||
1. On your GitLab server, open the configuration file:
|
||||
|
||||
For omnibus installation
|
||||
|
||||
```sh
|
||||
sudo editor /etc/gitlab/gitlab.rb
|
||||
```
|
||||
|
|
|
@ -55,6 +55,7 @@
|
|||
application_name: 'YOUR_APP_NAME',
|
||||
application_password: 'YOUR_APP_PASSWORD' } }
|
||||
```
|
||||
|
||||
1. Change `CROWD_SERVER_URL` to the URL of your Crowd server.
|
||||
1. Change `YOUR_APP_NAME` to the application name from Crowd applications page.
|
||||
1. Change `YOUR_APP_PASSWORD` to the application password you've set.
|
||||
|
|
|
@ -191,7 +191,6 @@ to lock down user abilities to invite new members to a group. When enabled follo
|
|||
1. Only administrator can manage memberships of any group including access levels.
|
||||
2. Users are not allowed to share project with other groups or invite members to a project created in a group.
|
||||
|
||||
|
||||
## Adjusting LDAP user sync schedule
|
||||
|
||||
> Introduced in GitLab Enterprise Edition Starter.
|
||||
|
@ -448,6 +447,7 @@ step of the sync.
|
|||
```ruby
|
||||
Rails.logger.level = Logger::DEBUG
|
||||
```
|
||||
|
||||
1. Choose a GitLab group to test with. This group should have an LDAP group link
|
||||
already configured. If the output is `nil`, the group could not be found.
|
||||
If a bunch of group attributes are output, your group was found successfully.
|
||||
|
@ -458,11 +458,13 @@ step of the sync.
|
|||
# Output
|
||||
=> #<Group:0x007fe825196558 id: 1234, name: "my_group"...>
|
||||
```
|
||||
|
||||
1. Run a group sync for this particular group.
|
||||
|
||||
```ruby
|
||||
EE::Gitlab::Auth::LDAP::Sync::Group.execute_all_providers(group)
|
||||
```
|
||||
|
||||
1. Look through the output of the sync. See [example log output](#example-log-output)
|
||||
below for more information about the output.
|
||||
1. If you still aren't able to see why the user isn't being added, query the
|
||||
|
@ -476,6 +478,7 @@ step of the sync.
|
|||
# Output
|
||||
=> #<EE::Gitlab::Auth::LDAP::Group:0x007fcbdd0bb6d8
|
||||
```
|
||||
|
||||
1. Query the LDAP group's member DNs and see if the user's DN is in the list.
|
||||
One of the DNs here should match the 'Identifier' from the LDAP identity
|
||||
checked earlier. If it doesn't, the user does not appear to be in the LDAP
|
||||
|
@ -487,6 +490,7 @@ step of the sync.
|
|||
# Output
|
||||
=> ["uid=john,ou=people,dc=example,dc=com", "uid=mary,ou=people,dc=example,dc=com"]
|
||||
```
|
||||
|
||||
1. Some LDAP servers don't store members by DN. Rather, they use UIDs instead.
|
||||
If you didn't see results from the last query, try querying by UIDs instead.
|
||||
|
||||
|
|
|
@ -77,6 +77,7 @@ check the [Troubleshooting section](#troubleshooting) before proceeding.
|
|||
### Checking cluster membership
|
||||
|
||||
To see which nodes are part of the cluster, run the following on any member in the cluster
|
||||
|
||||
```
|
||||
# /opt/gitlab/embedded/bin/consul members
|
||||
Node Address Status Type Build Protocol DC
|
||||
|
@ -112,7 +113,6 @@ You will see messages like the following in `gitlab-ctl tail consul` output if y
|
|||
2017-09-25_19:53:41.74356 2017/09/25 19:53:41 [ERR] agent: failed to sync remote state: No cluster leader
|
||||
```
|
||||
|
||||
|
||||
To fix this:
|
||||
|
||||
1. Pick an address on each node that all of the other nodes can reach this node through.
|
||||
|
@ -124,6 +124,7 @@ To fix this:
|
|||
bind_addr: 'IP ADDRESS'
|
||||
}
|
||||
```
|
||||
|
||||
1. Run `gitlab-ctl reconfigure`
|
||||
|
||||
If you still see the errors, you may have to [erase the consul database and reinitialize](#recreate-from-scratch) on the affected node.
|
||||
|
@ -150,6 +151,7 @@ To fix this:
|
|||
bind_addr: 'IP ADDRESS'
|
||||
}
|
||||
```
|
||||
|
||||
1. Run `gitlab-ctl reconfigure`
|
||||
|
||||
### Outage recovery
|
||||
|
@ -157,6 +159,7 @@ To fix this:
|
|||
If you lost enough server agents in the cluster to break quorum, then the cluster is considered failed, and it will not function without manual intervenetion.
|
||||
|
||||
#### Recreate from scratch
|
||||
|
||||
By default, GitLab does not store anything in the consul cluster that cannot be recreated. To erase the consul database and reinitialize
|
||||
|
||||
```
|
||||
|
@ -168,4 +171,5 @@ By default, GitLab does not store anything in the consul cluster that cannot be
|
|||
After this, the cluster should start back up, and the server agents rejoin. Shortly after that, the client agents should rejoin as well.
|
||||
|
||||
#### Recover a failed cluster
|
||||
|
||||
If you have taken advantage of consul to store other data, and want to restore the failed cluster, please follow the [Consul guide](https://www.consul.io/docs/guides/outage.html) to recover a failed cluster.
|
||||
|
|
|
@ -288,7 +288,6 @@ Make sure you install the necessary dependencies from step 1,
|
|||
add GitLab package repository from step 2.
|
||||
When installing the GitLab package, do not supply `EXTERNAL_URL` value.
|
||||
|
||||
|
||||
#### Configuring the Database nodes
|
||||
|
||||
1. Make sure to [configure the Consul nodes](consul.md).
|
||||
|
@ -343,6 +342,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value.
|
|||
to `/etc/gitlab/gitlab.rb`. In addition, append the following configuration
|
||||
to inform gitlab-ctl that they are standby nodes initially and it need not
|
||||
attempt to register them as primary node
|
||||
|
||||
```
|
||||
# HA setting to specify if a node should attempt to be master on initialization
|
||||
repmgr['master_on_initialization'] = false
|
||||
|
@ -977,7 +977,7 @@ If you enable Monitoring, it must be enabled on **all** database servers.
|
|||
|
||||
## Troubleshooting
|
||||
|
||||
### Consul and PostgreSQL changes not taking effect.
|
||||
### Consul and PostgreSQL changes not taking effect
|
||||
|
||||
Due to the potential impacts, `gitlab-ctl reconfigure` only reloads Consul and PostgreSQL, it will not restart the services. However, not all changes can be activated by reloading.
|
||||
|
||||
|
|
|
@ -42,8 +42,8 @@ maintaining ID mapping without LDAP, in most cases you should enable numeric UID
|
|||
and GIDs (which is off by default in some cases) for simplified permission
|
||||
management between systems:
|
||||
|
||||
- [NetApp instructions](https://library.netapp.com/ecmdocs/ECMP1401220/html/GUID-24367A9F-E17B-4725-ADC1-02D86F56F78E.html)
|
||||
- For non-NetApp devices, disable NFSv4 `idmapping` by performing opposite of [enable NFSv4 idmapper](https://wiki.archlinux.org/index.php/NFS#Enabling_NFSv4_idmapping)
|
||||
- [NetApp instructions](https://library.netapp.com/ecmdocs/ECMP1401220/html/GUID-24367A9F-E17B-4725-ADC1-02D86F56F78E.html)
|
||||
- For non-NetApp devices, disable NFSv4 `idmapping` by performing opposite of [enable NFSv4 idmapper](https://wiki.archlinux.org/index.php/NFS#Enabling_NFSv4_idmapping)
|
||||
|
||||
### Improving NFS performance with GitLab
|
||||
|
||||
|
|
|
@ -147,9 +147,9 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3786) in GitLab 12.0.
|
||||
|
||||
If you enable Monitoring, it must be enabled on **all** pgbouncer servers.
|
||||
If you enable Monitoring, it must be enabled on **all** pgbouncer servers.
|
||||
|
||||
1. Create/edit `/etc/gitlab/gitlab.rb` and add the following configuration:
|
||||
1. Create/edit `/etc/gitlab/gitlab.rb` and add the following configuration:
|
||||
|
||||
```ruby
|
||||
# Enable service discovery for Prometheus
|
||||
|
@ -168,7 +168,7 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
|
|||
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
|
||||
```
|
||||
|
||||
1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
|
||||
1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
|
||||
|
||||
### Interacting with pgbouncer
|
||||
|
||||
|
@ -190,6 +190,7 @@ pgbouncer=#
|
|||
The password you will be prompted for is the PGBOUNCER_USER_PASSWORD
|
||||
|
||||
To get some basic information about the instance, run
|
||||
|
||||
```shell
|
||||
pgbouncer=# show databases; show clients; show servers;
|
||||
name | host | port | database | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
|
||||
|
|
|
@ -593,7 +593,7 @@ which ideally should not have Redis or Sentinels on it for a HA setup.
|
|||
1. SSH into the server where the GitLab application is installed.
|
||||
1. Edit `/etc/gitlab/gitlab.rb` and add/change the following lines:
|
||||
|
||||
```
|
||||
```ruby
|
||||
## Must be the same in every sentinel node
|
||||
redis['master_name'] = 'gitlab-redis'
|
||||
|
||||
|
@ -796,10 +796,12 @@ cache, queues, and shared_state. To make this work with Sentinel:
|
|||
gitlab_rails['redis_queues_instance'] = REDIS_QUEUES_URL
|
||||
gitlab_rails['redis_shared_state_instance'] = REDIS_SHARED_STATE_URL
|
||||
```
|
||||
|
||||
**Note**: Redis URLs should be in the format: `redis://:PASSWORD@SENTINEL_MASTER_NAME`
|
||||
|
||||
1. PASSWORD is the plaintext password for the Redis instance
|
||||
1. SENTINEL_MASTER_NAME is the Sentinel master name (e.g. `gitlab-redis-cache`)
|
||||
|
||||
1. Include an array of hashes with host/port combinations, such as the following:
|
||||
|
||||
```ruby
|
||||
|
@ -816,6 +818,7 @@ cache, queues, and shared_state. To make this work with Sentinel:
|
|||
{ host: SHARED_STATE_SENTINEL_HOST2, port: PORT2 }
|
||||
]
|
||||
```
|
||||
|
||||
1. Note that for each persistence class, GitLab will default to using the
|
||||
configuration specified in `gitlab_rails['redis_sentinels']` unless
|
||||
overridden by the settings above.
|
||||
|
|
|
@ -160,6 +160,7 @@ master with IP `10.0.0.1` (some settings might overlap with the master):
|
|||
## the exact parallel-syncs progression as specified.
|
||||
sentinel failover_timeout 30000
|
||||
```
|
||||
|
||||
1. Restart the Redis service for the changes to take effect.
|
||||
1. Go through the steps again for all the other Sentinel nodes.
|
||||
|
||||
|
|
Loading…
Reference in New Issue