diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-02-03 06:08:30 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-02-03 06:08:30 +0300 |
commit | f4d27d532e3abeecd1caffeb3a56e698ae982e5b (patch) | |
tree | 27a1b43761cd6eedbdbf57b46b8fd9c5cc519a61 /doc/administration/operations | |
parent | a2a712139fc7fa58aa02b143f2767286d28ef28d (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/administration/operations')
4 files changed, 13 insertions, 12 deletions
diff --git a/doc/administration/operations/filesystem_benchmarking.md b/doc/administration/operations/filesystem_benchmarking.md index 0a20e94a778..019909e2e89 100644 --- a/doc/administration/operations/filesystem_benchmarking.md +++ b/doc/administration/operations/filesystem_benchmarking.md @@ -37,7 +37,7 @@ completes. The output will vary depending on what version of `fio` installed. The following is an example output from `fio` v2.2.10 on a networked solid-state drive (SSD): -``` +```plaintext test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64 fio-2.2.10 Starting 1 process diff --git a/doc/administration/operations/moving_repositories.md b/doc/administration/operations/moving_repositories.md index d54ffacd281..a11bce9aa02 100644 --- a/doc/administration/operations/moving_repositories.md +++ b/doc/administration/operations/moving_repositories.md @@ -21,7 +21,7 @@ overhead and tar is almost always already installed on your system. However, it is not possible to resume an interrupted tar pipe: if that happens then all data must be copied again. -``` +```shell sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\ tar -C /mnt/gitlab/repositories -xf -' ``` @@ -34,7 +34,7 @@ You can also use a tar pipe to copy data to another server. If your `git` user has SSH access to the newserver as `git@newserver`, you can pipe the data through SSH. -``` +```shell sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\ ssh git@newserver tar -C /mnt/gitlab/repositories -xf -' ``` @@ -50,7 +50,7 @@ with tar. In this scenario it is better to use rsync. This utility is either already installed on your system or easily installable via apt, yum etc. -``` +```shell sudo -u git sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \ /mnt/gitlab/repositories' ``` @@ -64,7 +64,7 @@ If you want to see progress, replace `-a` with `-av`. If the `git` user on your source system has SSH access to the target server you can send the repositories over the network with rsync. -``` +```shell sudo -u git sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \ git@newserver:/mnt/gitlab/repositories' ``` @@ -99,7 +99,7 @@ First we create a new directory, owned by `git`, to hold transfer logs. We assume the directory is empty before we start the transfer procedure, and that we are the only ones writing files in it. -``` +```shell # Omnibus sudo mkdir /var/opt/gitlab/transfer-logs sudo chown git:git /var/opt/gitlab/transfer-logs @@ -110,7 +110,7 @@ sudo -u git -H mkdir /home/git/transfer-logs We seed the process with a list of the directories we want to copy. -``` +```shell # Omnibus sudo -u git sh -c 'gitlab-rake gitlab:list_repos > /var/opt/gitlab/transfer-logs/all-repos-$(date +%s).txt' @@ -124,7 +124,7 @@ the number of jobs done by GNU Parallel should converge to zero. If it does not, some repositories listed in `all-repos-1234.txt` may have been deleted/renamed before they could be copied. -``` +```shell # Omnibus sudo -u git sh -c ' cat /var/opt/gitlab/transfer-logs/* | sort | uniq -u |\ @@ -154,7 +154,7 @@ Then you might only want to sync repositories that were changed via GitLab _after_ that time. You can use the `SINCE` variable to tell `rake gitlab:list_repos` to only print repositories with recent activity. -``` +```shell # Omnibus sudo gitlab-rake gitlab:list_repos SINCE='2015-10-1 12:00 UTC' |\ sudo -u git \ diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md index 2a9a4cff34e..b18c15e6b91 100644 --- a/doc/administration/operations/ssh_certificates.md +++ b/doc/administration/operations/ssh_certificates.md @@ -54,8 +54,9 @@ The SSH certificates being issued by that CA **MUST** have a "key id" corresponding to that user's username on GitLab, e.g. (some output omitted for brevity): -``` +```shell $ ssh-add -L | grep cert | ssh-keygen -L -f - + (stdin):1: Type: ssh-rsa-cert-v01@openssh.com user certificate Public key: RSA-CERT SHA256:[...] diff --git a/doc/administration/operations/unicorn.md b/doc/administration/operations/unicorn.md index 969f1211643..a19617daaef 100644 --- a/doc/administration/operations/unicorn.md +++ b/doc/administration/operations/unicorn.md @@ -29,7 +29,7 @@ requests. This is what a Unicorn worker timeout looks like in `unicorn_stderr.log`. The master process has PID 56227 below. -``` +```plaintext [2015-06-05T10:58:08.660325 #56227] ERROR -- : worker=10 PID:53009 timeout (61s > 60s), killing [2015-06-05T10:58:08.699360 #56227] ERROR -- : reaped #<Process::Status: pid 53009 SIGKILL (signal 9)> worker=10 [2015-06-05T10:58:08.708141 #62538] INFO -- : worker=10 spawned pid=62538 @@ -79,7 +79,7 @@ threshold is a random value between 200 and 250 MB. The master process (PID 117565) then reaps the worker process and spawns a new 'worker 4' with PID 127549. -``` +```plaintext [2015-06-05T12:07:41.828374 #125918] WARN -- : #<Unicorn::HttpServer:0x00000002734770>: worker (pid: 125918) exceeds memory limit (256413696 bytes > 254802235 bytes) [2015-06-05T12:07:41.828472 #125918] WARN -- : Unicorn::WorkerKiller send SIGQUIT (pid: 125918) alive: 23 sec (trial 1) [2015-06-05T12:07:42.025916 #117565] INFO -- : reaped #<Process::Status: pid 125918 exit 0> worker=4 |