Skip to content
Snippets Groups Projects
Commit 721c6ef0 authored by Marcel Amirault's avatar Marcel Amirault :interrobang:
Browse files

Standardize codeblock fences (sh)

Find and replace sh with shell
parent 6463e1b0
No related branches found
No related tags found
2 merge requests!158514Fix CodeReviewMetrics worker failure with kwargs,!24032Standardize code block naming to shell
Pipeline #113606526 passed
Showing
with 141 additions and 141 deletions
......@@ -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 root@<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 root@serverhostname (DSA)
256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (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.
```sh
```shell
gitlab-ctl replicate-geo-database \
--slot-name=<secondary_node_name> \
--host=<primary_node_ip>
......@@ -471,7 +471,7 @@ work:
admin user. If you are using an Omnibus-managed database, log onto the **primary**
node that is running the PostgreSQL database (the default Omnibus database name is gitlabhq_production):
```sh
```shell
sudo \
-u gitlab-psql /opt/gitlab/embedded/bin/psql \
-h /var/opt/gitlab/postgresql gitlabhq_production
......@@ -501,7 +501,7 @@ work:
1. Save the file and reconfigure GitLab for the changes to be applied:
```sh
```shell
gitlab-ctl reconfigure
```
......
......@@ -36,7 +36,7 @@ We need to make Docker Registry send notification events to the
1. SSH into your GitLab **primary** server and login as root:
```sh
```shell
sudo -i
```
......@@ -70,7 +70,7 @@ We need to make Docker Registry send notification events to the
1. Reconfigure the **primary** node for the change to take effect:
```sh
```shell
gitlab-ctl reconfigure
```
......@@ -90,7 +90,7 @@ generate a short-lived JWT that is pull-only-capable to access the
1. SSH into the **secondary** node and login as the `root` user:
```sh
```shell
sudo -i
```
......@@ -105,7 +105,7 @@ generate a short-lived JWT that is pull-only-capable to access the
1. Reconfigure the **secondary** node for the change to take effect:
```sh
```shell
gitlab-ctl reconfigure
```
......
......@@ -128,7 +128,7 @@ the **primary** database. Use the following as a guide.
Note that the username (`gitlab` by default) is incorporated into the hash.
```sh
```shell
gitlab-ctl pg-password-md5 gitlab
# Enter password: <your_password_here>
# Confirm password: <your_password_here>
......@@ -187,7 +187,7 @@ Configure the tracking database.
Note that the username (`gitlab_geo` by default) is incorporated into the
hash.
```sh
```shell
gitlab-ctl pg-password-md5 gitlab_geo
# Enter password: <your_password_here>
# Confirm password: <your_password_here>
......
......@@ -40,7 +40,7 @@ health check manually to get this information as well as a few more details.
This rake task can be run on an app node in the **primary** or **secondary**
Geo nodes:
```sh
```shell
sudo gitlab-rake gitlab:geo:check
```
......@@ -73,7 +73,7 @@ Checking Geo ... Finished
Current sync information can be found manually by running this rake task on any
**secondary** app node:
```sh
```shell
sudo gitlab-rake geo:status
```
......@@ -127,7 +127,7 @@ This name is used to look up the node with the same **Name** in
To check if the current machine has a node name that matches a node in the
database, run the check task:
```sh
```shell
sudo gitlab-rake gitlab:geo:check
```
......@@ -151,7 +151,7 @@ This machine's Geo node name matches a database record ... no
When running this rake task, you may see errors if the nodes are not properly configured:
```sh
```shell
sudo gitlab-rake gitlab:geo:check
```
......@@ -279,7 +279,7 @@ and indicates that your initial dataset is too large to be replicated in the def
Re-run `gitlab-ctl replicate-geo-database`, but include a larger value for
`--backup-timeout`:
```sh
```shell
sudo gitlab-ctl \
replicate-geo-database \
--host=<primary_node_hostname> \
......@@ -297,7 +297,7 @@ log data to build up in `pg_xlog`. Removing the unused slots can reduce the amou
1. Start a PostgreSQL console session:
```sh
```shell
sudo gitlab-psql
```
......@@ -348,7 +348,7 @@ postgresql['hot_standby_feedback'] = 'on'
Then reconfigure GitLab:
```sh
```shell
sudo gitlab-ctl reconfigure
```
......@@ -370,7 +370,7 @@ gitlab_rails['gitlab_shell_git_timeout'] = 10800
Then reconfigure GitLab:
```sh
```shell
sudo gitlab-ctl reconfigure
```
......@@ -390,7 +390,7 @@ to start again from scratch, there are a few steps that can help you:
You need to send a **SIGTSTP** kill signal for the first phase and them a **SIGTERM**
when all jobs have finished. Otherwise just use the `gitlab-ctl stop` commands.
```sh
```shell
gitlab-ctl status sidekiq
# run: sidekiq: (pid 10180) <- this is the PID you will use
kill -TSTP 10180 # change to the correct PID
......@@ -401,13 +401,13 @@ to start again from scratch, there are a few steps that can help you:
You can watch Sidekiq logs to know when Sidekiq jobs processing have finished:
```sh
```shell
gitlab-ctl tail sidekiq
```
1. Rename repository storage folders and create new ones. If you are not concerned about possible orphaned directories and files, then you can simply skip this step.
```sh
```shell
mv /var/opt/gitlab/git-data/repositories /var/opt/gitlab/git-data/repositories.old
mkdir -p /var/opt/gitlab/git-data/repositories
chown git:git /var/opt/gitlab/git-data/repositories
......@@ -432,7 +432,7 @@ to start again from scratch, there are a few steps that can help you:
To rename all of them:
```sh
```shell
gitlab-ctl stop
mv /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-rails/shared.old
......@@ -447,13 +447,13 @@ to start again from scratch, there are a few steps that can help you:
Reconfigure in order to recreate the folders and make sure permissions and ownership
are correctly
```sh
```shell
gitlab-ctl reconfigure
```
1. Reset the Tracking Database
```sh
```shell
gitlab-rake geo:db:drop
gitlab-ctl reconfigure
gitlab-rake geo:db:setup
......@@ -461,7 +461,7 @@ to start again from scratch, there are a few steps that can help you:
1. Restart previously stopped services
```sh
```shell
gitlab-ctl start
```
......@@ -537,7 +537,7 @@ To check the configuration:
1. SSH into an app node in the **secondary**:
```sh
```shell
sudo -i
```
......@@ -552,14 +552,14 @@ To check the configuration:
If the tracking database is running on the same node:
```sh
```shell
gitlab-geo-psql
```
Or, if the tracking database is running on a different node, you must specify
the user and host when entering the database console:
```sh
```shell
gitlab-geo-psql -U gitlab_geo -h <IP of tracking database>
```
......@@ -646,7 +646,7 @@ To check the configuration:
Make sure the password is correct. You can test that logins work by running `psql`:
```sh
```shell
# Connect to the tracking database as the `gitlab_geo` user
sudo \
-u git /opt/gitlab/embedded/bin/psql \
......@@ -685,7 +685,7 @@ reload of the FDW schema. To manually reload the FDW schema:
1. On the node running the Geo tracking database, enter the PostgreSQL console via
the `gitlab_geo` user:
```sh
```shell
sudo \
-u git /opt/gitlab/embedded/bin/psql \
-h /var/opt/gitlab/geo-postgresql \
......@@ -729,7 +729,7 @@ Geo database has an outdated FDW remote schema. It contains 229 of 236 expected
To resolve this, run the following command:
```sh
```shell
sudo gitlab-rake geo:db:refresh_foreign_tables
```
......
......@@ -42,7 +42,7 @@ everything is working correctly:
1. Run the Geo raketask on all nodes, everything should be green:
```sh
```shell
sudo gitlab-rake gitlab:geo:check
```
......
......@@ -16,7 +16,7 @@ This update will occur even if major PostgreSQL updates are disabled.
Before [refreshing Foreign Data Wrapper during a Geo HA upgrade](https://docs.gitlab.com/omnibus/update/README.html#run-post-deployment-migrations-and-checks),
restart the Geo tracking database:
```sh
```shell
sudo gitlab-ctl restart geo-postgresql
```
......@@ -31,7 +31,7 @@ for the recommended procedure.
This can be temporarily disabled by running the following before updating:
```sh
```shell
sudo touch /etc/gitlab/disable-postgresql-upgrade
```
......@@ -41,7 +41,7 @@ Before 10.8, broadcast messages would not propagate without flushing
the cache on the **secondary** nodes. This has been fixed in 10.8, but
requires one last cache flush on each **secondary** node:
```sh
```shell
sudo gitlab-rake cache:clear
```
......@@ -55,7 +55,7 @@ authentication method.
1. **(primary)** Login to your **primary** node and run:
```sh
```shell
gitlab-ctl pg-password-md5 gitlab
# Enter password: <your_password_here>
# Confirm password: <your_password_here>
......@@ -82,7 +82,7 @@ authentication method.
1. **(primary)** Reconfigure and restart:
```sh
```shell
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
```
......@@ -113,7 +113,7 @@ authentication method.
1. **(secondary)** Reconfigure and restart:
```sh
```shell
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
```
......@@ -129,7 +129,7 @@ contents of `/etc/gitlab/gitlab-secrets.json` on each **secondary** node with th
contents of `/etc/gitlab/gitlab-secrets.json` on the **primary** node, then run the
following command on each **secondary** node:
```sh
```shell
sudo gitlab-ctl reconfigure
```
......@@ -228,7 +228,7 @@ following to clean this up.
On the **secondary** Geo nodes, run as root:
```sh
```shell
mv /var/opt/gitlab/gitlab-rails/working /var/opt/gitlab/gitlab-rails/working.old
mkdir /var/opt/gitlab/gitlab-rails/working
chmod 700 /var/opt/gitlab/gitlab-rails/working
......@@ -240,7 +240,7 @@ You may delete `/var/opt/gitlab/gitlab-rails/working.old` any time.
Once this is done, we advise restarting GitLab on the **secondary** nodes for the
new working directory to be used:
```sh
```shell
sudo gitlab-ctl restart
```
......@@ -289,7 +289,7 @@ is prepended with the relevant node for better clarity:
1. **(secondary)** Make a backup of the `recovery.conf` file on **all**
**secondary** nodes to preserve PostgreSQL's credentials:
```sh
```shell
sudo cp /var/opt/gitlab/postgresql/data/recovery.conf /var/opt/gitlab/
```
......@@ -301,7 +301,7 @@ is prepended with the relevant node for better clarity:
stop all services except `postgresql` as we will use it to re-initialize the
**secondary** node's database:
```sh
```shell
sudo gitlab-ctl stop
sudo gitlab-ctl start postgresql
```
......@@ -310,19 +310,19 @@ is prepended with the relevant node for better clarity:
1. **(secondary)** Stop all services:
```sh
```shell
sudo gitlab-ctl stop
```
1. **(secondary)** Prevent running database migrations:
```sh
```shell
sudo touch /etc/gitlab/skip-auto-migrations
```
1. **(secondary)** Move the old database to another directory:
```sh
```shell
sudo mv /var/opt/gitlab/postgresql{,.bak}
```
......@@ -331,26 +331,26 @@ is prepended with the relevant node for better clarity:
1. **(secondary)** Make sure all services are up:
```sh
```shell
sudo gitlab-ctl start
```
1. **(secondary)** Reconfigure GitLab:
```sh
```shell
sudo gitlab-ctl reconfigure
```
1. **(secondary)** Run the PostgreSQL upgrade command:
```sh
```shell
sudo gitlab-ctl pg-upgrade
```
1. **(secondary)** See the stored credentials for the database that you will
need to re-initialize the replication:
```sh
```shell
sudo grep -s primary_conninfo /var/opt/gitlab/recovery.conf
```
......@@ -404,19 +404,19 @@ is prepended with the relevant node for better clarity:
1. **(secondary)** Run the recovery script using the credentials from the
previous step:
```sh
```shell
sudo bash /tmp/replica.sh
```
1. **(secondary)** Reconfigure GitLab:
```sh
```shell
sudo gitlab-ctl reconfigure
```
1. **(secondary)** Start all services:
```sh
```shell
sudo gitlab-ctl start
```
......@@ -425,7 +425,7 @@ is prepended with the relevant node for better clarity:
1. **(primary)** After all **secondary** nodes are updated, start all services in
**primary** node:
```sh
```shell
sudo gitlab-ctl start
```
......@@ -437,7 +437,7 @@ and it is required since 10.0.
1. Run database migrations on tracking database:
```sh
```shell
sudo gitlab-rake geo:db:migrate
```
......
......@@ -45,7 +45,7 @@ AcceptEnv GIT_PROTOCOL
Once configured, restart the SSH daemon. In Ubuntu, run:
```sh
```shell
sudo service ssh restart
```
......@@ -54,7 +54,7 @@ sudo service ssh restart
In order to use the new protocol, clients need to either pass the configuration
`-c protocol.version=2` to the Git command, or set it globally:
```sh
```shell
git config --global protocol.version 2
```
......@@ -62,7 +62,7 @@ git config --global protocol.version 2
Verify Git v2 is used by the client:
```sh
```shell
GIT_TRACE_CURL=1 git -c protocol.version=2 ls-remote https://your-gitlab-instance.com/group/repo.git 2>&1 | grep Git-Protocol
```
......@@ -74,13 +74,13 @@ You should see that the `Git-Protocol` header is sent:
Verify Git v2 is used by the server:
```sh
```shell
GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote https://your-gitlab-instance.com/group/repo.git 2>&1 | head
```
Example response using Git protocol v2:
```sh
```shell
$ GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote https://your-gitlab-instance.com/group/repo.git 2>&1 | head
10:42:50.574485 pkt-line.c:80 packet: git< # service=git-upload-pack
10:42:50.574653 pkt-line.c:80 packet: git< 0000
......@@ -98,7 +98,7 @@ $ GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote https://your-gitlab-ins
Verify Git v2 is used by the client:
```sh
```shell
GIT_SSH_COMMAND="ssh -v" git -c protocol.version=2 ls-remote ssh://your-gitlab-instance.com:group/repo.git 2>&1 |grep GIT_PROTOCOL
```
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment