Commit 5c8be575 authored by Nick Thomas's avatar Nick Thomas

Geo: database-backed SSH key lookups are mandatory

parent a5db2157
...@@ -9,6 +9,7 @@ from source**](configuration_source.md) guide. ...@@ -9,6 +9,7 @@ from source**](configuration_source.md) guide.
as the secondary Geo node. Do not login or set up anything else in the as the secondary Geo node. Do not login or set up anything else in the
secondary node for the moment. secondary node for the moment.
1. [Setup the database replication](database.md) (`primary (read-write) <-> secondary (read-only)` topology). 1. [Setup the database replication](database.md) (`primary (read-write) <-> secondary (read-only)` topology).
1. [Configure SSH authorizations to use the database](ssh.md)
1. **Configure GitLab to set the primary and secondary nodes.** 1. **Configure GitLab to set the primary and secondary nodes.**
1. [Follow the after setup steps](after_setup.md). 1. [Follow the after setup steps](after_setup.md).
...@@ -136,28 +137,7 @@ sensitive data in the database. Any secondary node must have the ...@@ -136,28 +137,7 @@ sensitive data in the database. Any secondary node must have the
gitlab-ctl reconfigure gitlab-ctl reconfigure
``` ```
### Step 4. Regenerating the authorized keys in the secondary node ### Step 4. Enabling hashed storage (from GitLab 10.0)
> **IMPORTANT:** Since GitLab 10.0 `~/.ssh/authorized_keys` no longer
> can be used, and this step is deprecated. Instead, follow the
> instructions on [configuring SSH authorization via database lookups](../administration/operations/speed_up_ssh.html)
> (for both primary AND secondary nodes).
Regenerate the keys for `~/.ssh/authorized_keys`
(HTTPS clone will still work without this extra step).
1. On the **secondary** node where the database is [already replicated](./database.md),
run:
```
# For Omnibus installations
gitlab-rake gitlab:shell:setup
```
This will enable `git` operations to authorize against your existing users.
New users and SSH keys updated after this step, will be replicated automatically.
### Step 5. Enabling hashed storage (from GitLab 10.0)
1. Visit the **primary** node's **Admin Area ➔ Settings** 1. Visit the **primary** node's **Admin Area ➔ Settings**
(`/admin/application_settings`) in your browser (`/admin/application_settings`) in your browser
...@@ -169,7 +149,7 @@ Using hashed storage significantly improves Geo replication - project and group ...@@ -169,7 +149,7 @@ Using hashed storage significantly improves Geo replication - project and group
renames no longer require synchronization between nodes - so we recommend it is renames no longer require synchronization between nodes - so we recommend it is
used for all GitLab Geo installations. used for all GitLab Geo installations.
### Step 6. Enabling the secondary GitLab node ### Step 5. Enabling the secondary GitLab node
1. SSH into the **secondary** node and login as root: 1. SSH into the **secondary** node and login as root:
...@@ -210,7 +190,7 @@ The two most obvious issues that replication can have here are: ...@@ -210,7 +190,7 @@ The two most obvious issues that replication can have here are:
[Troubleshooting](#troubleshooting) section) [Troubleshooting](#troubleshooting) section)
- Instance is firewalled (check your firewall rules) - Instance is firewalled (check your firewall rules)
### Step 7. Replicating the repositories data ### Step 6. Replicating the repositories data
Getting a new secondary Geo node up and running, will also require the Getting a new secondary Geo node up and running, will also require the
repositories data to be synced. repositories data to be synced.
......
...@@ -9,6 +9,7 @@ using the Omnibus GitLab packages, follow the ...@@ -9,6 +9,7 @@ using the Omnibus GitLab packages, follow the
will serve as the secondary Geo node. Do not login or set up anything else will serve as the secondary Geo node. Do not login or set up anything else
in the secondary node for the moment. in the secondary node for the moment.
1. [Setup the database replication](database_source.md) (`primary (read-write) <-> secondary (read-only)` topology). 1. [Setup the database replication](database_source.md) (`primary (read-write) <-> secondary (read-only)` topology).
1. [Configure SSH authorizations to use the database](ssh.md)
1. **Configure GitLab to set the primary and secondary nodes.** 1. **Configure GitLab to set the primary and secondary nodes.**
1. [Follow the after setup steps](after_setup.md). 1. [Follow the after setup steps](after_setup.md).
...@@ -129,28 +130,7 @@ sensitive data in the database. Any secondary node must have the ...@@ -129,28 +130,7 @@ sensitive data in the database. Any secondary node must have the
1. Save and close the file. 1. Save and close the file.
### Step 4. Regenerating the authorized keys in the secondary node ### Step 4. Enabling hashed storage (from GitLab 10.0)
> **IMPORTANT:** Since GitLab 10.0 `~/.ssh/authorized_keys` no longer
> can be used, and this step is deprecated. Instead, follow the
> instructions on [configuring SSH authorization via database lookups](../administration/operations/speed_up_ssh.html)
> (for both primary AND secondary nodes).
Regenerate the keys for `~/.ssh/authorized_keys`
(HTTPS clone will still work without this extra step).
1. On the **secondary** node where the database is [already replicated](./database.md),
run:
```
# Installations from source
sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
```
This will enable `git` operations to authorize against your existing users.
New users and SSH keys updated after this step, will be replicated automatically.
### Step 5. Enabling hashed storage (from GitLab 10.0)
1. Visit the **primary** node's **Admin Area ➔ Settings** 1. Visit the **primary** node's **Admin Area ➔ Settings**
(`/admin/application_settings`) in your browser (`/admin/application_settings`) in your browser
...@@ -163,7 +143,7 @@ renames no longer require synchronization between nodes - so we recommend it is ...@@ -163,7 +143,7 @@ renames no longer require synchronization between nodes - so we recommend it is
used for all GitLab Geo installations. used for all GitLab Geo installations.
### Step 6. Enabling the secondary GitLab node ### Step 5. Enabling the secondary GitLab node
1. SSH into the **secondary** node and login as root: 1. SSH into the **secondary** node and login as root:
...@@ -208,7 +188,7 @@ The two most obvious issues that replication can have here are: ...@@ -208,7 +188,7 @@ The two most obvious issues that replication can have here are:
[Troubleshooting](configuration.md#troubleshooting) section) [Troubleshooting](configuration.md#troubleshooting) section)
- Instance is firewalled (check your firewall rules) - Instance is firewalled (check your firewall rules)
### Step 7. Replicating the repositories data ### Step 6. Replicating the repositories data
Getting a new secondary Geo node up and running, will also require the Getting a new secondary Geo node up and running, will also require the
repositories data to be synced. repositories data to be synced.
......
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