diff options
Diffstat (limited to 'doc/administration')
| -rw-r--r-- | doc/administration/auth/ldap.md | 12 | ||||
| -rw-r--r-- | doc/administration/geo/replication/configuration.md | 4 | ||||
| -rw-r--r-- | doc/administration/high_availability/README.md | 2 | ||||
| -rw-r--r-- | doc/administration/high_availability/database.md | 2 | ||||
| -rw-r--r-- | doc/administration/high_availability/redis_source.md | 2 | ||||
| -rw-r--r-- | doc/administration/issue_closing_pattern.md | 2 | ||||
| -rw-r--r-- | doc/administration/job_artifacts.md | 12 | ||||
| -rw-r--r-- | doc/administration/job_traces.md | 40 | ||||
| -rw-r--r-- | doc/administration/logs.md | 2 | ||||
| -rw-r--r-- | doc/administration/merge_request_diffs.md | 3 | ||||
| -rw-r--r-- | doc/administration/monitoring/github_imports.md | 10 | ||||
| -rw-r--r-- | doc/administration/operations/sidekiq_memory_killer.md | 58 | ||||
| -rw-r--r-- | doc/administration/packages/container_registry.md | 6 | ||||
| -rw-r--r-- | doc/administration/pages/index.md | 32 | ||||
| -rw-r--r-- | doc/administration/pages/source.md | 2 | ||||
| -rw-r--r-- | doc/administration/raketasks/uploads/migrate.md | 36 | ||||
| -rw-r--r-- | doc/administration/repository_storage_paths.md | 4 | ||||
| -rw-r--r-- | doc/administration/restart_gitlab.md | 2 |
18 files changed, 106 insertions, 125 deletions
diff --git a/doc/administration/auth/ldap.md b/doc/administration/auth/ldap.md index 728add05bd8..186bf4c4825 100644 --- a/doc/administration/auth/ldap.md +++ b/doc/administration/auth/ldap.md @@ -563,15 +563,3 @@ If you are getting 'Connection Refused' errors when trying to connect to the LDAP server please double-check the LDAP `port` and `encryption` settings used by GitLab. Common combinations are `encryption: 'plain'` and `port: 389`, OR `encryption: 'simple_tls'` and `port: 636`. - -### Connection times out - -If GitLab cannot reach your LDAP endpoint, you will see a message like this: - -``` -Could not authenticate you from Ldapmain because "Connection timed out - user specified timeout". -``` - -If your configured LDAP provider and/or endpoint is offline or otherwise unreachable by GitLab, no LDAP user will be able to authenticate and log in. GitLab does not cache or store credentials for LDAP users to provide authentication during an LDAP outage. - -Contact your LDAP provider or administrator if you are seeing this error. diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md index b8df365e56c..ddb5f22fd05 100644 --- a/doc/administration/geo/replication/configuration.md +++ b/doc/administration/geo/replication/configuration.md @@ -25,7 +25,7 @@ Any change that requires access to the **Admin Area** needs to be done in the GitLab stores a number of secret values in the `/etc/gitlab/gitlab-secrets.json` file which *must* be the same on all nodes. Until there is -a means of automatically replicating these between nodes (see issue [gitlab-org/gitlab#3789]), +a means of automatically replicating these between nodes (see issue [gitlab-org/gitlab-ee#3789]), they must be manually replicated to the **secondary** node. 1. SSH into the **primary** node, and execute the command below: @@ -299,7 +299,7 @@ See the [troubleshooting document](troubleshooting.md). [setup-geo-omnibus]: index.md#using-omnibus-gitlab [Hashed Storage]: ../../repository_storage_types.md [Disaster Recovery]: ../disaster_recovery/index.md -[gitlab-org/gitlab#3789]: https://gitlab.com/gitlab-org/gitlab/issues/3789 +[gitlab-org/gitlab-ee#3789]: https://gitlab.com/gitlab-org/gitlab/issues/3789 [gitlab-com/infrastructure#2821]: https://gitlab.com/gitlab-com/infrastructure/issues/2821 [omnibus-ssl]: https://docs.gitlab.com/omnibus/settings/ssl.html [using-geo]: using_a_geo_server.md diff --git a/doc/administration/high_availability/README.md b/doc/administration/high_availability/README.md index e2998e4438a..0aaf956f169 100644 --- a/doc/administration/high_availability/README.md +++ b/doc/administration/high_availability/README.md @@ -165,7 +165,7 @@ contention due to certain workloads. #### Reference Architecture - **Supported Users (approximate):** 10,000 -- **Known Issues:** While validating the reference architecture, slow endpoints were discovered and are being investigated. [gitlab-org/gitlab-foss/issues/64335](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335) +- **Known Issues:** While validating the reference architecture, slow endpoints were discovered and are being investigated. [gitlab-org/gitlab-ce/issues/64335](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335) The Support and Quality teams built, performance tested, and validated an environment that supports about 10,000 users. The specifications below are a diff --git a/doc/administration/high_availability/database.md b/doc/administration/high_availability/database.md index c9f6e768772..99582dae57a 100644 --- a/doc/administration/high_availability/database.md +++ b/doc/administration/high_availability/database.md @@ -1049,7 +1049,7 @@ If you're running into an issue with a component not outlined here, be sure to c ## Configure using Omnibus **Note**: We recommend that you follow the instructions here for a full [PostgreSQL cluster](#high-availability-with-gitlab-omnibus-premium-only). -If you are reading this section due to an old bookmark, you can find that old documentation [in the repository](https://gitlab.com/gitlab-org/gitlab/blob/v10.1.4/doc/administration/high_availability/database.md#configure-using-omnibus). +If you are reading this section due to an old bookmark, you can find that old documentation [in the repository](https://gitlab.com/gitlab-org/gitlab-foss/blob/v10.1.4/doc/administration/high_availability/database.md#configure-using-omnibus). Read more on high-availability configuration: diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md index 379c64dcf90..0758b240a25 100644 --- a/doc/administration/high_availability/redis_source.md +++ b/doc/administration/high_availability/redis_source.md @@ -374,4 +374,4 @@ When in doubt, please read [Redis Sentinel documentation](https://redis.io/topic [downloads]: https://about.gitlab.com/downloads [restart]: ../restart_gitlab.md#installations-from-source [it]: https://gitlab.com/gitlab-org/gitlab-foss/uploads/c4cc8cd353604bd80315f9384035ff9e/The_Internet_IT_Crowd.png -[resque]: https://gitlab.com/gitlab-org/gitlab/blob/master/config/resque.yml.example +[resque]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/resque.yml.example diff --git a/doc/administration/issue_closing_pattern.md b/doc/administration/issue_closing_pattern.md index afe8c7c7e9f..0e34505c2b0 100644 --- a/doc/administration/issue_closing_pattern.md +++ b/doc/administration/issue_closing_pattern.md @@ -13,7 +13,7 @@ in the project's default branch. In order to change the pattern you need to have access to the server that GitLab is installed on. -The default pattern can be located in [`gitlab.yml.example`](https://gitlab.com/gitlab-org/gitlab/blob/master/config/gitlab.yml.example) +The default pattern can be located in [`gitlab.yml.example`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/config/gitlab.yml.example) under the "Automatic issue closing" section. > **Tip:** diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md index 1ab37824694..913321012e4 100644 --- a/doc/administration/job_artifacts.md +++ b/doc/administration/job_artifacts.md @@ -92,7 +92,7 @@ Use an object storage option like AWS S3 to store job artifacts. DANGER: **Danger:** If you're enabling S3 in [GitLab HA](high_availability/README.md), you will need to have an [NFS mount set up for CI traces and artifacts](high_availability/nfs.md#a-single-nfs-mount) or enable [live tracing](job_traces.md#new-live-trace-architecture). If these settings are not set, you will risk job traces disappearing or not being saved. -#### Object Storage Settings +### Object Storage Settings For source installations the following settings are nested under `artifacts:` and then `object_store:`. On Omnibus GitLab installs they are prefixed by `artifacts_object_store_`. @@ -105,7 +105,7 @@ For source installations the following settings are nested under `artifacts:` an | `proxy_download` | Set to true to enable proxying all files served. Option allows to reduce egress traffic as this allows clients to download directly from remote storage instead of proxying all data | `false` | | `connection` | Various connection options described below | | -##### S3 compatible connection settings +#### S3 compatible connection settings The connection settings match those provided by [Fog](https://github.com/fog), and are as follows: @@ -188,14 +188,6 @@ _The artifacts are stored by default in sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production ``` -### Migrating from object storage to local storage - -In order to migrate back to local storage: - -1. Set both `direct_upload` and `background_upload` to false under the artifacts object storage settings. Don't forget to restart GitLab. -1. Run `rake gitlab:artifacts:migrate_to_local` on your console. -1. Disable `object_storage` for artifacts in `gitlab.rb`. Remember to restart GitLab afterwards. - ## Expiring artifacts If an expiry date is used for the artifacts, they are marked for deletion diff --git a/doc/administration/job_traces.md b/doc/administration/job_traces.md index af60d777932..8a68f82d2fc 100644 --- a/doc/administration/job_traces.md +++ b/doc/administration/job_traces.md @@ -59,6 +59,46 @@ job traces are automatically migrated to it along with the other job artifacts. See "Phase 4: uploading" in [Data flow](#data-flow) to learn about the process. +## How to archive legacy job trace files + +Legacy job traces, which were created before GitLab 10.5, were not archived regularly. +It's the same state with the "2: overwriting" in the above [Data flow](#data-flow). +To archive those legacy job traces, please follow the instruction below. + +1. Execute the following command + + ```bash + gitlab-rake gitlab:traces:archive + ``` + + After you executed this task, GitLab instance queues up Sidekiq jobs (asynchronous processes) + for migrating job trace files from local storage to object storage. + It could take time to complete the all migration jobs. You can check the progress by the following command + + ```bash + sudo gitlab-rails console + ``` + + ```bash + [1] pry(main)> Sidekiq::Stats.new.queues['pipeline_background:archive_trace'] + => 100 + ``` + + If the count becomes zero, the archiving processes are done + +## How to migrate archived job traces to object storage + +> [Introduced][ce-21193] in GitLab 11.3. + +If job traces have already been archived into local storage, and you want to migrate those traces to object storage, please follow the instruction below. + +1. Ensure [Object storage integration for Job Artifacts](job_artifacts.md#object-storage-settings) is enabled +1. Execute the following command + + ```bash + gitlab-rake gitlab:traces:migrate + ``` + ## How to remove job traces There isn't a way to automatically expire old job logs, but it's safe to remove diff --git a/doc/administration/logs.md b/doc/administration/logs.md index 9ccfde58605..7857dcc1f08 100644 --- a/doc/administration/logs.md +++ b/doc/administration/logs.md @@ -23,7 +23,7 @@ requests from the API are logged to a separate file in `api_json.log`. Each line contains a JSON line that can be ingested by Elasticsearch, Splunk, etc. For example: ```json -{"method":"GET","path":"/gitlab/gitlab-foss/issues/1234","format":"html","controller":"Projects::IssuesController","action":"show","status":200,"duration":229.03,"view":174.07,"db":13.24,"time":"2017-08-08T20:15:54.821Z","params":[{"key":"param_key","value":"param_value"}],"remote_ip":"18.245.0.1","user_id":1,"username":"admin","gitaly_calls":76,"gitaly_duration":7.41,"queue_duration": 112.47} +{"method":"GET","path":"/gitlab/gitlab-ce/issues/1234","format":"html","controller":"Projects::IssuesController","action":"show","status":200,"duration":229.03,"view":174.07,"db":13.24,"time":"2017-08-08T20:15:54.821Z","params":[{"key":"param_key","value":"param_value"}],"remote_ip":"18.245.0.1","user_id":1,"username":"admin","gitaly_calls":76,"gitaly_duration":7.41,"queue_duration": 112.47} ``` In this example, you can see this was a GET request for a specific diff --git a/doc/administration/merge_request_diffs.md b/doc/administration/merge_request_diffs.md index db256728f4d..f24a3f94ceb 100644 --- a/doc/administration/merge_request_diffs.md +++ b/doc/administration/merge_request_diffs.md @@ -61,9 +61,6 @@ To enable external storage of merge request diffs, follow the instructions below ## Using object storage -CAUTION: **WARNING:** - Currently migrating to object storage is **non-reversible** - Instead of storing the external diffs on disk, we recommended the use of an object store like AWS S3 instead. This configuration relies on valid AWS credentials to be configured already. diff --git a/doc/administration/monitoring/github_imports.md b/doc/administration/monitoring/github_imports.md index 4d60cf0d491..2b1b7a230f7 100644 --- a/doc/administration/monitoring/github_imports.md +++ b/doc/administration/monitoring/github_imports.md @@ -16,7 +16,7 @@ This metric tracks the total time spent (in seconds) importing a project (from project creation until the import process finishes), for every imported project. The name of the project is stored in the `project` label in the format -`namespace/name` (e.g. `gitlab-org/gitlab`). +`namespace/name` (e.g. `gitlab-org/gitlab-ce`). ## Number of imported projects @@ -54,7 +54,7 @@ projects. This metric does not expose any labels. This metric tracks the number of imported issues across all projects. The name of the project is stored in the `project` label in the format -`namespace/name` (e.g. `gitlab-org/gitlab`). +`namespace/name` (e.g. `gitlab-org/gitlab-ce`). ## Number of imported pull requests @@ -65,7 +65,7 @@ The name of the project is stored in the `project` label in the format This metric tracks the number of imported pull requests across all projects. The name of the project is stored in the `project` label in the format -`namespace/name` (e.g. `gitlab-org/gitlab`). +`namespace/name` (e.g. `gitlab-org/gitlab-ce`). ## Number of imported comments @@ -76,7 +76,7 @@ The name of the project is stored in the `project` label in the format This metric tracks the number of imported comments across all projects. The name of the project is stored in the `project` label in the format -`namespace/name` (e.g. `gitlab-org/gitlab`). +`namespace/name` (e.g. `gitlab-org/gitlab-ce`). ## Number of imported pull request review comments @@ -87,7 +87,7 @@ The name of the project is stored in the `project` label in the format This metric tracks the number of imported comments across all projects. The name of the project is stored in the `project` label in the format -`namespace/name` (e.g. `gitlab-org/gitlab`). +`namespace/name` (e.g. `gitlab-org/gitlab-ce`). ## Number of imported repositories diff --git a/doc/administration/operations/sidekiq_memory_killer.md b/doc/administration/operations/sidekiq_memory_killer.md index 509bc77a8c3..8eac42f2fe2 100644 --- a/doc/administration/operations/sidekiq_memory_killer.md +++ b/doc/administration/operations/sidekiq_memory_killer.md @@ -26,50 +26,18 @@ run as a process group leader (e.g., using `chpst -P`). If using Omnibus or the The MemoryKiller is controlled using environment variables. -- `SIDEKIQ_DAEMON_MEMORY_KILLER`: defaults to 0. When set to 1, the MemoryKiller - works in _daemon_ mode. Otherwise, the MemoryKiller works in _legacy_ mode. - - In _legacy_ mode, the MemoryKiller checks the Sidekiq process RSS after each job. - - In _daemon_ mode, the MemoryKiller checks the Sidekiq process RSS every 3 seconds - (defined by `SIDEKIQ_MEMORY_KILLER_CHECK_INTERVAL`). - -- `SIDEKIQ_MEMORY_KILLER_MAX_RSS`: if this variable is set, and its value is greater - than 0, the MemoryKiller is enabled. Otherwise the MemoryKiller is disabled. - - `SIDEKIQ_MEMORY_KILLER_MAX_RSS` defines the Sidekiq process allowed RSS. - - In _legacy_ mode, if the Sidekiq process exceeds the allowed RSS then an irreversible - delayed graceful restart will be triggered. The restart of Sidekiq will happen - after `SIDEKIQ_MEMORY_KILLER_GRACE_TIME` seconds. - - In _daemon_ mode, if the Sidekiq process exceeds the allowed RSS for longer than - `SIDEKIQ_MEMORY_KILLER_GRACE_TIME` the graceful restart will be triggered. If the - Sidekiq process go below the allowed RSS within `SIDEKIQ_MEMORY_KILLER_GRACE_TIME`, - the restart will be aborted. - - The default value for Omnibus packages is set +- `SIDEKIQ_MEMORY_KILLER_MAX_RSS`: if this variable is set, and its value is + greater than 0, then after each Sidekiq job, the MemoryKiller will check the + RSS of the Sidekiq process that executed the job. If the RSS of the Sidekiq + process (expressed in kilobytes) exceeds SIDEKIQ_MEMORY_KILLER_MAX_RSS, a + delayed shutdown is triggered. The default value for Omnibus packages is set [in the omnibus-gitlab repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb). - -- `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS`: is used by _daemon_ mode. If the Sidekiq - process RSS (expressed in kilobytes) exceeds `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS`, - an immediate graceful restart of Sidekiq is triggered. - -- `SIDEKIQ_MEMORY_KILLER_CHECK_INTERVAL`: used in _daemon_ mode to define how - often to check process RSS, default to 3 seconds. - -- `SIDEKIQ_MEMORY_KILLER_GRACE_TIME`: defaults to 900 seconds (15 minutes). - The usage of this variable is described as part of `SIDEKIQ_MEMORY_KILLER_MAX_RSS`. - -- `SIDEKIQ_MEMORY_KILLER_SHUTDOWN_WAIT`: defaults to 30 seconds. This defines the - maximum time allowed for all Sidekiq jobs to finish. No new jobs will be accepted - during that time, and the process will exit as soon as all jobs finish. - - If jobs do not finish during that time, the MemoryKiller will interrupt all currently - running jobs by sending `SIGTERM` to the Sidekiq process. - - If the process hard shutdown/restart is not performed by Sidekiq, - the Sidekiq process will be forcefully terminated after - `Sidekiq.options[:timeout] * 2` seconds. An external supervision mechanism - (e.g. Runit) must restart Sidekiq afterwards. +- `SIDEKIQ_MEMORY_KILLER_GRACE_TIME`: defaults to 900 seconds (15 minutes). When + a shutdown is triggered, the Sidekiq process will keep working normally for + another 15 minutes. +- `SIDEKIQ_MEMORY_KILLER_SHUTDOWN_WAIT`: defaults to 30 seconds. When the grace + time has expired, the MemoryKiller tells Sidekiq to stop accepting new jobs. + Existing jobs get 30 seconds to finish. After that, the MemoryKiller tells + Sidekiq to shut down, and an external supervision mechanism (e.g. Runit) must + restart Sidekiq. diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md index 58a34607e2d..b5320d39d92 100644 --- a/doc/administration/packages/container_registry.md +++ b/doc/administration/packages/container_registry.md @@ -5,8 +5,8 @@ > Docker versions earlier than 1.10. NOTE: **Note:** -This document is the administrator's guide. To learn how to use GitLab Container -Registry, see the [user documentation](../../user/packages/container_registry/index.md). +This document is about the admin guide. To learn how to use GitLab Container +Registry [user documentation](../../user/packages/container_registry/index.md). With the Container Registry integrated into GitLab, every project can have its own space to store its Docker images. @@ -37,7 +37,7 @@ If you have installed GitLab from source: 1. After the installation is complete, you will have to configure the Registry's settings in `gitlab.yml` in order to enable it. 1. Use the sample NGINX configuration file that is found under - [`lib/support/nginx/registry-ssl`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/nginx/registry-ssl) and edit it to match the + [`lib/support/nginx/registry-ssl`](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/support/nginx/registry-ssl) and edit it to match the `host`, `port` and TLS certs paths. The contents of `gitlab.yml` are: diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md index 8cce6dbcb97..41a372c4aeb 100644 --- a/doc/administration/pages/index.md +++ b/doc/administration/pages/index.md @@ -13,6 +13,10 @@ description: 'Learn how to administer GitLab Pages.' GitLab Pages allows for hosting of static sites. It must be configured by an administrator. Separate [user documentation][pages-userguide] is available. +Read the [changelog](#changelog) if you are upgrading to a new GitLab +version as it may include new features and changes needed to be made in your +configuration. + NOTE: **Note:** This guide is for Omnibus GitLab installations. If you have installed GitLab from source, see @@ -429,6 +433,34 @@ Pages are part of the [regular backup][backup] so there is nothing to configure. You should strongly consider running GitLab pages under a different hostname than GitLab to prevent XSS attacks. +## Changelog + +GitLab Pages were first introduced in GitLab EE 8.3. Since then, many features +where added, like custom CNAME and TLS support, and many more are likely to +come. Below is a brief changelog. If no changes were introduced or a version is +missing from the changelog, assume that the documentation is the same as the +latest previous version. + +--- + +**GitLab 8.17 ([documentation](https://gitlab.com/gitlab-org/gitlab-foss/blob/8-17-stable/doc/administration/pages/index.md))** + +- GitLab Pages were ported to Community Edition in GitLab 8.17. +- Documentation was refactored to be more modular and easy to follow. + +**GitLab 8.5 ([documentation](https://gitlab.com/gitlab-org/gitlab/blob/8-5-stable-ee/doc/pages/administration.md))** + +- In GitLab 8.5 we introduced the [gitlab-pages][] daemon which is now the + recommended way to set up GitLab Pages. +- The [NGINX configs][] have changed to reflect this change. So make sure to + update them. +- Custom CNAME and TLS certificates support. +- Documentation was moved to one place. + +**GitLab 8.3 ([documentation](https://gitlab.com/gitlab-org/gitlab/blob/8-3-stable-ee/doc/pages/administration.md))** + +- GitLab Pages feature was introduced. + [backup]: ../../raketasks/backup_restore.md [ce-14605]: https://gitlab.com/gitlab-org/gitlab-foss/issues/14605 [ee-80]: https://gitlab.com/gitlab-org/gitlab/merge_requests/80 diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md index ad2a57e3241..bacfa0117bb 100644 --- a/doc/administration/pages/source.md +++ b/doc/administration/pages/source.md @@ -455,5 +455,5 @@ than GitLab to prevent XSS attacks. [pages-userguide]: ../../user/project/pages/index.md [restart]: ../restart_gitlab.md#installations-from-source [gitlab-pages]: https://gitlab.com/gitlab-org/gitlab-pages/tree/v0.4.0 -[gl-example]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab.default.example +[gl-example]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/support/init.d/gitlab.default.example [shared runners]: ../../ci/runners/README.md diff --git a/doc/administration/raketasks/uploads/migrate.md b/doc/administration/raketasks/uploads/migrate.md index 3bd8f2c27d4..d9b4c9b3369 100644 --- a/doc/administration/raketasks/uploads/migrate.md +++ b/doc/administration/raketasks/uploads/migrate.md @@ -113,39 +113,3 @@ To migrate all uploads created by legacy uploaders, run: ```shell bundle exec rake gitlab:uploads:legacy:migrate ``` - -## Migrate from object storage to local storage - -If you need to disable Object Storage for any reason, first you need to migrate -your data out of Object Storage and back into your local storage. - -**Before proceeding, it is important to disable both `direct_upload` and `background_upload` under `uploads` settings in `gitlab.rb`** - -CAUTION: **Warning:** - **Extended downtime is required** so no new files are created in object storage during - the migration. A configuration setting will be added soon to allow migrating - from object storage to local files with only a brief moment of downtime for configuration changes. - See issue [gitlab-org/gitlab-ce#66144](https://gitlab.com/gitlab-org/gitlab-ce/issues/66144) - -### All-in-one rake task - -GitLab provides a wrapper rake task that migrates all uploaded files - avatars, -logos, attachments, favicon, etc. - to local storage in one go. Under the hood, -it invokes individual rake tasks to migrate files falling under each of this -category one by one. For details on these rake tasks please [refer to the section above](#individual-rake-tasks), -keeping in mind the task name in this case is `gitlab:uploads:migrate_to_local`. - -**Omnibus Installation** - -```bash -gitlab-rake "gitlab:uploads:migrate_to_local:all" -``` - -**Source Installation** - -```bash -sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate_to_local:all -``` - -After this is done, you may disable Object Storage by undoing the changes described -in the instructions to [configure object storage](../../uploads.md#using-object-storage-core-only) diff --git a/doc/administration/repository_storage_paths.md b/doc/administration/repository_storage_paths.md index 7d3e36e9796..376eb90deea 100644 --- a/doc/administration/repository_storage_paths.md +++ b/doc/administration/repository_storage_paths.md @@ -118,6 +118,6 @@ randomly placed on one of the selected paths. [restart-gitlab]: restart_gitlab.md#installations-from-source [reconfigure-gitlab]: restart_gitlab.md#omnibus-gitlab-reconfigure [backups]: ../raketasks/backup_restore.md -[raketask]: https://gitlab.com/gitlab-org/gitlab/blob/033e5423a2594e08a7ebcd2379bd2331f4c39032/lib/backup/repository.rb#L54-56 -[repospath]: https://gitlab.com/gitlab-org/gitlab/blob/8-9-stable/config/gitlab.yml.example#L457 +[raketask]: https://gitlab.com/gitlab-org/gitlab-foss/blob/033e5423a2594e08a7ebcd2379bd2331f4c39032/lib/backup/repository.rb#L54-56 +[repospath]: https://gitlab.com/gitlab-org/gitlab-foss/blob/8-9-stable/config/gitlab.yml.example#L457 [ce-11449]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/11449 diff --git a/doc/administration/restart_gitlab.md b/doc/administration/restart_gitlab.md index 9f95080654f..169a220b9a9 100644 --- a/doc/administration/restart_gitlab.md +++ b/doc/administration/restart_gitlab.md @@ -141,5 +141,5 @@ If you are using other init systems, like systemd, you can check the [install]: ../install/installation.md "Documentation to install GitLab from source" [mailroom]: reply_by_email.md "Used for replying by email in GitLab issues and merge requests" [chef]: https://www.chef.io/products/chef-infra/ "Chef official website" -[src-service]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab "GitLab init service file" +[src-service]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/support/init.d/gitlab "GitLab init service file" [gl-recipes]: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/init "GitLab Recipes repository" |