summaryrefslogtreecommitdiff
path: root/doc/administration/package_information
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2021-09-20 13:18:24 +0000
committerGitLab Bot <gitlab-bot@gitlab.com>2021-09-20 13:18:24 +0000
commit0653e08efd039a5905f3fa4f6e9cef9f5d2f799c (patch)
tree4dcc884cf6d81db44adae4aa99f8ec1233a41f55 /doc/administration/package_information
parent744144d28e3e7fddc117924fef88de5d9674fe4c (diff)
downloadgitlab-ce-0653e08efd039a5905f3fa4f6e9cef9f5d2f799c.tar.gz
Add latest changes from gitlab-org/gitlab@14-3-stable-eev14.3.0-rc42
Diffstat (limited to 'doc/administration/package_information')
-rw-r--r--doc/administration/package_information/defaults.md72
-rw-r--r--doc/administration/package_information/deprecated_os.md82
-rw-r--r--doc/administration/package_information/deprecation_policy.md95
-rw-r--r--doc/administration/package_information/index.md101
-rw-r--r--doc/administration/package_information/licensing.md79
-rw-r--r--doc/administration/package_information/omnibus_packages.md115
-rw-r--r--doc/administration/package_information/postgresql_versions.md42
-rw-r--r--doc/administration/package_information/signed_packages.md25
8 files changed, 611 insertions, 0 deletions
diff --git a/doc/administration/package_information/defaults.md b/doc/administration/package_information/defaults.md
new file mode 100644
index 00000000000..45bea065995
--- /dev/null
+++ b/doc/administration/package_information/defaults.md
@@ -0,0 +1,72 @@
+---
+stage: Enablement
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# Package defaults
+
+Unless configuration is specified in the `/etc/gitlab/gitlab.rb` file,
+the package will assume the defaults as noted below.
+
+## Ports
+
+See the table below for the list of ports that the Omnibus GitLab assigns
+by default:
+
+| Component | On by default | Communicates via | Alternative | Connection port |
+| :----------------------------------------------------: | :------------: | :--------------: | :---------: | :------------------------------------: |
+| <a name="gitlab-rails"></a> GitLab Rails | Yes | Port | X | 80 or 443 |
+| <a name="gitlab-shell"></a> GitLab Shell | Yes | Port | X | 22 |
+| <a name="postgresql"></a> PostgreSQL | Yes | Socket | Port (5432) | X |
+| <a name="redis"></a> Redis | Yes | Socket | Port (6379) | X |
+| <a name="puma"></a> Puma | Yes | Socket | Port (8080) | X |
+| <a name="gitlab-workhorse"></a> GitLab Workhorse | Yes | Socket | Port (8181) | X |
+| <a name="nginx-status"></a> NGINX status | Yes | Port | X | 8060 |
+| <a name="prometheus"></a> Prometheus | Yes | Port | X | 9090 |
+| <a name="node-exporter"></a> Node exporter | Yes | Port | X | 9100 |
+| <a name="redis-exporter"></a> Redis exporter | Yes | Port | X | 9121 |
+| <a name="postgres-exporter"></a> PostgreSQL exporter | Yes | Port | X | 9187 |
+| <a name="pgbouncer-exporter"></a> PgBouncer exporter | No | Port | X | 9188 |
+| <a name="gitlab-exporter"></a> GitLab Exporter | Yes | Port | X | 9168 |
+| <a name="sidekiq-exporter"></a> Sidekiq exporter | Yes | Port | X | 8082 |
+| <a name="puma-exporter"></a> Puma exporter | No | Port | X | 8083 |
+| <a name="geo-postgresql"></a> Geo PostgreSQL | No | Socket | Port (5431) | X |
+| <a name="redis-sentinel"></a> Redis Sentinel | No | Port | X | 26379 |
+| <a name="incoming-email"></a> Incoming email | No | Port | X | 143 |
+| <a name="elasticsearch"></a> Elastic search | No | Port | X | 9200 |
+| <a name="gitlab-pages"></a> GitLab Pages | No | Port | X | 80 or 443 |
+| <a name="gitlab-registry-web"></a> GitLab Registry | No* | Port | X | 80, 443 or 5050 |
+| <a name="gitlab-registry"></a> GitLab Registry | No | Port | X | 5000 |
+| <a name="ldap"></a> LDAP | No | Port | X | Depends on the component configuration |
+| <a name="kerberos"></a> Kerberos | No | Port | X | 8443 or 8088 |
+| <a name="omniauth"></a> OmniAuth | Yes | Port | X | Depends on the component configuration |
+| <a name="smtp"></a> SMTP | No | Port | X | 465 |
+| <a name="remote-syslog"></a> Remote syslog | No | Port | X | 514 |
+| <a name="mattermost"></a> Mattermost | No | Port | X | 8065 |
+| <a name="mattermost-web"></a> Mattermost | No | Port | X | 80 or 443 |
+| <a name="pgbouncer"></a> PgBouncer | No | Port | X | 6432 |
+| <a name="consul"></a> Consul | No | Port | X | 8300, 8301(UDP), 8500, 8600[^Consul-notes] |
+| <a name="patroni"></a> Patroni | No | Port | X | 8008 |
+| <a name="gitlab-kas"></a> GitLab KAS | No | Port | X | 8150 |
+| <a name="gitaly"></a> Gitaly | No | Port | X | 8075 |
+
+Legend:
+
+- `Component` - Name of the component.
+- `On by default` - Is the component running by default.
+- `Communicates via` - How the component talks with the other components.
+- `Alternative` - If it is possible to configure the component to use different type of communication. The type is listed with default port used in that case.
+- `Connection port` - Port on which the component communicates.
+
+GitLab also expects a filesystem to be ready for the storage of Git repositories
+and various other files.
+
+Note that if you are using NFS (Network File System), files will be carried
+over a network which will require, based on implementation, ports `111` and
+`2049` to be open.
+
+NOTE:
+In some cases, the GitLab Registry will be automatically enabled by default. Please see [our documentation](../packages/container_registry.md) for more details
+
+ [^Consul-notes]: If using additional Consul functionality, more ports may need to be opened. See the [official documentation](https://www.consul.io/docs/install/ports#ports-table) for the list.
diff --git a/doc/administration/package_information/deprecated_os.md b/doc/administration/package_information/deprecated_os.md
new file mode 100644
index 00000000000..251dbe1e20e
--- /dev/null
+++ b/doc/administration/package_information/deprecated_os.md
@@ -0,0 +1,82 @@
+---
+stage: Enablement
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# OS Versions that are no longer supported
+
+GitLab provides omnibus packages for operating systems only until their
+EOL (End-Of-Life). After the EOL date of the OS, GitLab will stop releasing
+official packages. The list of deprecated operating systems and the final GitLab
+release for them can be found below:
+
+| OS Version | End Of Life | Last supported GitLab version |
+| --------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Raspbian Wheezy | [May 2015](https://downloads.raspberrypi.org/raspbian/images/raspbian-2015-05-07/) | [GitLab CE](https://packages.gitlab.com/app/gitlab/raspberry-pi2/search?q=gitlab-ce_8.17&dist=debian%2Fwheezy) 8.17 |
+| OpenSUSE 13.2 | [January 2017](https://en.opensuse.org/Lifetime#Discontinued_distributions) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce-9.1&dist=opensuse%2F13.2) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee-9.1&dist=opensuse%2F13.2) 9.1 |
+| Ubuntu 12.04 | [April 2017](https://ubuntu.com/info/release-end-of-life) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce_9.1&dist=ubuntu%2Fprecise) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee_9.1&dist=ubuntu%2Fprecise) 9.1 |
+| OpenSUSE 42.1 | [May 2017](https://en.opensuse.org/Lifetime#Discontinued_distributions) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce-9.3&dist=opensuse%2F42.1) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee-9.3&dist=opensuse%2F42.1) 9.3 |
+| OpenSUSE 42.2 | [January 2018](https://en.opensuse.org/Lifetime#Discontinued_distributions) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce-10.4&dist=opensuse%2F42.2) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee-10.4&dist=opensuse%2F42.2) 10.4 |
+| Debian Wheezy | [May 2018](https://www.debian.org/News/2018/20180601) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce_11.6&dist=debian%2Fwheezy) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee_11.6&dist=debian%2Fwheezy) 11.6 |
+| Raspbian Jessie | [May 2017](https://downloads.raspberrypi.org/raspbian/images/raspbian-2017-07-05/) | [GitLab CE](https://packages.gitlab.com/app/gitlab/raspberry-pi2/search?q=gitlab-ce_11.7&dist=debian%2Fjessie) 11.7 |
+| Ubuntu 14.04 | [April 2019](https://ubuntu.com/info/release-end-of-life) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce_11.10&dist=ubuntu%2Ftrusty) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee_11.10&dist=ubuntu%2Ftrusty) 11.10 |
+| OpenSUSE 42.3 | [July 2019](https://en.opensuse.org/Lifetime#Discontinued_distributions) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce-12.1&dist=opensuse%2F42.3) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee-12.1&dist=opensuse%2F42.3) 12.1 |
+| OpenSUSE 15.0 | [December 2019](https://en.opensuse.org/Lifetime#Discontinued_distributions) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce-12.5&dist=opensuse%2F15.0) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee-12.5&dist=opensuse%2F15.0) 12.5 |
+| Raspbian Stretch | [June 2020](https://downloads.raspberrypi.org/raspbian/images/raspbian-2019-04-09/) | [GitLab CE](https://packages.gitlab.com/app/gitlab/raspberry-pi2/search?q=gitlab-ce_13.2&dist=raspbian%2Fstretch) 13.3 |
+| Debian Jessie | [June 2020](https://www.debian.org/News/2020/20200709) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce_13.2&dist=debian%2Fjessie) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee_13.2&dist=debian%2Fjessie) 13.3 |
+| CentOS 6 | [November 2020](https://wiki.centos.org/About/Product) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=13.6&filter=all&filter=all&dist=el%2F6) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=13.6&filter=all&filter=all&dist=el%2F6) 13.6 |
+| OpenSUSE 15.1 | [November 2020](https://en.opensuse.org/Lifetime#Discontinued_distributions) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce-13.12&dist=opensuse%2F15.1) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee-13.12&dist=opensuse%2F15.2) 13.12 |
+| Ubuntu 16.04 | [April 2021](https://ubuntu.com/info/release-end-of-life) | [GitLab CE](https://packages.gitlab.com/app/gitlab/gitlab-ce/search?q=gitlab-ce_13.12&dist=ubuntu%2Fxenial) / [GitLab EE](https://packages.gitlab.com/app/gitlab/gitlab-ee/search?q=gitlab-ee_13.12&dist=ubuntu%2Fxenial) 13.12 |
+
+NOTE:
+An exception to this deprecation policy is when we are unable to provide
+packages for the next version of the operating system. The most common reason
+for this our package repository provider, Packagecloud, not supporting newer
+versions and hence we can't upload packages to it.
+
+## Update GitLab package sources after upgrading the OS
+
+After upgrading the Operating System (OS) as per its own documentation,
+it may be necessary to also update the GitLab package source URL
+in your package manager configuration.
+If your package manager reports that no further updates are available,
+although [new versions have been released](https://about.gitlab.com/releases/categories/releases/), repeat the
+"Add the GitLab package repository" instructions
+of the [Linux package install guide](https://about.gitlab.com/install/#content).
+Future GitLab upgrades will now be fetched according to your upgraded OS.
+
+## Supported Operating Systems
+
+GitLab officially supports LTS versions of operating systems. While OSs like
+Ubuntu have a clear distinction between LTS and non-LTS versions, there are
+other OSs, openSUSE for example, that don't follow the LTS concept. Hence to
+avoid confusion, the official policy is that at any point of time, all the
+operating systems supported by GitLab are listed in the [installation
+page](https://about.gitlab.com/install/).
+
+The following lists the currently supported OSs and their possible EOL dates.
+
+| OS Version | First supported GitLab version | Arch | OS EOL | Details |
+| ---------------- | ------------------------------ | --------------- | ------------- | ------------------------------------------------------------ |
+| CentOS 7 | GitLab CE / GitLab EE 7.10.0 | x86_64 | June 2024 | <https://wiki.centos.org/About/Product> |
+| CentOS 8 | GitLab CE / GitLab EE 12.8.1 | x86_64, aarch64 | Dec 2021 | <https://wiki.centos.org/About/Product> |
+| Debian 9 | GitLab CE / GitLab EE 9.3.0 | amd64 | 2022 | <https://wiki.debian.org/DebianReleases#Production_Releases> |
+| Debian 10 | GitLab CE / GitLab EE 12.2.0 | amd64, arm64 | TBD | <https://wiki.debian.org/DebianReleases#Production_Releases> |
+| OpenSUSE 15.2 | GitLab CE / GitLab EE 13.11.0 | x86_64, aarch64 | Dec 2021 | <https://en.opensuse.org/Lifetime> |
+| SLES 12 | GitLab EE 9.0.0 | x86_64 | Oct 2027 | <https://www.suse.com/lifecycle/> |
+| Ubuntu 18.04 | GitLab CE / GitLab EE 10.7.0 | amd64 | April 2023 | <https://wiki.ubuntu.com/Releases> |
+| Ubuntu 20.04 | GitLab CE / GitLab EE 13.2.0 | amd64, arm64 | April 2025 | <https://wiki.ubuntu.com/Releases> |
+| Raspbian Buster | GitLab CE 12.2.0 | armhf | 2022 | <https://wiki.debian.org/DebianReleases#Production_Releases> |
+
+### Packages for ARM64
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/issues/27) in GitLab 13.4.
+
+GitLab provides arm64/aarch64 packages for some supported operating systems.
+You can see if your operating system architecture is supported in the table
+above.
+
+WARNING:
+There are currently still some [known issues and limitation](https://gitlab.com/groups/gitlab-org/-/epics/4397)
+running GitLab on ARM.
diff --git a/doc/administration/package_information/deprecation_policy.md b/doc/administration/package_information/deprecation_policy.md
new file mode 100644
index 00000000000..cc16661442a
--- /dev/null
+++ b/doc/administration/package_information/deprecation_policy.md
@@ -0,0 +1,95 @@
+---
+stage: Enablement
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# Deprecation policy
+
+The Omnibus GitLab packages come with number of different libraries and services which offers users plethora of configuration options.
+
+As libraries and services get updated, their configuration options change
+and become obsolete. To increase maintainability and preserve a working
+setup, various configuration requires removal.
+
+## Configuration deprecation
+
+### Policy
+
+The Omnibus GitLab package will retain configuration for at least **one major**
+version. We cannot guarantee that deprecated configuration
+will be available in the next major release. See [example](#example) for more details.
+
+### Notice
+
+If the configuration becomes obsolete, we will announce the deprecation:
+
+- via release blog post on `https://about.gitlab.com/blog/`. The blog post item
+ will contain the deprecation notice together with the target removal date.
+- via installation/reconfigure output (if applicable).
+- via official documentation on `https://docs.gitlab.com/`. The documentation update will contain the corrected syntax (if applicable) or a date of configuration removal.
+
+### Procedure
+
+This section lists steps necessary for deprecating and removing configuration.
+
+We can differentiate two different types of configuration:
+
+- Sensitive: Configuration that can cause major service outage ( Data integrity,
+ installation integrity, preventing users from reaching the installation, etc.)
+- Regular: Configuration that can make a feature unavailable but still makes the installation useable ( Change in default project/group settings, miscommunication with other components and similar )
+
+We also need to differentiate deprecation and removal procedure.
+
+#### Deprecating configuration
+
+Deprecation procedure is similar for both `sensitive` and `regular` configuration. The only difference is in the removal target date.
+
+Common steps:
+
+1. Create an issue at the [Omnibus GitLab issue tracker](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues) with details on deprecation type and other necessary information. Apply the label `deprecation`.
+1. Decide on the removal target for the deprecated configuration
+1. Formulate deprecation notice for each item as noted in [Notice section](#notice)
+
+Removal target:
+
+For regular configuration, removal target should always be the date of the **next major** release. If the date is not known, you can reference the next major version.
+
+For sensitive configuration things are a bit more complicated.
+We should aim to not remove sensitive configuration in the *next major* release if the next major release is 2 minor releases away (This number is chosen to match our security backport release policy).
+
+See the table below for some examples:
+
+| Config. type | Deprecation announced | Final minor release | Remove |
+| -------- | -------- | -------- | -------- |
+| Sensitive | 10.1.0 | 10.9.0 | 11.0.0 |
+| Sensitive | 10.7.0 | 10.9.0 | 12.0.0 |
+| Regular | 10.1.0 | 10.9.0 | 11.0.0 |
+| Regular | 10.8.0 | 10.9.0 | 11.0.0 |
+
+#### Removing configuration
+
+When deprecation is announced and removal target set, the milestone for the issue
+should be changed to match the removal target version.
+
+The final comment in the issue **has to have**:
+
+1. Text snippet for the release blog post section
+1. Documentation MR ( or snippet ) for introducing the change
+1. Draft MR removing the configuration OR details on what needs to be done. See [Adding deprecation messages](https://docs.gitlab.com/omnibus/development/adding-deprecation-messages.html) for more on this
+
+## Example
+
+User configuration available in `/etc/gitlab/gitlab.rb` was introduced in GitLab version 10.0, `gitlab_rails['configuration'] = true`. In GitLab version 10.4.0, a new change was introduced that requires rename of this configuration option. New configuration option is `gitlab_rails['better_configuration'] = true`. Development team will translate the old configuration into new one
+and trigger a deprecation procedure.
+
+This means that these two configuration
+options will both be valid through GitLab version 10. In other words,
+if you still have `gitlab_rails['configuration'] = true` set in GitLab 10.8.0
+the feature will continue working the same way as if you had `gitlab_rails['better_configuration'] = true` set.
+However, setting the old version of configuration will print out a deprecation
+notice at the end of installation/upgrade/reconfigure run.
+
+With GitLab 11, `gitlab_rails['configuration'] = true` will no longer work and you will have to manually change the configuration in `/etc/gitlab/gitlab.rb` to the new valid config.
+**Note** If this configuration option is sensitive and can put integrity of the installation or
+data in danger, installation/upgrade will be aborted.
diff --git a/doc/administration/package_information/index.md b/doc/administration/package_information/index.md
new file mode 100644
index 00000000000..e18fb621b89
--- /dev/null
+++ b/doc/administration/package_information/index.md
@@ -0,0 +1,101 @@
+---
+stage: Enablement
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# Package information
+
+The Omnibus GitLab package is bundled with all dependencies required for GitLab
+to function correctly. More details can be found
+at [bundling dependencies document](omnibus_packages.md).
+
+## Package Version
+
+The released package versions are in the format `MAJOR.MINOR.PATCH-EDITION.OMNIBUS_RELEASE`
+
+| Component | Meaning | Example |
+| --------- | ------- | ------- |
+| MAJOR.MINOR.PATCH | The GitLab version this corresponds to | 13.3.0 |
+| EDITION | The edition of GitLab this corresponds to | ee |
+| OMNIBUS_RELEASE | The omnibus release. Usually, this will be 0. This will be incremented if we need to build a new package without changing the GitLab version. | 0 |
+
+## Licenses
+
+See [licensing](licensing.md)
+
+## Defaults
+
+The Omnibus GitLab package requires various configuration to get the
+components in working order.
+If the configuration is not provided, the package will use the default
+values assumed in the package.
+
+These defaults are noted in the package [defaults document](defaults.md).
+
+## Checking the versions of bundled software
+
+Once the Omnibus GitLab package is installed, all versions of the bundled
+libraries are located in `/opt/gitlab/version-manifest.txt`.
+
+If you don't have the package installed, you can always check the Omnibus GitLab
+[source repository](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master), specifically the
+[config directory](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/config).
+
+For example, if you take a look at the `8-6-stable` branch, you can conclude that
+8.6 packages were running [Ruby 2.1.8](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/8-6-stable/config/projects/gitlab.rb#L48).
+Or, that 8.5 packages were bundled with [NGINX 1.9.0](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/8-5-stable/config/software/nginx.rb#L20).
+
+## Signatures of GitLab, Inc. provided packages
+
+Documentation on package signatures can be found at [Signed Packages](signed_packages.md)
+
+## Checking for newer configuration options on upgrade
+
+Configuration file in `/etc/gitlab/gitlab.rb` is created on initial installation
+of the Omnibus GitLab package. On subsequent package upgrades, the configuration
+file is not updated with new configuration. This is done in order to avoid
+accidental overwrite of user configuration provided in `/etc/gitlab/gitlab.rb`.
+
+New configuration options are noted in the
+[`gitlab.rb.template` file](https://gitlab.com/gitlab-org/omnibus-gitlab/raw/master/files/gitlab-config-template/gitlab.rb.template).
+
+The Omnibus GitLab package also provides convenience command which will
+compare the existing user configuration with the latest version of the
+template contained in the package.
+
+To view a diff between your configuration file and the latest version, run:
+
+```shell
+sudo gitlab-ctl diff-config
+```
+
+_**Note:** This command is available from GitLab 8.17_
+
+**Important:** If you are copy-pasting the output of this command into your
+`/etc/gitlab/gitlab.rb` configuration file, make sure to omit leading `+` and `-`
+on each line.
+
+## Init system detection
+
+Omnibus GitLab will attempt to query the underlaying system in order to
+check which init system it uses.
+This manifests itself as a `WARNING` during the `sudo gitlab-ctl reconfigure`
+run.
+
+Depending on the init system, this `WARNING` can be one of:
+
+```plaintext
+/sbin/init: unrecognized option '--version'
+```
+
+when the underlying init system *IS NOT* upstart.
+
+```plaintext
+ -.mount loaded active mounted /
+```
+
+when the underlying init system *IS* systemd.
+
+These warnings _can be safely ignored_. They are not suppressed because this
+allows everyone to debug possible detection issues faster.
diff --git a/doc/administration/package_information/licensing.md b/doc/administration/package_information/licensing.md
new file mode 100644
index 00000000000..8557a94bf93
--- /dev/null
+++ b/doc/administration/package_information/licensing.md
@@ -0,0 +1,79 @@
+---
+stage: Enablement
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# Package Licensing
+
+## License
+
+While GitLab itself is MIT, the Omnibus GitLab sources are licensed under the Apache-2.0.
+
+## License file location
+
+Starting with version 8.11, the Omnibus GitLab package contains license
+information of all software that is bundled within the package.
+
+After installing the package, licenses for each individual bundled library
+can be found in `/opt/gitlab/LICENSES` directory.
+
+There is also one `LICENSE` file which contains all licenses compiled together.
+This compiled license can be found in `/opt/gitlab/LICENSE` file.
+
+Starting with version 9.2, the Omnibus GitLab package ships a
+`dependency_licenses.json` file containing version and license information of
+all bundled software, including software libraries, Ruby gems that the rails
+application uses, and JavaScript libraries that is required for the frontend
+components. This file, being in JSON format, is easily machine parseable and
+can be used for automated checks or validations. The file may be found at
+`/opt/gitlab/dependency_licenses.json`.
+
+Starting with version 11.3, we have also made the license information available
+online, at: <https://gitlab-org.gitlab.io/omnibus-gitlab/licenses.html>
+
+## Checking licenses
+
+The Omnibus GitLab package is made up of many pieces of software, comprising code
+that is covered by many different licenses. Those licenses are provided and
+compiled as stated above.
+
+Starting with version 8.13, GitLab has placed an additional step into
+Omnibus GitLab. The `license_check` step calls
+`lib/gitlab/tasks/license_check.rake`, which checks the compiled `LICENSE` file
+against the current list of approved and questionable licenses as denoted in the
+arrays at the top of the script. This script will output one of `Good`,
+`Unknown` or `Check` for each piece of software that is a part of the
+Omnibus GitLab package.
+
+- `Good`: denotes a license that is approved for all usage types, within GitLab and
+ Omnibus GitLab.
+- `Unknown`: denotes a license that is not recognized in the list of 'good' or 'bad',
+ which should be immediately reviewed for implications of use.
+- `Check`: denotes a license that has the potential be incompatible with GitLab itself,
+ and thus should be checked for how it is used as a part of the Omnibus GitLab package
+ to ensure compliance.
+
+This list is currently sourced from the [GitLab development documentation on licensing](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/doc/development/licensing.md).
+However, due to the nature of the Omnibus GitLab package the licenses may not apply
+in the same way. Such as with `git` and `rsync`. See the [GNU License FAQ](https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation)
+
+## License acknowledgements
+
+### libjpeg-turbo - BSD 3-clause license
+
+This software is based in part on the work of the Independent JPEG Group.
+
+## Trademark Usage
+
+Within the GitLab documentation, reference to third party technology(ies) and/or trademarks of third party entities, may be made. The inclusion of reference to third party technology and/or entities is solely for the purposes of example(s) of how GitLab software may interact with, or be used in conjunction with, such third party technology.
+All trademarks, materials, documentation, and other intellectual property remain the property of any/all such third party.
+
+### Trademark Requirements
+
+Use of GitLab Trademarks must be in compliance with the standards set forth in [our guidelines](https://about.gitlab.com/handbook/marketing/corporate-marketing/brand-activation/trademark-guidelines/) (as updated from time to time).
+CHEF® and all Chef marks are owned by Progress Software Corporation and must be used in accordance with the [Progress Software Trademark Usage Policy](https://www.progress.com/legal/trademarks).
+
+When using a GitLab or 3rd party trademark in documentation, include the (R) symbol in the first instance, for example, "Chef(R) is used for configuring...." You may omit the symbol in subsequent instances.
+
+If a trademark owner requires a particular notice or trademark requirement, such notice or requirement should be stated above.
diff --git a/doc/administration/package_information/omnibus_packages.md b/doc/administration/package_information/omnibus_packages.md
new file mode 100644
index 00000000000..aa73534fc55
--- /dev/null
+++ b/doc/administration/package_information/omnibus_packages.md
@@ -0,0 +1,115 @@
+---
+stage: Enablement
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# Omnibus based packages and images
+
+Below you can find some basic information on why GitLab provides packages and
+a Docker image that come with bundled dependencies.
+
+These methods are great for physical and virtual machine installations, and simple Docker installations.
+
+## Goals
+
+We have a few core goals with these packages:
+
+1. Extremely easy to install, upgrade, maintain.
+1. Support for a wide variety of operating systems
+1. Wide support of cloud service providers
+
+## Omnibus GitLab Architecture
+
+GitLab in its core is a Ruby on Rails project. However, GitLab as a whole
+application is more complex and has multiple components. If these components are
+not present or are incorrectly configured, GitLab will not work or it will work
+unpredictably.
+
+The [GitLab Architecture Overview](../../development/architecture.md#gitlab-architecture-overview) shows some of these components and how they
+interact. Each of these components needs to be configured and kept up to date.
+
+Most of the components also have external dependencies. For example, the Rails
+application depends on a number of [Ruby gems](https://gitlab.com/gitlab-org/gitlab-foss/blob/master/Gemfile.lock). Some of these dependencies also
+have their own external dependencies which need to be present on the Operating
+System in order for them to function correctly.
+
+Furthermore, GitLab has a monthly release cycle requiring frequent maintenance
+to stay up to date.
+
+All the things listed above present a challenge for the user maintaining the GitLab
+installation.
+
+## External Software Dependencies
+
+For applications such as GitLab, external dependencies usually bring the following
+challenges:
+
+- Keeping versions in sync between direct and indirect dependencies
+- Availability of a version on a specific Operating System
+- Version changes can introduce or remove previously used configuration
+- Security implications when library is marked as vulnerable but does not have
+ a new version released yet
+
+Keep in mind that if a dependency exists on your Operating System, it does not
+necessarily exist on other supported OSs.
+
+## Benefits
+
+A few benefits of a package with bundled dependencies:
+
+1. Minimal effort required to install GitLab.
+1. Minimum configuration required to get GitLab up and running.
+1. Minimum effort required to upgrade between GitLab versions.
+1. Multiple platforms supported.
+1. Maintenance on older platforms is greatly simplified.
+1. Less effort to support potential issues.
+
+## Drawbacks
+
+Some drawbacks of a package with bundled dependencies:
+
+1. Duplication with possibly existing software.
+1. Less flexibility in configuration.
+
+## Why would I install an omnibus package when I can use a system package?
+
+The answer can be simplified to: less maintenance required. Instead of handling
+multiple packages that *can* break existing functionality if the versions are
+not compatible, only handle one.
+
+Multiple packages require correct configuration in multiple locations.
+Keeping configuration in sync can be error prone.
+
+If you have the skill set to maintain all current dependencies and enough time
+to handle any future dependencies that might get introduced, the above listed
+reasons might not be good enough for you to not use the omnibus package.
+
+There are two things to keep in mind before going down this route:
+
+1. Getting support for any problems
+ you encounter might be more difficult due to the number of possibilities that exist
+ when using a library version that is not tested by majority of users.
+1. Omnibus package also allows shutting off of any services that you do not need,
+ if you need to run a component independently. For example, you can use a
+ [non-bundled PostgreSQL database](https://docs.gitlab.com/omnibus/settings/database.html#using-a-non-packaged-postgresql-database-management-server) with the omnibus package.
+
+Keep in mind that a non-standard solution like the omnibus package
+might be a better fit when the application has a number of moving parts.
+
+## Docker image with multiple services
+
+[GitLab Docker image](../../install/docker.md#gitlab-docker-images) is based on the omnibus package.
+
+Considering that container spawned from this image contains multiple processes,
+these types of containers are also referred to as 'fat containers'.
+
+There are reasons for and against an image like this, but they are similar to
+what was noted above:
+
+1. Very simple to get started.
+1. Upgrading to the latest version is extremely simple.
+1. Running separate services in multiple containers and keeping them running
+ can be more complex and might not be required for a given install.
+
+This method is useful for organizations just getting started with containers and schedulers, and may not be ready for a more complex installation. This method is a great introduction, and will work well for smaller organizations.
diff --git a/doc/administration/package_information/postgresql_versions.md b/doc/administration/package_information/postgresql_versions.md
new file mode 100644
index 00000000000..89da4864872
--- /dev/null
+++ b/doc/administration/package_information/postgresql_versions.md
@@ -0,0 +1,42 @@
+---
+stage: Enablement
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# PostgreSQL versions shipped with Omnibus GitLab
+
+NOTE:
+This table lists only GitLab versions where a significant change happened in the
+package regarding PostgreSQL versions, not all.
+
+Usually, PostgreSQL versions change with major or minor GitLab releases. However, patch versions
+of Omnibus GitLab sometimes update the patch level of PostgreSQL.
+
+For example:
+
+- Omnibus 12.7.6 shipped with PostgreSQL 9.6.14 and 10.9.
+- Omnibus 12.7.7 shipped with PostgreSQL 9.6.17 and 10.12.
+
+[Find out which versions of PostgreSQL (and other components) ship with
+each Omnibus GitLab release](https://gitlab-org.gitlab.io/omnibus-gitlab/licenses.html).
+
+Read more about update policies and warnings in the PostgreSQL
+[upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
+
+| GitLab version | PostgreSQL versions | Default version for fresh installs | Default version for upgrades | Notes |
+| -------------- | --------------------- | ---------------------------------- | ---------------------------- | ----- |
+| 14.1 | 12.6, 13.3 | 12.6 | 12.6 | PostgreSQL 13 available for fresh installations if not using Geo or High Availability. |
+| 14.0 | 12.6 | 12.6 | 12.6 | HA installations with repmgr are no longer supported and will be prevented from upgrading to Omnibus GitLab 14.0 |
+| 13.8 | 11.9, 12.4 | 12.4 | 12.4 | Package upgrades automatically performed PostgreSQL upgrade for nodes that are not part of a Geo or HA cluster.). |
+| 13.7 | 11.9, 12.4 | 12.4 | 11.9 | For upgrades users can manually upgrade to 12.4 following the [upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-133-and-later). |
+| 13.4 | 11.9, 12.4 | 11.9 | 11.9 | Package upgrades aborted if users not running PostgreSQL 11 already |
+| 13.3 | 11.7, 12.3 | 11.7 | 11.7 | Package upgrades aborted if users not running PostgreSQL 11 already |
+| 13.0 | 11.7 | 11.7 | 11.7 | Package upgrades aborted if users not running PostgreSQL 11 already |
+| 12.10 | 9.6.17, 10.12, and 11.7 | 11.7 | 11.7 | Package upgrades automatically performed PostgreSQL upgrade for nodes that are not part of a Geo or repmgr cluster. |
+| 12.8 | 9.6.17, 10.12, and 11.7 | 10.12 | 10.12 | Users can manually upgrade to 11.7 following the upgrade docs. |
+| 12.0 | 9.6.11 and 10.7 | 10.7 | 10.7 | Package upgrades automatically performed PostgreSQL upgrade. |
+| 11.11 | 9.6.11 and 10.7 | 9.6.11 | 9.6.11 | Users can manually upgrade to 10.7 following the upgrade docs. |
+| 10.0 | 9.6.3 | 9.6.3 | 9.6.3 | Package upgrades aborted if users still on 9.2. |
+| 9.0 | 9.2.18 and 9.6.1 | 9.6.1 | 9.6.1 | Package upgrades automatically performed PostgreSQL upgrade. |
+| 8.14 | 9.2.18 and 9.6.1 | 9.2.18 | 9.2.18 | Users can manually upgrade to 9.6 following the upgrade docs. |
diff --git a/doc/administration/package_information/signed_packages.md b/doc/administration/package_information/signed_packages.md
new file mode 100644
index 00000000000..fb994809460
--- /dev/null
+++ b/doc/administration/package_information/signed_packages.md
@@ -0,0 +1,25 @@
+---
+stage: Enablement
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
+# Package Signatures
+
+As of the release of GitLab 9.5 on August 22, 2017, GitLab provides signed Omnibus GitLab packages for RPM and DEB based distributions. This means that all packages provided on <https://packages.gitlab.com> are signed, starting with `9.5.0`, and all future versions of supported branches (e.g. `9.3.x` and `9.4.x` after August 22, 2017). Any package version prior to August 22, 2017, will not be signed. Please pass the appropriate argument to your package manager. (Example: `yum --nogpgcheck`)
+
+Omnibus GitLab packages produced by GitLab are created via the [Omnibus](https://github.com/chef/omnibus) tool, for which GitLab has added DEB signing via `debsigs` in [our own fork](https://gitlab.com/gitlab-org/omnibus). This addition, combined with the existing functionality of RPM signing, allows GitLab to provide signed packages for all supported distributions using DEB or RPM.
+
+These packages are produced by the GitLab CI process, as found in the [Omnibus GitLab project](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/.gitlab-ci.yml), prior to their delivery to <https://packages.gitlab.com> to ensure provide assurance that the packages are not altered prior to delivery to our community.
+
+## GnuPG Public Keys
+
+All packages are signed with [GnuPG](https://www.gnupg.org/), in a method appropriate for their format. The key used to sign these packages can be found on [pgp.mit.edu](https://pgp.mit.edu) at [0x3cfcf9baf27eab47](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3CFCF9BAF27EAB47)
+
+## Verifying Signatures
+
+Information on how to verify GitLab package signatures can be found in [Package Signatures](https://docs.gitlab.com/omnibus/update/package_signatures.html).
+
+## GPG Signature Management
+
+Information on how GitLab manages GPG keys for package signing can be found in [the runbooks](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/packaging/manage-package-signing-keys.md).