Commit 721c6ef0 authored by Marcel Amirault's avatar Marcel Amirault 🌴

Standardize codeblock fences (sh)

Find and replace sh with shell
parent 6463e1b0
Pipeline #113606526 passed with stages
in 5 minutes and 13 seconds
......@@ -144,7 +144,7 @@ the steps bellow.
1. Enter the Rails console:
```sh
```shell
sudo gitlab-rails console
```
......
......@@ -14,13 +14,13 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t
For omnibus installation
```sh
```shell
sudo editor /etc/gitlab/gitlab.rb
```
For installations from source:
```sh
```shell
sudo -u git -H editor /home/git/gitlab/config/gitlab.yml
```
......
......@@ -20,13 +20,13 @@ Authenticate to GitLab using the Atlassian Crowd OmniAuth provider.
**Omnibus:**
```sh
```shell
sudo editor /etc/gitlab/gitlab.rb
```
**Source:**
```sh
```shell
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
......
......@@ -149,7 +149,7 @@ You can use the [`AdFind`](https://social.technet.microsoft.com/wiki/contents/ar
You can use the filter `objectclass=*` to return all directory objects.
```sh
```shell
adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -up Password1 -b "OU=GitLab INT,DC=GitLab,DC=org" -f (objectClass=*)
```
......@@ -157,7 +157,7 @@ adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -u
You can also retrieve a single object by **specifying** the object name or full **DN**. In this example we specify the object name only `CN=Leroy Fox`.
```sh
```shell
adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -up Password1 -b "OU=GitLab INT,DC=GitLab,DC=org" -f (&(objectcategory=person)(CN=Leroy Fox))
```
......@@ -169,7 +169,7 @@ You can use the `ldapsearch` utility (on Unix based systems) to test that your L
You can use the filter `objectclass=*` to return all directory objects.
```sh
```shell
ldapsearch -D "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" \
-w Password1 -p 636 -h ad.example.org \
-b "OU=GitLab INT,DC=GitLab,DC=org" -Z \
......@@ -180,7 +180,7 @@ ldapsearch -D "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" \
You can also retrieve a single object by **specifying** the object name or full **DN**. In this example we specify the object name only `CN=Leroy Fox`.
```sh
```shell
ldapsearch -D "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -w Password1 -p 389 -h ad.example.org -b "OU=GitLab INT,DC=GitLab,DC=org" -Z -s sub "CN=Leroy Fox"
```
......
......@@ -11,13 +11,13 @@ JWT will provide you with a secret key for you to use.
For Omnibus GitLab:
```sh
```shell
sudo editor /etc/gitlab/gitlab.rb
```
For installations from source:
```sh
```shell
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
......
......@@ -564,7 +564,7 @@ This example uses `ldapsearch` and assumes you are using ActiveDirectory. The
following query returns the login names of the users that will be allowed to
log in to GitLab if you configure your own user_filter.
```sh
```shell
ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt -b "$base" "$user_filter" sAMAccountName
```
......
......@@ -13,13 +13,13 @@ The OpenID Connect will provide you with a client details and secret for you to
For Omnibus GitLab:
```sh
```shell
sudo editor /etc/gitlab/gitlab.rb
```
For installations from source:
```sh
```shell
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
......
......@@ -46,13 +46,13 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
**For Omnibus GitLab installations**
```sh
```shell
sudo editor /etc/gitlab/gitlab.rb
```
**For installations from source**
```sh
```shell
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
......
......@@ -27,7 +27,7 @@ the node more time before scheduling a planned failover.
Run the following commands in a Rails console on the **primary** node:
```sh
```shell
gitlab-rails console
```
......@@ -95,7 +95,7 @@ The automatic background re-verification is enabled by default, but you can
disable if you need. Run the following commands in a Rails console on the
**primary** node:
```sh
```shell
gitlab-rails console
```
......@@ -120,13 +120,13 @@ to be resynced without the backoff period:
For repositories:
```sh
```shell
sudo gitlab-rake geo:verification:repository:reset
```
For wikis:
```sh
```shell
sudo gitlab-rake geo:verification:wiki:reset
```
......@@ -146,25 +146,25 @@ If the **primary** and **secondary** nodes have a checksum verification mismatch
(the path is usually `/var/opt/gitlab/git-data/repositories`). Note that if `git_data_dirs`
is customized, check the directory layout on your server to be sure.
```sh
```shell
cd /var/opt/gitlab/git-data/repositories
```
1. Run the following command on the **primary** node, redirecting the output to a file:
```sh
```shell
git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > primary-node-refs
```
1. Run the following command on the **secondary** node, redirecting the output to a file:
```sh
```shell
git show-ref --head | grep -E "HEAD|(refs/(heads|tags|keep-around|merge-requests|environments|notes)/)" > secondary-node-refs
```
1. Copy the files from the previous steps on the same system, and do a diff between the contents:
```sh
```shell
diff primary-node-refs secondary-node-refs
```
......
......@@ -21,7 +21,7 @@ To bring the former **primary** node up to date:
1. SSH into the former **primary** node that has fallen behind.
1. Make sure all the services are up:
```sh
```shell
sudo gitlab-ctl start
```
......
......@@ -39,13 +39,13 @@ must disable the **primary** node.
1. SSH into the **primary** node to stop and disable GitLab, if possible:
```sh
```shell
sudo gitlab-ctl stop
```
Prevent GitLab from starting up again if the server unexpectedly reboots:
```sh
```shell
sudo systemctl disable gitlab-runsvdir
```
......@@ -54,7 +54,7 @@ must disable the **primary** node.
started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3058)).
It may be safest to uninstall the GitLab package completely:
```sh
```shell
yum remove gitlab-ee
```
......@@ -63,7 +63,7 @@ must disable the **primary** node.
or any other distro based on the Upstart init system, you can prevent GitLab
from starting if the machine reboots by doing the following:
```sh
```shell
initctl stop gitlab-runsvvdir
echo 'manual' > /etc/init/gitlab-runsvdir.override
initctl reload-configuration
......@@ -100,7 +100,7 @@ Note the following when promoting a secondary:
1. SSH in to your **secondary** node and login as root:
```sh
```shell
sudo -i
```
......@@ -117,7 +117,7 @@ Note the following when promoting a secondary:
1. Promote the **secondary** node to the **primary** node. Execute:
```sh
```shell
gitlab-ctl promote-to-primary-node
```
......@@ -173,7 +173,7 @@ secondary domain, like changing Git remotes and API URLs.
1. SSH into the **secondary** node and login as root:
```sh
```shell
sudo -i
```
......@@ -192,13 +192,13 @@ secondary domain, like changing Git remotes and API URLs.
1. Reconfigure the **secondary** node for the change to take effect:
```sh
```shell
gitlab-ctl reconfigure
```
1. Execute the command below to update the newly promoted **primary** node URL:
```sh
```shell
gitlab-rake geo:update_primary_node_url
```
......@@ -223,7 +223,7 @@ Because the **secondary** is already promoted, that data in the tracking databas
The data can be removed with the following command:
```sh
```shell
sudo rm -rf /var/opt/gitlab/geo-postgresql
```
......@@ -237,7 +237,7 @@ and after that you also need two extra steps.
1. SSH into the new **primary** node and login as root:
```sh
```shell
sudo -i
```
......@@ -268,13 +268,13 @@ and after that you also need two extra steps.
1. Save the file and reconfigure GitLab for the database listen changes and
the replication slot changes to be applied.
```sh
```shell
gitlab-ctl reconfigure
```
Restart PostgreSQL for its changes to take effect:
```sh
```shell
gitlab-ctl restart postgresql
```
......@@ -289,7 +289,7 @@ and after that you also need two extra steps.
Save the file and reconfigure GitLab:
```sh
```shell
gitlab-ctl reconfigure
```
......
......@@ -65,7 +65,7 @@ supports everything the **primary** node does **before** scheduling a planned fa
Run the following on both **primary** and **secondary** nodes:
```sh
```shell
gitlab-rake gitlab:check
gitlab-rake gitlab:geo:check
```
......@@ -79,7 +79,7 @@ The SSH host keys and `/etc/gitlab/gitlab-secrets.json` files should be
identical on all nodes. Check this by running the following on all nodes and
comparing the output:
```sh
```shell
sudo sha256sum /etc/ssh/ssh_host* /etc/gitlab/gitlab-secrets.json
```
......@@ -136,7 +136,7 @@ access to the **primary** node during the maintenance window.
For instance, you might run the following commands on the server(s) making up your **primary** node:
```sh
```shell
sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 22 -j ACCEPT
sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
sudo iptables -A INPUT --destination-port 22 -j REJECT
......
......@@ -30,7 +30,7 @@ they must be manually replicated to the **secondary** node.
1. SSH into the **primary** node, and execute the command below:
```sh
```shell
sudo cat /etc/gitlab/gitlab-secrets.json
```
......@@ -38,20 +38,20 @@ they must be manually replicated to the **secondary** node.
1. SSH into the **secondary** node and login as the `root` user:
```sh
```shell
sudo -i
```
1. Make a backup of any existing secrets:
```sh
```shell
mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
```
1. Copy `/etc/gitlab/gitlab-secrets.json` from the **primary** node to the **secondary** node, or
copy-and-paste the file contents between nodes:
```sh
```shell
sudo editor /etc/gitlab/gitlab-secrets.json
# paste the output of the `cat` command you ran on the primary
......@@ -60,14 +60,14 @@ they must be manually replicated to the **secondary** node.
1. Ensure the file permissions are correct:
```sh
```shell
chown root:root /etc/gitlab/gitlab-secrets.json
chmod 0600 /etc/gitlab/gitlab-secrets.json
```
1. Reconfigure the **secondary** node for the change to take effect:
```sh
```shell
gitlab-ctl reconfigure
gitlab-ctl restart
```
......@@ -88,13 +88,13 @@ keys must be manually replicated to the **secondary** node.
1. SSH into the **secondary** node and login as the `root` user:
```sh
```shell
sudo -i
```
1. Make a backup of any existing SSH host keys:
```sh
```shell
find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
```
......@@ -102,14 +102,14 @@ keys must be manually replicated to the **secondary** node.
If you can access your **primary** node using the **root** user:
```sh
```shell
# Run this from the secondary node, change `<primary_node_fqdn>` for the IP or FQDN of the server
scp [email protected]<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
```
If you only have access through a user with **sudo** privileges:
```sh
```shell
# Run this from your primary node:
sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
......@@ -120,20 +120,20 @@ keys must be manually replicated to the **secondary** node.
1. On your **secondary** node, ensure the file permissions are correct:
```sh
```shell
chown root:root /etc/ssh/ssh_host_*_key*
chmod 0600 /etc/ssh/ssh_host_*_key*
```
1. To verify key fingerprint matches, execute the following command on both nodes:
```sh
```shell
for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
```
You should get an output similar to this one and they should be identical on both nodes:
```sh
```shell
1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M [email protected] (DSA)
256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY [email protected] (ECDSA)
256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM [email protected] (ED25519)
......@@ -142,7 +142,7 @@ keys must be manually replicated to the **secondary** node.
1. Verify that you have the correct public keys for the existing private keys:
```sh
```shell
# This will print the fingerprint for private keys:
for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
......@@ -155,7 +155,7 @@ keys must be manually replicated to the **secondary** node.
1. Restart sshd on your **secondary** node:
```sh
```shell
# Debian or Ubuntu installations
sudo service ssh reload
......@@ -167,7 +167,7 @@ keys must be manually replicated to the **secondary** node.
1. SSH into your GitLab **secondary** server and login as root:
```sh
```shell
sudo -i
```
......@@ -180,7 +180,7 @@ keys must be manually replicated to the **secondary** node.
1. Reconfigure the **secondary** node for the change to take effect:
```sh
```shell
gitlab-ctl reconfigure
```
......@@ -201,20 +201,20 @@ keys must be manually replicated to the **secondary** node.
1. Click the **Add node** button to add the **secondary** node.
1. SSH into your GitLab **secondary** server and restart the services:
```sh
```shell
gitlab-ctl restart
```
Check if there are any common issue with your Geo setup by running:
```sh
```shell
gitlab-rake gitlab:geo:check
```
1. SSH into your **primary** server and login as root to verify the
**secondary** node is reachable or there are any common issue with your Geo setup:
```sh
```shell
gitlab-rake gitlab:geo:check
```
......
......@@ -49,7 +49,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
1. SSH into your GitLab **primary** server and login as root:
```sh
```shell
sudo -i
```
......@@ -62,13 +62,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
1. Reconfigure the **primary** node for the change to take effect:
```sh
```shell
gitlab-ctl reconfigure
```
1. Execute the command below to define the node as **primary** node:
```sh
```shell
gitlab-ctl set-geo-primary-node
```
......@@ -78,7 +78,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
Generate a MD5 hash of the desired password:
```sh
```shell
gitlab-ctl pg-password-md5 gitlab
# Enter password: <your_password_here>
# Confirm password: <your_password_here>
......@@ -101,7 +101,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
called `gitlab_replicator`. You must set the password for this user manually.
You will be prompted to enter a password:
```sh
```shell
gitlab-ctl set-replication-password
```
......@@ -134,7 +134,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
To lookup the address of a Geo node, SSH in to the Geo node and execute:
```sh
```shell
##
## Private address
##
......@@ -219,13 +219,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
1. Save the file and reconfigure GitLab for the database listen changes and
the replication slot changes to be applied:
```sh
```shell
gitlab-ctl reconfigure
```
Restart PostgreSQL for its changes to take effect:
```sh
```shell
gitlab-ctl restart postgresql
```
......@@ -240,7 +240,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
Save the file and reconfigure GitLab:
```sh
```shell
gitlab-ctl reconfigure
```
......@@ -254,7 +254,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
the **secondary** node needs a copy of the certificate. Make a copy of the PostgreSQL
`server.crt` file on the **primary** node by running this command:
```sh
```shell
cat ~gitlab-psql/data/server.crt
```
......@@ -266,13 +266,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
1. SSH into your GitLab **secondary** server and login as root:
```sh
```shell
sudo -i
```
1. Stop application server and Sidekiq
```sh
```shell
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
```
......@@ -282,7 +282,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
1. [Check TCP connectivity][rake-maintenance] to the **primary** node's PostgreSQL server:
```sh
```shell
gitlab-rake gitlab:tcp_check[<primary_node_ip>,5432]
```
......@@ -295,7 +295,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
1. Create a file `server.crt` in the **secondary** server, with the content you got on the last step of the **primary** node's setup:
```sh
```shell
editor server.crt
```
......@@ -303,7 +303,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
Install the `server.crt` file:
```sh
```shell
install \
-D \
-o gitlab-psql \
......@@ -319,7 +319,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
1. Test that the `gitlab-psql` user can connect to the **primary** node's database
(the default Omnibus database name is gitlabhq_production):
```sh
```shell
sudo \
-u gitlab-psql /opt/gitlab/embedded/bin/psql \
--list \
......@@ -377,13 +377,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
1. Reconfigure GitLab for the changes to take effect:
```sh
```shell
gitlab-ctl reconfigure
```
1. Restart PostgreSQL for the IP change to take effect and reconfigure again:
```sh
```shell
gitlab-ctl restart postgresql
gitlab-ctl reconfigure
```
......@@ -405,7 +405,7 @@ data before running `pg_basebackup`.
1. SSH into your GitLab **secondary** server and login as root:
```sh
```shell
sudo -i
```
......@@ -419,7 +419,7 @@ data before running `pg_basebackup`.
CAUTION: **Warning:** Each Geo **secondary** node must have its own unique replication slot name.
Using the same slot name between two secondaries will break PostgreSQL replication.