diff options
Diffstat (limited to 'doc/administration')
| -rw-r--r-- | doc/administration/auth/smartcard.md | 5 | ||||
| -rw-r--r-- | doc/administration/geo/replication/object_storage.md | 18 | ||||
| -rw-r--r-- | doc/administration/geo/replication/security_review.md | 68 | ||||
| -rw-r--r-- | doc/administration/housekeeping.md | 11 | ||||
| -rw-r--r-- | doc/administration/reference_architectures/troubleshooting.md | 2 | ||||
| -rw-r--r-- | doc/administration/whats-new.md | 18 |
6 files changed, 71 insertions, 51 deletions
diff --git a/doc/administration/auth/smartcard.md b/doc/administration/auth/smartcard.md index 4fe69d0160e..07c29984552 100644 --- a/doc/administration/auth/smartcard.md +++ b/doc/administration/auth/smartcard.md @@ -108,6 +108,11 @@ attribute. As a prerequisite, you must use an LDAP server that: - Supports the `certificateExactMatch` matching rule. - Has the certificate stored in the `userCertificate` attribute. +NOTE: +Active Directory doesn't support the `certificateExactMatch` matching rule so +[it is not supported at this time](https://gitlab.com/gitlab-org/gitlab/-/issues/327491). For +more information, see [the relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328074). + ## Configure GitLab for smartcard authentication **For Omnibus installations** diff --git a/doc/administration/geo/replication/object_storage.md b/doc/administration/geo/replication/object_storage.md index ad419f999b3..7dd831092a3 100644 --- a/doc/administration/geo/replication/object_storage.md +++ b/doc/administration/geo/replication/object_storage.md @@ -9,9 +9,9 @@ type: howto Geo can be used in combination with Object Storage (AWS S3, or other compatible object storage). -Currently, **secondary** nodes can use either: +Currently, **secondary** sites can use either: -- The same storage bucket as the **primary** node. +- The same storage bucket as the **primary** site. - A replicated storage bucket. To have: @@ -28,13 +28,13 @@ To have: WARNING: This is a [**beta** feature](https://about.gitlab.com/handbook/product/#beta) and is not ready yet for production use at any scale. The main limitations are a lack of testing at scale and no verification of any replicated data. -**Secondary** nodes can replicate files stored on the **primary** node regardless of +**Secondary** sites can replicate files stored on the **primary** site regardless of whether they are stored on the local file system or in object storage. To enable GitLab replication, you must: 1. Go to **Admin Area > Geo**. -1. Press **Edit** on the **secondary** node. +1. Press **Edit** on the **secondary** site. 1. In the **Synchronization Settings** section, find the **Allow this secondary node to replicate content on Object Storage** checkbox to enable it. @@ -46,7 +46,7 @@ For CI job artifacts, there is similar documentation to configure For user uploads, there is similar documentation to configure [upload object storage](../../uploads.md#using-object-storage) -If you want to migrate the **primary** node's files to object storage, you can +If you want to migrate the **primary** site's files to object storage, you can configure the **secondary** in a few ways: - Use the exact same object storage. @@ -57,15 +57,15 @@ configure the **secondary** in a few ways: GitLab does not currently support the case where both: -- The **primary** node uses local storage. -- A **secondary** node uses object storage. +- The **primary** site uses local storage. +- A **secondary** site uses object storage. ## Third-party replication services When using Amazon S3, you can use [CRR](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) to -have automatic replication between the bucket used by the **primary** node and -the bucket used by **secondary** nodes. +have automatic replication between the bucket used by the **primary** site and +the bucket used by **secondary** sites. If you are using Google Cloud Storage, consider using [Multi-Regional Storage](https://cloud.google.com/storage/docs/storage-classes#multi-regional). diff --git a/doc/administration/geo/replication/security_review.md b/doc/administration/geo/replication/security_review.md index abb84b95623..f84d7a2171d 100644 --- a/doc/administration/geo/replication/security_review.md +++ b/doc/administration/geo/replication/security_review.md @@ -36,7 +36,7 @@ from [owasp.org](https://owasp.org/). - The GitLab model of sensitivity is centered around public vs. internal vs. private projects. Geo replicates them all indiscriminately. "Selective sync" exists for files and repositories (but not database content), which would permit - only less-sensitive projects to be replicated to a **secondary** node if desired. + only less-sensitive projects to be replicated to a **secondary** site if desired. - See also: [GitLab data classification policy](https://about.gitlab.com/handbook/engineering/security/data-classification-standard.html). ### What data backup and retention requirements have been defined for the application? @@ -48,18 +48,18 @@ from [owasp.org](https://owasp.org/). ### Who are the application's end‐users? -- **Secondary** nodes are created in regions that are distant (in terms of - Internet latency) from the main GitLab installation (the **primary** node). They are - intended to be used by anyone who would ordinarily use the **primary** node, who finds - that the **secondary** node is closer to them (in terms of Internet latency). +- **Secondary** sites are created in regions that are distant (in terms of + Internet latency) from the main GitLab installation (the **primary** site). They are + intended to be used by anyone who would ordinarily use the **primary** site, who finds + that the **secondary** site is closer to them (in terms of Internet latency). ### How do the end‐users interact with the application? -- **Secondary** nodes provide all the interfaces a **primary** node does +- **Secondary** sites provide all the interfaces a **primary** site does (notably a HTTP/HTTPS web application, and HTTP/HTTPS or SSH Git repository access), but is constrained to read-only activities. The principal use case is - envisioned to be cloning Git repositories from the **secondary** node in favor of the - **primary** node, but end-users may use the GitLab web interface to view projects, + envisioned to be cloning Git repositories from the **secondary** site in favor of the + **primary** site, but end-users may use the GitLab web interface to view projects, issues, merge requests, snippets, etc. ### What security expectations do the end‐users have? @@ -67,10 +67,10 @@ from [owasp.org](https://owasp.org/). - The replication process must be secure. It would typically be unacceptable to transmit the entire database contents or all files and repositories across the public Internet in plaintext, for instance. -- **Secondary** nodes must have the same access controls over its content as the - **primary** node - unauthenticated users must not be able to gain access to privileged - information on the **primary** node by querying the **secondary** node. -- Attackers must not be able to impersonate the **secondary** node to the **primary** node, and +- **Secondary** sites must have the same access controls over its content as the + **primary** site - unauthenticated users must not be able to gain access to privileged + information on the **primary** site by querying the **secondary** site. +- Attackers must not be able to impersonate the **secondary** site to the **primary** site, and thus gain access to privileged information. ## Administrators @@ -86,7 +86,7 @@ from [owasp.org](https://owasp.org/). ### What administrative capabilities does the application offer? -- **Secondary** nodes may be added, modified, or removed by users with +- **Secondary** sites may be added, modified, or removed by users with administrative access. - The replication process may be controlled (start/stop) via the Sidekiq administrative controls. @@ -95,9 +95,9 @@ from [owasp.org](https://owasp.org/). ### What details regarding routing, switching, firewalling, and load‐balancing have been defined? -- Geo requires the **primary** node and **secondary** node to be able to communicate with each - other across a TCP/IP network. In particular, the **secondary** nodes must be able to - access HTTP/HTTPS and PostgreSQL services on the **primary** node. +- Geo requires the **primary** site and **secondary** site to be able to communicate with each + other across a TCP/IP network. In particular, the **secondary** sites must be able to + access HTTP/HTTPS and PostgreSQL services on the **primary** site. ### What core network devices support the application? @@ -105,9 +105,9 @@ from [owasp.org](https://owasp.org/). ### What network performance requirements exist? -- Maximum replication speeds between **primary** node and **secondary** node is limited by the +- Maximum replication speeds between **primary** site and **secondary** site is limited by the available bandwidth between sites. No hard requirements exist - time to complete - replication (and ability to keep up with changes on the **primary** node) is a function + replication (and ability to keep up with changes on the **primary** site) is a function of the size of the data set, tolerance for latency, and available network capacity. @@ -189,9 +189,9 @@ from [owasp.org](https://owasp.org/). ### How will database connection strings, encryption keys, and other sensitive components be stored, accessed, and protected from unauthorized detection? - There are some Geo-specific values. Some are shared secrets which must be - securely transmitted from the **primary** node to the **secondary** node at setup time. Our - documentation recommends transmitting them from the **primary** node to the system - administrator via SSH, and then back out to the **secondary** node in the same manner. + securely transmitted from the **primary** site to the **secondary** site at setup time. Our + documentation recommends transmitting them from the **primary** site to the system + administrator via SSH, and then back out to the **secondary** site in the same manner. In particular, this includes the PostgreSQL replication credentials and a secret key (`db_key_base`) which is used to decrypt certain columns in the database. The `db_key_base` secret is stored unencrypted on the file system, in @@ -205,25 +205,25 @@ from [owasp.org](https://owasp.org/). - Data is entered via the web application exposed by GitLab itself. Some data is also entered using system administration commands on the GitLab servers (e.g., `gitlab-ctl set-primary-node`). -- **Secondary** nodes also receive inputs via PostgreSQL streaming replication from the **primary** node. +- **Secondary** sites also receive inputs via PostgreSQL streaming replication from the **primary** site. ### What data output paths does the application support? -- **Primary** nodes output via PostgreSQL streaming replication to the **secondary** node. +- **Primary** sites output via PostgreSQL streaming replication to the **secondary** site. Otherwise, principally via the web application exposed by GitLab itself, and via SSH `git clone` operations initiated by the end-user. ### How does data flow across the application's internal components? -- **Secondary** nodes and **primary** nodes interact via HTTP/HTTPS (secured with JSON web +- **Secondary** sites and **primary** sites interact via HTTP/HTTPS (secured with JSON web tokens) and via PostgreSQL streaming replication. -- Within a **primary** node or **secondary** node, the SSOT is the file system and the database - (including Geo tracking database on **secondary** node). The various internal components +- Within a **primary** site or **secondary** site, the SSOT is the file system and the database + (including Geo tracking database on **secondary** site). The various internal components are orchestrated to make alterations to these stores. ### What data input validation requirements have been defined? -- **Secondary** nodes must have a faithful replication of the **primary** node's data. +- **Secondary** sites must have a faithful replication of the **primary** site's data. ### What data does the application store and how? @@ -231,11 +231,11 @@ from [owasp.org](https://owasp.org/). ### What data is or may need to be encrypted and what key management requirements have been defined? -- Neither **primary** nodes or **secondary** nodes encrypt Git repository or file system data at +- Neither **primary** sites or **secondary** sites encrypt Git repository or file system data at rest. A subset of database columns are encrypted at rest using the `db_otp_key`. - A static secret shared across all hosts in a GitLab deployment. - In transit, data should be encrypted, although the application does permit - communication to proceed unencrypted. The two main transits are the **secondary** node's + communication to proceed unencrypted. The two main transits are the **secondary** site's replication process for PostgreSQL, and for Git repositories/files. Both should be protected using TLS, with the keys for that managed via Omnibus per existing configuration for end-user access to GitLab. @@ -253,19 +253,19 @@ from [owasp.org](https://owasp.org/). ### What user privilege levels does the application support? -- Geo adds one type of privilege: **secondary** nodes can access a special Geo API to +- Geo adds one type of privilege: **secondary** sites can access a special Geo API to download files over HTTP/HTTPS, and to clone repositories using HTTP/HTTPS. ### What user identification and authentication requirements have been defined? -- **Secondary** nodes identify to Geo **primary** nodes via OAuth or JWT authentication +- **Secondary** sites identify to Geo **primary** sites via OAuth or JWT authentication based on the shared database (HTTP access) or a PostgreSQL replication user (for database replication). The database replication also requires IP-based access controls to be defined. ### What user authorization requirements have been defined? -- **Secondary** nodes must only be able to *read* data. They are not currently able to mutate data on the **primary** node. +- **Secondary** sites must only be able to *read* data. They are not currently able to mutate data on the **primary** site. ### What session management requirements have been defined? @@ -279,9 +279,9 @@ from [owasp.org](https://owasp.org/). ### What access requirements have been defined for URI and Service calls? -- **Secondary** nodes make many calls to the **primary** node's API. This is how file +- **Secondary** sites make many calls to the **primary** site's API. This is how file replication proceeds, for instance. This endpoint is only accessible with a JWT token. -- The **primary** node also makes calls to the **secondary** node to get status information. +- The **primary** site also makes calls to the **secondary** site to get status information. ## Application Monitoring diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md index 0e24ab40157..82891e68a0f 100644 --- a/doc/administration/housekeeping.md +++ b/doc/administration/housekeeping.md @@ -4,9 +4,10 @@ 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/#assignments --- -# Housekeeping +# Housekeeping **(FREE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/3041) in GitLab 8.4. +GitLab supports and automates housekeeping tasks within your current repository, +such as compressing file revisions and removing unreachable objects. ## Automatic housekeeping @@ -37,9 +38,11 @@ the `pushes_since_gc` value is 200 a `git gc` runs. Housekeeping also [removes unreferenced LFS files](../raketasks/cleanup.md#remove-unreferenced-lfs-files) from your project on the same schedule as the `git gc` operation, freeing up storage space for your project. -You can find this option under your project's **Settings > General > Advanced**. +To manually start the housekeeping process: - +1. In your project, go to **Settings > General**. +1. Expand the **Advanced** section. +1. Select **Run housekeeping**. ## How housekeeping handles pool repositories diff --git a/doc/administration/reference_architectures/troubleshooting.md b/doc/administration/reference_architectures/troubleshooting.md index e5d65264a5c..d5f57965a80 100644 --- a/doc/administration/reference_architectures/troubleshooting.md +++ b/doc/administration/reference_architectures/troubleshooting.md @@ -4,7 +4,7 @@ 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/#assignments --- -# Troubleshooting a reference architecture setup +# Troubleshooting a reference architecture setup **(FREE SELF)** This page serves as the troubleshooting documentation if you followed one of the [reference architectures](index.md#reference-architectures). diff --git a/doc/administration/whats-new.md b/doc/administration/whats-new.md index 4cbb0b854ae..a5e3a232890 100644 --- a/doc/administration/whats-new.md +++ b/doc/administration/whats-new.md @@ -19,11 +19,23 @@ feature list, the feature list is tailored to your subscription type: - Features only available to self-managed installations are not shown on GitLab.com. - Features only available on GitLab.com are not shown to self-managed installations. -The **What's new** feature cannot be disabled, but -[is planned](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59011) for a future release. - ## Self-managed installations Due to our release post process, the content for **What's new** is not yet finalized when a new version (`.0` release) is cut. The updated **What's new** is included in the first patch release, such as `13.10.1`. + +## Configure What's new variant + +You can configure the What's new variant: + +1. Navigate to **Admin Area > Settings > Preferences**, then expand **What's new**. +1. Choose one of the following options: + + | Option | Description | + | ------ | ----------- | + | Enable What's new: All tiers | What's new presents new features from all tiers to help you keep track of all new features. | + | Enable What's new: Current tier only | What's new presents new features for your current subscription tier, while hiding new features not available to your subscription tier. | + | Disable What's new | What's new is disabled and can no longer be viewed. | + +1. Save your changes. |