diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-10-20 08:43:02 +0000 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-10-20 08:43:02 +0000 |
commit | d9ab72d6080f594d0b3cae15f14b3ef2c6c638cb (patch) | |
tree | 2341ef426af70ad1e289c38036737e04b0aa5007 /doc/administration/troubleshooting | |
parent | d6e514dd13db8947884cd58fe2a9c2a063400a9b (diff) | |
download | gitlab-ce-d9ab72d6080f594d0b3cae15f14b3ef2c6c638cb.tar.gz |
Add latest changes from gitlab-org/gitlab@14-4-stable-eev14.4.0-rc42
Diffstat (limited to 'doc/administration/troubleshooting')
-rw-r--r-- | doc/administration/troubleshooting/debug.md | 2 | ||||
-rw-r--r-- | doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md | 74 | ||||
-rw-r--r-- | doc/administration/troubleshooting/img/database-query-dialog_v14_3.png | bin | 0 -> 72494 bytes | |||
-rw-r--r-- | doc/administration/troubleshooting/img/obtaining-a-session-cookie-for-request_v14_3.png | bin | 0 -> 113452 bytes | |||
-rw-r--r-- | doc/administration/troubleshooting/img/paste-request-id-into-progress-bar_v14_3.png | bin | 0 -> 6495 bytes | |||
-rw-r--r-- | doc/administration/troubleshooting/img/select-request-id-from-request-selector-drop-down-menu_v14_3.png | bin | 0 -> 30026 bytes | |||
-rw-r--r-- | doc/administration/troubleshooting/img/view-pg-details_v14_3.png | bin | 0 -> 6656 bytes | |||
-rw-r--r-- | doc/administration/troubleshooting/linux_cheat_sheet.md | 2 | ||||
-rw-r--r-- | doc/administration/troubleshooting/ssl.md | 4 | ||||
-rw-r--r-- | doc/administration/troubleshooting/tracing_correlation_id.md | 66 |
10 files changed, 113 insertions, 35 deletions
diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md index aea891b8a77..e00243aca0a 100644 --- a/doc/administration/troubleshooting/debug.md +++ b/doc/administration/troubleshooting/debug.md @@ -225,7 +225,7 @@ gitlab_rails['env'] = { ``` For source installations, set the environment variable. -Refer to [Puma Worker timeout](https://docs.gitlab.com/omnibus/settings/puma.html#worker-timeout). +Refer to [Puma Worker timeout](../operations/puma.md#worker-timeout). [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect. diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md index 491db37d9da..109f451be5a 100644 --- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md +++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md @@ -26,7 +26,7 @@ As GitLab changes, changes to the code are inevitable, and so some scripts may not work as they once used to. These are not kept up-to-date as these scripts/commands were added as they were found/needed. As mentioned above, we recommend running these scripts under the supervision of a -Support Engineer, who can also verify that they will continue to work as they +Support Engineer, who can also verify that they continue to work as they should and, if needed, update the script for the latest version of GitLab. ## Find specific methods for an object @@ -38,8 +38,6 @@ Array.methods.grep(/sing/) ## Find method source -Works for [non-instrumented methods](../../development/instrumentation.md#checking-instrumented-methods): - ```ruby instance_of_object.method(:foo).source_location @@ -187,7 +185,7 @@ Project.update_all(visibility_level: 0) ```ruby # -# This section will list all the projects which are pending deletion +# This section lists all the projects which are pending deletion # projects = Project.where(pending_delete: true) projects.each do |p| @@ -197,7 +195,7 @@ projects.each do |p| end # -# Assign a user (the root user will do) +# Assign a user (the root user does) # user = User.find_by_username('root') @@ -257,7 +255,7 @@ namespace = Namespace.find_by_full_path("<new_namespace>") ### For Removing webhooks that is getting timeout due to large webhook logs ```ruby -# ID will be the webhook_id +# ID is the webhook_id hook=WebHook.find(ID) WebHooks::DestroyService.new(current_user).execute(hook) @@ -399,7 +397,7 @@ projects = Project.find_by_sql("SELECT * FROM projects WHERE name LIKE '%ject'") ### Recreate WARNING: -This is a destructive operation, the Wiki will be empty. +This is a destructive operation, the Wiki becomes empty. A Projects Wiki can be recreated by this command: @@ -476,13 +474,13 @@ Projects::ImportExport::ExportService.new(project, user).execute If the project you wish to export is available at `https://gitlab.example.com/baltig/pipeline-templates`, the value to use for `PROJECT_PATH` would be `baltig/pipeline-templates`. -If this all runs successfully, you will see output like the following before being returned to the Rails console prompt: +If this all runs successfully, you see an output like the following before being returned to the Rails console prompt: ```ruby => nil ``` -The exported project will be located within a `.tar.gz` file in `/var/opt/gitlab/gitlab-rails/uploads/-/system/import_export_upload/export_file/`. +The exported project is located within a `.tar.gz` file in `/var/opt/gitlab/gitlab-rails/uploads/-/system/import_export_upload/export_file/`. ## Repository @@ -490,27 +488,29 @@ The exported project will be located within a `.tar.gz` file in `/var/opt/gitlab If it seems that a commit has gone "missing", search the sequence of pushes to a repository. [This StackOverflow article](https://stackoverflow.com/questions/13468027/the-mystery-of-the-missing-commit-across-merges) -describes how you can end up in this state without a force push. +describes how you can end up in this state without a force push. Another cause can be a misconfigured [server hook](../server_hooks.md) that changes a HEAD ref via a `git reset` operation. + +If you look at the output from the sample code below for the target branch, you +see a discontinuity in the from/to commits as you step through the output. The `commit_from` of each new push should equal the `commit_to` of the previous push. A break in that sequence indicates one or more commits have been "lost" from the repository history. -If you look at the output from the sample code below for the target branch, you will -see a discontinuity in the from/to commits as you step through the output. Each new -push should be "from" the "to" SHA of the previous push. When this discontinuity happens, -you will see two pushes with the same "from" SHA: +The following example checks the last 100 pushes and prints the `commit_from` and `commit_to` entries: ```ruby -p = Project.find_with_namespace('u/p') +p = Project.find_by_full_path('u/p') p.events.pushed_action.last(100).each do |e| - printf "%-20.20s %8s...%8s (%s)\n", e.data[:ref], e.data[:before], e.data[:after], e.author.try(:username) + printf "%-20.20s %8s...%8s (%s) +", e.push_event_payload[:ref], e.push_event_payload[:commit_from], e.push_event_payload[:commit_to], e.author.try(:username) end ``` -GitLab 9.5 and above: +Example output showing break in sequence at line 4: -```ruby -p = Project.find_by_full_path('u/p') -p.events.pushed_action.last(100).each do |e| - printf "%-20.20s %8s...%8s (%s)\n", e.push_event_payload[:ref], e.push_event_payload[:commit_from], e.push_event_payload[:commit_to], e.author.try(:username) -end +```plaintext +master f21b07713251e04575908149bdc8ac1f105aabc3...6bc56c1f46244792222f6c85b11606933af171de (root) +master 6bc56c1f46244792222f6c85b11606933af171de...132da6064f5d3453d445fd7cb452b148705bdc1b (root) +master 132da6064f5d3453d445fd7cb452b148705bdc1b...a62e1e693150a2e46ace0ce696cd4a52856dfa65 (root) +master 58b07b719a4b0039fec810efa52f479ba1b84756...f05321a5b5728bd8a89b7bf530aa44043c951dce (root) +master f05321a5b5728bd8a89b7bf530aa44043c951dce...7d02e575fd790e76a3284ee435368279a5eb3773 (root) ``` ## Mirrors @@ -558,7 +558,7 @@ end ```ruby u = User.new(username: 'test_user', email: 'test@example.com', name: 'Test User', password: 'password', password_confirmation: 'password') -u.skip_confirmation! # Use it only if you wish user to be automatically confirmed. If skipped, user will recieve confirmation e-mail +u.skip_confirmation! # Use it only if you wish user to be automatically confirmed. If skipped, user receives confirmation e-mail u.save! ``` @@ -612,7 +612,7 @@ identifier = Analytics::UsageTrends::Measurement.identifiers[:billable_users] ```ruby users = User.where('id NOT IN (select distinct(user_id) from project_authorizations)') -# How many users will be removed? +# How many users are removed? users.count # If that count looks sane: @@ -726,6 +726,18 @@ group.require_two_factor_authentication=false group.save ``` +## Authentication + +### Re-enable standard web sign-in form + +Re-enable the standard username and password-based sign-in form if it was disabled as a [Sign-in restriction](../../user/admin_area/settings/sign_in_restrictions.md#password-authentication-enabled). + +You can use this method when a configured external authentication provider (through SSO or an LDAP configuration) is facing an outage and direct sign-in access to GitLab is required. + +```ruby +Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: true) +``` + ## SCIM ### Fixing bad SCIM identities @@ -1061,7 +1073,7 @@ encrypted credentials to allow manual reentry: If `User OTP Secret Bad count:` is detected. For each user listed disable/enable two-factor authentication. -The following script will search in some of the tables for encrypted tokens that are +The following script searches in some of the tables for encrypted tokens that are causing decryption errors, and update or reset as needed: ```shell @@ -1123,7 +1135,7 @@ Geo::ProjectRegistry.sync_failed('repository') ### Resync repositories -#### Queue up all repositories for resync. Sidekiq will handle each sync +#### Queue up all repositories for resync. Sidekiq handles each sync ```ruby Geo::ProjectRegistry.update_all(resync_repository: true, resync_wiki: true) @@ -1170,10 +1182,10 @@ registry.replicator.send(:download) #### Verify package files on the secondary manually -This will iterate over all package files on the secondary, looking at the +This iterates over all package files on the secondary, looking at the `verification_checksum` stored in the database (which came from the primary) and then calculate this value on the secondary to check if they match. This -won't change anything in the UI: +does not change anything in the UI: ```ruby # Run on secondary @@ -1235,7 +1247,7 @@ Gitlab::UsageData.to_json ### Generate a fresh new Service Ping -This will also refresh the cached Service Ping displayed in the admin area +This also refreshes the cached Service Ping displayed in the Admin Area ```ruby Gitlab::UsageData.to_json(force_refresh: true) @@ -1269,7 +1281,7 @@ cluster = Clusters::Cluster.find_by(name: 'cluster_name') Delete cluster without associated resources: ```ruby -# Find an admin user +# Find users with the Administrator role user = User.find_by(username: 'admin_user') # Find the cluster with the ID @@ -1289,7 +1301,7 @@ Open the rails console (`gitlab rails c`) and run the following command to see a ApplicationSetting.last.attributes ``` -Among other attributes, in the output you will notice that all the settings available in the [Elasticsearch Integration page](../../integration/elasticsearch.md), like: `elasticsearch_indexing`, `elasticsearch_url`, `elasticsearch_replicas`, `elasticsearch_pause_indexing`, and so on. +Among other attributes, the output contains all the settings available in the [Elasticsearch Integration page](../../integration/elasticsearch.md), such as `elasticsearch_indexing`, `elasticsearch_url`, `elasticsearch_replicas`, and `elasticsearch_pause_indexing`. #### Setting attributes diff --git a/doc/administration/troubleshooting/img/database-query-dialog_v14_3.png b/doc/administration/troubleshooting/img/database-query-dialog_v14_3.png Binary files differnew file mode 100644 index 00000000000..197cfa17da2 --- /dev/null +++ b/doc/administration/troubleshooting/img/database-query-dialog_v14_3.png diff --git a/doc/administration/troubleshooting/img/obtaining-a-session-cookie-for-request_v14_3.png b/doc/administration/troubleshooting/img/obtaining-a-session-cookie-for-request_v14_3.png Binary files differnew file mode 100644 index 00000000000..a63ebf9ecf2 --- /dev/null +++ b/doc/administration/troubleshooting/img/obtaining-a-session-cookie-for-request_v14_3.png diff --git a/doc/administration/troubleshooting/img/paste-request-id-into-progress-bar_v14_3.png b/doc/administration/troubleshooting/img/paste-request-id-into-progress-bar_v14_3.png Binary files differnew file mode 100644 index 00000000000..a19585d7a89 --- /dev/null +++ b/doc/administration/troubleshooting/img/paste-request-id-into-progress-bar_v14_3.png diff --git a/doc/administration/troubleshooting/img/select-request-id-from-request-selector-drop-down-menu_v14_3.png b/doc/administration/troubleshooting/img/select-request-id-from-request-selector-drop-down-menu_v14_3.png Binary files differnew file mode 100644 index 00000000000..b8314056c9b --- /dev/null +++ b/doc/administration/troubleshooting/img/select-request-id-from-request-selector-drop-down-menu_v14_3.png diff --git a/doc/administration/troubleshooting/img/view-pg-details_v14_3.png b/doc/administration/troubleshooting/img/view-pg-details_v14_3.png Binary files differnew file mode 100644 index 00000000000..1fe12462e4e --- /dev/null +++ b/doc/administration/troubleshooting/img/view-pg-details_v14_3.png diff --git a/doc/administration/troubleshooting/linux_cheat_sheet.md b/doc/administration/troubleshooting/linux_cheat_sheet.md index 9eadbad171e..b66e88a8d60 100644 --- a/doc/administration/troubleshooting/linux_cheat_sheet.md +++ b/doc/administration/troubleshooting/linux_cheat_sheet.md @@ -14,7 +14,7 @@ having an issue with GitLab, you may want to check your [support options](https: first, before attempting to use this information. WARNING: -If you are administering GitLab you are expected to know these commands for your distribution +If you administer GitLab you are expected to know these commands for your distribution of choice. If you are a GitLab Support Engineer, consider this a cross-reference to translate `yum` -> `apt-get` and the like. diff --git a/doc/administration/troubleshooting/ssl.md b/doc/administration/troubleshooting/ssl.md index 80be30a6509..01a4c4af65b 100644 --- a/doc/administration/troubleshooting/ssl.md +++ b/doc/administration/troubleshooting/ssl.md @@ -45,7 +45,7 @@ following issues: ``` - The error `SSL certificate problem: unable to get local issuer certificate` - is displayed when setting up a [mirror](../../user/project/repository/repository_mirroring.md#repository-mirroring) + is displayed when setting up a [mirror](../../user/project/repository/mirror/index.md) from this GitLab instance. - `openssl` works when specifying the path to the certificate: @@ -115,7 +115,7 @@ and the restart the runner by running `gitlab-runner restart`. ## Mirroring a remote GitLab repository that uses a self-signed SSL certificate -When configuring a local GitLab instance to [mirror a repository](../../user/project/repository/repository_mirroring.md) +When configuring a local GitLab instance to [mirror a repository](../../user/project/repository/mirror/index.md) from a remote GitLab instance that uses a self-signed certificate, you may see the `SSL certificate problem: self signed certificate` error message in the user interface. diff --git a/doc/administration/troubleshooting/tracing_correlation_id.md b/doc/administration/troubleshooting/tracing_correlation_id.md index 3518f52e6f6..3bafbed4b3f 100644 --- a/doc/administration/troubleshooting/tracing_correlation_id.md +++ b/doc/administration/troubleshooting/tracing_correlation_id.md @@ -135,3 +135,69 @@ You can use the [performance bar](../monitoring/performance/performance_bar.md) To view the data, the correlation ID of the request must match the same session as the user viewing the performance bar. For API requests, this means that you must perform the request using the session cookie of the signed-in user. + +For example, if you want to view the database queries executed for the following API endpoint: + +```shell +https://gitlab.com/api/v4/groups/2564205/projects?with_security_reports=true&page=1&per_page=1 +``` + +First, enable the **Developer Tools** panel. See [Getting the correlation ID in your browser](#getting-the-correlation-id-in-your-browser) for details on how to do this. + +After developer tools have been enabled, obtain a session cookie as follows: + +1. Visit <https://gitlab.com> while logged in. +1. (Optional) Select **Fetch/XHR** request filter in the **Developer Tools** panel. This step is described for Google Chrome developer tools and is not strictly necessary, it just makes it easier to find the correct request. +1. Select the `results?request_id=<some-request-id>` request on the left hand side. +1. The session cookie is displayed under the `Request Headers` section of the `Headers` panel. Right-click on the cookie value and select `Copy value`. + +![Obtaining a session cookie for request](img/obtaining-a-session-cookie-for-request_v14_3.png) + +You have the value of the session cookie copied to your clipboard, for example: + +```shell +experimentation_subject_id=<subject-id>; _gitlab_session=<session-id>; event_filter=all; visitor_id=<visitor-id>; perf_bar_enabled=true; sidebar_collapsed=true; diff_view=inline; sast_entry_point_dismissed=true; auto_devops_settings_dismissed=true; cf_clearance=<cf-clearance>; collapsed_gutter=false; frequently_used_emojis=clap,thumbsup,rofl,tada,eyes,bow +``` + +Use the value of the session cookie to craft an API request by pasting it into a custom header of a `curl` request: + +```shell +$ curl --include "https://gitlab.com/api/v4/groups/2564205/projects?with_security_reports=true&page=1&per_page=1" \ +--header 'cookie: experimentation_subject_id=<subject-id>; _gitlab_session=<session-id>; event_filter=all; visitor_id=<visitor-id>; perf_bar_enabled=true; sidebar_collapsed=true; diff_view=inline; sast_entry_point_dismissed=true; auto_devops_settings_dismissed=true; cf_clearance=<cf-clearance>; collapsed_gutter=false; frequently_used_emojis=clap,thumbsup,rofl,tada,eyes,bow' + + date: Tue, 28 Sep 2021 03:55:33 GMT + content-type: application/json + ... + x-request-id: 01FGN8P881GF2E5J91JYA338Y3 + ... + [ + { + "id":27497069, + "description":"Analyzer for images used on live K8S containers based on Starboard" + }, + "container_registry_image_prefix":"registry.gitlab.com/gitlab-org/security-products/analyzers/cluster-image-scanning", + "..." + ] +``` + +The response contains the data from the API endpoint, and a `correlation_id` value, returned in the `x-request-id` header, as described in the [Identify the correlation ID for a request](#identify-the-correlation-id-for-a-request) section. + +You can then view the database details for this request: + +1. Paste the `x-request-id` value into the `request details` field of the [performance bar](../monitoring/performance/performance_bar.md) and press <kbd>Enter/Return</kbd>. This example uses the `x-request-id` value `01FGN8P881GF2E5J91JYA338Y3`, returned by the above response: + + ![Paste request ID into progress bar](img/paste-request-id-into-progress-bar_v14_3.png) + +1. A new request is inserted into the `Request Selector` dropdown on the right-hand side of the Performance Bar. Select the new request to view the metrics of the API request: + + ![Select request ID from request selector drop down menu](img/select-request-id-from-request-selector-drop-down-menu_v14_3.png) + + <!-- vale gitlab.Substitutions = NO --> +1. Select the `pg` link in the Progress Bar to view the database queries executed by the API request: + + ![View pg database details](img/view-pg-details_v14_3.png) + <!-- vale gitlab.Substitutions = YES --> + + The database query dialog is displayed: + + ![Database query dialog](img/database-query-dialog_v14_3.png) |