Commit d337f898 authored by Nick Thomas's avatar Nick Thomas

Document adding non-standard SSL certificates to the Geo secondary

parent 2a030c97
...@@ -137,7 +137,17 @@ Using hashed storage significantly improves Geo replication - project and group ...@@ -137,7 +137,17 @@ 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 4. Managing the secondary GitLab node ### Step 4. (Optional) Configuring the secondary to trust the primary
You can safely skip this step if your primary uses a CA-issued HTTPS certificate.
If your primary is using a self-signed certificate for *HTTPS* support, you will
need to add that certificate to the secondary's trust store. Retrieve the
certificate from the primary and follow
[these instructions](https://docs.gitlab.com/omnibus/settings/ssl.html)
on the secondary.
### Step 5. Managing the secondary GitLab node
You can monitor the status of the syncing process on a secondary node You can monitor the status of the syncing process on a secondary node
by visiting the primary node's **Admin Area ➔ Geo Nodes** (`/admin/geo_nodes`) by visiting the primary node's **Admin Area ➔ Geo Nodes** (`/admin/geo_nodes`)
...@@ -231,7 +241,7 @@ to add a new secondary in the short term, you can follow these instructions: ...@@ -231,7 +241,7 @@ to add a new secondary in the short term, you can follow these instructions:
``` ```
Follow the steps above to set up the new Geo node. When you reach Follow the steps above to set up the new Geo node. When you reach
[Step 4: Enabling the secondary GitLab node](#step-4-enabling-the-secondary-gitlab-node) [Step 5: Enabling the secondary GitLab node](#step-5-managing-the-secondary-gitlab-node)
select "SSH (deprecated)" instead of "HTTP/HTTPS", and populate the "Public Key" select "SSH (deprecated)" instead of "HTTP/HTTPS", and populate the "Public Key"
with the output of the previous command (beginning `ssh-rsa AAAA...`). with the output of the previous command (beginning `ssh-rsa AAAA...`).
......
...@@ -128,8 +128,23 @@ Using hashed storage significantly improves Geo replication - project and group ...@@ -128,8 +128,23 @@ 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 4. (Optional) Configuring the secondary to trust the primary
### Step 4. Managing the secondary GitLab node You can safely skip this step if your primary uses a CA-issued HTTPS certificate.
If your primary is using a self-signed certificate for *HTTPS* support, you will
need to add that certificate to the secondary's trust store. Retrieve the
certificate from the primary and follow your distribution's instructions for
adding it to the secondary's trust store. In Debian/Ubuntu, for example, with a
certificate file of `primary.geo.example.com.crt`, you would follow these steps:
```
sudo -i
cp primary.geo.example.com.crt /usr/local/share/ca-certificates
update-ca-certificates
```
### Step 5. Managing the secondary GitLab node
You can monitor the status of the syncing process on a secondary node You can monitor the status of the syncing process on a secondary node
by visiting the primary node's **Admin Area ➔ Geo Nodes** (`/admin/geo_nodes`) by visiting the primary node's **Admin Area ➔ Geo Nodes** (`/admin/geo_nodes`)
......
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