diff options
Diffstat (limited to 'doc/administration')
| -rw-r--r-- | doc/administration/auth/authentiq.md | 5 | ||||
| -rw-r--r-- | doc/administration/auth/ldap-ee.md | 2 | ||||
| -rw-r--r-- | doc/administration/auth/ldap.md | 3 | ||||
| -rw-r--r-- | doc/administration/compliance.md | 2 | ||||
| -rw-r--r-- | doc/administration/geo/disaster_recovery/background_verification.md | 2 | ||||
| -rw-r--r-- | doc/administration/geo/disaster_recovery/planned_failover.md | 2 | ||||
| -rw-r--r-- | doc/administration/geo/replication/datatypes.md | 2 | ||||
| -rw-r--r-- | doc/administration/geo/replication/index.md | 5 | ||||
| -rw-r--r-- | doc/administration/git_annex.md | 6 | ||||
| -rw-r--r-- | doc/administration/incoming_email.md | 2 | ||||
| -rw-r--r-- | doc/administration/index.md | 5 | ||||
| -rw-r--r-- | doc/administration/monitoring/performance/grafana_configuration.md | 9 | ||||
| -rw-r--r-- | doc/administration/restart_gitlab.md | 10 |
13 files changed, 33 insertions, 22 deletions
diff --git a/doc/administration/auth/authentiq.md b/doc/administration/auth/authentiq.md index d15beb4f6fc..e9b32b64160 100644 --- a/doc/administration/auth/authentiq.md +++ b/doc/administration/auth/authentiq.md @@ -66,7 +66,10 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t On the sign in page there should now be an Authentiq icon below the regular sign in form. Click the icon to begin the authentication process. -- If the user has the Authentiq ID app installed in their iOS or Android device, they can scan the QR code, decide what personal details to share and sign in to your GitLab installation. +- If the user has the Authentiq ID app installed in their iOS or Android device, they can: + 1. Scan the QR code. + 1. Decide what personal details to share. + 1. Sign in to your GitLab installation. - If not they will be prompted to download the app and then follow the procedure above. If everything goes right, the user will be returned to GitLab and will be signed in. diff --git a/doc/administration/auth/ldap-ee.md b/doc/administration/auth/ldap-ee.md index 5217cd5114a..cbe24ca9e22 100644 --- a/doc/administration/auth/ldap-ee.md +++ b/doc/administration/auth/ldap-ee.md @@ -392,7 +392,7 @@ Group sync was written to be as performant as possible. Data is cached, database queries are optimized, and LDAP queries are minimized. The last benchmark run revealed the following metrics: -For 20,000 LDAP users, 11,000 LDAP groups and 1,000 GitLab groups with 10 +For 20000 LDAP users, 11000 LDAP groups and 1000 GitLab groups with 10 LDAP group links each: - Initial sync (no existing members assigned in GitLab) took 1.8 hours diff --git a/doc/administration/auth/ldap.md b/doc/administration/auth/ldap.md index 339710624fa..db7c11ada10 100644 --- a/doc/administration/auth/ldap.md +++ b/doc/administration/auth/ldap.md @@ -461,7 +461,8 @@ LDAP email address, and then sign into GitLab via their LDAP credentials. ## Enabling LDAP username lowercase -Some LDAP servers, depending on their configurations, can return uppercase usernames. This can lead to several confusing issues like, for example, creating links or namespaces with uppercase names. +Some LDAP servers, depending on their configurations, can return uppercase usernames. +This can lead to several confusing issues such as creating links or namespaces with uppercase names. GitLab can automatically lowercase usernames provided by the LDAP server by enabling the configuration option `lowercase_usernames`. By default, this configuration option is `false`. diff --git a/doc/administration/compliance.md b/doc/administration/compliance.md index 44e1cc8059a..447b69e14b4 100644 --- a/doc/administration/compliance.md +++ b/doc/administration/compliance.md @@ -14,6 +14,6 @@ GitLab’s [security features](../security/README.md) may also help you meet rel |**[Lock project membership to group](../user/group/index.md#member-lock-starter)**<br>Group owners can prevent new members from being added to projects within a group.|Starter+|✓| |**[LDAP group sync](auth/ldap-ee.md#group-sync)**<br>GitLab Enterprise Edition gives admins the ability to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.|Starter+|| |**[LDAP group sync filters](auth/ldap-ee.md#group-sync)**<br>GitLab Enterprise Edition Premium gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.|Premium+|| -|**[Audit logs](audit_events.md)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives admins the ability to view any modifications made within the GitLab server in an advanced audit log system, so you can control, analyze and track every change.|Premium+|| +|**[Audit logs](audit_events.md)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives admins the ability to view any modifications made within the GitLab server in an advanced audit log system, so you can control, analyze, and track every change.|Premium+|| |**[Auditor users](auditor_users.md)**<br>Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance.|Premium+|| |**[Credentials inventory](../user/admin_area/credentials_inventory.md)**<br>With a credentials inventory, GitLab administrators can keep track of the credentials used by all of the users in their GitLab instance. |Ultimate|| diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md index c042e3e9872..322b3b3fe4d 100644 --- a/doc/administration/geo/disaster_recovery/background_verification.md +++ b/doc/administration/geo/disaster_recovery/background_verification.md @@ -176,7 +176,7 @@ progress to include them in [ee-1430]. For now, you can verify their integrity manually by following [these instructions][foreground-verification] on both nodes, and comparing the output between them. -In GitLab EE 12.1, Geo calculates checksums for attachments, LFS objects and +In GitLab EE 12.1, Geo calculates checksums for attachments, LFS objects, and archived traces on secondary nodes after the transfer, compares it with the stored checksums, and rejects transfers if mismatched. Please note that Geo currently does not support an automatic way to verify these data if they have diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md index cd3d5a88de7..25050e4b13e 100644 --- a/doc/administration/geo/disaster_recovery/planned_failover.md +++ b/doc/administration/geo/disaster_recovery/planned_failover.md @@ -187,7 +187,7 @@ access to the **primary** node during the maintenance window. 1. On the **secondary** node, navigate to **Admin Area > Monitoring > Background Jobs > Queues** and wait for all the `geo` queues to drop to 0 queued and 0 running jobs. 1. On the **secondary** node, use [these instructions][foreground-verification] - to verify the integrity of CI artifacts, LFS objects and uploads in file + to verify the integrity of CI artifacts, LFS objects, and uploads in file storage. At this point, your **secondary** node will contain an up-to-date copy of everything the diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md index 75ce7503c34..6b1b3131a96 100644 --- a/doc/administration/geo/replication/datatypes.md +++ b/doc/administration/geo/replication/datatypes.md @@ -13,7 +13,7 @@ We currently distinguish between three different data types: - [Blobs](#blobs) - [Database](#database) -See the list below of each feature or component we replicate, its corresponding data type, replication and +See the list below of each feature or component we replicate, its corresponding data type, replication, and verification methods: | Type | Feature / component | Replication method | Verification method | diff --git a/doc/administration/geo/replication/index.md b/doc/administration/geo/replication/index.md index 4eaf6a88575..ccc8b9ecd2d 100644 --- a/doc/administration/geo/replication/index.md +++ b/doc/administration/geo/replication/index.md @@ -12,7 +12,8 @@ Replication with Geo is the solution for widely distributed development teams. Fetching large repositories can take a long time for teams located far from a single GitLab instance. -Geo provides local, read-only instances of your GitLab instances, reducing the time it takes to clone and fetch large repositories and speeding up development. +Geo provides local, read-only instances of your GitLab instances. This can reduce the time it takes +to clone and fetch large repositories, speeding up development. NOTE: **Note:** Check the [requirements](#requirements-for-running-geo) carefully before setting up Geo. @@ -269,7 +270,7 @@ For answers to common questions, see the [Geo FAQ](faq.md). Since GitLab 9.5, Geo stores structured log messages in a `geo.log` file. For Omnibus installations, this file is at `/var/log/gitlab/gitlab-rails/geo.log`. -This file contains information about when Geo attempts to sync repositories and files. Each line in the file contains a separate JSON entry that can be ingested into Elasticsearch, Splunk, etc. +This file contains information about when Geo attempts to sync repositories and files. Each line in the file contains a separate JSON entry that can be ingested into, for example, Elasticsearch or Splunk. For example: diff --git a/doc/administration/git_annex.md b/doc/administration/git_annex.md index 87e1d3b1e8e..49a22dc6a52 100644 --- a/doc/administration/git_annex.md +++ b/doc/administration/git_annex.md @@ -18,7 +18,7 @@ you can. Not being able to version control large binaries is a big problem for many larger organizations. -Videos, photos, audio, compiled binaries and many other types of files are too +Videos, photos, audio, compiled binaries, and many other types of files are too large. As a workaround, people keep artwork-in-progress in a Dropbox folder and only check in the final result. This results in using outdated files, not having a complete history and increases the risk of losing work. @@ -41,13 +41,13 @@ configuration options required to enable it. `git-annex` needs to be installed both on the server and the client side. -For Debian-like systems (e.g., Debian, Ubuntu) this can be achieved by running: +For Debian-like systems (for example, Debian and Ubuntu) this can be achieved by running: ``` sudo apt-get update && sudo apt-get install git-annex ``` -For RedHat-like systems (e.g., CentOS, RHEL) this can be achieved by running: +For RedHat-like systems (for example, CentOS and RHEL) this can be achieved by running: ``` sudo yum install epel-release && sudo yum install git-annex diff --git a/doc/administration/incoming_email.md b/doc/administration/incoming_email.md index 07b6f79a0fa..6a0249d85d8 100644 --- a/doc/administration/incoming_email.md +++ b/doc/administration/incoming_email.md @@ -81,7 +81,7 @@ incoming email domain to `hooli.com`, an attacker could abuse the "Create new issue by email" or "[Create new merge request by email](../user/project/merge_requests/creating_merge_requests.md#new-merge-request-by-email-core-only)" features by using a project's unique address as the email when signing up for -Slack, which would send a confirmation email, which would create a new issue or +Slack. This would send a confirmation email, which would create a new issue or merge request on the project owned by the attacker, allowing them to click the confirmation link and validate their account on your company's private Slack instance. diff --git a/doc/administration/index.md b/doc/administration/index.md index fcfdcfdf6c8..0028f7d8a1d 100644 --- a/doc/administration/index.md +++ b/doc/administration/index.md @@ -76,7 +76,7 @@ Learn how to install, configure, update, and maintain your GitLab instance. ### Maintaining GitLab -- [Raketasks](../raketasks/README.md): Perform various tasks for maintenance, backups, automatic webhooks setup, etc. +- [Raketasks](../raketasks/README.md): Perform various tasks for maintenance, backups, automatic webhooks setup, and more. - [Backup and restore](../raketasks/backup_restore.md): Backup and restore your GitLab instance. - [Operations](operations/index.md): Keeping GitLab up and running (clean up Redis sessions, moving repositories, Sidekiq MemoryKiller, Unicorn). - [Restart GitLab](restart_gitlab.md): Learn how to restart GitLab and its components. @@ -107,7 +107,7 @@ Learn how to install, configure, update, and maintain your GitLab instance. - [Libravatar](libravatar.md): Use Libravatar instead of Gravatar for user avatars. - [Sign-up restrictions](../user/admin_area/settings/sign_up_restrictions.md): block email addresses of specific domains, or whitelist only specific domains. - [Access restrictions](../user/admin_area/settings/visibility_and_access_controls.md#enabled-git-access-protocols): Define which Git access protocols can be used to talk to GitLab (SSH, HTTP, HTTPS). -- [Authentication and Authorization](auth/README.md): Configure external authentication with LDAP, SAML, CAS and additional providers. +- [Authentication and Authorization](auth/README.md): Configure external authentication with LDAP, SAML, CAS, and additional providers. - [Sync LDAP](auth/ldap-ee.md) **(STARTER ONLY)** - [Kerberos authentication](../integration/kerberos.md) **(STARTER ONLY)** - See also other [authentication](../topics/authentication/index.md#gitlab-administrators) topics (for example, enforcing 2FA). @@ -230,4 +230,3 @@ who are aware of the risks. - [Strace zine](https://wizardzines.com/zines/strace/) - GitLab.com-specific resources: - [Group SAML/SCIM setup](troubleshooting/group_saml_scim.md) -
\ No newline at end of file diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md index 2fdeeae302b..12b69d10179 100644 --- a/doc/administration/monitoring/performance/grafana_configuration.md +++ b/doc/administration/monitoring/performance/grafana_configuration.md @@ -148,7 +148,14 @@ However, you should **not** reinstate your old data _except_ under one of the fo 1. If you are certain that you changed your default admin password when you enabled Grafana 1. If you run GitLab in a private network, accessed only by trusted users, and your Grafana login page has not been exposed to the internet -If you require access to your old Grafana data but do not meet one of these criteria, you may consider reinstating it temporarily, [exporting the dashboards](https://grafana.com/docs/reference/export_import/#exporting-a-dashboard) you need, then refreshing the data and [re-importing your dashboards](https://grafana.com/docs/reference/export_import/#importing-a-dashboard). Note that this poses a temporary vulnerability while your old Grafana data is in use, and the decision to do so should be weighed carefully with your need to access existing data and dashboards. +If you require access to your old Grafana data but do not meet one of these criteria, you may consider: + +1. Reinstating it temporarily. +1. [Exporting the dashboards](https://grafana.com/docs/reference/export_import/#exporting-a-dashboard) you need. +1. Refreshing the data and [re-importing your dashboards](https://grafana.com/docs/reference/export_import/#importing-a-dashboard). + +DANGER: **Danger:** +This poses a temporary vulnerability while your old Grafana data is in use and the decision to do so should be weighed carefully with your need to access existing data and dashboards. For more information and further mitigation details, please refer to our [blog post on the security release](https://about.gitlab.com/blog/2019/08/12/critical-security-release-gitlab-12-dot-1-dot-6-released/). diff --git a/doc/administration/restart_gitlab.md b/doc/administration/restart_gitlab.md index bd3a52d487a..176ff5c1b1b 100644 --- a/doc/administration/restart_gitlab.md +++ b/doc/administration/restart_gitlab.md @@ -87,8 +87,8 @@ Reconfiguring GitLab should occur in the event that something in its configuration (`/etc/gitlab/gitlab.rb`) has changed. When you run this command, [Chef], the underlying configuration management -application that powers Omnibus GitLab, will make sure that all directories, -permissions, services, etc., are in place and in the same shape that they were +application that powers Omnibus GitLab, will make sure that all things like directories, +permissions, and services are in place and in the same shape that they were initially shipped. It will also restart GitLab components where needed, if any of their @@ -128,7 +128,7 @@ The GitLab MailRoom email processor with pid 28114 is running. GitLab and all its components are up and running. ``` -This should restart Unicorn, Sidekiq, GitLab Workhorse and [Mailroom][] +This should restart Unicorn, Sidekiq, GitLab Workhorse, and [Mailroom][] (if enabled). The init service file that does all the magic can be found on your server in `/etc/init.d/gitlab`. @@ -149,8 +149,8 @@ If you are using other init systems, like systemd, you can check the There is no single command to restart the entire GitLab application installed via the [cloud native Helm Chart](https://docs.gitlab.com/charts/). Usually, it should be -enough to restart a specific component separately (`gitaly`, `unicorn`, -`workhorse`, `gitlab-shell`, etc.) by deleting all the pods related to it: +enough to restart a specific component separately (for example, `gitaly`, `unicorn`, +`workhorse`, or `gitlab-shell`) by deleting all the pods related to it: ```shell kubectl delete pods -l release=<helm release name>,app=<component name> |