diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-01-30 15:09:15 +0000 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-01-30 15:09:15 +0000 |
| commit | 536aa3a1f4b96abc4ca34489bf2cbe503afcded7 (patch) | |
| tree | 88d08f7dfa29a32d6526773c4fe0fefd9f2bc7d1 /doc/administration | |
| parent | 50ae4065530c4eafbeb7c5ff2c462c48c02947ca (diff) | |
| download | gitlab-ce-536aa3a1f4b96abc4ca34489bf2cbe503afcded7.tar.gz | |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/administration')
76 files changed, 502 insertions, 500 deletions
diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md index 6366ed21865..fa217c31eb2 100644 --- a/doc/administration/audit_events.md +++ b/doc/administration/audit_events.md @@ -144,7 +144,7 @@ the steps bellow. 1. Enter the Rails console: - ```sh + ```shell sudo gitlab-rails console ``` diff --git a/doc/administration/auth/authentiq.md b/doc/administration/auth/authentiq.md index b84eca4ef0d..d15beb4f6fc 100644 --- a/doc/administration/auth/authentiq.md +++ b/doc/administration/auth/authentiq.md @@ -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 ``` diff --git a/doc/administration/auth/crowd.md b/doc/administration/auth/crowd.md index 8704782e78f..da6c01ec382 100644 --- a/doc/administration/auth/crowd.md +++ b/doc/administration/auth/crowd.md @@ -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 diff --git a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md index a5a102d888b..35620be7d7e 100644 --- a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md +++ b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md @@ -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" ``` diff --git a/doc/administration/auth/jwt.md b/doc/administration/auth/jwt.md index 146baeba6d1..15eee50c771 100644 --- a/doc/administration/auth/jwt.md +++ b/doc/administration/auth/jwt.md @@ -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 ``` diff --git a/doc/administration/auth/ldap-ee.md b/doc/administration/auth/ldap-ee.md index a15e34c33a5..5217cd5114a 100644 --- a/doc/administration/auth/ldap-ee.md +++ b/doc/administration/auth/ldap-ee.md @@ -465,7 +465,7 @@ step of the sync. 1. Start a Rails console: - ```bash + ```shell # For Omnibus installations sudo gitlab-rails console @@ -540,7 +540,7 @@ statements. Indicates the point where syncing actually begins: -```bash +```shell Started syncing all providers for 'my_group' group ``` @@ -551,7 +551,7 @@ log entries like this - one for each LDAP group. If you don't see an LDAP user DN in this log entry, LDAP is not returning the user when we do the lookup. Verify the user is actually in the LDAP group. -```bash +```shell Members in 'ldap_group_1' LDAP group: ["uid=john0,ou=people,dc=example,dc=com", "uid=mary0,ou=people,dc=example,dc=com", "uid=john1,ou=people,dc=example,dc=com", "uid=mary1,ou=people,dc=example,dc=com", "uid=john2,ou=people,dc=example,dc=com", @@ -571,7 +571,7 @@ NOTE: **Note:** 10 is 'Guest', 20 is 'Reporter', 30 is 'Developer', 40 is 'Maintainer' and 50 is 'Owner'. -```bash +```shell Resolved 'my_group' group member access: {"uid=john0,ou=people,dc=example,dc=com"=>30, "uid=mary0,ou=people,dc=example,dc=com"=>30, "uid=john1,ou=people,dc=example,dc=com"=>30, "uid=mary1,ou=people,dc=example,dc=com"=>30, "uid=john2,ou=people,dc=example,dc=com"=>30, @@ -588,7 +588,7 @@ If you think a particular user should already exist in GitLab, but you're seeing this entry, it could be due to a mismatched DN stored in GitLab. See [User DN has changed](#User-DN-has-changed) to update the user's LDAP identity. -```bash +```shell User with DN `uid=john0,ou=people,dc=example,dc=com` should have access to 'my_group' group but there is no user in GitLab with that identity. Membership will be updated once the user signs in for @@ -597,6 +597,6 @@ the first time. Finally, the following entry says syncing has finished for this group: -```bash +```shell Finished syncing all providers for 'my_group' group ``` diff --git a/doc/administration/auth/ldap.md b/doc/administration/auth/ldap.md index 857f554f2fe..6f6c2e0068e 100644 --- a/doc/administration/auth/ldap.md +++ b/doc/administration/auth/ldap.md @@ -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 ``` @@ -583,7 +583,7 @@ ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt -b "$ba - Run the following check command to make sure that the LDAP settings are correct and GitLab can see your users: - ```bash + ```shell # For Omnibus installations sudo gitlab-rake gitlab:ldap:check diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md index 698a5506b83..6f59cffc3cc 100644 --- a/doc/administration/auth/oidc.md +++ b/doc/administration/auth/oidc.md @@ -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 ``` diff --git a/doc/administration/auth/okta.md b/doc/administration/auth/okta.md index 41745e8caae..7b5effe3d77 100644 --- a/doc/administration/auth/okta.md +++ b/doc/administration/auth/okta.md @@ -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 ``` diff --git a/doc/administration/file_hooks.md b/doc/administration/file_hooks.md index 89b454a73a0..5c8fb2f9d74 100644 --- a/doc/administration/file_hooks.md +++ b/doc/administration/file_hooks.md @@ -94,7 +94,7 @@ The rake task will use a sample data and execute each of file hook. The output should be enough to determine if the system sees your file hook and if it was executed without errors. -```bash +```shell # Omnibus installations sudo gitlab-rake file_hooks:validate diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md index 5caf1d53a2c..ca2cfec6e13 100644 --- a/doc/administration/geo/disaster_recovery/background_verification.md +++ b/doc/administration/geo/disaster_recovery/background_verification.md @@ -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 ``` diff --git a/doc/administration/geo/disaster_recovery/bring_primary_back.md b/doc/administration/geo/disaster_recovery/bring_primary_back.md index 64d7ef2d609..96280e4570b 100644 --- a/doc/administration/geo/disaster_recovery/bring_primary_back.md +++ b/doc/administration/geo/disaster_recovery/bring_primary_back.md @@ -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 ``` diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md index a3014c0a21e..2999e0b6f1d 100644 --- a/doc/administration/geo/disaster_recovery/index.md +++ b/doc/administration/geo/disaster_recovery/index.md @@ -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 ``` @@ -135,7 +135,7 @@ do this manually. 1. SSH in to the database node in the **secondary** and trigger PostgreSQL to promote to read-write: - ```bash + ```shell sudo gitlab-pg-ctl promote ``` @@ -157,7 +157,7 @@ do this manually. 1. Promote the **secondary** to **primary**. SSH into a single application server and execute: - ```bash + ```shell sudo gitlab-rake geo:set_secondary_as_primary ``` @@ -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 ``` diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md index 8fee172ec64..cd3d5a88de7 100644 --- a/doc/administration/geo/disaster_recovery/planned_failover.md +++ b/doc/administration/geo/disaster_recovery/planned_failover.md @@ -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 diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md index 44baab40153..58507d2c487 100644 --- a/doc/administration/geo/replication/configuration.md +++ b/doc/administration/geo/replication/configuration.md @@ -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 ``` diff --git a/doc/administration/geo/replication/database.md b/doc/administration/geo/replication/database.md index bddd30dbb2a..0e6583741bc 100644 --- a/doc/administration/geo/replication/database.md +++ b/doc/administration/geo/replication/database.md @@ -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 ``` diff --git a/doc/administration/geo/replication/docker_registry.md b/doc/administration/geo/replication/docker_registry.md index 95db766e482..7d041d97ed2 100644 --- a/doc/administration/geo/replication/docker_registry.md +++ b/doc/administration/geo/replication/docker_registry.md @@ -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 ``` diff --git a/doc/administration/geo/replication/external_database.md b/doc/administration/geo/replication/external_database.md index 6948dcc0c68..210c3a77128 100644 --- a/doc/administration/geo/replication/external_database.md +++ b/doc/administration/geo/replication/external_database.md @@ -13,13 +13,13 @@ developed and tested. We aim to be compatible with most external 1. SSH into a GitLab **primary** application server and login as root: - ```bash + ```shell sudo -i ``` 1. Execute the command below to define the node as **primary** node: - ```bash + ```shell gitlab-ctl set-geo-primary-node ``` @@ -100,7 +100,7 @@ To configure the connection to the external read-replica database and enable Log 1. SSH into a GitLab **secondary** application server and login as root: - ```bash + ```shell sudo -i ``` @@ -147,7 +147,7 @@ the tracking database on port 5432. 1. SSH into a GitLab **secondary** server and login as root: - ```bash + ```shell sudo -i ``` @@ -168,7 +168,7 @@ the tracking database on port 5432. 1. Run the tracking database migrations: - ```bash + ```shell gitlab-rake geo:db:create gitlab-rake geo:db:migrate ``` @@ -179,7 +179,7 @@ the tracking database on port 5432. Save the script below in a file, ex. `/tmp/geo_fdw.sh` and modify the connection params to match your environment. Execute it to set up the FDW connection. - ```bash + ```shell #!/bin/bash # Secondary Database connection params: @@ -213,6 +213,6 @@ the tracking database on port 5432. 1. Save the file and [restart GitLab](../../restart_gitlab.md#omnibus-gitlab-restart) 1. Populate the FDW tables: - ```bash + ```shell gitlab-rake geo:db:refresh_foreign_tables ``` diff --git a/doc/administration/geo/replication/high_availability.md b/doc/administration/geo/replication/high_availability.md index 19266a6b358..5c124e9c6dc 100644 --- a/doc/administration/geo/replication/high_availability.md +++ b/doc/administration/geo/replication/high_availability.md @@ -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> diff --git a/doc/administration/geo/replication/remove_geo_node.md b/doc/administration/geo/replication/remove_geo_node.md index e24eb2bd428..c3ff0ef47c1 100644 --- a/doc/administration/geo/replication/remove_geo_node.md +++ b/doc/administration/geo/replication/remove_geo_node.md @@ -10,13 +10,13 @@ Once removed from the Geo admin page, you must stop and uninstall the **secondar 1. On the **secondary** node, stop GitLab: - ```bash + ```shell sudo gitlab-ctl stop ``` 1. On the **secondary** node, uninstall GitLab: - ```bash + ```shell # Stop gitlab and remove its supervision process sudo gitlab-ctl uninstall @@ -31,7 +31,7 @@ Once GitLab has been uninstalled from the **secondary** node, the replication sl 1. On the **primary** node, start a PostgreSQL console session: - ```bash + ```shell sudo gitlab-psql ``` diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md index 46fd5eb7ca7..1a4c37dc709 100644 --- a/doc/administration/geo/replication/troubleshooting.md +++ b/doc/administration/geo/replication/troubleshooting.md @@ -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 ``` diff --git a/doc/administration/geo/replication/updating_the_geo_nodes.md b/doc/administration/geo/replication/updating_the_geo_nodes.md index fda0ebbbeac..426eb54c66a 100644 --- a/doc/administration/geo/replication/updating_the_geo_nodes.md +++ b/doc/administration/geo/replication/updating_the_geo_nodes.md @@ -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 ``` diff --git a/doc/administration/geo/replication/using_a_geo_server.md b/doc/administration/geo/replication/using_a_geo_server.md index b814bcf8459..b1ba5b3e876 100644 --- a/doc/administration/geo/replication/using_a_geo_server.md +++ b/doc/administration/geo/replication/using_a_geo_server.md @@ -8,7 +8,7 @@ Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS) Example of the output you will see when pushing to a **secondary** node: -```bash +```shell $ git push remote: remote: You're pushing to a Geo secondary. We'll help you by proxying this diff --git a/doc/administration/geo/replication/version_specific_updates.md b/doc/administration/geo/replication/version_specific_updates.md index 772defe0191..5fb9391af99 100644 --- a/doc/administration/geo/replication/version_specific_updates.md +++ b/doc/administration/geo/replication/version_specific_updates.md @@ -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,33 +331,33 @@ 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 ``` 1. **(secondary)** Save the snippet below in a file, let's say `/tmp/replica.sh`. Modify the embedded paths if necessary: - ```bash + ```shell #!/bin/bash PORT="5432" @@ -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 ``` diff --git a/doc/administration/git_annex.md b/doc/administration/git_annex.md index 52d848efa27..87e1d3b1e8e 100644 --- a/doc/administration/git_annex.md +++ b/doc/administration/git_annex.md @@ -96,7 +96,7 @@ one is located in `config.yml` of GitLab Shell. Here is an example workflow of uploading a very large file and then checking it into your Git repository: -```bash +```shell git clone git@example.com:group/project.git git annex init 'My Laptop' # initialize the annex project and give an optional description @@ -165,7 +165,7 @@ repository. Downloading a single large file is also very simple: -```bash +```shell git clone git@gitlab.example.com:group/project.git git annex sync # sync Git branches but not the large file @@ -174,7 +174,7 @@ git annex get debian.iso # download the large file To download all files: -```bash +```shell git clone git@gitlab.example.com:group/project.git git annex sync --content # sync Git branches and download all the large files diff --git a/doc/administration/git_protocol.md b/doc/administration/git_protocol.md index 436f1a55369..2e5c362a3ab 100644 --- a/doc/administration/git_protocol.md +++ b/doc/administration/git_protocol.md @@ -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 ``` diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index f1c9604b77f..ec5b8e57870 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -309,7 +309,7 @@ can read and write to `/mnt/gitlab/storage2`. 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure). 1. Tail the logs to see the requests: - ```sh + ```shell sudo gitlab-ctl tail gitaly ``` @@ -343,7 +343,7 @@ can read and write to `/mnt/gitlab/storage2`. 1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source). 1. Tail the logs to see the requests: - ```sh + ```shell tail -f /home/git/gitlab/log/gitaly.log ``` @@ -435,7 +435,7 @@ To configure Gitaly with TLS: 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on client node(s). 1. On the Gitaly server, create the `/etc/gitlab/ssl` directory and copy your key and certificate there: - ```sh + ```shell sudo mkdir -p /etc/gitlab/ssl sudo chmod 755 /etc/gitlab/ssl sudo cp key.pem cert.pem /etc/gitlab/ssl/ @@ -491,7 +491,7 @@ To configure Gitaly with TLS: 1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) on client node(s). 1. Create the `/etc/gitlab/ssl` directory and copy your key and certificate there: - ```sh + ```shell sudo mkdir -p /etc/gitlab/ssl sudo chmod 700 /etc/gitlab/ssl sudo cp key.pem cert.pem /etc/gitlab/ssl/ @@ -856,7 +856,7 @@ your GitLab / Gitaly server already at `/opt/gitlab/embedded/bin/gitaly-debug`. If you're investigating an older GitLab version you can compile this tool offline and copy the executable to your server: -```sh +```shell git clone https://gitlab.com/gitlab-org/gitaly.git cd cmd/gitaly-debug GOOS=linux GOARCH=amd64 go build -o gitaly-debug @@ -864,7 +864,7 @@ GOOS=linux GOARCH=amd64 go build -o gitaly-debug To see the help page of `gitaly-debug` for a list of supported sub-commands, run: -```sh +```shell gitaly-debug -h ``` @@ -887,7 +887,7 @@ default level is `WARN`. You can run a GRPC trace with: -```sh +```shell GRPC_TRACE=all GRPC_VERBOSITY=DEBUG sudo gitlab-rake gitlab:gitaly:check ``` @@ -925,7 +925,7 @@ Confirm the following are all true: - When any user performs a `git push` to any repository on this Gitaly node, it fails with the following error (note the `401 Unauthorized`): - ```sh + ```shell remote: GitLab: 401 Unauthorized To <REMOTE_URL> ! [remote rejected] branch-name -> branch-name (pre-receive hook declined) @@ -939,7 +939,7 @@ Confirm the following are all true: - When [tailing the logs](https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server) on an app node and reproducing the error, you get `401` errors when reaching the `/api/v4/internal/allowed` endpoint: - ```sh + ```shell # api_json.log { "time": "2019-07-18T00:30:14.967Z", @@ -1009,7 +1009,7 @@ If you are having trouble connecting to a Gitaly node with command line (CLI) to Verify that you can reach Gitaly via TCP: -```bash +```shell sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT] ``` @@ -1019,7 +1019,7 @@ If you use proxy servers in your command line environment, such as Bash, these c If you use Bash or a compatible command line environment, run the following commands to determine whether you have proxy servers configured: -```bash +```shell echo $http_proxy echo $https_proxy ``` @@ -1028,7 +1028,7 @@ If either of these variables have a value, your Gitaly CLI connections may be ge To remove the proxy setting, run the following commands (depending on which variables had values): -```bash +```shell unset http_proxy unset https_proxy ``` diff --git a/doc/administration/high_availability/consul.md b/doc/administration/high_availability/consul.md index 71d380dbec7..0ea5e55cc35 100644 --- a/doc/administration/high_availability/consul.md +++ b/doc/administration/high_availability/consul.md @@ -58,7 +58,7 @@ On each Consul node perform the following: Before moving on, make sure Consul is configured correctly. Run the following command to verify all server nodes are communicating: -```sh +```shell /opt/gitlab/embedded/bin/consul members ``` diff --git a/doc/administration/high_availability/database.md b/doc/administration/high_availability/database.md index 8e57b049730..daeb0f9baf5 100644 --- a/doc/administration/high_availability/database.md +++ b/doc/administration/high_availability/database.md @@ -46,7 +46,7 @@ deploy the bundled PostgreSQL. and confirmation. Use the value that is output by this command in the next step as the value of `POSTGRESQL_PASSWORD_HASH`. - ```sh + ```shell sudo gitlab-ctl pg-password-md5 gitlab ``` @@ -202,7 +202,7 @@ When using default setup, minimum configuration requires: - `CONSUL_PASSWORD_HASH`. This is a hash generated out of Consul username/password pair. Can be generated with: - ```sh + ```shell sudo gitlab-ctl pg-password-md5 CONSUL_USERNAME ``` @@ -245,7 +245,7 @@ We will need the following password information for the application's database u - `POSTGRESQL_PASSWORD_HASH`. This is a hash generated out of the username/password pair. Can be generated with: - ```sh + ```shell sudo gitlab-ctl pg-password-md5 POSTGRESQL_USERNAME ``` @@ -258,7 +258,7 @@ When using default setup, minimum configuration requires: - `PGBOUNCER_PASSWORD_HASH`. This is a hash generated out of PgBouncer username/password pair. Can be generated with: - ```sh + ```shell sudo gitlab-ctl pg-password-md5 PGBOUNCER_USERNAME ``` @@ -376,13 +376,13 @@ Select one node as a primary node. 1. Open a database prompt: - ```sh + ```shell gitlab-psql -d gitlabhq_production ``` 1. Enable the `pg_trgm` extension: - ```sh + ```shell CREATE EXTENSION pg_trgm; ``` @@ -390,7 +390,7 @@ Select one node as a primary node. 1. Verify the cluster is initialized with one node: - ```sh + ```shell gitlab-ctl repmgr cluster show ``` @@ -411,7 +411,7 @@ Select one node as a primary node. 1. Set up the repmgr standby: - ```sh + ```shell gitlab-ctl repmgr standby setup MASTER_NODE_NAME ``` @@ -436,7 +436,7 @@ Select one node as a primary node. 1. Verify the node now appears in the cluster: - ```sh + ```shell gitlab-ctl repmgr cluster show ``` @@ -457,7 +457,7 @@ Before moving on, make sure the databases are configured correctly. Run the following command on the **primary** node to verify that replication is working properly: -```sh +```shell gitlab-ctl repmgr cluster show ``` @@ -475,7 +475,7 @@ If the 'Role' column for any node says "FAILED", check the Also, check that the check master command works successfully on each node: -```sh +```shell su - gitlab-consul gitlab-ctl repmgr-check-master || echo 'This node is a standby repmgr node' ``` @@ -512,7 +512,7 @@ attributes set, but the following need to be set. Ensure that all migrations ran: -```sh +```shell gitlab-rake gitlab:db:configure ``` @@ -702,7 +702,7 @@ After deploying the configuration follow these steps: Enable the `pg_trgm` extension - ```sh + ```shell gitlab-psql -d gitlabhq_production ``` @@ -714,7 +714,7 @@ After deploying the configuration follow these steps: Make this node a standby of the primary - ```sh + ```shell gitlab-ctl repmgr standby setup 10.6.0.21 ``` @@ -722,7 +722,7 @@ After deploying the configuration follow these steps: Make this node a standby of the primary - ```sh + ```shell gitlab-ctl repmgr standby setup 10.6.0.21 ``` @@ -730,13 +730,13 @@ After deploying the configuration follow these steps: Set `gitlab-consul` user's PgBouncer password to `toomanysecrets` - ```sh + ```shell gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul ``` Run database migrations - ```sh + ```shell gitlab-rake gitlab:db:configure ``` @@ -863,7 +863,7 @@ If you need to failover manually, you have two options: Run: -```sh +```shell gitlab-ctl stop postgresql ``` @@ -875,14 +875,14 @@ standby nodes. 1. Ensure the old master node is not still active. 1. Login to the server that should become the new master and run: - ```sh + ```shell gitlab-ctl repmgr standby promote ``` 1. If there are any other standby servers in the cluster, have them follow the new master server: - ```sh + ```shell gitlab-ctl repmgr standby follow NEW_MASTER ``` @@ -894,7 +894,7 @@ after it has been restored to service. - If you want to remove the node from the cluster, on any other node in the cluster, run: - ```sh + ```shell gitlab-ctl repmgr standby unregister --node=X ``` @@ -902,7 +902,7 @@ after it has been restored to service. To find this, you can use: - ```sh + ```shell awk -F = '$1 == "node" { print $2 }' /var/opt/gitlab/postgresql/repmgr.conf ``` @@ -914,13 +914,13 @@ after it has been restored to service. Then you will use this id to unregister the node: - ```sh + ```shell gitlab-ctl repmgr standby unregister --node=959789412 ``` - To add the node as a standby server: - ```sh + ```shell gitlab-ctl repmgr standby follow NEW_MASTER gitlab-ctl restart repmgrd ``` @@ -972,7 +972,7 @@ the previous section: 1. On the current master node, create a password for the `gitlab` and `gitlab_repmgr` user: - ```sh + ```shell gitlab-psql -d template1 template1=# \password gitlab_repmgr Enter password: **** @@ -992,7 +992,7 @@ the previous section: 1. Create a `.pgpass` file. Enter the `gitlab_repmgr` password twice to when asked: - ```sh + ```shell gitlab-ctl write-pgpass --user gitlab_repmgr --hostuser gitlab-psql --database '*' ``` diff --git a/doc/administration/high_availability/gitlab.md b/doc/administration/high_availability/gitlab.md index b4269cd4e38..ad00cb8df9f 100644 --- a/doc/administration/high_availability/gitlab.md +++ b/doc/administration/high_availability/gitlab.md @@ -101,7 +101,7 @@ these additional steps before proceeding with GitLab installation. On the first application server, run: -```sh +```shell sudo gitlab-ctl reconfigure ``` diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index 1d0dc420987..0d88191151a 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -55,7 +55,7 @@ NOTE: **Note:** From GitLab 12.1, it will automatically be detected if Rugged ca If you previously enabled Rugged using the feature flag, you will need to unset the feature flag by using: -```sh +```shell sudo gitlab-rake gitlab:features:unset_rugged ``` @@ -82,7 +82,7 @@ on an Linux NFS server, do the following: 1. On the NFS server, run: - ```sh + ```shell echo 0 > /proc/sys/fs/leases-enable sysctl -w fs.leases-enable=0 ``` @@ -186,7 +186,7 @@ single NFS mount point as you normally would in `/etc/fstab`. Let's assume your NFS mount point is `/gitlab-nfs`. Then, add the following bind mounts in `/etc/fstab`: -```bash +```shell /gitlab-nfs/gitlab-data/git-data /var/opt/gitlab/git-data none bind 0 0 /gitlab-nfs/gitlab-data/.ssh /var/opt/gitlab/.ssh none bind 0 0 /gitlab-nfs/gitlab-data/uploads /var/opt/gitlab/gitlab-rails/uploads none bind 0 0 diff --git a/doc/administration/high_availability/nfs_host_client_setup.md b/doc/administration/high_availability/nfs_host_client_setup.md index 5b6b28bf633..75dec1eef29 100644 --- a/doc/administration/high_availability/nfs_host_client_setup.md +++ b/doc/administration/high_availability/nfs_host_client_setup.md @@ -27,7 +27,7 @@ Using EFS may negatively impact performance. Please review the [relevant documen Installing the nfs-kernel-server package allows you to share directories with the clients running the GitLab application. -```sh +```shell apt-get update apt-get install nfs-kernel-server ``` @@ -47,7 +47,7 @@ In this setup we will share the home directory on the host with the client. Edit Restart the NFS server after making changes to the `exports` file for the changes to take effect. -```sh +```shell systemctl restart nfs-kernel-server ``` @@ -64,7 +64,7 @@ inside your HA environment to the NFS server configured above. The nfs-common provides NFS functionality without installing server components which we don't need running on the application nodes. -```sh +```shell apt-get update apt-get install nfs-common ``` @@ -76,14 +76,14 @@ Please note that if your mount point directory contains any files they will be h once the remote shares are mounted. An empty/new directory on the client is recommended for this purpose. -```sh +```shell mkdir -p /nfs/home ``` Confirm that the mount point works by mounting it on the client and checking that it is mounted with the command below: -```sh +```shell mount <host_ip_address>:/home df -h ``` @@ -134,7 +134,7 @@ Check that NFS traffic from the client is allowed by the firewall on the host by the command: `sudo ufw status`. If it's being blocked, then you can allow traffic from a specific client with the command below. -```sh +```shell sudo ufw allow from <client-ip-address> to any port nfs ``` diff --git a/doc/administration/high_availability/pgbouncer.md b/doc/administration/high_availability/pgbouncer.md index 7b93159628d..cea55e6c9b4 100644 --- a/doc/administration/high_availability/pgbouncer.md +++ b/doc/administration/high_availability/pgbouncer.md @@ -57,7 +57,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data 1. Create a `.pgpass` file so Consul is able to reload PgBouncer. Enter the `PGBOUNCER_PASSWORD` twice when asked: - ```sh + ```shell gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul ``` @@ -65,7 +65,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data 1. Ensure each node is talking to the current master: - ```sh + ```shell gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD ``` @@ -77,7 +77,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data 1. Once the console prompt is available, run the following queries: - ```sh + ```shell show databases ; show clients ; ``` diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 8e94b56a940..01ee94ce208 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -8,8 +8,10 @@ type: reference The following are the requirements for providing your own Redis instance: -- Redis version 2.8 or higher. Version 3.2 or higher is recommend as this is - what ships with the GitLab Omnibus package. +- GitLab 12.0 and later requires Redis version 3.2 or higher. Version 3.2 or higher is recommend as this is + what ships with the GitLab Omnibus package. Older Redis versions do not + support an optional count argument to SPOP which is now required for + [Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md). - Standalone Redis or Redis high availability with Sentinel are supported. Redis Cluster is not supported. - Managed Redis from cloud providers such as AWS Elasticache will work. If these @@ -978,7 +980,7 @@ To make sure your configuration is correct: 1. To simulate a failover on master Redis, SSH into the Redis server and run: - ```bash + ```shell # port must match your master redis port, and the sleep time must be a few seconds bigger than defined one redis-cli -h localhost -p 6379 DEBUG sleep 20 ``` diff --git a/doc/administration/incoming_email.md b/doc/administration/incoming_email.md index 1550787d532..07b6f79a0fa 100644 --- a/doc/administration/incoming_email.md +++ b/doc/administration/incoming_email.md @@ -102,14 +102,14 @@ for a real-world example of this exploit. 1. Reconfigure GitLab for the changes to take effect: - ```sh + ```shell sudo gitlab-ctl reconfigure sudo gitlab-ctl restart ``` 1. Verify that everything is configured correctly: - ```sh + ```shell sudo gitlab-rake gitlab:incoming_email:check ``` @@ -119,7 +119,7 @@ Reply by email should now be working. 1. Go to the GitLab installation directory: - ```sh + ```shell cd /home/git/gitlab ``` @@ -128,20 +128,20 @@ Reply by email should now be working. 1. Enable `mail_room` in the init script at `/etc/default/gitlab`: - ```sh + ```shell sudo mkdir -p /etc/default echo 'mail_room_enabled=true' | sudo tee -a /etc/default/gitlab ``` 1. Restart GitLab: - ```sh + ```shell sudo service gitlab restart ``` 1. Verify that everything is configured correctly: - ```sh + ```shell sudo -u git -H bundle exec rake gitlab:incoming_email:check RAILS_ENV=production ``` diff --git a/doc/administration/integration/plantuml.md b/doc/administration/integration/plantuml.md index 33ac925748f..4e34e9923e1 100644 --- a/doc/administration/integration/plantuml.md +++ b/doc/administration/integration/plantuml.md @@ -15,7 +15,7 @@ server that will generate the diagrams. With Docker, you can just run a container like this: -```sh +```shell docker run -d --name plantuml -p 8080:8080 plantuml/plantuml-server:tomcat ``` @@ -50,7 +50,7 @@ own PlantUML server is easy in Debian/Ubuntu distributions using Tomcat. First you need to create a `plantuml.war` file from the source code: -```sh +```shell sudo apt-get install graphviz openjdk-8-jdk git-core maven git clone https://github.com/plantuml/plantuml-server.git cd plantuml-server @@ -101,7 +101,7 @@ nginx['custom_gitlab_server_config'] = "location /-/plantuml { \n rewrite ^/-/(p To activate the changes, run the following command: -```sh +```shell sudo gitlab-ctl reconfigure ``` diff --git a/doc/administration/invalidate_markdown_cache.md b/doc/administration/invalidate_markdown_cache.md index ebd8578e410..7bebf555a6c 100644 --- a/doc/administration/invalidate_markdown_cache.md +++ b/doc/administration/invalidate_markdown_cache.md @@ -11,6 +11,6 @@ increasing the `local_markdown_version` setting in application settings. This c be done by [changing the application settings through the API](../api/settings.md#change-application-settings): -```bash +```shell curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings?local_markdown_version=<increased_number> ``` diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md index 04974c6ea8b..ad17e9064e6 100644 --- a/doc/administration/job_artifacts.md +++ b/doc/administration/job_artifacts.md @@ -156,7 +156,7 @@ _The artifacts are stored by default in 1. Save the file and [reconfigure GitLab][] for the changes to take effect. 1. Migrate any existing local artifacts to the object storage: - ```bash + ```shell gitlab-rake gitlab:artifacts:migrate ``` @@ -184,7 +184,7 @@ _The artifacts are stored by default in 1. Save the file and [restart GitLab][] for the changes to take effect. 1. Migrate any existing local artifacts to the object storage: - ```bash + ```shell sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production ``` @@ -239,7 +239,7 @@ you can flip the feature flag from a Rails console. 1. Enter the Rails console: - ```sh + ```shell sudo gitlab-rails console ``` @@ -253,7 +253,7 @@ you can flip the feature flag from a Rails console. 1. Enter the Rails console: - ```sh + ```shell cd /home/git/gitlab RAILS_ENV=production sudo -u git -H bundle exec rails console ``` diff --git a/doc/administration/job_logs.md b/doc/administration/job_logs.md index fc37fbb170d..7f56f98db08 100644 --- a/doc/administration/job_logs.md +++ b/doc/administration/job_logs.md @@ -100,7 +100,7 @@ Here is the detailed data flow: The following commands are to be issued in a Rails console: -```sh +```shell # Omnibus GitLab gitlab-rails console diff --git a/doc/administration/lfs/lfs_administration.md b/doc/administration/lfs/lfs_administration.md index fbf48619854..68a5939dcd1 100644 --- a/doc/administration/lfs/lfs_administration.md +++ b/doc/administration/lfs/lfs_administration.md @@ -138,13 +138,13 @@ There are two ways to manually do the same thing as automatic uploading (describ **Option 1: rake task** -```sh +```shell rake gitlab:lfs:migrate ``` **Option 2: rails console** -```sh +```shell $ sudo gitlab-rails console # Login to rails console > # Upload LFS files manually @@ -178,7 +178,7 @@ On Omnibus installations, the settings are prefixed by `lfs_object_store_`: 1. Save the file and [reconfigure GitLab]s for the changes to take effect. 1. Migrate any existing local LFS objects to the object storage: - ```bash + ```shell gitlab-rake gitlab:lfs:migrate ``` @@ -214,7 +214,7 @@ For source installations the settings are nested under `lfs:` and then 1. Save the file and [restart GitLab][] for the changes to take effect. 1. Migrate any existing local LFS objects to the object storage: - ```bash + ```shell sudo -u git -H bundle exec rake gitlab:lfs:migrate RAILS_ENV=production ``` diff --git a/doc/administration/lfs/manage_large_binaries_with_git_lfs.md b/doc/administration/lfs/manage_large_binaries_with_git_lfs.md index 1fd3077ecb9..025b547c37e 100644 --- a/doc/administration/lfs/manage_large_binaries_with_git_lfs.md +++ b/doc/administration/lfs/manage_large_binaries_with_git_lfs.md @@ -50,7 +50,7 @@ Lets take a look at the workflow when you need to check large files into your Gi repository with Git LFS. For example, if you want to upload a very large file and check it into your Git repository: -```bash +```shell git clone git@gitlab.example.com:group/project.git git lfs install # initialize the Git LFS project git lfs track "*.iso" # select the file extensions that you want to treat as large files @@ -59,7 +59,7 @@ git lfs track "*.iso" # select the file extensions that you want Once a certain file extension is marked for tracking as a LFS object you can use Git as usual without having to redo the command to track a file with the same extension: -```bash +```shell cp ~/tmp/debian.iso ./ # copy a large file into the current directory git add . # add the large file to the project git commit -am "Added Debian iso" # commit the file meta data @@ -69,7 +69,7 @@ git push origin master # sync the git repo and large file to the **Make sure** that `.gitattributes` is tracked by Git. Otherwise Git LFS will not be working properly for people cloning the project: -```bash +```shell git add .gitattributes ``` @@ -78,14 +78,14 @@ LFS-tracked files and clones them via HTTP. If you performed the `git clone` command with a SSH URL, you have to enter your GitLab credentials for HTTP authentication. -```bash +```shell git clone git@gitlab.example.com:group/project.git ``` If you already cloned the repository and you want to get the latest LFS object that are on the remote repository, eg. for a branch from origin: -```bash +```shell git lfs fetch origin master ``` @@ -101,14 +101,14 @@ The first thing to do before using File Locking is to tell Git LFS which kind of files are lockable. The following command will store PNG files in LFS and flag them as lockable: -```bash +```shell git lfs track "*.png" --lockable ``` After executing the above command a file named `.gitattributes` will be created or updated with the following content: -```bash +```shell *.png filter=lfs diff=lfs merge=lfs -text lockable ``` @@ -116,7 +116,7 @@ You can also register a file type as lockable without using LFS (In order to be able to lock/unlock a file you need a remote server that implements the LFS File Locking API), in order to do that you can edit the `.gitattributes` file manually: -```bash +```shell *.pdf lockable ``` @@ -128,14 +128,14 @@ need to lock the file before editing it. Once you're ready to edit your file you need to lock it first: -```bash +```shell git lfs lock images/banner.png Locked images/banner.png ``` This will register the file as locked in your name on the server: -```bash +```shell git lfs locks images/banner.png joe ID:123 ``` @@ -143,13 +143,13 @@ images/banner.png joe ID:123 Once you have pushed your changes, you can unlock the file so others can also edit it: -```bash +```shell git lfs unlock images/banner.png ``` You can also unlock by id: -```bash +```shell git lfs unlock --id=123 ``` @@ -157,7 +157,7 @@ If for some reason you need to unlock a file that was not locked by you, you can use the `--force` flag as long as you have a `maintainer` access on the project: -```bash +```shell git lfs unlock --id=123 --force ``` @@ -183,7 +183,7 @@ available to the project anymore. Probably the object was removed from the serve Git LFS will log the failures into a log file. To view this log file, while in project directory: -```bash +```shell git lfs logs last ``` @@ -215,7 +215,7 @@ This behaviour is caused by Git LFS using HTTPS connections by default when a To prevent this from happening, set the lfs url in project Git config: -```bash +```shell git config --add lfs.url "http://gitlab.example.com/group/project.git/info/lfs" ``` @@ -235,7 +235,7 @@ you use. This is described in [Git credentials man pages](https://git-scm.com/do For example, you can tell Git to remember the password for a period of time in which you expect to push the objects: -```bash +```shell git config --global credential.helper 'cache --timeout=3600' ``` diff --git a/doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md b/doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md index cf798472d62..3f983bebf27 100644 --- a/doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md +++ b/doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md @@ -48,7 +48,7 @@ Fire up a terminal, navigate to your Git repository and: 1. Disable `git-annex`: - ```bash + ```shell git annex sync --content git annex direct git annex uninit @@ -85,7 +85,7 @@ if the server also has Git Annex 6 installed. Read more in the 1. Backup your repository - ```bash + ```shell cd repository git annex sync --content cd .. @@ -97,14 +97,14 @@ if the server also has Git Annex 6 installed. Read more in the 1. Use `annex direct`: - ```bash + ```shell cd repository git annex direct ``` The output should be similar to this: - ```bash + ```shell commit On branch master Your branch is up-to-date with 'origin/master'. @@ -116,13 +116,13 @@ if the server also has Git Annex 6 installed. Read more in the 1. Disable Git Annex with [`annex uninit`][uninit]: - ```bash + ```shell git annex uninit ``` The output should be similar to this: - ```bash + ```shell unannex debian.iso ok Deleted branch git-annex (was 2534d2c). ``` @@ -131,13 +131,13 @@ if the server also has Git Annex 6 installed. Read more in the 1. Switch back to `indirect` mode: - ```bash + ```shell git annex indirect ``` The output should be similar to this: - ```bash + ```shell (merging origin/git-annex into git-annex...) (recording state in git...) commit (recording state in git...) @@ -165,7 +165,7 @@ GitLab.com), therefore, you don't need to do anything server-side. 1. First, make sure you have `git-lfs` installed locally: - ```bash + ```shell git lfs help ``` @@ -174,7 +174,7 @@ GitLab.com), therefore, you don't need to do anything server-side. 1. Inside the repo, run the following command to initiate LFS: - ```bash + ```shell git lfs install ``` @@ -182,7 +182,7 @@ GitLab.com), therefore, you don't need to do anything server-side. can track specific files, all files containing the same extension, or an entire directory: - ```bash + ```shell git lfs track images/01.png # per file git lfs track **/*.png # per extension git lfs track images/ # per directory @@ -194,7 +194,7 @@ GitLab.com), therefore, you don't need to do anything server-side. 1. Add the files, commit and push them to GitLab: - ```bash + ```shell git add . git commit -m "commit message" git push @@ -217,7 +217,7 @@ branches created by Git Annex: `git-annex`, and all under `synced/`. You can also do this on the command line with: -```bash +```shell git branch -d synced/master git branch -d synced/git-annex git push origin :synced/master @@ -229,7 +229,7 @@ git remote prune origin If there are still some Annex objects inside your repository (`.git/annex/`) or references inside `.git/config`, run `annex uninit` again: -```bash +```shell git annex uninit ``` diff --git a/doc/administration/monitoring/performance/gitlab_configuration.md b/doc/administration/monitoring/performance/gitlab_configuration.md index 1bff170768a..e8a6c661464 100644 --- a/doc/administration/monitoring/performance/gitlab_configuration.md +++ b/doc/administration/monitoring/performance/gitlab_configuration.md @@ -17,7 +17,7 @@ changes. Finally, a restart of all GitLab processes is required for the changes to take effect: -```bash +```shell # For Omnibus installations sudo gitlab-ctl restart diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md index 2fbbeb0b774..2fdeeae302b 100644 --- a/doc/administration/monitoring/performance/grafana_configuration.md +++ b/doc/administration/monitoring/performance/grafana_configuration.md @@ -133,7 +133,7 @@ After upgrading, the Grafana dashboard will be disabled and the location of your To prevent the data from being relocated, you can run the following command prior to upgrading: -```sh +```shell echo "0" > /var/opt/gitlab/grafana/CVE_reset_status ``` diff --git a/doc/administration/monitoring/performance/influxdb_configuration.md b/doc/administration/monitoring/performance/influxdb_configuration.md index b18be09ef4b..234d0dc2e88 100644 --- a/doc/administration/monitoring/performance/influxdb_configuration.md +++ b/doc/administration/monitoring/performance/influxdb_configuration.md @@ -110,14 +110,14 @@ buffer size is set to the same value, the default value is almost never enough. To set the OS buffer size to 200 MB, on Linux you can run the following command: -```bash +```shell sysctl -w net.core.rmem_max=209715200 ``` To make this permanent, add the following to `/etc/sysctl.conf` and restart the server: -```bash +```shell net.core.rmem_max=209715200 ``` @@ -154,7 +154,7 @@ and password (`-password <password>`) you set earlier to the commands below._ Run the following command to create a database named `gitlab`: -```bash +```shell influx -execute 'CREATE DATABASE gitlab' ``` @@ -162,7 +162,7 @@ The name **must** be `gitlab`, do not use any other name. Next, make sure that the database was successfully created: -```bash +```shell influx -execute 'SHOW DATABASES' ``` diff --git a/doc/administration/operations/extra_sidekiq_processes.md b/doc/administration/operations/extra_sidekiq_processes.md index fd5f9fe6c26..5cdd33ba507 100644 --- a/doc/administration/operations/extra_sidekiq_processes.md +++ b/doc/administration/operations/extra_sidekiq_processes.md @@ -55,7 +55,7 @@ To start extra Sidekiq processes, you must enable `sidekiq-cluster`: 1. Save the file and reconfigure GitLab for the changes to take effect: - ```sh + ```shell sudo gitlab-ctl reconfigure ``` @@ -78,7 +78,7 @@ you list: 1. Save the file and reconfigure GitLab for the changes to take effect: - ```sh + ```shell sudo gitlab-ctl reconfigure ``` @@ -113,7 +113,7 @@ use all of its resources to perform those operations. To set up a separate 1. Save the file and reconfigure GitLab for the changes to take effect: - ```sh + ```shell sudo gitlab-ctl reconfigure ``` @@ -145,7 +145,7 @@ details. 1. Save the file and reconfigure GitLab for the changes to take effect: - ```sh + ```shell sudo gitlab-ctl reconfigure ``` @@ -162,7 +162,7 @@ This will set the concurrency (number of threads) for the Sidekiq process. 1. Save the file and reconfigure GitLab for the changes to take effect: - ```sh + ```shell sudo gitlab-ctl reconfigure ``` @@ -207,7 +207,7 @@ For debugging purposes, you can start extra Sidekiq processes by using the comma `/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster`. This command takes arguments using the following syntax: -```bash +```shell /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...] ``` @@ -225,14 +225,14 @@ For example, say you want to start 2 extra processes: one to process the `process_commit` queue, and one to process the `post_receive` queue. This can be done as follows: -```bash +```shell /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit post_receive ``` If you instead want to start one process processing both queues, you'd use the following syntax: -```bash +```shell /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive ``` @@ -240,7 +240,7 @@ If you want to have one Sidekiq process dealing with the `process_commit` and `post_receive` queues, and one process to process the `gitlab_shell` queue, you'd use the following: -```bash +```shell /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive gitlab_shell ``` @@ -272,7 +272,7 @@ The `sidekiq-cluster` command can store its PID in a file. By default no PID file is written, but this can be changed by passing the `--pidfile` option to `sidekiq-cluster`. For example: -```bash +```shell /opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster --pidfile /var/run/gitlab/sidekiq_cluster.pid process_commit ``` diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md index 96571b0a5d9..7d0fc43f810 100644 --- a/doc/administration/operations/fast_ssh_key_lookup.md +++ b/doc/administration/operations/fast_ssh_key_lookup.md @@ -60,7 +60,7 @@ AuthorizedKeysCommandUser git Reload OpenSSH: -```bash +```shell # Debian or Ubuntu installations sudo service ssh reload diff --git a/doc/administration/operations/filesystem_benchmarking.md b/doc/administration/operations/filesystem_benchmarking.md index b5922d9d99d..0a20e94a778 100644 --- a/doc/administration/operations/filesystem_benchmarking.md +++ b/doc/administration/operations/filesystem_benchmarking.md @@ -25,7 +25,7 @@ To install: Then run the following: -```sh +```shell fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/path/to/git-data/testfile --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 ``` @@ -78,32 +78,32 @@ executed, and then read the same 1,000 files. [repository storage path](../repository_storage_paths.md). 1. Create a temporary directory for the test so it's easy to remove the files later: - ```sh + ```shell mkdir test; cd test ``` 1. Run the command: - ```sh + ```shell time for i in {0..1000}; do echo 'test' > "test${i}.txt"; done ``` 1. To benchmark read performance, run the command: - ```sh + ```shell time for i in {0..1000}; do cat "test${i}.txt" > /dev/null; done ``` 1. Remove the test files: - ```sh + ```shell cd ../; rm -rf test ``` The output of the `time for ...` commands will look similar to the following. The important metric is the `real` time. -```sh +```shell $ time for i in {0..1000}; do echo 'test' > "test${i}.txt"; done real 0m0.116s diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md index 3804319f60d..b325fc59469 100644 --- a/doc/administration/packages/container_registry.md +++ b/doc/administration/packages/container_registry.md @@ -169,7 +169,7 @@ If your certificate provider provides the CA Bundle certificates, append them to Users should now be able to login to the Container Registry with their GitLab credentials using: -```bash +```shell docker login gitlab.example.com:4567 ``` @@ -194,7 +194,7 @@ Let's assume that you want the container Registry to be accessible at `/etc/gitlab/ssl/registry.gitlab.example.com.key` and make sure they have correct permissions: - ```bash + ```shell chmod 600 /etc/gitlab/ssl/registry.gitlab.example.com.* ``` @@ -234,7 +234,7 @@ registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key" Users should now be able to login to the Container Registry using their GitLab credentials: -```bash +```shell docker login registry.gitlab.example.com ``` @@ -793,7 +793,7 @@ After adding the setting, [reconfigure GitLab](../restart_gitlab.md#omnibus-gitl Use curl to request debug output from the debug server: -```bash +```shell curl localhost:5001/debug/health curl localhost:5001/debug/vars ``` diff --git a/doc/administration/packages/index.md b/doc/administration/packages/index.md index 2d2a6f3de3a..421b70709b5 100644 --- a/doc/administration/packages/index.md +++ b/doc/administration/packages/index.md @@ -166,12 +166,12 @@ The processing will be done in a background worker and requires **no downtime**. For Omnibus GitLab: -```sh +```shell sudo gitlab-rake "gitlab:packages:migrate" ``` For installations from source: -```bash +```shell RAILS_ENV=production sudo -u git -H bundle exec rake gitlab:packages:migrate ``` diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md index 1521c48f6fd..5ed0965115e 100644 --- a/doc/administration/pages/index.md +++ b/doc/administration/pages/index.md @@ -360,14 +360,14 @@ that method from working. Use the following workaround: 1. Append your GitLab server TLS/SSL certficate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL - ```bash + ```shell printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem echo -n | openssl s_client -connect gitlab-domain-example.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem ``` 1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For GitLab Omnibus instances: - ```bash + ```shell sudo gitlab-ctl restart gitlab-pages ``` diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md index 3689a604840..1f38a71efe1 100644 --- a/doc/administration/pages/source.md +++ b/doc/administration/pages/source.md @@ -98,7 +98,7 @@ The Pages daemon doesn't listen to the outside world. 1. Install the Pages daemon: - ```bash + ```shell cd /home/git sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git cd gitlab-pages @@ -108,7 +108,7 @@ The Pages daemon doesn't listen to the outside world. 1. Go to the GitLab installation directory: - ```bash + ```shell cd /home/git/gitlab ``` @@ -138,7 +138,7 @@ The Pages daemon doesn't listen to the outside world. 1. Copy the `gitlab-pages` NGINX configuration file: - ```bash + ```shell sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages.conf ``` @@ -160,7 +160,7 @@ outside world. 1. Install the Pages daemon: - ```bash + ```shell cd /home/git sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git cd gitlab-pages @@ -170,7 +170,7 @@ outside world. 1. In `gitlab.yml`, set the port to `443` and https to `true`: - ```bash + ```shell ## GitLab Pages pages: enabled: true @@ -195,7 +195,7 @@ outside world. 1. Copy the `gitlab-pages-ssl` NGINX configuration file: - ```bash + ```shell sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages-ssl.conf ``` @@ -225,7 +225,7 @@ world. Custom domains are supported, but no TLS. 1. Install the Pages daemon: - ```bash + ```shell cd /home/git sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git cd gitlab-pages @@ -263,7 +263,7 @@ world. Custom domains are supported, but no TLS. 1. Copy the `gitlab-pages-ssl` NGINX configuration file: - ```bash + ```shell sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages.conf ``` @@ -290,7 +290,7 @@ world. Custom domains and TLS are supported. 1. Install the Pages daemon: - ```bash + ```shell cd /home/git sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git cd gitlab-pages @@ -332,7 +332,7 @@ world. Custom domains and TLS are supported. 1. Copy the `gitlab-pages-ssl` NGINX configuration file: - ```bash + ```shell sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages-ssl.conf ``` diff --git a/doc/administration/pseudonymizer.md b/doc/administration/pseudonymizer.md index fd42f6a6363..eac4dc26b4e 100644 --- a/doc/administration/pseudonymizer.md +++ b/doc/administration/pseudonymizer.md @@ -85,7 +85,7 @@ You can optionally run the pseudonymizer using the following environment variabl - `PSEUDONYMIZER_OUTPUT_DIR` - where to store the output CSV files (defaults to `/tmp`) - `PSEUDONYMIZER_BATCH` - the batch size when querying the DB (defaults to `100000`) -```bash +```shell ## Omnibus sudo gitlab-rake gitlab:db:pseudonymizer diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md index 7f3405df060..6f9a7f4293d 100644 --- a/doc/administration/raketasks/check.md +++ b/doc/administration/raketasks/check.md @@ -33,13 +33,13 @@ integrity check described previously. **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:git:fsck ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:git:fsck RAILS_ENV=production ``` @@ -58,7 +58,7 @@ Currently, integrity checks are supported for the following types of file: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:artifacts:check sudo gitlab-rake gitlab:lfs:check sudo gitlab-rake gitlab:uploads:check @@ -66,7 +66,7 @@ sudo gitlab-rake gitlab:uploads:check **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:artifacts:check RAILS_ENV=production sudo -u git -H bundle exec rake gitlab:lfs:check RAILS_ENV=production sudo -u git -H bundle exec rake gitlab:uploads:check RAILS_ENV=production @@ -82,7 +82,7 @@ Variable | Type | Description `ID_TO` | integer | Specifies the ID value to end at, inclusive of the value. `VERBOSE` | boolean | Causes failures to be listed individually, rather than being summarized. -```bash +```shell sudo gitlab-rake gitlab:artifacts:check BATCH=100 ID_FROM=50 ID_TO=250 sudo gitlab-rake gitlab:lfs:check BATCH=100 ID_FROM=50 ID_TO=250 sudo gitlab-rake gitlab:uploads:check BATCH=100 ID_FROM=50 ID_TO=250 @@ -90,7 +90,7 @@ sudo gitlab-rake gitlab:uploads:check BATCH=100 ID_FROM=50 ID_TO=250 Example output: -```bash +```shell $ sudo gitlab-rake gitlab:uploads:check Checking integrity of Uploads - 1..1350: Failures: 0 @@ -107,7 +107,7 @@ Done! Example verbose output: -```bash +```shell $ sudo gitlab-rake gitlab:uploads:check VERBOSE=1 Checking integrity of Uploads - 1..1350: Failures: 0 diff --git a/doc/administration/raketasks/geo.md b/doc/administration/raketasks/geo.md index 8bf720d2872..91c83b5f6ba 100644 --- a/doc/administration/raketasks/geo.md +++ b/doc/administration/raketasks/geo.md @@ -11,13 +11,13 @@ This is equivalent of running `git repack -d` on a _bare_ repository. **Omnibus Installation** -```bash +```shell sudo gitlab-rake geo:git:housekeeping:incremental_repack ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake geo:git:housekeeping:incremental_repack RAILS_ENV=production ``` @@ -29,13 +29,13 @@ when this is enabled in GitLab. **Omnibus Installation** -```bash +```shell sudo gitlab-rake geo:git:housekeeping:full_repack ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake geo:git:housekeeping:full_repack RAILS_ENV=production ``` @@ -46,13 +46,13 @@ a reachability bitmap index when this is enabled in GitLab. **Omnibus Installation** -```bash +```shell sudo gitlab-rake geo:git:housekeeping:gc ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake geo:git:housekeeping:gc RAILS_ENV=production ``` @@ -63,12 +63,12 @@ can remove them using the rake task `geo:run_orphaned_project_registry_cleaner`: **Omnibus Installation** -```bash +```shell sudo gitlab-rake geo:run_orphaned_project_registry_cleaner ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake geo:run_orphaned_project_registry_cleaner RAILS_ENV=production ``` diff --git a/doc/administration/raketasks/github_import.md b/doc/administration/raketasks/github_import.md index d6dd39cb1bc..6bf77b1fa0b 100644 --- a/doc/administration/raketasks/github_import.md +++ b/doc/administration/raketasks/github_import.md @@ -16,7 +16,7 @@ before/after the brackets. Also, Some shells (e.g., zsh) can interpret the open/ To import a project from the list of your GitHub projects available: -```bash +```shell # Omnibus installations sudo gitlab-rake "import:github[access_token,root,foo/bar]" @@ -32,7 +32,7 @@ will get created from your GitHub project. Subgroups are also possible: `foo/foo To import a specific GitHub project (named `foo/github_repo` here): -```bash +```shell # Omnibus installations sudo gitlab-rake "import:github[access_token,root,foo/bar,foo/github_repo]" diff --git a/doc/administration/raketasks/ldap.md b/doc/administration/raketasks/ldap.md index 41a9a4192cf..899b1ef9f4d 100644 --- a/doc/administration/raketasks/ldap.md +++ b/doc/administration/raketasks/ldap.md @@ -9,20 +9,20 @@ using the command below. **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:ldap:check ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:ldap:check RAILS_ENV=production ``` By default, the task will return a sample of 100 LDAP users. Change this limit by passing a number to the check task: -```bash +```shell rake gitlab:ldap:check[50] ``` @@ -41,13 +41,13 @@ instead. **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:ldap:group_sync ``` **Source Installation** -```bash +```shell bundle exec rake gitlab:ldap:group_sync ``` @@ -79,13 +79,13 @@ as the `old_provider` and the correct provider as the `new_provider`. **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:ldap:rename_provider[old_provider,new_provider] ``` **Source Installation** -```bash +```shell bundle exec rake gitlab:ldap:rename_provider[old_provider,new_provider] RAILS_ENV=production ``` @@ -95,7 +95,7 @@ Consider beginning with the default server ID `main` (full provider `ldapmain`). If we change `main` to `mycompany`, the `new_provider` is `ldapmycompany`. To rename all user identities run the following command: -```bash +```shell sudo gitlab-rake gitlab:ldap:rename_provider[ldapmain,ldapmycompany] ``` @@ -116,13 +116,13 @@ for them: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:ldap:rename_provider ``` **Source Installation** -```bash +```shell bundle exec rake gitlab:ldap:rename_provider RAILS_ENV=production ``` @@ -136,6 +136,6 @@ What is the new provider? Ex. 'ldapcustom': ldapmycompany This tasks also accepts the `force` environment variable which will skip the confirmation dialog: -```bash +```shell sudo gitlab-rake gitlab:ldap:rename_provider[old_provider,new_provider] force=yes ``` diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md index efc7a84a80e..6dc5542466f 100644 --- a/doc/administration/raketasks/maintenance.md +++ b/doc/administration/raketasks/maintenance.md @@ -6,13 +6,13 @@ This command gathers information about your GitLab installation and the System i **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:env:info ``` **Source Installation** -```bash +```shell bundle exec rake gitlab:env:info RAILS_ENV=production ``` @@ -66,13 +66,13 @@ You may also have a look at our Troubleshooting Guides: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:check ``` **Source Installation** -```bash +```shell bundle exec rake gitlab:check RAILS_ENV=production ``` @@ -129,13 +129,13 @@ In some case it is necessary to rebuild the `authorized_keys` file. **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:shell:setup ``` **Source Installation** -```bash +```shell cd /home/git/gitlab sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production ``` @@ -153,13 +153,13 @@ clear Redis' cache. **Omnibus Installation** -```bash +```shell sudo gitlab-rake cache:clear ``` **Source Installation** -```bash +```shell cd /home/git/gitlab sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production ``` @@ -174,7 +174,7 @@ Omnibus packages. **Source Installation** -```bash +```shell cd /home/git/gitlab sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production ``` @@ -194,13 +194,13 @@ in the GitLab Performance Monitoring database. **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:track_deployment ``` **Source Installation** -```bash +```shell cd /home/git/gitlab sudo -u git -H bundle exec rake gitlab:track_deployment RAILS_ENV=production ``` @@ -213,13 +213,13 @@ is included to help you with this: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:tcp_check[example.com,80] ``` **Source Installation** -```bash +```shell cd /home/git/gitlab sudo -u git -H bundle exec rake gitlab:tcp_check[example.com,80] RAILS_ENV=production ``` @@ -238,13 +238,13 @@ To clear all exclusive leases: DANGER: **DANGER**: Don't run it while GitLab or Sidekiq is running -```bash +```shell sudo gitlab-rake gitlab:exclusive_lease:clear ``` To specify a lease `type` or lease `type + id`, specify a scope: -```bash +```shell # to clear all leases for repository garbage collection: sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:*] @@ -256,14 +256,14 @@ sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4] To check the status of migrations, you can use the following rake task: -```bash +```shell sudo gitlab-rake db:migrate:status ``` This will output a table with a `Status` of `up` or `down` for each Migration ID. -```bash +```shell database: gitlabhq_production Status Migration ID Migration Name @@ -279,6 +279,6 @@ This could be as a result of [updating existing metrics](../../development/prome To re-import the metrics you can run: -```bash +```shell sudo gitlab-rake metrics:setup_common_metrics ``` diff --git a/doc/administration/raketasks/project_import_export.md b/doc/administration/raketasks/project_import_export.md index 2857f5a27aa..f782a24e654 100644 --- a/doc/administration/raketasks/project_import_export.md +++ b/doc/administration/raketasks/project_import_export.md @@ -13,7 +13,7 @@ The GitLab Import/Export version can be checked by using: -```bash +```shell # Omnibus installations sudo gitlab-rake gitlab:import_export:version @@ -23,7 +23,7 @@ bundle exec rake gitlab:import_export:version RAILS_ENV=production The current list of DB tables that will get exported can be listed by using: -```bash +```shell # Omnibus installations sudo gitlab-rake gitlab:import_export:data diff --git a/doc/administration/raketasks/storage.md b/doc/administration/raketasks/storage.md index 1198f3414c5..a14c8ed7969 100644 --- a/doc/administration/raketasks/storage.md +++ b/doc/administration/raketasks/storage.md @@ -16,19 +16,19 @@ This task will schedule all your existing projects and attachments associated wi **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:storage:migrate_to_hashed ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:storage:migrate_to_hashed RAILS_ENV=production ``` They both also accept a range as environment variable: -```bash +```shell # to migrate any non migrated project from ID 20 to 50. export ID_FROM=20 export ID_TO=50 @@ -63,19 +63,19 @@ Legacy storage type. For Omnibus installations, run the following: -```bash +```shell sudo gitlab-rake gitlab:storage:rollback_to_legacy ``` For source installations, run the following: -```bash +```shell sudo -u git -H bundle exec rake gitlab:storage:rollback_to_legacy RAILS_ENV=production ``` Both commands accept a range as environment variable: -```bash +```shell # to rollback any migrated project from ID 20 to 50. export ID_FROM=20 export ID_TO=50 @@ -95,13 +95,13 @@ To have a simple summary of projects using **Legacy** storage: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:storage:legacy_projects ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:storage:legacy_projects RAILS_ENV=production ``` @@ -109,13 +109,13 @@ To list projects using **Legacy** storage: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:storage:list_legacy_projects ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:storage:list_legacy_projects RAILS_ENV=production ``` @@ -126,13 +126,13 @@ To have a simple summary of projects using **Hashed** storage: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:storage:hashed_projects ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:storage:hashed_projects RAILS_ENV=production ``` @@ -140,13 +140,13 @@ To list projects using **Hashed** storage: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:storage:list_hashed_projects ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:storage:list_hashed_projects RAILS_ENV=production ``` @@ -156,13 +156,13 @@ To have a simple summary of project attachments using **Legacy** storage: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:storage:legacy_attachments ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:storage:legacy_attachments RAILS_ENV=production ``` @@ -170,13 +170,13 @@ To list project attachments using **Legacy** storage: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:storage:list_legacy_attachments ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:storage:list_legacy_attachments RAILS_ENV=production ``` @@ -186,13 +186,13 @@ To have a simple summary of project attachments using **Hashed** storage: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:storage:hashed_attachments ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:storage:hashed_attachments RAILS_ENV=production ``` @@ -200,13 +200,13 @@ To list project attachments using **Hashed** storage: **Omnibus Installation** -```bash +```shell sudo gitlab-rake gitlab:storage:list_hashed_attachments ``` **Source Installation** -```bash +```shell sudo -u git -H bundle exec rake gitlab:storage:list_hashed_attachments RAILS_ENV=production ``` diff --git a/doc/administration/raketasks/uploads/migrate.md b/doc/administration/raketasks/uploads/migrate.md index aef15e3f388..adef6251a27 100644 --- a/doc/administration/raketasks/uploads/migrate.md +++ b/doc/administration/raketasks/uploads/migrate.md @@ -17,13 +17,13 @@ described in the next section. **Omnibus Installation** -```bash +```shell gitlab-rake "gitlab:uploads:migrate:all" ``` **Source Installation** -```bash +```shell sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate:all ``` @@ -52,7 +52,7 @@ Variable | Type | Description **Omnibus Installation** -```bash +```shell # gitlab-rake gitlab:uploads:migrate[uploader_class, model_class, mount_point] # Avatars @@ -80,7 +80,7 @@ gitlab-rake "gitlab:uploads:migrate[FileUploader, MergeRequest]" >**Note:** Use `RAILS_ENV=production` for every task. -```bash +```shell # sudo -u git -H bundle exec rake gitlab:uploads:migrate # Avatars @@ -112,13 +112,13 @@ To migrate all uploads created by legacy uploaders, run: **Omnibus Installation** -```bash +```shell gitlab-rake gitlab:uploads:legacy:migrate ``` **Source Installation** -```bash +```shell bundle exec rake gitlab:uploads:legacy:migrate ``` @@ -145,13 +145,13 @@ keeping in mind the task name in this case is `gitlab:uploads:migrate_to_local`. **Omnibus Installation** -```bash +```shell gitlab-rake "gitlab:uploads:migrate_to_local:all" ``` **Source Installation** -```bash +```shell sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate_to_local:all ``` diff --git a/doc/administration/raketasks/uploads/sanitize.md b/doc/administration/raketasks/uploads/sanitize.md index 98cc1ddcff9..3e9b44a24fb 100644 --- a/doc/administration/raketasks/uploads/sanitize.md +++ b/doc/administration/raketasks/uploads/sanitize.md @@ -7,7 +7,7 @@ You need `exiftool` installed on your system. If you installed GitLab: - Using the Omnibus package, you're all set. - From source, make sure `exiftool` is installed: - ```sh + ```shell # Debian/Ubuntu sudo apt-get install libimage-exiftool-perl @@ -22,7 +22,7 @@ Because EXIF data may contain sensitive information (e.g. GPS location), you can remove EXIF data also from existing images which were uploaded before with the following command: -```bash +```shell sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:remove_exif ``` @@ -46,13 +46,13 @@ each with a separate range of upload IDs (by setting `start_id` and `stop_id`). To run the command without dry mode and remove EXIF data from all uploads, you can use: -```bash +```shell sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:remove_exif[,,false,] 2>&1 | tee exif.log ``` To run the command without dry mode on uploads with ID between 100 and 5000 and pause for 0.1 second, you can use: -```bash +```shell sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:remove_exif[100,5000,false,0.1] 2>&1 | tee exif.log ``` diff --git a/doc/administration/reply_by_email_postfix_setup.md b/doc/administration/reply_by_email_postfix_setup.md index 56cd23b2eb8..3a28e37cfc0 100644 --- a/doc/administration/reply_by_email_postfix_setup.md +++ b/doc/administration/reply_by_email_postfix_setup.md @@ -14,7 +14,7 @@ The instructions make the assumption that you will be using the email address `i 1. Install the `postfix` package if it is not installed already: - ```sh + ```shell sudo apt-get install postfix ``` @@ -22,7 +22,7 @@ The instructions make the assumption that you will be using the email address `i 1. Install the `mailutils` package. - ```sh + ```shell sudo apt-get install mailutils ``` @@ -30,13 +30,13 @@ The instructions make the assumption that you will be using the email address `i 1. Create a user for incoming email. - ```sh + ```shell sudo useradd -m -s /bin/bash incoming ``` 1. Set a password for this user. - ```sh + ```shell sudo passwd incoming ``` @@ -46,13 +46,13 @@ The instructions make the assumption that you will be using the email address `i 1. Connect to the local SMTP server: - ```sh + ```shell telnet localhost 25 ``` You should see a prompt like this: - ```sh + ```shell Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. @@ -61,13 +61,13 @@ The instructions make the assumption that you will be using the email address `i If you get a `Connection refused` error instead, verify that `postfix` is running: - ```sh + ```shell sudo postfix status ``` If it is not, start it: - ```sh + ```shell sudo postfix start ``` @@ -94,7 +94,7 @@ The instructions make the assumption that you will be using the email address `i 1. Check if the `incoming` user received the email: - ```sh + ```shell su - incoming mail ``` @@ -108,13 +108,13 @@ The instructions make the assumption that you will be using the email address `i Quit the mail app: - ```sh + ```shell q ``` 1. Log out of the `incoming` account and go back to being `root`: - ```sh + ```shell logout ``` @@ -124,13 +124,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo 1. Configure Postfix to use Maildir-style mailboxes: - ```sh + ```shell sudo postconf -e "home_mailbox = Maildir/" ``` 1. Restart Postfix: - ```sh + ```shell sudo /etc/init.d/postfix restart ``` @@ -139,7 +139,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo 1. Follow steps 1 and 2 of _[Test the out-of-the-box setup](#test-the-out-of-the-box-setup)_. 1. Check if the `incoming` user received the email: - ```sh + ```shell su - incoming MAIL=/home/incoming/Maildir mail @@ -154,7 +154,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo Quit the mail app: - ```sh + ```shell q ``` @@ -166,7 +166,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo 1. Log out of the `incoming` account and go back to being `root`: - ```sh + ```shell logout ``` @@ -174,25 +174,25 @@ Courier, which we will install later to add IMAP authentication, requires mailbo 1. Install the `courier-imap` package: - ```sh + ```shell sudo apt-get install courier-imap ``` And start `imapd`: - ```sh + ```shell imapd start ``` 1. The courier-authdaemon isn't started after installation. Without it, imap authentication will fail: - ```sh + ```shell sudo service courier-authdaemon start ``` You can also configure courier-authdaemon to start on boot: - ```sh + ```shell sudo systemctl enable courier-authdaemon ``` @@ -200,7 +200,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo 1. Let Postfix know about the domains that it should consider local: - ```sh + ```shell sudo postconf -e "mydestination = gitlab.example.com, localhost.localdomain, localhost" ``` @@ -208,25 +208,25 @@ Courier, which we will install later to add IMAP authentication, requires mailbo We'll assume `192.168.1.0/24` is your local LAN. You can safely skip this step if you don't have other machines in the same local network. - ```sh + ```shell sudo postconf -e "mynetworks = 127.0.0.0/8, 192.168.1.0/24" ``` 1. Configure Postfix to receive mail on all interfaces, which includes the internet: - ```sh + ```shell sudo postconf -e "inet_interfaces = all" ``` 1. Configure Postfix to use the `+` delimiter for sub-addressing: - ```sh + ```shell sudo postconf -e "recipient_delimiter = +" ``` 1. Restart Postfix: - ```sh + ```shell sudo service postfix restart ``` @@ -236,13 +236,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo 1. Connect to the SMTP server: - ```sh + ```shell telnet gitlab.example.com 25 ``` You should see a prompt like this: - ```sh + ```shell Trying 123.123.123.123... Connected to gitlab.example.com. Escape character is '^]'. @@ -269,7 +269,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo 1. Check if the `incoming` user received the email: - ```sh + ```shell su - incoming MAIL=/home/incoming/Maildir mail @@ -284,13 +284,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo Quit the mail app: - ```sh + ```shell q ``` 1. Log out of the `incoming` account and go back to being `root`: - ```sh + ```shell logout ``` @@ -298,13 +298,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo 1. Connect to the IMAP server: - ```sh + ```shell telnet gitlab.example.com 143 ``` You should see a prompt like this: - ```sh + ```shell Trying 123.123.123.123... Connected to mail.example.gitlab.com. Escape character is '^]'. @@ -327,7 +327,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo 1. Disconnect from the IMAP server: - ```sh + ```shell a logout ``` diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md index 9c7b5bc6b87..3e887e11ca6 100644 --- a/doc/administration/repository_storage_types.md +++ b/doc/administration/repository_storage_types.md @@ -118,7 +118,7 @@ to validate. You can do so by specifying a range with the operation. This is an example of how to limit the rollout to Project IDs 50 to 100, running in an Omnibus GitLab installation: -```bash +```shell sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100 ``` @@ -139,7 +139,7 @@ To schedule a complete rollback, see the The rollback task also supports specifying a range of Project IDs. Here is an example of limiting the rollout to Project IDs 50 to 100, in an Omnibus GitLab installation: -```bash +```shell sudo gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=50 ID_TO=100 ``` diff --git a/doc/administration/restart_gitlab.md b/doc/administration/restart_gitlab.md index 6f3c6028f71..bd3a52d487a 100644 --- a/doc/administration/restart_gitlab.md +++ b/doc/administration/restart_gitlab.md @@ -31,7 +31,7 @@ GitLab Rails application (Unicorn) as well as the other components, like: There may be times in the documentation where you will be asked to _restart_ GitLab. In that case, you need to run the following command: -```bash +```shell sudo gitlab-ctl restart ``` @@ -51,13 +51,13 @@ ok: run: unicorn: (pid 11338) 0s To restart a component separately, you can append its service name to the `restart` command. For example, to restart **only** NGINX you would run: -```bash +```shell sudo gitlab-ctl restart nginx ``` To check the status of GitLab services, run: -```bash +```shell sudo gitlab-ctl status ``` @@ -79,7 +79,7 @@ GitLab. Remember that this method applies only for the Omnibus packages. Reconfigure Omnibus GitLab with: -```bash +```shell sudo gitlab-ctl reconfigure ``` @@ -152,7 +152,7 @@ the [cloud native Helm Chart](https://docs.gitlab.com/charts/). Usually, it shou enough to restart a specific component separately (`gitaly`, `unicorn`, `workhorse`, `gitlab-shell`, etc.) by deleting all the pods related to it: -```bash +```shell kubectl delete pods -l release=<helm release name>,app=<component name> ``` diff --git a/doc/administration/server_hooks.md b/doc/administration/server_hooks.md index 7fded3dd41e..dbaf6047552 100644 --- a/doc/administration/server_hooks.md +++ b/doc/administration/server_hooks.md @@ -111,7 +111,7 @@ declined or an error occurs during the Git hook, your script should: This hook script written in bash will generate the following message in GitLab's UI: -```bash +```shell #!/bin/sh echo "GL-HOOK-ERR: My custom error message."; exit 1 diff --git a/doc/administration/smime_signing_email.md b/doc/administration/smime_signing_email.md index 60cab22d1f4..ed7447c0da9 100644 --- a/doc/administration/smime_signing_email.md +++ b/doc/administration/smime_signing_email.md @@ -67,7 +67,7 @@ extensions), which contain the following in a single encrypted file: In order to export the required files in PEM encoding from the PKCS#12 file, the `openssl` command can be used: -```bash +```shell #-- Extract private key in PEM encoding (no password, unencrypted) $ openssl pkcs12 -in gitlab.p12 -nocerts -nodes -out gitlab.key diff --git a/doc/administration/snippets/index.md b/doc/administration/snippets/index.md index 2e17db7b1f6..7632d685dc0 100644 --- a/doc/administration/snippets/index.md +++ b/doc/administration/snippets/index.md @@ -35,7 +35,7 @@ The steps to configure this setting through the Rails console are: 1. Start the Rails console: - ```bash + ```shell # For Omnibus installations sudo gitlab-rails console @@ -60,12 +60,12 @@ To retrieve the current value, start the Rails console and run: The process to set the snippets size limit through the Application Settings API is exactly the same as you would do to [update any other setting](../../api/settings.md#change-application-settings). -```bash +```shell curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings?snippet_size_limit=52428800 ``` You can also use the API to [retrieve the current value](../../api/settings.md#get-current-application-settings). -```bash +```shell curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/application/settings ``` diff --git a/doc/administration/timezone.md b/doc/administration/timezone.md index 3594ba19181..bc6eaf57a23 100644 --- a/doc/administration/timezone.md +++ b/doc/administration/timezone.md @@ -31,7 +31,7 @@ gitlab_rails['time_zone'] = 'America/New_York' After adding the configuration parameter, reconfigure and restart your GitLab instance: -```sh +```shell gitlab-ctl reconfigure gitlab-ctl restart ``` diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md index b754b954391..01d143d045e 100644 --- a/doc/administration/troubleshooting/debug.md +++ b/doc/administration/troubleshooting/debug.md @@ -10,13 +10,13 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se 1. Run a Rails console: - ```sh + ```shell sudo gitlab-rails console production ``` or for source installs: - ```sh + ```shell bundle exec rails console production ``` diff --git a/doc/administration/troubleshooting/elasticsearch.md b/doc/administration/troubleshooting/elasticsearch.md index a582e07b141..0fdd5314a9d 100644 --- a/doc/administration/troubleshooting/elasticsearch.md +++ b/doc/administration/troubleshooting/elasticsearch.md @@ -332,7 +332,7 @@ bind ports 9200/9300 so it can be used. The following is an example of running a docker container of Elasticsearch v7.2.0: -```bash +```shell docker pull docker.elastic.co/elasticsearch/elasticsearch:7.2.0 docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:7.2.0 ``` diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md index c4b7324ce05..7bffe00a969 100644 --- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md +++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md @@ -30,7 +30,7 @@ should and, if needed, update the script for the latest version of GitLab. If the script you want to run is short, you can use the Rails Runner to avoid entering the rails console in the first place. Here's an example of its use: -```bash +```shell gitlab-rails runner "RAILS_COMMAND" # Example with a 2-line script @@ -130,19 +130,19 @@ end ### Check the GitLab version fast -```bash +```shell grep -m 1 gitlab /opt/gitlab/version-manifest.txt ``` ### Debugging SSH -```bash +```shell GIT_SSH_COMMAND="ssh -vvv" git clone <repository> ``` ### Debugging over HTTPS -```bash +```shell GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone <repository> ``` @@ -301,19 +301,19 @@ correctly named empty project using the steps below. Move the new repository to the empty repository: -```bash +```shell mv /var/opt/gitlab/git-data/repositories/<group>/<new-project> /var/opt/gitlab/git-data/repositories/<group>/<empty-project> ``` Make sure the permissions are correct: -```bash +```shell chown -R git:git <path-to-directory>.git ``` Clear the cache: -```bash +```shell sudo gitlab-rake cache:clear ``` @@ -489,7 +489,7 @@ User.active.count ::HistoricalData.max_historical_user_count ``` -```bash +```shell # Using curl and jq (up to a max 100, see pagination docs https://docs.gitlab.com/ee/api/#pagination curl --silent --header "Private-Token: ********************" "https://gitlab.example.com/api/v4/users?per_page=100&active" | jq --compact-output '.[] | [.id,.name,.username]' ``` @@ -995,13 +995,13 @@ See <https://github.com/mperham/sidekiq/wiki/Signals#ttin>. ### Connect to Redis (omnibus) -```sh +```shell /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket ``` ### Connect to Redis (HA) -```sh +```shell /opt/gitlab/embedded/bin/redis-cli -h <host ip> -a <password> ``` @@ -1034,7 +1034,7 @@ This script will go through all the encrypted variables and count how many are n to be decrypted. Might be helpful to run on multiple nodes to see which `gitlab-secrets.json` file is most up to date: -```bash +```shell wget -O /tmp/bad-decrypt.rb https://gitlab.com/snippets/1730735/raw gitlab-rails runner /tmp/bad-decrypt.rb ``` @@ -1075,7 +1075,7 @@ two-factor authentication. This script will search for all encrypted tokens that are causing decryption errors, and update or reset as needed: -```bash +```shell wget -O /tmp/encrypted-tokens.rb https://gitlab.com/snippets/1876342/raw gitlab-rails runner /tmp/encrypted-tokens.rb ``` diff --git a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md index 7c2c2050b12..dfd5e82a159 100644 --- a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md +++ b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md @@ -20,13 +20,13 @@ and they will assist you with any issues you are having. - How to authorize to your GCP project (can be especially useful if you have projects under different GCP accounts): - ```bash + ```shell gcloud auth login ``` - How to access Kubernetes dashboard: - ```bash + ```shell # for minikube: minikube dashboard —url # for non-local installations if access via Kubectl is configured: @@ -42,7 +42,7 @@ and they will assist you with any issues you are having. - How to copy a file from local machine to a pod: - ```bash + ```shell kubectl cp file-name pod-name:./destination-path ``` @@ -51,19 +51,19 @@ and they will assist you with any issues you are having. - Check logs via Kubernetes dashboard. - Check logs via Kubectl: - ```bash + ```shell kubectl logs <unicorn pod> -c dependencies ``` - How to tail all Kubernetes cluster events in real time: - ```bash + ```shell kubectl get events -w --all-namespaces ``` - How to get logs of the previously terminated pod instance: - ```bash + ```shell kubectl logs <pod-name> --previous ``` @@ -79,13 +79,13 @@ and they will assist you with any issues you are having. - Tailing logs of a separate pod. An example for a Unicorn pod: - ```bash + ```shell kubectl logs gitlab-unicorn-7656fdd6bf-jqzfs -c unicorn ``` - Tail and follow all pods that share a label (in this case, `unicorn`): - ```bash + ```shell # all containers in the unicorn pods kubectl logs -f -l app=unicorn --all-containers=true --max-log-requests=50 @@ -96,21 +96,21 @@ and they will assist you with any issues you are having. - One can stream logs from all containers at once, similar to the Omnibus command `gitlab-ctl tail`: - ```bash + ```shell kubectl logs -f -l release=gitlab --all-containers=true --max-log-requests=100 ``` - Check all events in the `gitlab` namespace (the namespace name can be different if you specified a different one when deploying the Helm chart): - ```bash + ```shell kubectl get events -w --namespace=gitlab ``` - Most of the useful GitLab tools (console, rake tasks, etc) are found in the task-runner pod. You may enter it and run commands inside or run them from the outside: - ```bash + ```shell # find the pod kubectl get pods | grep task-runner @@ -145,7 +145,7 @@ and they will assist you with any issues you are having. - How to get your initial admin password <https://docs.gitlab.com/charts/installation/deployment.html#initial-login>: - ```bash + ```shell # find the name of the secret containing the password kubectl get secrets | grep initial-root # decode it @@ -154,19 +154,19 @@ and they will assist you with any issues you are having. - How to connect to a GitLab Postgres database: - ```bash + ```shell kubectl exec -it <task-runner-pod-name> -- /srv/gitlab/bin/rails dbconsole -p ``` - How to get info about Helm installation status: - ```bash + ```shell helm status name-of-installation ``` - How to update GitLab installed using Helm Chart: - ```bash + ```shell helm repo upgrade # get current values and redirect them to yaml file (analogue of gitlab.rb values) @@ -185,7 +185,7 @@ and they will assist you with any issues you are having. - Modify the `gitlab.yaml` file. - Run the following command to apply changes: - ```bash + ```shell helm upgrade <release name> <chart path> -f gitlab.yaml ``` @@ -197,20 +197,20 @@ to those documents for details. - Install Kubectl via Homebrew: - ```bash + ```shell brew install kubernetes-cli ``` - Install Minikube via Homebrew: - ```bash + ```shell brew cask install minikube ``` - Start Minikube and configure it. If Minikube cannot start, try running `minikube delete && minikube start` and repeat the steps: - ```bash + ```shell minikube start --cpus 3 --memory 8192 # minimum amount for GitLab to work minikube addons enable ingress minikube addons enable kube-dns @@ -218,7 +218,7 @@ to those documents for details. - Install Helm via Homebrew and initialize it: - ```bash + ```shell brew install kubernetes-helm helm init --service-account tiller ``` @@ -231,7 +231,7 @@ to those documents for details. - Install the GitLab Helm Chart: - ```bash + ```shell helm repo add gitlab https://charts.gitlab.io helm install --name gitlab -f <path-to-yaml-file> gitlab/gitlab ``` diff --git a/doc/administration/troubleshooting/linux_cheat_sheet.md b/doc/administration/troubleshooting/linux_cheat_sheet.md index 853f553571c..0ad1f028f20 100644 --- a/doc/administration/troubleshooting/linux_cheat_sheet.md +++ b/doc/administration/troubleshooting/linux_cheat_sheet.md @@ -23,7 +23,7 @@ on. Contributions are welcome to help add them. ### Distro Information -```bash +```shell # Debian/Ubuntu uname -a lsb_release -a @@ -38,14 +38,14 @@ cat /etc/os-release ### Shut down or Reboot -```bash +```shell shutdown -h now reboot ``` ### Permissions -```bash +```shell # change the user:group ownership of a file/dir chown root:git <file_or_dir> @@ -55,7 +55,7 @@ chmod u+x <file> ### Files & Dirs -```bash +```shell # create a new directory and all subdirectories mkdir -p dir/dir2/dir3 @@ -71,7 +71,7 @@ sed -i 's/original-text/new-text/g' <filename> ### See all set environment variables -```bash +```shell env ``` @@ -79,7 +79,7 @@ env ### File names -```bash +```shell # search for a file in a filesystem find . -name 'filename.rb' -print @@ -95,7 +95,7 @@ history ### File contents -```bash +```shell # -B/A = show 2 lines before/after search_term grep -B 2 -A 2 search_term <filename> @@ -114,7 +114,7 @@ fgrep -R string_pattern <filename or directory> ### CLI -```bash +```shell # View command history history @@ -132,7 +132,7 @@ sudo !! ### Memory, Disk, & CPU usage -```bash +```shell # disk space info. The '-h' gives the data in human-readable values df -h @@ -157,7 +157,7 @@ top -o %CPU ### Strace -```bash +```shell # strace a process strace -tt -T -f -y -s 1024 -p <pid> @@ -200,7 +200,7 @@ can also sort based on total time, # of syscalls made, PID #, and # of child pro using the `-S` or `--sort` flag. The number of results defaults to 25 processes, but can be changed using the `-c`/`--count` option. See `--help` for full details. -```sh +```shell $ ./strace-parser strace.txt Top 25 PIDs @@ -218,7 +218,7 @@ Based on the summary, you can then view the details of syscalls made by one or m procsses using the `-p`/`--pid` for a specific process, or `-s`/`--stats` flags for a sorted list. `--stats` takes the same sorting and count options as summary. -```sh +```shell $ ./strace-parse strace.text -p 6423 PID 6423 @@ -274,7 +274,7 @@ small differences should not be considered significant. ### Ports -```bash +```shell # Find the programs that are listening on ports netstat -plnt ss -plnt @@ -283,7 +283,7 @@ lsof -i -P | grep <port> ### Internet/DNS -```bash +```shell # Show domain IP address dig +short example.com nslookup example.com @@ -302,7 +302,7 @@ curl --head --location https://example.com ## Package Management -```bash +```shell # Debian/Ubuntu # List packages @@ -332,7 +332,7 @@ rpm -qa | grep <package> ## Logs -```bash +```shell # Print last lines in log file where 'n' # is the number of lines to print tail -n /path/to/log/file diff --git a/doc/administration/troubleshooting/ssl.md b/doc/administration/troubleshooting/ssl.md index dcda4fbb7a9..98d144e012f 100644 --- a/doc/administration/troubleshooting/ssl.md +++ b/doc/administration/troubleshooting/ssl.md @@ -83,13 +83,13 @@ To fix this problem: If your GitLab instance is using a self-signed certificate, or the certificate is signed by an internal certificate authority (CA), you might run into the following errors when attempting to perform Git operations: -```bash +```shell $ git clone https://gitlab.domain.tld/group/project.git Cloning into 'project'... fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': SSL certificate problem: self signed certificate ``` -```bash +```shell $ git clone https://gitlab.domain.tld/group/project.git Cloning into 'project'... fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none @@ -107,6 +107,6 @@ To fix this problem: - Disable SSL verification in your Git client. Note that this intended as a temporary measure as it could be considered a **security risk**. - ```bash + ```shell git config --global http.sslVerify false ``` diff --git a/doc/administration/troubleshooting/test_environments.md b/doc/administration/troubleshooting/test_environments.md index d0f670a5663..e9db5f64446 100644 --- a/doc/administration/troubleshooting/test_environments.md +++ b/doc/administration/troubleshooting/test_environments.md @@ -37,7 +37,7 @@ you change a few things: For example, when the `docker-machine` host we want to use is `do-docker`: -```sh +```shell docker run --detach --name gitlab \ --env GITLAB_OMNIBUS_CONFIG="external_url 'http://$(docker-machine ip do-docker)'; gitlab_rails['gitlab_shell_ssh_port'] = 2222;" \ --hostname $(docker-machine ip do-docker) \ @@ -52,7 +52,7 @@ gitlab/gitlab-ee:11.5.3-ee.0 We can use the [`test-saml-idp` Docker image](https://hub.docker.com/r/jamedjo/test-saml-idp) to do the work for us: -```sh +```shell docker run --name gitlab_saml -p 8080:8080 -p 8443:8443 \ -e SIMPLESAMLPHP_SP_ENTITY_ID=<GITLAB_IP_OR_DOMAIN> \ -e SIMPLESAMLPHP_SP_ASSERTION_CONSUMER_SERVICE=<GITLAB_IP_OR_DOMAIN>/users/auth/saml/callback \ @@ -93,7 +93,7 @@ See [the GDK SAML documentation](https://gitlab.com/gitlab-org/gitlab-developmen ### Elasticsearch -```sh +```shell docker run -d --name elasticsearch \ -p 9200:9200 -p 9300:9300 \ -e "discovery.type=single-node" \ @@ -110,7 +110,7 @@ on running PlantUML in Docker. ### Jira -```sh +```shell docker run -d -p 8081:8080 cptactionhank/atlassian-jira:latest ``` @@ -119,7 +119,7 @@ Jira license. ### Grafana -```sh +```shell docker run -d --name grafana -e "GF_SECURITY_ADMIN_PASSWORD=gitlab" -p 3000:3000 grafana/grafana ``` |