|
2 | 2 | stage: Systems |
3 | 3 | group: Distribution |
4 | 4 | info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments |
| 5 | +remove_date: '2023-10-20' |
| 6 | +redirect_to: '../index.md' |
5 | 7 | --- |
6 | 8 |
|
7 | | -# GitLab 11 specific changes **(FREE SELF)** |
| 9 | +This document was moved to [another location](../index.md). |
8 | 10 |
|
9 | | -## TLS v1.1 Deprecation |
10 | | - |
11 | | -Beginning with GitLab 12.0, TLS v1.1 will be disabled by default to improve security. |
12 | | - |
13 | | -This mitigates numerous issues including, but not limited to, Heartbleed and makes |
14 | | -GitLab compliant out of the box with the PCI DSS 3.1 standard. |
15 | | -[Learn more about why TLS v1.1 is being deprecated in our blog.](https://about.gitlab.com/blog/2018/10/15/gitlab-to-deprecate-older-tls/) |
16 | | - |
17 | | -## Clients supporting TLS v1.2 |
18 | | - |
19 | | -- **Git-Credential-Manager** - support since **1.14.0** |
20 | | -- **Git on Red Hat Enterprise Linux 6** - support since **6.8** |
21 | | -- **Git on Red Hat Enterprise Linux 7** - support since **7.2** |
22 | | -- **JGit / Java** - support since **JDK 7** |
23 | | -- **Visual Studio** - support since version **2017** |
24 | | - |
25 | | -Modify or add these entries to `gitlab.rb` and run `gitlab-ctl reconfigure` to disable TLS v1.1 immediately: |
26 | | - |
27 | | -```ruby |
28 | | -nginx['ssl_protocols'] = "TLSv1.2" |
29 | | -``` |
30 | | - |
31 | | -## Upgrade prerequisites |
32 | | - |
33 | | -For successfully upgrading to GitLab 11.0, users need to satisfy following |
34 | | -requirements: |
35 | | - |
36 | | -1. Users should be running latest version in the 10.x series. At the time of |
37 | | - writing this documentation, it is GitLab 10.8.7. |
38 | | - |
39 | | -1. The configurations that were deprecated (list below) in the 10.x series have |
40 | | - been now removed. Users needs to remove them from `/etc/gitlab/gitlab.rb`. Then run `gitlab-ctl reconfigure` to apply the configuration changes. |
41 | | - |
42 | | -If either of the above requirements are not satisfied, upgrade process will |
43 | | -abort without making changes to user's existing installation. This is to ensure |
44 | | -that users does not end up with a broken GitLab due to these unsupported |
45 | | -configurations. |
46 | | - |
47 | | -## Removed configurations |
48 | | - |
49 | | -The following configurations were deprecated in the 10.x series and have now |
50 | | -been removed: |
51 | | - |
52 | | -1. Mattermost related configurations - Support for most of the Mattermost |
53 | | - related configuration have been removed, except for the essential ones that |
54 | | - are needed for GitLab-Mattermost integration. [Check out the official documentation for details](https://docs.gitlab.com/ee/integration/mattermost/index.html#upgrading-gitlab-mattermost-from-versions-prior-to-110) |
55 | | - |
56 | | -1. Legacy `git_data_dir` configuration, which was used to set location of where |
57 | | - data was to be stored. It has been now replaced with `git_data_dirs` |
58 | | - configuration. [Check out the official documentation for details](../settings/configuration.md#store-git-data-in-an-alternative-directory) |
59 | | - |
60 | | -1. Old format of `git_data_dirs` configuration has been replaced with a new |
61 | | - format, allowing much more fine grain control. [Check out the official documentation for details](../settings/configuration.md#store-git-data-in-an-alternative-directory) |
62 | | - |
63 | | -## Changes introduced in minor versions |
64 | | - |
65 | | -### 11.2 |
66 | | - |
67 | | -Rack Attack is disabled by default. To continue using Rack Attack, you must [enable it manually](https://docs.gitlab.com/ee/administration/settings/protected_paths.html). |
68 | | - |
69 | | -### 11.3 |
70 | | - |
71 | | -1. A [security patch](https://about.gitlab.com/releases/2018/11/28/security-release-gitlab-11-dot-5-dot-1-released/#improper-enforcement-of-token-scope) |
72 | | - removed the ability to get files from a repository by passing |
73 | | - a `private_token` URL parameter. |
74 | | - Instead, a redirect to `/users/sign_in` is now served. |
75 | | - Update any CI scripts, custom automations, etc. to use the |
76 | | - [repository files API](https://docs.gitlab.com/ee/api/repository_files.html#get-raw-file-from-repository). |
77 | | - |
78 | | -### 11.4 |
79 | | - |
80 | | -1. Version of bundled Redis has been upgraded to 3.2.12. This is a critical |
81 | | - security update that fixes multiple vulnerabilities. After upgrading to 11.4, |
82 | | - run `gitlab-ctl restart redis` to ensure the new version is loaded. |
83 | | - |
84 | | -1. The [bundled version of Prometheus](https://docs.gitlab.com/ee/administration/monitoring/prometheus/index.html) |
85 | | - has been upgraded to 2.4.2 and fresh installations will use it by default. |
86 | | - Version 2 of Prometheus uses a data format incompatible with version 1. |
87 | | - |
88 | | - For users looking for preserving the Prometheus version 1 data, a command |
89 | | - line tool is provided to upgrade their Prometheus service and migrate data to |
90 | | - the format supported by new Prometheus version. This tool can be invoked |
91 | | - using the following command: |
92 | | - |
93 | | - ```shell |
94 | | - sudo gitlab-ctl prometheus-upgrade |
95 | | - ``` |
96 | | - |
97 | | - This tool will convert existing data to a format supported by the latest |
98 | | - Prometheus version. Depending on the volume of data, this process can take |
99 | | - hours. If users do not want to migrate the data, but start with a clean |
100 | | - database, they can pass `--skip-data-migration` flag to the above command. |
101 | | - |
102 | | - NOTE: |
103 | | - Prometheus service will be stopped during the migration process. |
104 | | - |
105 | | - To know about other supported options, pass `--help` flag to the above |
106 | | - command. |
107 | | - |
108 | | - This tool **will not** be automatically invoked during package upgrades. |
109 | | - Users will have to run it manually to migrate to latest version of |
110 | | - Prometheus, and are advised to do it as soon as possible. Therefore, existing |
111 | | - users who are upgrading to 11.4 will continue to use Prometheus 1.x until |
112 | | - they manually migrate to the 2.x version. |
113 | | - |
114 | | - Support for Prometheus 1.x versions that were shipped with earlier versions |
115 | | - of GitLab has been deprecated and will be removed completely in GitLab 12.0. |
116 | | - Users still using those versions will be presented with a deprecation warning |
117 | | - during reconfigure. With GitLab 12.0 Prometheus will be upgraded to 2.x automatically, |
118 | | - Prometheus 1.0 data will not be migrated. |
119 | | -1. A [security patch](https://about.gitlab.com/releases/2018/11/28/security-release-gitlab-11-dot-5-dot-1-released/#improper-enforcement-of-token-scope) |
120 | | - removed the ability to get files from a repository by passing |
121 | | - a `private_token` URL parameter. |
122 | | - Instead, a redirect to `/users/sign_in` is now served. |
123 | | - Update any CI scripts, custom automations, etc. to use the |
124 | | - [repository files API](https://docs.gitlab.com/ee/api/repository_files.html#get-raw-file-from-repository). |
125 | | - |
126 | | -### 11.5 |
127 | | - |
128 | | -1. A [security patch](https://about.gitlab.com/releases/2018/11/28/security-release-gitlab-11-dot-5-dot-1-released/#improper-enforcement-of-token-scope) |
129 | | - removed the ability to get files from a repository by passing |
130 | | - a `private_token` URL parameter. |
131 | | - Instead, a redirect to `/users/sign_in` is now served. |
132 | | - Update any CI scripts, custom automations, etc. to use the |
133 | | - [repository files API](https://docs.gitlab.com/ee/api/repository_files.html#get-raw-file-from-repository). |
134 | | - |
135 | | -### 11.6 |
136 | | - |
137 | | -1. [Sidekiq probe of GitLab Monitor](https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_exporter.html) |
138 | | - will be disabled by default if GitLab is configured in [Redis for scaling](https://docs.gitlab.com/ee/administration/redis/index.html). |
139 | | - To manually enable it, users can set `gitlab_monitor['probe_sidekiq'] = true` |
140 | | - in `/etc/gitlab/gitlab.rb` file. However, when manually enabling it in Redis |
141 | | - HA mode, users are expected to point the probe to a Redis instance connected |
142 | | - to the instance using the `gitlab_rails['redis_*']` settings. |
143 | | - |
144 | | - A valid example configuration is: |
145 | | - |
146 | | - ```ruby |
147 | | - gitlab_monitor['probe_sidekiq'] = true |
148 | | - gitlab_rails['redis_host'] = <IP of Redis master node> |
149 | | - gitlab_rails['redis_port'] = <Port where Redis runs in master node> |
150 | | - gitlab_rails['redis_password'] = <Password to connect to Redis master> |
151 | | - ``` |
152 | | - |
153 | | - NOTE: |
154 | | - In the above configuration, when a failover happens after the |
155 | | - master node fails, GitLab Monitor will still be probing the original master |
156 | | - node, since it is specified in `gitlab.rb`. Users will have to manually update |
157 | | - `gitlab.rb` to point it to the new master node. |
158 | | - |
159 | | -1. Ruby has been updated to 2.5.3. GitLab will be down during the upgrade until |
160 | | - the Unicorn processes have been restarted. The restart is done automatically |
161 | | - at the end of `gitlab-ctl reconfigure`, which is run by default on upgrade. |
162 | | - |
163 | | - NOTE: |
164 | | - The application will throw 500 http errors until the Unicorn restart is completed. |
165 | | - |
166 | | -### 11.8 |
167 | | - |
168 | | -1. The [runit](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/runit) cookbook was updated to be closer to the latest version of the upstream [runit cookbook](https://github.com/chef-cookbooks/runit). No user changes are necessary for this release. |
| 11 | +<!-- This redirect file can be deleted after 2023-10-20. --> |
| 12 | +<!-- Redirects that point to other docs in the same project expire in three months. --> |
| 13 | +<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. --> |
| 14 | +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html --> |
0 commit comments